Mailman 3 April 2005 - pypy-dev

Nonzero
by Armin Rigo 17 Apr '05

17 Apr '05

Hi Carl, (Reply to pypy-dev) On Sun, Apr 17, 2005 at 12:27:59AM +0200, Carl Friedrich Bolz wrote: > BTW: I think there's a problem in DescrOperation.is_true. If you have a > > class Monty: > def __nonzero__(self): > return self > > and you call bool(Monty()) you get an infinite recursion, since > DescrOperation.is_true calls space.is_true on the result of the __nonzero__ > method, which in turn calls DescrOperation.is_true again. CPython raises a > "TypeError, __nonzero__ should return an int". I didn't feel confident > enough to fix it myself. Yes, there are two ways to go about it: CPython raises a TypeError basically to avoid exactly this infinite recursion. But on other cases it lets the infinite recursion happen, but bound it, and you get a RuntimeError about the recursion limit. For PyPy, the general idea was to have a utility that looks through all loops of the function call graph of PyPy, and inserts infinite recursion detection calls automatically. In this way we can safely reproduce the CPython approach. Then your example would give a nice RuntimeError. Of course in this specific case we can also simply copy the TypeErroring behavior. What about doing so if and only if there is a test :-) Armin

1 0

Quick question
by Ben.Young＠risk.sungard.com 14 Apr '05

14 Apr '05

Just a quick question from an interested observer! Has the trivial object space completely died now? I can't find in the source, but the documentation specifically states that it won't be going away! Keep up the good work! Cheers, Ben

2 1

Re: [pypy-svn] r10600 - pypy/dist/pypy/translator/genc
by Armin Rigo 14 Apr '05

14 Apr '05

Hi Christian, On Thu, Apr 14, 2005 at 01:53:41AM +0200, tismer(a)codespeak.net wrote: > Modified: > pypy/dist/pypy/translator/genc/pyobj_include.h > Log: > OP_ABS was missing, targetpypy1 was not compiling! > How can this happen??? I changed the flow space to unify calls to built-in functions and operations when possible. For example, the annotator had to deal with both the 'type' operation and the 'type()' built-in doing the same thing. Now the flow objspace contains a list of built-ins that map to operations, and always produces the operation. That's why genc.h is now found to be incomplete: operations like 'abs' didn't use to turn up... I will just go over the full list of operations and make sure pyobj_include.h contains them. Armin

1 0

Deltareport Overview
by Eric van Riet Paap 13 Apr '05

13 Apr '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The last report at http://codespeak.net/pypy/rev/ is from 06-Apr-2005 02:20 Is the script no longer working or does it only add a new entry when the percentages change? - - Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCXVTdMcwuX5fyfyMRAkm+AJ4qysIqxnTgeeyav2ijuM5E8k/m3ACgjKel FZbYGVtylghvbDOsRWaV6+w= =Jor8 -----END PGP SIGNATURE-----

2 1

llvm ebuild for Gentoo available
by Eric van Riet Paap 12 Apr '05

12 Apr '05

Hello everybody, Not sure if anyone is using Gentoo Linux but if you do there is an ebuild available which makes installing llvm trivial. The other of the email is Valery Khamenya and the location is: http://bugs.gentoo.org/show_bug.cgi?id=88628 cheers Eric

2 1

(no subject)
by Eric van Riet Paap 12 Apr '05

12 Apr '05

That should read "The author of the email is Valery Khamenya" offcourse! E

1 0

Integer arithmetic
by Armin Rigo 12 Apr '05

12 Apr '05

Hi all, (IRC summary with Samuele and myself) We propose the following rules for how integer operations should behave in R-Python code: * operations on plain integers produce longs in CPython when they overflow, and wrap-around silently on platforms like C. In other words, they behave differently when run on top of Python or after translation. We cannot easily change that, but instead the following rule seems to be the sanest idea: in both cases, the only guarantee is that the last 32 (or 64) bits of the result are correct. If needed we must call a function, intmask(x), to ensure that we mask off the high bits on Python. intmask() is a no-op after translation to C. * unsigned arithmetic: the r_uint class is fine for that. It provides wrap-around unsigned arithmetic on top of Python, and for the translator it is a marker that unsigned ints should be generated. Warning, mixed operations r_uint+int produce r_uint results; be careful about unlimited propagation. Conversion: r_uint(x) for int-to-uint; intmask(x) for uint-to-int. * a new space.uint_w() turns a non-negative wrapped int or long into an r_uint. * overflow detection: only for signed arithmetic, and only explicitely using a macro-ish function ovfchecked(). It's only allowed to call it as ovfchecked(<variable> <operation> <variable>); no subexpressions. It means that this single operation is the one that is done with overflow checking. When running on top of Python, ovfchecked(x) just returns x unless it is too large, in which case you get an OverflowError. After translation, the two basic block operations "z = op(x,y)" and "simple_call(ovfchecked, z)" can be detected easily and turned into whatever the back-end does for overflow checking. (Additionally, hpk proposed a hack that checks the syntax of the ovfchecked() call when running on top of Python, to avoid problems with expressions like ovfchecked(x+y+z) where after translation only the last operation is checked.) * Christian's very nice r_int is on the way out... its main usage, in intobject.py, will be replaced by ovfchecked(). It's just more explicit and not really longer. It's also more in line with Python's evoluation which says that arithmetic operations don't raise OverflowErrors any more. Comments welcome! Armin

3 6

Re: [py-dev] Re: Error with py.test and scipy ...
by holger krekel 08 Apr '05

08 Apr '05

On Fri, Apr 08, 2005 at 01:33 +0200, Valentino Volonghi aka Dialtone wrote: > holger krekel wrote: > > >I would be surprised if my brand-new hack breaks yours (because that > >is exactly what it is trying to avoid) but i've learned that "import" > >makes the impossible possible and vice versa. > > > >cheers, > > > > > It was a quick fix in my case :). Everybody says that, see "piles of hacks" earlier :-) > It shouldn't be hard to figure out a common failing pattern in import > magic. for example: > nevow was failing because of namedAny that imports a module from a > string representing the entire path in PYTHONPATH. brain shaking already ... > from nevow import util > In [6]:util.namedAny('nevow.flat.ten') > Out[6]:<module 'nevow.flat.ten' from > '/Volumes/dati/Sviluppo/Nevow/nevow/flat/ten.pyc'> > > namedAny is this one: > > def namedAny(name): > """Get a fully named package, module, module-global object, or > attribute. > """ > names = name.split('.') > topLevelPackage = None > moduleNames = names[:] > while not topLevelPackage: > try: > trialname = '.'.join(moduleNames) > topLevelPackage = __import__(trialname) > except ImportError: > # if the ImportError happened in the module being imported, > # this is a failure that should be handed to our caller. > # count stack frames to tell the difference. > > # string-matching is another technique, but I think it could be > # fooled in some funny cases > #if sys.exc_info()[1] != "cannot import name %s" % trialname: > # raise > import traceback > if len(traceback.extract_tb(sys.exc_info()[2])) > 1: > raise > moduleNames.pop() > > obj = topLevelPackage > for n in names[1:]: > obj = getattr(obj, n) > > return obj > > But I can't remember exactly the failure. The ML is here to help > (something about the PYTHONPATH anyway). I have written similar code and there were always side cases that made it at least hard to debug and find the actual problem in the program. cheers, holger

1 1

help(1) OverflowError
by Sanghyeon Seo 07 Apr '05

07 Apr '05

With the current PyPy HEAD, help(1) results in OverflowError, after a long time. I just wanted to test whether pydoc works, but I didn't expect OverflowError... Traceback (application-level): File "<inline>help(1)", line 1 in ? File "/home/tinuviel/pypy/dist/lib-python-2.3.4/pydoc.py", line 47 in ? import sys, imp, os, re, types, inspect, __builtin__ File "/home/tinuviel/pypy/dist/lib-python-2.3.4/inspect.py", line 31 in ? import sys, os, types, string, re, dis, imp, tokenize, linecache File "/home/tinuviel/pypy/dist/lib-python-2.3.4/tokenize.py", line 100 in ? tokenprog, pseudoprog, single3prog, double3prog = map( File "/home/tinuviel/pypy/dist/lib-python-2.3.4/sre.py", line 179 in compile return _compile(pattern, flags) File "/home/tinuviel/pypy/dist/lib-python-2.3.4/sre.py", line 228 in _compile p = sre_compile.compile(pattern, flags) 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 Any idea?

5 4

Re: [pypy-svn] r10385 - in pypy/dist/pypy/translator/llvm: . test
by Armin Rigo 07 Apr '05

07 Apr '05

Hi Carl, On Thu, Apr 07, 2005 at 12:37:20AM +0200, cfbolz(a)codespeak.net wrote: > * The code generator tries to avoid creating empty blocks. There is already code in simplify.py that should remove empty blocks and perform other similar simplifications. I guess it needs to be called again after the annotator's "a.simplify()", which might remove some operations and thus make new blocks empty. Armin

1 0