[pypy-dev] help(1) OverflowError

[Samuele Pedroni]

holger krekel wrote:
> On Fri, Apr 01, 2005 at 10:48 +0100, Armin Rigo wrote:
> 
>>On Fri, Apr 01, 2005 at 03:56:34PM +0900, Sanghyeon Seo wrote:
>>
>>>  File "/home/tinuviel/pypy/dist/lib-python-2.3.4/sre_compile.py",
>>>line 488 in compile
>>>        groupindex, indexgroup
>>>OverflowError: long int too large to convert to int
>>
>>Actually, if you have a very fast machine, debugging with pdb in py.py works
>>fine.  It's related to Michael Chermside's module/_sre_pypy/ check-in.  The
>>bug is that _sre.compile() should accept as 3rd argument a list of unsigned
>>integers, but in the current implementation expects a list of signed integers
>>-- hence the OverflowError.
>>
>>Help!  What is the proper way to unwrap an unsigned integer?
> 
> 
> Hum, nobody seems to be able to answer this at the moment. 
> It probably relates to the fact that our usage of integers at 
> interpreter-level in general is fuzzy.  Or do we have a concise 
> explicit definition for their usage? 

one possible way to attack this issue is to write a snippet file of 
functions with arithmetic expressions that document the current patterns 
and how we want/already expect to do things like express unsigned 
numbers, unsigned arithmetic etc, overflow handling. This would help 
think the issues through, work as documentation of the idioms and enable 
to construct tests that check that the result running on top of CPython 
vs. after translation with or without annotation are what we expect and 
consistent up to expected type differences (for example a translated 
annotated snippet using r_uint may produce a long after doing internally 
unsigned arithmetic with r_uint erased by the translation and converting 
the result back to PyObject).

We probably already have some of this scattered around or that can be 
extracted from the tests of our restricted arith objects, but pursuing 
this constistently may be very valuable instead of waiting that some big 
piece of code will do the wrong thing and then we fix the problem after 
painful debugging. In this case this approach is probably easier than
with the annotator in general where some problems were hard to imagine 
before encountering them, but even in that case boiling things down to 
small examples has been very valuable so far.



> Anyway, apparently Samuele and me re-patched the trunk to not use 
> Michael Chermside's _sre_pypy implementation for the moment because 
> of this issue.  You can get back the previous behaviour (with the 
> help(1) problem) by uncommenting in baseobjspace.py the 
> line starting with ... self.setbuiltinmodule("_sre"
> at least on amd64 (which fails differently from a 32bit
> machine, sigh). 
> 
>     holger
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev