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 _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
_______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
