Mailman 3 October 2010 - pypy-dev

Building pypy on freebsd 64bit
by Shadrin Eugene 18 Nov '11

18 Nov '11

Hi! I tryed to build pypy on the freebsd, 64bit platform, but failed. First of all I downloaded a 32bit-Python to run pypy. And then: [user@server_name ~/pypy-trunk/pypy/translator/goal]$ ~/py32/bin/python translate.py -Ojit [translation:info] Translating target as defined by targetpypystandalone [platform:execute] gcc -m32 -c -O3 -pthread -fomit-frame-pointer /var/tmp/usession-trunk-22/gcctest.c -o /var/tmp/usession-trunk-22/gcctest.o [platform:WARNING] /var/tmp/usession-trunk-22/gcctest.c:28:2: warning: no newline at end of file [platform:execute] gcc -m32 /var/tmp/usession-trunk-22/gcctest.o -L/lib32 -L/usr/lib32 -L`pwd`/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32 -pthread -o /var/tmp/usession-trunk-22/gcctest printf("sizeof short=%ld\n", (long)sizeof(short)); printf("sizeof unsigned short=%ld\n", (long)sizeof(unsigned short)); printf("sizeof int=%ld\n", (long)sizeof(int)); printf("sizeof unsigned int=%ld\n", (long)sizeof(unsigned int)); printf("sizeof long=%ld\n", (long)sizeof(long)); printf("sizeof unsigned long=%ld\n", (long)sizeof(unsigned long)); printf("sizeof signed char=%ld\n", (long)sizeof(signed char)); printf("sizeof unsigned char=%ld\n", (long)sizeof(unsigned char)); printf("sizeof long long=%ld\n", (long)sizeof(long long)); printf("sizeof unsigned long long=%ld\n", (long)sizeof(unsigned long long)); printf("sizeof size_t=%ld\n", (long)sizeof(size_t)); printf("sizeof time_t=%ld\n", (long)sizeof(time_t)); printf("sizeof wchar_t=%ld\n", (long)sizeof(wchar_t)); printf("sizeof mode_t=%ld\n", (long)sizeof(mode_t)); printf("sizeof pid_t=%ld\n", (long)sizeof(pid_t)); sizeof short=2 sizeof unsigned short=2 sizeof int=4 sizeof unsigned int=4 sizeof long=8 sizeof unsigned long=8 sizeof signed char=1 sizeof unsigned char=1 sizeof long long=8 sizeof unsigned long long=8 sizeof size_t=8 sizeof time_t=8 sizeof wchar_t=4 sizeof mode_t=2 sizeof pid_t=4 Traceback (most recent call last): File "translate.py", line 300, in <module> main() File "translate.py", line 205, in main targetspec_dic, translateconfig, config, args = parse_options_and_load_target() File "translate.py", line 153, in parse_options_and_load_target targetspec_dic = load_target(targetspec) File "translate.py", line 105, in load_target mod = __import__(specname) File "targetpypystandalone.py", line 5, in <module> from pypy.objspace.std.objspace import StdObjSpace File "/place/home/hitrobot/pypy-trunk/pypy/objspace/std/__init__.py", line 1, in <module> from pypy.objspace.std.objspace import StdObjSpace File "/place/home/hitrobot/pypy-trunk/pypy/objspace/std/objspace.py", line 3, in <module> from pypy.interpreter import pyframe, function, special File "/place/home/hitrobot/pypy-trunk/pypy/interpreter/pyframe.py", line 13, in <module> from pypy.rlib import jit, rstack File "/place/home/hitrobot/pypy-trunk/pypy/rlib/rstack.py", line 10, in <module> from pypy.rpython.lltypesystem import rffi, lltype File "/place/home/hitrobot/pypy-trunk/pypy/rpython/lltypesystem/rffi.py", line 824, in <module> sys.maxint, sizeof(lltype.Signed))) AssertionError: Mixed configuration of the word size of the machine: the underlying Python was compiled with maxint=2147483647, but the C compiler says that 'long' is 8 bytes I got this error, then I added "-m32" flag to gcc argument list (in the posix.py source file) , but error occured again :( Does anybody tryed to build pypy-c on the 64bit FreeBsd? Thank you for your answer! -- Shadrin Eugene

5 7

Next sprint: Düsseldorf, end of October
by Armin Rigo 03 Nov '10

03 Nov '10

Hi all! Düsseldorf PyPy sprint October 25th-31st 2010 ===================================================== The next PyPy sprint will be held in the Computer Science department of Heinrich-Heine Universität Düsseldorf from the 25th to the 31st of October 2010. This is a fully public sprint, everyone is welcome to join us. Topics and goals ---------------- Open. (to be defined more precisely) Location -------- The sprint will take place in a seminar room of the computer science department. It is in the building 25.12 of the university campus. For travel instructions see http://stups.cs.uni-duesseldorf.de/anreise/esbahn.php Registration ------------ If you'd like to come, please subscribe to the `pypy-sprint mailing list`_ and drop a note about your interests and post any questions. More organisational information will be send to that list. We'll keep a list of `people`_ which we'll update (which you can do so yourself if you have codespeak commit rights). .. _`pypy-sprint mailing list`: http://codespeak.net/mailman/listinfo/pypy-sprint .. _`people`: http://codespeak.net/pypy/extradoc/sprintinfo/ddorf2010/people.txt

3 3

Re: [pypy-dev] PyPy JIT & C extensions
by Andrew Francis 25 Oct '10

25 Oct '10

Hi Folks: > --- On Thu, 9/30/10, Armin Rigo <arigo(a)tunes.org> > wrote: > > > From: Armin Rigo <arigo(a)tunes.org> > > Subject: Re: [pypy-dev] PyPy JIT & C extensions, > greenlet > > To: "Andrew Francis" <andrewfr_ice(a)yahoo.com> > > Cc: pypy-dev(a)codespeak.net > > Date: Thursday, September 30, 2010, 5:25 AM > > > > Maybe I should expand on an idea posted on #pypy by > > fijal. He mentioned that he would like to try to > support Stackless in PyPy without using the stackless transform, >>just by using the same low-level stack hacks that are done by greenlet.c > and optionally by Stackless Python. This means that there would be two > > different approaches we can consider to support > Stackless in PyPy: A few days ago, I floated this idea in the #pypy IRC channel. Why can't we take a JITed pypy, install the greenlet package, run it and see what happens? After all, greenlet is a C extension module. Hopefully this would provide a base line for work to be required? I am trying this but I am having a few hiccups getting setup.py to do the right thing. Since I am a newbie, I would like to know what is wrong with this line of reasoning? Cheers, Andrew

4 5

Re: [pypy-dev] [pypy-svn] r78267 - pypy/branch/arm-backend/pypy/jit/backend/arm/tools
by Maciej Fijalkowski 25 Oct '10

25 Oct '10

Hey. Can we make this directory 'tool' instead of 'tools' like every other tool directory? Cheers, fijal On Mon, Oct 25, 2010 at 4:45 PM, <david(a)codespeak.net> wrote: > Author: david > Date: Mon Oct 25 16:45:58 2010 > New Revision: 78267 > > Added: > pypy/branch/arm-backend/pypy/jit/backend/arm/tools/ > pypy/branch/arm-backend/pypy/jit/backend/arm/tools/objdump.py (contents, props changed) > Log: > Wrapper for calling objdump on dumped memory > > Added: pypy/branch/arm-backend/pypy/jit/backend/arm/tools/objdump.py > ============================================================================== > --- (empty file) > +++ pypy/branch/arm-backend/pypy/jit/backend/arm/tools/objdump.py Mon Oct 25 16:45:58 2010 > @@ -0,0 +1,5 @@ > +#!/usr/bin/env python > +import os > +import sys > + > +os.system('objdump -D --architecture=arm --target=binary %s' % sys.argv[1]) > _______________________________________________ > pypy-svn mailing list > pypy-svn(a)codespeak.net > http://codespeak.net/mailman/listinfo/pypy-svn >

1 0

Re: [pypy-dev] [pypy-svn] r77933 - pypy/branch/jitffi/pypy/jit/metainterp/test
by Maciej Fijalkowski 17 Oct '10

17 Oct '10

The exception still can't happen though. On Thu, Oct 14, 2010 at 3:32 PM, <antocuni(a)codespeak.net> wrote: > Author: antocuni > Date: Thu Oct 14 15:32:22 2010 > New Revision: 77933 > > Modified: > pypy/branch/jitffi/pypy/jit/metainterp/test/test_optimizefficall.py > Log: > update this test too > > > Modified: pypy/branch/jitffi/pypy/jit/metainterp/test/test_optimizefficall.py > ============================================================================== > --- pypy/branch/jitffi/pypy/jit/metainterp/test/test_optimizefficall.py (original) > +++ pypy/branch/jitffi/pypy/jit/metainterp/test/test_optimizefficall.py Thu Oct 14 15:32:22 2010 > @@ -77,7 +77,9 @@ > call(0, p2, descr=libffi_prepare) > call(0, p2, i0, descr=libffi_push_arg) > call(0, p2, f1, descr=libffi_push_arg) > - i3 = call(0, p2, 12345, descr=libffi_call) > + i3 = call_may_force(0, p2, 12345, descr=libffi_call) > + guard_not_forced() [] > + guard_no_exception() [] > jump(i3, f1, p2) > """ > expected = ops > _______________________________________________ > pypy-svn mailing list > pypy-svn(a)codespeak.net > http://codespeak.net/mailman/listinfo/pypy-svn >

1 0

issue tracker spam issues / switching
by holger krekel 11 Oct '10

11 Oct '10

Hi all, seems like the pypy-dev issue tracker got some spam through bot-registered users. Unless i am mistaken there is no easy way to add a captcha in addition to the e-mail confirmation registration and so i made the default role for new issue tracker users "anonymous". This means new users need to find an admin who assigns the role "User". Admins on the trackers are e.g. Armin, Maciej, Anto, Amaury, myself and probably others. Not a great solution, i know. It doesn't affect any of the existing users, though. it's probably a good occassion to push for switching to using new issue tracker software especially since there has been other complaints as well. best, holger

2 1

ssl cert expired / OS X download doesn't work
by Brian Slesinsky 07 Oct '10

07 Oct '10

Hi, I tried running pypy 1.3 on OS X but ran into a few issues: First, I got this error: $ pypy dyld: Library not loaded: /usr/lib/libssl.0.9.8.dylib Referenced from: /usr/local/pypy-1.3/bin/pypy Reason: image not found Trace/BPT trap It looks like my machine (running OS X 10.5.8) has libssl.0.9.7.dylib, but not libssl.0.9.8. (I suppose I could recompile from source, but don't feel like waiting an hour.) Also, the SSL certificate has expired for https://codespeak.net, which is why I didn't post there. Anyway, please keep up the good work. - Brian

2 1

Re: [pypy-dev] PyPy JIT & C extensions, greenlet
by Andrew Francis 05 Oct '10

05 Oct '10

Hi Armin and folks: --- On Thu, 9/30/10, Armin Rigo <arigo(a)tunes.org> wrote: > From: Armin Rigo <arigo(a)tunes.org> > Subject: Re: [pypy-dev] PyPy JIT & C extensions, greenlet > To: "Andrew Francis" <andrewfr_ice(a)yahoo.com> > Cc: pypy-dev(a)codespeak.net > Date: Thursday, September 30, 2010, 5:25 AM > Maybe I should expand on an idea posted on #pypy by > fijal. He mentioned that he would like to try to support Stackless in > PyPy without using the stackless transform, just by using the > same low-level stack hacks that are done by greenlet.c and > optionally by Stackless Python. This means that there would be two > different approaches we can consider to support Stackless in PyPy: That sounds like a neat idea! > tasklet-switching Python code tasklet-switching Python code > becomes a single loop in becomes N loops with residual calls > to machine code Maybe this is the core of my problems (and ability to help) - I have a superficial understanding of how Stackless works under the hood. Where do the N loops come from? I have read Christian's "Stackless Python" paper (http://www.python.org/workshops/2000-01/proceedings/papers/tismers/stackles…) and slowly but surely I do more stuff with the C Stackless code base. That said, I haven't found any particularly good papers on how the Python interpreter itself is architected. Maybe I should look at how the greenlet package works. Again, I would be happy to help but I am not quite sure where to start so at least I can ask intelligent questions in the pypy IRC. Cheers, Andrew

1 0

Re: [pypy-dev] [pypy-svn] r77589 - pypy/trunk/pypy/jit/metainterp
by Antonio Cuni 05 Oct '10

05 Oct '10

On 04/10/10 23:32, fijal(a)codespeak.net wrote: > def transform(op): > from pypy.jit.metainterp.history import AbstractDescr > - # Rename CALL_PURE to CALL. > + # Rename CALL_PURE and CALL_INVARIANT to CALL. > # Simplify the VIRTUAL_REF_* so that they don't show up in the backend. > - if op.getopnum() == rop.CALL_PURE: > + if (op.getopnum() == rop.CALL_PURE or > + op.getopnum() == rop.CALL_LOOPINVARIANT): > op = ResOperation(rop.CALL, op.getarglist()[1:], op.result, > op.getdescr()) > elif op.getopnum() == rop.VIRTUAL_REF: Hi, I just wanted to tell that since the resoperation-refactoring, there is now a nice "copy_and_change" method to be used exactly for the case where you want to replace an operation with a "similar" one. So, the code above should be written like: op = op.copy_and_change(rop.CALL, args=op.getarglist()[1:]) ciao, Anto

2 1

Re: [pypy-dev] Question on the future of RPython
by Paolo Giarrusso 01 Oct '10

01 Oct '10

On Thu, Sep 30, 2010 at 03:21, Terrence Cole <list-sink(a)trainedmonkeystudios.org> wrote: > On Wed, 2010-09-29 at 23:50 +0200, Paolo Giarrusso wrote: > I think it makes sense to treat the sorts of optimizations you can do > with static analysis of a dynamic language with the same sort of guarded > optimism that is used in pypy's jit compiler: run with the assumption > that it will all work out, but watch for failure and fallback to a safe > slow-path nicely when things go off the rails. Agreed, but "watch out for failure" is done by guards, and one of the further advantages of type inference, on top of "type feedback", described there, is being able to remove some of those guards, because that might help in some inner loops. In some cases, that's still possible, by "watching out" not during code execution but during execution of infrequent events. In Java loading a class might invalidate some optimization assumptions (like "this class has no subclass", useful for inlining without guards), but that's checked by the classloading fast-path. Same things could apply to allow Python cross-module type-inferencing. I don't know exactly how modules at JIT compile-time and runtime can be different, but I guess that invalidation at module loading should catch that. And invalidate lots of compiled code, which is usually fine. The interaction of this with tracing is actually interesting: in a Python tracing JIT, you could keep the traces and restore omitted guards, but when your JIT traces the Python interpreter, I wonder how do you express any of this. One can insert a guard only if needed, but telling "hey, this is invalid" requires some special API. My proposal, here, would be a "virtual guard", which is recorded in the guard but omitted from the output. The "omission" is what can be invalidated, but the trace itself (not its compiled version) is kept (because it can still be executed). If some form of this makes actually sense (I've just thought on it 5 minutes), this is something worth publishing, which would allow me to take some time of my PhD to work on it - if it's not already done by papers on tracing JITs. -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/

3 4

pypy-dev October 2010