[pypy-dev] help(1) OverflowError
pedronis at strakt.com
Thu Apr 7 22:26:46 CEST 2005
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).
> pypy-dev at codespeak.net
More information about the Pypy-dev