From con at samuelreis.de Mon Nov 2 23:47:27 2009 From: con at samuelreis.de (Samuel Reis) Date: Mon, 02 Nov 2009 23:47:27 +0100 Subject: [pypy-dev] Hello PyPy Developer Team Message-ID: <4AEF617F.6030502@samuelreis.de> Hello everybody, My name is Samuel Reis and I'm a 17-year-old student from Hanover, Germany. First of all, I'm very sorry for my English. It's not that I think I write English _that_ worse, but I don't know what kind of impression I make with that. Anyway ... I found this project a few months ago while I was looking for alternative python interpreters. Since then I found it really interested reading blog posts, sprint reports, etc. and watching this project's progress. Meanwhile it has to be the whole site that I already read, I think ;). I would call myself a (not so advanced) advanced programmer :) in C, as I do that since a few years (besides some ugly BASIC-Dialects - not that C is beautiful since I met python). Not to forget obj-orientated PHP, which was my entry point to scripting languages and still is the majority of code I write - both private and at work. To the Python language I'm a freshman (a few months, as said), but although I have to look up 60-70% of the functions in the manual, I know and understand the python language structure very well. The concept of defining python in python itself fascinates me, and also how this concept developed and now involves the possibility to create interpreter code for (in theory) every computer language/environment (if I understood that right). Contributing to this project would make me very happy, so I would be glad if there were some/more minor things to do for me as a beginner. Oh, yeah, and not to forget: I've created a small piece of artwork related to pypy. I don't know if it has any use for you, but just for the sharings sake, I'll share it with you. http://samuelreis.de/artwork/pypy/pypy_fin.jpg http://samuelreis.de/artwork/pypy/pypy_fin.svg The logo art is inspired of an ancient symbol called "Ouroboros", "depicting a serpent or dragon swallowing its own tail and forming a circle." (en.wikipedia.org) I think this nicely symbolizes the recursivity of writing a python interpreter in python itself. This is licensed under the CC BY-SA Germany license. (http://creativecommons.org/licenses/by-sa/3.0/de/deed.en) I'll be very happy with your feedback :) Regards -- Samuel From ludovico.cavedon at gmail.com Tue Nov 3 03:02:52 2009 From: ludovico.cavedon at gmail.com (Ludovico Cavedon) Date: Mon, 02 Nov 2009 18:02:52 -0800 Subject: [pypy-dev] pypy jit error Message-ID: <4AEF8F4C.40301@gmail.com> Hi all, I am trying to run pypy with the jit compiler. I want to report some code I have that is failing, while with CPython it is not. I was able to isolate the the problem in a small testcase I am attaching. It is failing after exactly 1000 next() calls to the generator created by b(). File "pypyfail.py", line 6, in b b= (vv[i] for i in [0]) TypeError: object , file 'pypyfail.py', line 6> is not callable I built the latest SVN trunk snapshot of pypy with pypy/translator/goal/translate.py -Ojit Btw, the executable is called "pypy-c" rather than "pypy-c-jit", is that ok? Thank you in advance, Ludovico -------------- next part -------------- A non-text attachment was scrubbed... Name: pypyfail.py Type: text/x-python Size: 140 bytes Desc: not available URL: From vincent.legoll at gmail.com Tue Nov 3 09:50:14 2009 From: vincent.legoll at gmail.com (Vincent Legoll) Date: Tue, 3 Nov 2009 09:50:14 +0100 Subject: [pypy-dev] pypy jit error In-Reply-To: <4AEF8F4C.40301@gmail.com> References: <4AEF8F4C.40301@gmail.com> Message-ID: <4727185d0911030050w3271eda7j37ec87b89dac6bae@mail.gmail.com> Hi, Is it still failing with the b function renamed c for example ? -- Vincent Legoll From ludovico.cavedon at gmail.com Tue Nov 3 09:56:34 2009 From: ludovico.cavedon at gmail.com (Ludovico Cavedon) Date: Tue, 03 Nov 2009 00:56:34 -0800 Subject: [pypy-dev] pypy jit error In-Reply-To: <4727185d0911030050w3271eda7j37ec87b89dac6bae@mail.gmail.com> References: <4AEF8F4C.40301@gmail.com> <4727185d0911030050w3271eda7j37ec87b89dac6bae@mail.gmail.com> Message-ID: <4AEFF042.3060206@gmail.com> Vincent Legoll wrote: > Is it still failing with the b function renamed c for example ? Ups, I used "b" twice :) Yes, it is failing also with b() renamed to c() Thanks, Ludovico From arigo at tunes.org Wed Nov 4 23:58:19 2009 From: arigo at tunes.org (Armin Rigo) Date: Wed, 4 Nov 2009 23:58:19 +0100 Subject: [pypy-dev] Hello PyPy Developer Team In-Reply-To: <4AEF617F.6030502@samuelreis.de> References: <4AEF617F.6030502@samuelreis.de> Message-ID: <20091104225819.GA19783@code0.codespeak.net> Hi Samuel, This is just a quick answer to let you know that we are actually sprinting in D?sseldorf for one week, since this Friday (6-13 Nov). As it is not that far from Hanover, maybe you are interested in joining us? Even if it's just one day or just the weekend, you are welcome to. A bientot, Armin From fijall at gmail.com Thu Nov 5 00:08:30 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Thu, 5 Nov 2009 00:08:30 +0100 Subject: [pypy-dev] pypy jit error In-Reply-To: <4AEFF042.3060206@gmail.com> References: <4AEF8F4C.40301@gmail.com> <4727185d0911030050w3271eda7j37ec87b89dac6bae@mail.gmail.com> <4AEFF042.3060206@gmail.com> Message-ID: <693bc9ab0911041508laceca55y1bc8d37c9e30a271@mail.gmail.com> Hey. Thanks for the report. I think this is a dup of issue which I have been fighting recently, seems to work for me right now. Cheers, fijal On Tue, Nov 3, 2009 at 9:56 AM, Ludovico Cavedon wrote: > Vincent Legoll wrote: >> Is it still failing with the b function renamed c for example ? > > Ups, I used "b" twice :) > > Yes, it is failing also with b() renamed to c() > > Thanks, > Ludovico > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > From con at samuelreis.de Thu Nov 5 10:03:25 2009 From: con at samuelreis.de (Samuel Reis) Date: Thu, 05 Nov 2009 10:03:25 +0100 Subject: [pypy-dev] Hello PyPy Developer Team In-Reply-To: <20091104225819.GA19783@code0.codespeak.net> References: <4AEF617F.6030502@samuelreis.de> <20091104225819.GA19783@code0.codespeak.net> Message-ID: <4AF294DD.1050702@samuelreis.de> Am 04.11.09 23:58, schrieb Armin Rigo: > Hi Samuel, > > This is just a quick answer to let you know that we are actually > sprinting in D?sseldorf for one week, since this Friday (6-13 Nov). As > it is not that far from Hanover, maybe you are interested in joining us? > Even if it's just one day or just the weekend, you are welcome to. > > > A bientot, > > Armin > Hello Armin, Sounds good, but unfortunately I'm extremely busy on both weekends. But of course I'll look forward to join you on future sprints, if held in the north of germany, because I'll have to see how to self-finance travelling and accommodation. Regards - Samuel From arigo at tunes.org Thu Nov 5 10:36:05 2009 From: arigo at tunes.org (Armin Rigo) Date: Thu, 5 Nov 2009 10:36:05 +0100 Subject: [pypy-dev] Problem with pypy-c and stacklesssocket.py In-Reply-To: <462481.61824.qm@web112404.mail.gq1.yahoo.com> References: <462481.61824.qm@web112404.mail.gq1.yahoo.com> Message-ID: <20091105093605.GA686@code0.codespeak.net> Hi Andrew, On Fri, Oct 30, 2009 at 10:36:54AM -0700, Andrew Francis wrote: > File "/home/andrew/lab/pypy-dist/lib-python/2.5.2/asyncore.py", line 109, in poll > is_r = obj.readable() > ReferenceError: weakly referenced object no longer exists I am afraid that you will not get much answers, mostly because we are not into developing or supporting the Stackless modules right now. However the problem does not seem Stackless-oriented, but just a misuse of reference counting. You get obviously a weak proxy object, so the question is who made it and why, and why does it make a difference between CPython and PyPy. Remember that as we don't have reference counting, weak references can disappear at times that look a bit more "random" in PyPy than in CPython. I can only imagine that it's this kind of abuse of reference counting that hits you with PyPy (or Jython or IronPython fwiw). A bientot, Armin. From micahel at gmail.com Thu Nov 5 10:44:09 2009 From: micahel at gmail.com (Michael Hudson-Doyle) Date: Thu, 5 Nov 2009 22:44:09 +1300 Subject: [pypy-dev] Advice for a talk... In-Reply-To: <20090930084647.GB17579@code0.codespeak.net> References: <693bc9ab0909270019l78af72d7od2df0f0e2c395f02@mail.gmail.com> <20090930084647.GB17579@code0.codespeak.net> Message-ID: So I've finally got around to lightly updating my talk; you can see my latest version at: http://people.canonical.com/~mwh/pypy-kiwipycon09.pdf Any comments you have would be appreciated but as I'm travelling to the conference tomorrow I'm not going to have very long to act on them :-) (all my own fault of course). Cheers, mwh 2009/9/30 Armin Rigo : > Hi Michael, From anto.cuni at gmail.com Thu Nov 5 11:14:05 2009 From: anto.cuni at gmail.com (Antonio Cuni) Date: Thu, 05 Nov 2009 11:14:05 +0100 Subject: [pypy-dev] Advice for a talk... In-Reply-To: References: <693bc9ab0909270019l78af72d7od2df0f0e2c395f02@mail.gmail.com> <20090930084647.GB17579@code0.codespeak.net> Message-ID: <4AF2A56D.5040804@gmail.com> Michael Hudson-Doyle wrote: > So I've finally got around to lightly updating my talk; you can see my > latest version at: > > http://people.canonical.com/~mwh/pypy-kiwipycon09.pdf > > Any comments you have would be appreciated but as I'm travelling to > the conference tomorrow I'm not going to have very long to act on them > :-) (all my own fault of course). I don't think that V8 implements a tracing JIT, but just a "standard" JIT with polymorphic inline caches and "hidden classes" (i.e., the equivalent of SELF's map or pypy sharing dicts). ciao, Anto From ludovico.cavedon at gmail.com Sun Nov 8 06:37:59 2009 From: ludovico.cavedon at gmail.com (Ludovico Cavedon) Date: Sat, 07 Nov 2009 21:37:59 -0800 Subject: [pypy-dev] pypy jit error In-Reply-To: <693bc9ab0911041508laceca55y1bc8d37c9e30a271@mail.gmail.com> References: <4AEF8F4C.40301@gmail.com> <4727185d0911030050w3271eda7j37ec87b89dac6bae@mail.gmail.com> <4AEFF042.3060206@gmail.com> <693bc9ab0911041508laceca55y1bc8d37c9e30a271@mail.gmail.com> Message-ID: <4AF65937.5050509@gmail.com> Maciej Fijalkowski wrote: > Thanks for the report. I think this is a dup of issue which I have > been fighting recently, seems to work for me right now. The latest trunk fixed it also for me, thanks! Ludovico From jacob at openend.se Sun Nov 8 14:52:39 2009 From: jacob at openend.se (Jacob =?utf-8?q?Hall=C3=A9n?=) Date: Sun, 8 Nov 2009 14:52:39 +0100 Subject: [pypy-dev] Interesting reading for people generating assembler code Message-ID: <200911081452.40466.jacob@openend.se> I think this presentation contains some interesting tidbits and insights that may be of use to people doing machine code generation - perhaps both in the JIT and in the translation end of things. http://www.linux- kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf Jacob From andrewfr_ice at yahoo.com Tue Nov 10 17:53:30 2009 From: andrewfr_ice at yahoo.com (Andrew Francis) Date: Tue, 10 Nov 2009 08:53:30 -0800 (PST) Subject: [pypy-dev] Update Re: Problem with pypy-c and stacklesssocket.py In-Reply-To: <20091105093605.GA686@code0.codespeak.net> Message-ID: <351842.45656.qm@web112404.mail.gq1.yahoo.com> Hi Armin: --- On Thu, 11/5/09, Armin Rigo wrote: > From: Armin Rigo > I am afraid that you will not get much answers, mostly > because we are not into developing or supporting the Stackless >modules right now. Fair enough. > However the problem does not seem Stackless-oriented, but just a misuse >of reference counting.? You get obviously a weak proxy object, so the > question is who made it and why, and why does it make a difference > between CPython and PyPy.? Remember that as we don't have reference >counting, weak references can disappear at times that look a bit more >"random" in PyPy than in CPython.? I can only imagine that it's this >kind of abuse of reference counting that hits you with PyPy (or Jython >or IronPython fwiw). Thanks for the response. I removed the weakrefs from stacklesssocket. The echoserver no longer crashes. However my driver still reports errors (about 25% of the connections fail, as opposed to about 60% and a server crash). At this stage, when I have time, I will put more debugging in stacklesssocket.py (or asyncore.py) and my driver to get more information about what is happening. Cheers, Andrew From victorw at MIT.EDU Wed Nov 11 17:06:29 2009 From: victorw at MIT.EDU (Victor Williamson) Date: Wed, 11 Nov 2009 11:06:29 -0500 Subject: [pypy-dev] New - untrusted code Message-ID: <1257955589.11922.42.camel@victorw-laptop> Hello Pypy dev, I am researching ways to allow applications to safely import untrusted code in Python without having to run the malicious code in its own process; Pypy may be a good prototyping environment. I want to verify if any work either as an extension or as interpreter changes has been done to handle untrusted imports in Pypy. Thanks and best regards, Victor From maciejdziardziel at wp.pl Wed Nov 11 18:07:47 2009 From: maciejdziardziel at wp.pl (Fiedzia) Date: Wed, 11 Nov 2009 18:07:47 +0100 Subject: [pypy-dev] pypy.objspace.std.model.UnwrapError in socket.epoll.register Message-ID: Out of curiosity i tried to use pypy to run diesel (http://dieselweb.org/lib/). For some reason pypy in trunk doesn't add OutputType property in cStringIO (perhaps it needs some installation or postprocessing because this property is mentioned in cStringIO pypy module). After setting it manually at the beginning of diesel helloworld example, i can see long traceback that ends with: File "/home/fiedzia/soft/pypy/trunk/pypy/objspace/std/fake.py", line 141, in funcrun frame.setfastscope(scope_w) File "/home/fiedzia/soft/pypy/trunk/pypy/objspace/std/fake.py", line 162, in setfastscope raise UnwrapError('calling %s: %s' % (code.cpy_callable, e)) pypy.objspace.std.model.UnwrapError: calling : cannot unwrap > using select.epoll from pypy console seems to work, but obviously diesel pushes it to the limits. Is there something that i can try to make it working or do i hit something unsupported by pypy? -- Thanks Maciej Dziardziel From holger at merlinux.eu Wed Nov 11 18:17:06 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 11 Nov 2009 18:17:06 +0100 Subject: [pypy-dev] New - untrusted code In-Reply-To: <1257955589.11922.42.camel@victorw-laptop> References: <1257955589.11922.42.camel@victorw-laptop> Message-ID: <20091111171706.GH17999@trillke.net> Hello Victor, On Wed, Nov 11, 2009 at 11:06 -0500, Victor Williamson wrote: > Hello Pypy dev, > > I am researching ways to allow applications to safely import untrusted > code in Python without having to run the malicious code in its own > process; Pypy may be a good prototyping environment. I want to > verify if any work either as an extension or as interpreter changes has > been done to handle untrusted imports in Pypy. cool. Have you read http://codespeak.net/pypy/dist/pypy/doc/sandbox.html ? I don't know about projects using PyPy's sandboxing currently. The raw functionality is very powerful but work on deployment and usage is due. During the ongoing Duesseldorf sprint we discussed about a new model to use transparent proxying techniques (http://tinyurl.com/mrq9nc ) to perform imports through a "interpreter backend" subprocess, e.g. CPython, Jython, IPy. In this mode a Sandboxed PyPy could run native applications and represent remote python objects transparently. As a starting point we discussed running QT applications from PyPy in this manner. I am interested to work on related topics. In particular i plan to work on http://codespeak.net/execnet in the upcoming weeks in order to make ad-hoc configuration and deployment of Python interpreters a breeze (also for cross-interpreter testing). Always interested in peers :) cheers, holger From cfbolz at gmx.de Wed Nov 11 18:22:23 2009 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Wed, 11 Nov 2009 18:22:23 +0100 Subject: [pypy-dev] pypy.objspace.std.model.UnwrapError in socket.epoll.register In-Reply-To: References: Message-ID: <4AFAF2CF.60601@gmx.de> On 11/11/2009 06:07 PM, Fiedzia wrote: > Out of curiosity i tried to use pypy to run diesel > (http://dieselweb.org/lib/). > > For some reason pypy in trunk doesn't add OutputType property in cStringIO > (perhaps it needs some installation or postprocessing because this property > is mentioned in cStringIO pypy module). After setting it manually at the > beginning of diesel helloworld example, i can see long traceback that ends > with: > > File "/home/fiedzia/soft/pypy/trunk/pypy/objspace/std/fake.py", line 141, > in funcrun > frame.setfastscope(scope_w) > File "/home/fiedzia/soft/pypy/trunk/pypy/objspace/std/fake.py", line 162, > in setfastscope > raise UnwrapError('calling %s: %s' % (code.cpy_callable, e)) > pypy.objspace.std.model.UnwrapError: calling 'select.epoll' objects>: cannot unwrap instance of > > > using select.epoll from pypy console seems to work, but obviously diesel > pushes it to the limits. Is there something that i can try to make it > working or do i hit something unsupported by pypy? > Try to either use a compiled pypy (which would be significantly faster anyway) or start your py.py with the option --allworkingmodules Cheers, Carl Friedrich From trottier at gmail.com Thu Nov 19 02:14:31 2009 From: trottier at gmail.com (Leo Trottier) Date: Wed, 18 Nov 2009 17:14:31 -0800 Subject: [pypy-dev] pypy-c-jit compilation error Message-ID: ... perhaps this has been resolved (??) but two compilation attempts on the pypy/trunk from earlier today failed with the following error message. I'm compiling on a VirtualBox install of Xubuntu on OS-X (2 gig allocated, dual-core 1 GHz cpu). the pypy-dist version compiles fine ... and/all guidance would be appreciated ========================== [platform:ERROR] make: Entering directory `/tmp/usession-trunk-1/testing_1' [platform:ERROR] gcc -O3 -pthread -fomit-frame-pointer -frandom-seed=testing_1.c -o testing_1.s -S testing_1.c -I/usr/include/python2.6 -I/home/leo/Source Code/pypy-trunk/pypy/translator/c -I/usr/include/libffi [platform:ERROR] make: Leaving directory `/tmp/usession-trunk-1/testing_1' [Timer] Timings: [Timer] annotate --- 623.8 s [Timer] rtype_lltype --- 768.0 s [Timer] pyjitpl_lltype --- 570.6 s [Timer] backendopt_lltype --- 359.7 s [Timer] stackcheckinsertion_lltype --- 118.4 s [Timer] database_c --- 789.6 s [Timer] source_c --- 927.0 s [Timer] compile_c --- 2.5 s [Timer] =========================================== [Timer] Total: --- 4159.4 s [translation:ERROR] Error: [translation:ERROR] Traceback (most recent call last): [translation:ERROR] File "translate.py", line 277, in main [translation:ERROR] drv.proceed(goals) [translation:ERROR] File "/home/leo/Source Code/pypy-trunk/pypy/translator/driver.py", line 741, in proceed [translation:ERROR] return self._execute(goals, task_skip = self._maybe_skip()) [translation:ERROR] File "/home/leo/Source Code/pypy-trunk/pypy/translator/tool/taskengine.py", line 116, in _execute [translation:ERROR] res = self._do(goal, taskcallable, *args, **kwds) [translation:ERROR] File "/home/leo/Source Code/pypy-trunk/pypy/translator/driver.py", line 279, in _do [translation:ERROR] res = func() [translation:ERROR] File "/home/leo/Source Code/pypy-trunk/pypy/translator/driver.py", line 504, in task_compile_c [translation:ERROR] cbuilder.compile() [translation:ERROR] File "/home/leo/Source Code/pypy-trunk/pypy/translator/c/genc.py", line 447, in compile [translation:ERROR] self.translator.platform.execute_makefile(self.targetdir) [translation:ERROR] File "/home/leo/Source Code/pypy-trunk/pypy/translator/platform/posix.py", line 114, in execute_makefile [translation:ERROR] self._handle_error(returncode, stdout, stderr, path.join('make')) [translation:ERROR] File "/home/leo/Source Code/pypy-trunk/pypy/translator/platform/__init__.py", line 117, in _handle_error [translation:ERROR] raise CompilationError(stdout, stderr) [translation:ERROR] CompilationError: From amauryfa at gmail.com Thu Nov 19 09:43:36 2009 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Thu, 19 Nov 2009 09:43:36 +0100 Subject: [pypy-dev] pypy-c-jit compilation error In-Reply-To: References: Message-ID: Hi, 2009/11/19 Leo Trottier : > ... perhaps this has been resolved (??) but two compilation attempts > on the pypy/trunk from earlier today failed with the following error > message. ?I'm compiling on a VirtualBox install of Xubuntu on OS-X (2 > gig allocated, dual-core 1 GHz cpu). > > the pypy-dist version compiles fine ... > > and/all guidance would be appreciated Could you try the compilation step manually: cd /tmp/usession-trunk-1/testing_1 make and report the error you see there? -- Amaury Forgeot d'Arc From trottier at gmail.com Thu Nov 19 13:00:07 2009 From: trottier at gmail.com (Leo Trottier) Date: Thu, 19 Nov 2009 04:00:07 -0800 Subject: [pypy-dev] pypy-c-jit compilation error In-Reply-To: <3A7C2110-F1D6-469B-8D42-0881B2F3CDD6@gmail.com> References: <965F4B8F-592A-4B0C-BFF7-A5DB064D5D00@gmail.com> <3A7C2110-F1D6-469B-8D42-0881B2F3CDD6@gmail.com> Message-ID: [apologies for the spam, but people seem interested] On Snow Leopard, after adding the -m32 flags recommended by Leonardo, it got all the way to compilation, and then failed. I had tried to do a c-jit compile over the latest trunk using 32bit python. Here is the full run log: http://paste.pocoo.org/show/151639/ Leo On Wed, Nov 18, 2009 at 7:16 PM, Leonardo wrote: > There is still no backend for x86_64 but you can compile it with the jit in > 32 bit mode. For this you have to make your cpython go to 32bit mode (search > for it on the web, it is different if it is the standard python, the > python.org dmg or the macports one) and apply this patch: > > http://paste.pocoo.org/show/151604/ > > but it is way faster than compiling on a virtual machine. > > I want to work more on this patch and make it force the -m flag (based on > the arch of the python interpreter) to the compiler so it properly works on > snow leopard (that can run both 32 and 64 bit programs independent of kernel > arch). > > If you do please tell me how it went please :) > > On Nov 19, 2009, at 1:01 AM, Leo wrote: > > > I meant to say, is the JIT working in Snow Leopard in 64 bit? > > > > Leo > > > > On Wed, Nov 18, 2009 at 7:00 PM, Leo Trottier > wrote: > >> Is the working in Snow Leopard in 64 bit? It seemed there were > >> intractable errors in this regard earlier? > >> > >> Leo > >> > >> On Wed, Nov 18, 2009 at 6:40 PM, Leonardo wrote: > >>> Why don't you compile it on osx? most things should be working on osx > now. > >>> > >>> On Nov 18, 2009, at 11:14 PM, Leo wrote: > >>> > >>>> ... perhaps this has been resolved (??) but two compilation attempts > >>>> on the pypy/trunk from earlier today failed with the following error > >>>> message. I'm compiling on a VirtualBox install of Xubuntu on OS-X (2 > >>>> gig allocated, dual-core 1 GHz cpu). > >>>> > >>>> the pypy-dist version compiles fine ... > >>>> > >>>> and/all guidance would be appreciated > >>>> ========================== > >>>> > >>>> [platform:ERROR] make: Entering directory > `/tmp/usession-trunk-1/testing_1' > >>>> [platform:ERROR] gcc -O3 -pthread -fomit-frame-pointer > >>>> -frandom-seed=testing_1.c -o testing_1.s -S testing_1.c > >>>> -I/usr/include/python2.6 -I/home/leo/Source > >>>> Code/pypy-trunk/pypy/translator/c -I/usr/include/libffi > >>>> [platform:ERROR] make: Leaving directory > `/tmp/usession-trunk-1/testing_1' > >>>> [Timer] Timings: > >>>> [Timer] annotate --- 623.8 s > >>>> [Timer] rtype_lltype --- 768.0 s > >>>> [Timer] pyjitpl_lltype --- 570.6 s > >>>> [Timer] backendopt_lltype --- 359.7 s > >>>> [Timer] stackcheckinsertion_lltype --- 118.4 s > >>>> [Timer] database_c --- 789.6 s > >>>> [Timer] source_c --- 927.0 s > >>>> [Timer] compile_c --- 2.5 s > >>>> [Timer] =========================================== > >>>> [Timer] Total: --- 4159.4 s > >>>> [translation:ERROR] Error: > >>>> [translation:ERROR] Traceback (most recent call last): > >>>> [translation:ERROR] File "translate.py", line 277, in main > >>>> [translation:ERROR] drv.proceed(goals) > >>>> [translation:ERROR] File "/home/leo/Source > >>>> Code/pypy-trunk/pypy/translator/driver.py", line 741, in proceed > >>>> [translation:ERROR] return self._execute(goals, task_skip = > >>>> self._maybe_skip()) > >>>> [translation:ERROR] File "/home/leo/Source > >>>> Code/pypy-trunk/pypy/translator/tool/taskengine.py", line 116, in > >>>> _execute > >>>> [translation:ERROR] res = self._do(goal, taskcallable, *args, > **kwds) > >>>> [translation:ERROR] File "/home/leo/Source > >>>> Code/pypy-trunk/pypy/translator/driver.py", line 279, in _do > >>>> [translation:ERROR] res = func() > >>>> [translation:ERROR] File "/home/leo/Source > >>>> Code/pypy-trunk/pypy/translator/driver.py", line 504, in > >>>> task_compile_c > >>>> [translation:ERROR] cbuilder.compile() > >>>> [translation:ERROR] File "/home/leo/Source > >>>> Code/pypy-trunk/pypy/translator/c/genc.py", line 447, in compile > >>>> [translation:ERROR] > >>>> self.translator.platform.execute_makefile(self.targetdir) > >>>> [translation:ERROR] File "/home/leo/Source > >>>> Code/pypy-trunk/pypy/translator/platform/posix.py", line 114, in > >>>> execute_makefile > >>>> [translation:ERROR] self._handle_error(returncode, stdout, stderr, > >>>> path.join('make')) > >>>> [translation:ERROR] File "/home/leo/Source > >>>> Code/pypy-trunk/pypy/translator/platform/__init__.py", line 117, in > >>>> _handle_error > >>>> [translation:ERROR] raise CompilationError(stdout, stderr) > >>>> [translation:ERROR] CompilationError: > >>>> _______________________________________________ > >>>> pypy-dev at codespeak.net > >>>> http://codespeak.net/mailman/listinfo/pypy-dev > >>> > >>> -- > >>> Leonardo > >>> > >>> > >>> > >>> > >> > > -- > Leonardo > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amauryfa at gmail.com Thu Nov 19 13:06:47 2009 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Thu, 19 Nov 2009 13:06:47 +0100 Subject: [pypy-dev] pypy-c-jit compilation error In-Reply-To: References: <965F4B8F-592A-4B0C-BFF7-A5DB064D5D00@gmail.com> <3A7C2110-F1D6-469B-8D42-0881B2F3CDD6@gmail.com> Message-ID: 2009/11/19 Leo Trottier : > [apologies for the spam, but people seem interested] > On Snow Leopard, after adding the -m32 flags recommended by Leonardo, it got > all the way to compilation, and then failed. I had tried to do a c-jit > compile over the latest trunk using 32bit python. > Here is the full run log:?http://paste.pocoo.org/show/151639/ Unfortunately, the log does not show all compilation output. Again you should do it manually: cd /var/folders/S+/S+mQx368HdO8O9qxkcyoQk+++TI/-Tmp-/usession-trunk-0/testing_1 make -- Amaury Forgeot d'Arc From trottier at gmail.com Thu Nov 19 13:13:55 2009 From: trottier at gmail.com (Leo Trottier) Date: Thu, 19 Nov 2009 04:13:55 -0800 Subject: [pypy-dev] pypy-c-jit compilation error In-Reply-To: References: <965F4B8F-592A-4B0C-BFF7-A5DB064D5D00@gmail.com> <3A7C2110-F1D6-469B-8D42-0881B2F3CDD6@gmail.com> Message-ID: As requested: http://paste.pocoo.org/show/151641/ On Thu, Nov 19, 2009 at 4:06 AM, Amaury Forgeot d'Arc wrote: > 2009/11/19 Leo Trottier : > > [apologies for the spam, but people seem interested] > > On Snow Leopard, after adding the -m32 flags recommended by Leonardo, it > got > > all the way to compilation, and then failed. I had tried to do a c-jit > > compile over the latest trunk using 32bit python. > > Here is the full run log: http://paste.pocoo.org/show/151639/ > > Unfortunately, the log does not show all compilation output. > Again you should do it manually: > > cd > /var/folders/S+/S+mQx368HdO8O9qxkcyoQk+++TI/-Tmp-/usession-trunk-0/testing_1 > make > > -- > Amaury Forgeot d'Arc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fijall at gmail.com Thu Nov 19 13:19:02 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Thu, 19 Nov 2009 13:19:02 +0100 Subject: [pypy-dev] pypy-c-jit compilation error In-Reply-To: References: <965F4B8F-592A-4B0C-BFF7-A5DB064D5D00@gmail.com> <3A7C2110-F1D6-469B-8D42-0881B2F3CDD6@gmail.com> Message-ID: <693bc9ab0911190419vb03205ai6524f0310b5a1d81@mail.gmail.com> Hey. This seems to be a problem with trackgcroot, can you put up offending .s file (implement_5.s) somewhere? If not, send it to me by mail, I'll do it. On Thu, Nov 19, 2009 at 1:13 PM, Leo Trottier wrote: > As requested: > http://paste.pocoo.org/show/151641/ > > On Thu, Nov 19, 2009 at 4:06 AM, Amaury Forgeot d'Arc > wrote: >> >> 2009/11/19 Leo Trottier : >> > [apologies for the spam, but people seem interested] >> > On Snow Leopard, after adding the -m32 flags recommended by Leonardo, it >> > got >> > all the way to compilation, and then failed. I had tried to do a c-jit >> > compile over the latest trunk using 32bit python. >> > Here is the full run log:?http://paste.pocoo.org/show/151639/ >> >> Unfortunately, the log does not show all compilation output. >> Again you should do it manually: >> >> cd >> /var/folders/S+/S+mQx368HdO8O9qxkcyoQk+++TI/-Tmp-/usession-trunk-0/testing_1 >> make >> >> -- >> Amaury Forgeot d'Arc > > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > From fijall at gmail.com Thu Nov 19 18:06:59 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Thu, 19 Nov 2009 18:06:59 +0100 Subject: [pypy-dev] pypy-c-jit compilation error In-Reply-To: References: <965F4B8F-592A-4B0C-BFF7-A5DB064D5D00@gmail.com> <3A7C2110-F1D6-469B-8D42-0881B2F3CDD6@gmail.com> <693bc9ab0911190419vb03205ai6524f0310b5a1d81@mail.gmail.com> Message-ID: <693bc9ab0911190906l79021e2av808590b7cb0dd530@mail.gmail.com> Thanks. They stay for a while (4 more runs by default), so they're deleted but not immediately. Cheers, fijal On Thu, Nov 19, 2009 at 6:03 PM, Leo Trottier wrote: > The .s files are typically removed when the build fails. ?I've managed to > grab one, I think, before it got deleted. > You'll see it fail in the log, presumably in the same way, here: > http://paste.pocoo.org/show/151704/ > I've abused paste.pocoo and posted it > here:?http://paste.pocoo.org/show/151706/ > (I've also attached it) > Leo > > On Thu, Nov 19, 2009 at 4:19 AM, Maciej Fijalkowski > wrote: >> >> Hey. >> >> This seems to be a problem with trackgcroot, can you put up offending >> .s file (implement_5.s) somewhere? If not, send it to me by mail, I'll >> do it. >> >> On Thu, Nov 19, 2009 at 1:13 PM, Leo Trottier wrote: >> > As requested: >> > http://paste.pocoo.org/show/151641/ >> > >> > On Thu, Nov 19, 2009 at 4:06 AM, Amaury Forgeot d'Arc >> > >> > wrote: >> >> >> >> 2009/11/19 Leo Trottier : >> >> > [apologies for the spam, but people seem interested] >> >> > On Snow Leopard, after adding the -m32 flags recommended by Leonardo, >> >> > it >> >> > got >> >> > all the way to compilation, and then failed. I had tried to do a >> >> > c-jit >> >> > compile over the latest trunk using 32bit python. >> >> > Here is the full run log:?http://paste.pocoo.org/show/151639/ >> >> >> >> Unfortunately, the log does not show all compilation output. >> >> Again you should do it manually: >> >> >> >> cd >> >> >> >> /var/folders/S+/S+mQx368HdO8O9qxkcyoQk+++TI/-Tmp-/usession-trunk-0/testing_1 >> >> make >> >> >> >> -- >> >> Amaury Forgeot d'Arc >> > >> > >> > _______________________________________________ >> > pypy-dev at codespeak.net >> > http://codespeak.net/mailman/listinfo/pypy-dev >> > > > From amauryfa at gmail.com Thu Nov 19 18:09:49 2009 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Thu, 19 Nov 2009 18:09:49 +0100 Subject: [pypy-dev] pypy-c-jit compilation error In-Reply-To: References: <965F4B8F-592A-4B0C-BFF7-A5DB064D5D00@gmail.com> <3A7C2110-F1D6-469B-8D42-0881B2F3CDD6@gmail.com> <693bc9ab0911190419vb03205ai6524f0310b5a1d81@mail.gmail.com> Message-ID: 2009/11/19 Leo Trottier : > The .s files are typically removed when the build fails. ?I've managed to > grab one, I think, before it got deleted. > You'll see it fail in the log, presumably in the same way, here: > http://paste.pocoo.org/show/151704/ > I've abused paste.pocoo and posted it > here:?http://paste.pocoo.org/show/151706/ > (I've also attached it) Unfortunately, the file you sent has been truncated (before the point where it fails) Can you please run rm implement_9.s make implement_9.s to regenerate it. Cheers, -- Amaury Forgeot d'Arc From amauryfa at gmail.com Fri Nov 20 00:55:43 2009 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Fri, 20 Nov 2009 00:55:43 +0100 Subject: [pypy-dev] pypy-c-jit compilation error In-Reply-To: References: <3A7C2110-F1D6-469B-8D42-0881B2F3CDD6@gmail.com> <693bc9ab0911190419vb03205ai6524f0310b5a1d81@mail.gmail.com> Message-ID: 2009/11/19 Leo Trottier : > attached -- > also (more lodgeit abuse):?http://paste.pocoo.org/show/151708/ > Leo I narrowed the problem to one function. copy the attached file somewhere, and run trackgcroot like this: python translator/c/gcc/trackgcroot.py -fdarwin -t function.s I'm still trying to understand the control flow of this function (there are 68 jumps...) and why trackgcroot fails to find the value at the origin of some register. -- Amaury Forgeot d'Arc -------------- next part -------------- A non-text attachment was scrubbed... Name: function.s Type: application/octet-stream Size: 9677 bytes Desc: not available URL: From santagada at gmail.com Fri Nov 20 01:30:14 2009 From: santagada at gmail.com (Leonardo Santagada) Date: Thu, 19 Nov 2009 22:30:14 -0200 Subject: [pypy-dev] pypy-c-jit compilation error In-Reply-To: References: <3A7C2110-F1D6-469B-8D42-0881B2F3CDD6@gmail.com> <693bc9ab0911190419vb03205ai6524f0310b5a1d81@mail.gmail.com> Message-ID: <5BF5CCD8-A876-43B6-A184-0428D6065E9B@gmail.com> On Nov 19, 2009, at 9:55 PM, Amaury Forgeot d'Arc wrote: > 2009/11/19 Leo Trottier : >> attached -- >> also (more lodgeit abuse): http://paste.pocoo.org/show/151708/ >> Leo > > I narrowed the problem to one function. > copy the attached file somewhere, and run trackgcroot like this: > > python translator/c/gcc/trackgcroot.py -fdarwin -t function.s > > I'm still trying to understand the control flow of this function > (there are 68 jumps...) > and why trackgcroot fails to find the value at the origin of some register. I just translated pypy-c-jit (now using my new patch, setting -arch i386 instead of -m32) and it worked, although it didn't compile bz2 support (probably a package I installed with macports without the universal variant). Here is the new patch if someone wants to test it more: http://paste.pocoo.org/show/151790/ -- Leonardo Santagada santagada at gmail.com From trottier at gmail.com Fri Nov 20 03:17:01 2009 From: trottier at gmail.com (Leo Trottier) Date: Thu, 19 Nov 2009 18:17:01 -0800 Subject: [pypy-dev] pypy-c-jit compilation error In-Reply-To: References: <3A7C2110-F1D6-469B-8D42-0881B2F3CDD6@gmail.com> <693bc9ab0911190419vb03205ai6524f0310b5a1d81@mail.gmail.com> Message-ID: Here's the result: .Traceback (most recent call last): File "translator/c/gcc/trackgcroot.py", line 1612, in tracker.process(f, g, filename=fn) File "translator/c/gcc/trackgcroot.py", line 1420, in process lines = parser.process_function(lines, entrypoint, filename) File "translator/c/gcc/trackgcroot.py", line 1071, in process_function lines, entrypoint, filename) File "translator/c/gcc/trackgcroot.py", line 986, in process_function table = tracker.computegcmaptable(self.verbose) File "translator/c/gcc/trackgcroot.py", line 50, in computegcmaptable self.trackgcroots() File "translator/c/gcc/trackgcroot.py", line 269, in trackgcroots self.walk_instructions_backwards(walker, insn, loc) File "translator/c/gcc/trackgcroot.py", line 288, in walk_instructions_backwards for prevstate in walker(insn, state): File "translator/c/gcc/trackgcroot.py", line 261, in walker source = insn.source_of(loc, tag) File "/Users/leotrottier/Source_Code/pypy-trunk/pypy/translator/c/gcc/instruction.py", line 96, in source_of (localvar,)) AssertionError: must come from an argument to the function, got <-44;esp> On Thu, Nov 19, 2009 at 3:55 PM, Amaury Forgeot d'Arc wrote: > 2009/11/19 Leo Trottier : > > attached -- > > also (more lodgeit abuse): http://paste.pocoo.org/show/151708/ > > Leo > > I narrowed the problem to one function. > copy the attached file somewhere, and run trackgcroot like this: > > python translator/c/gcc/trackgcroot.py -fdarwin -t function.s > > I'm still trying to understand the control flow of this function > (there are 68 jumps...) > and why trackgcroot fails to find the value at the origin of some register. > > -- > Amaury Forgeot d'Arc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amauryfa at gmail.com Fri Nov 20 15:03:58 2009 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Fri, 20 Nov 2009 15:03:58 +0100 Subject: [pypy-dev] pypy-c-jit compilation error In-Reply-To: References: <693bc9ab0911190419vb03205ai6524f0310b5a1d81@mail.gmail.com> Message-ID: Hi, 2009/11/20 Leo Trottier : [...] > AssertionError: must come from an argument to the function, got <-44;esp> This should be corrected by now. A function known by the compiler to abort and not return was not listed in the script that builds the control flow of assembler code. -- Amaury Forgeot d'Arc From grobinson at flyfi.com Sat Nov 21 14:54:30 2009 From: grobinson at flyfi.com (Gary Robinson) Date: Sat, 21 Nov 2009 08:54:30 -0500 Subject: [pypy-dev] pyprocessing/multiprocessing Message-ID: <20091121085430645676.95eb2994@flyfi.com> Hi, I'm wondering whether anyone has gotten the pyprocessing/multiprocessing module (in one version or the other) working with PyPy? I don't see it listed among the supported modules, but I want to ask to make sure I'm not just missing something. If it's not working yet, is there an ETA?? Thanks, Gary -- Gary Robinson CTO Emergent Music, LLC grobinson at flyfi.com 207-942-3463 Company: http://www.flyfi.com Blog: http://www.garyrobinson.net From fijall at gmail.com Sat Nov 21 15:05:28 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Sat, 21 Nov 2009 15:05:28 +0100 Subject: [pypy-dev] pyprocessing/multiprocessing In-Reply-To: <20091121085430645676.95eb2994@flyfi.com> References: <20091121085430645676.95eb2994@flyfi.com> Message-ID: <693bc9ab0911210605o6592ceffrd2f63d9ee4701614@mail.gmail.com> No, noone did. You can't get C module to work on PyPy, you need to port it to RPython first. I'm not aware about anyone who would like to work on it among core devs, I suppose feel free to do so, we can help. It's open source after all :-) Cheers, fijal On Sat, Nov 21, 2009 at 2:54 PM, Gary Robinson wrote: > Hi, > > I'm wondering whether anyone has gotten the pyprocessing/multiprocessing module (in one version or the other) working with PyPy? I don't see it listed among the supported modules, but I want to ask to make sure I'm not just missing something. If it's not working yet, is there an ETA?? > > Thanks, > Gary > -- > > Gary Robinson > CTO > Emergent Music, LLC > grobinson at flyfi.com > 207-942-3463 > Company: http://www.flyfi.com > Blog: ? ?http://www.garyrobinson.net > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > From fijall at gmail.com Sat Nov 21 15:06:29 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Sat, 21 Nov 2009 15:06:29 +0100 Subject: [pypy-dev] pyprocessing/multiprocessing In-Reply-To: <693bc9ab0911210605o6592ceffrd2f63d9ee4701614@mail.gmail.com> References: <20091121085430645676.95eb2994@flyfi.com> <693bc9ab0911210605o6592ceffrd2f63d9ee4701614@mail.gmail.com> Message-ID: <693bc9ab0911210606r371c0cddg52775410a2b2a00f@mail.gmail.com> On Sat, Nov 21, 2009 at 3:05 PM, Maciej Fijalkowski wrote: > No, noone did. You can't get C module to work on PyPy, you need to > port it to RPython first. I'm not aware about anyone who would like to > work on it among core devs, I suppose feel free to do so, we can help. > It's open source after all :-) > > Cheers, > fijal > Oh, and by the way, personally I would prefer to kill the GIL, so we don't have to worry any more (but also noone from core devs is working on it). Cheers, fijal From benjamin at python.org Sat Nov 21 15:05:52 2009 From: benjamin at python.org (Benjamin Peterson) Date: Sat, 21 Nov 2009 08:05:52 -0600 Subject: [pypy-dev] pyprocessing/multiprocessing In-Reply-To: <20091121085430645676.95eb2994@flyfi.com> References: <20091121085430645676.95eb2994@flyfi.com> Message-ID: <1afaf6160911210605l4c063516s43febb87dc6a9999@mail.gmail.com> 2009/11/21 Gary Robinson : > Hi, > > I'm wondering whether anyone has gotten the pyprocessing/multiprocessing module (in one version or the other) working with PyPy? I don't see it listed among the supported modules, but I want to ask to make sure I'm not just missing something. If it's not working yet, is there an ETA?? We don't support Python 2.6, and probably won't for at least a year. -- Regards, Benjamin From grobinson at flyfi.com Sat Nov 21 15:35:02 2009 From: grobinson at flyfi.com (Gary Robinson) Date: Sat, 21 Nov 2009 09:35:02 -0500 Subject: [pypy-dev] pyprocessing/multiprocessing In-Reply-To: <693bc9ab0911210606r371c0cddg52775410a2b2a00f@mail.gmail.com> References: <20091121085430645676.95eb2994@flyfi.com> <693bc9ab0911210605o6592ceffrd2f63d9ee4701614@mail.gmail.com> <693bc9ab0911210606r371c0cddg52775410a2b2a00f@mail.gmail.com> Message-ID: <20091121093502403150.86fa8efe@flyfi.com> OK, thanks for the confirmation that it's not working yet, and letting me know what it would take! I wish we had the resources to take on the task of converting it to RPython, but there's no way at this point. :) I'm using pyprocessing with unladen swallow now and it works fine but for the kinds of things we're doing (mathy floating point stuff) I'd expect more speed from PyPy... -- Gary Robinson CTO Emergent Music, LLC grobinson at flyfi.com 207-942-3463 Company: http://www.flyfi.com Blog: http://www.garyrobinson.net On Sat, 21 Nov 2009 15:06:29 +0100, Maciej Fijalkowski wrote: > On Sat, Nov 21, 2009 at 3:05 PM, Maciej Fijalkowski > wrote: >> No, noone did. You can't get C module to work on PyPy, you need to >> port it to RPython first. I'm not aware about anyone who would like to >> work on it among core devs, I suppose feel free to do so, we can help. >> It's open source after all :-) >> >> Cheers, >> fijal >> > > Oh, and by the way, personally I would prefer to kill the GIL, so we > don't have to worry any more (but also noone from core devs is working > on it). > > Cheers, > fijal From grobinson at flyfi.com Sat Nov 21 15:36:59 2009 From: grobinson at flyfi.com (Gary Robinson) Date: Sat, 21 Nov 2009 09:36:59 -0500 Subject: [pypy-dev] pyprocessing/multiprocessing In-Reply-To: <1afaf6160911210605l4c063516s43febb87dc6a9999@mail.gmail.com> References: <20091121085430645676.95eb2994@flyfi.com> <1afaf6160911210605l4c063516s43febb87dc6a9999@mail.gmail.com> Message-ID: <20091121093659444784.6e5958ed@flyfi.com> > We don't support Python 2.6, and probably won't for at least a year. > pyprocessing is the module that multiprocessing sprang from. pyprocessing is much older, and works fine with python 2.5. (2.6's multiprocessing module has been backported to 2.5 too, I hear, but I'm not using it.) pyprocessing is here: http://pyprocessing.berlios.de/. (The actual module is called "processing" but pyprocessing has long been the name people have used to refer to it.) If somebody got that working, it should be a relatively short step to get multiprocessing working in PyPy's 2.6-compatible version. I care far more about pyprocessing than about 2.6... If the PyPy GIL was gone, that would be better of course, but that doesn't sound like it's going to happen any time soon... -- Gary Robinson CTO Emergent Music, LLC grobinson at flyfi.com 207-942-3463 Company: http://www.flyfi.com Blog: http://www.garyrobinson.net On Sat, 21 Nov 2009 08:05:52 -0600, Benjamin Peterson wrote: > 2009/11/21 Gary Robinson : >> Hi, >> >> I'm wondering whether anyone has gotten the >> pyprocessing/multiprocessing module (in one version or the other) >> working with PyPy? I don't see it listed among the supported >> modules, but I want to ask to make sure I'm not just missing >> something. If it's not working yet, is there an ETA?? > > We don't support Python 2.6, and probably won't for at least a year. > From ademan555 at gmail.com Sat Nov 21 21:00:38 2009 From: ademan555 at gmail.com (Dan Roberts) Date: Sat, 21 Nov 2009 12:00:38 -0800 Subject: [pypy-dev] os.wait() implementation Message-ID: <1258833638.15793.3.camel@StormEagle> Hi Everyone, I now have an application-level implementation of os.wait() complete. It's built on top of os.waitpid(), but according to the documentation I've found, the behavior should be the same. My test might be a bit objectionable as well, but I wanted to use a non-zero return value. I also modified test_popen() as it wasn't waiting for its children, and broke my test_os_wait(), since it was waiting for the child processes created by test_popen(). In the future it would be desirable to implement os.wait() in terms of the c wait() function in ll_os.py but currently (at least on Ubuntu 9.10) the c wait() function takes a pointer to a transparent struct, rather than an int, and that seems to prevent my interpreter level version from being built. I've attached both versions, but the interpreter level version will not translate. cheers, Dan P.S. This is my first patch, so it's probably worth giving it at least a once over... -------------- next part -------------- A non-text attachment was scrubbed... Name: pypy_os_wait_interplevel.diff Type: text/x-patch Size: 3494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pypy_os_wait_test_fixed.diff Type: text/x-patch Size: 2298 bytes Desc: not available URL: From arigo at tunes.org Sun Nov 22 12:29:24 2009 From: arigo at tunes.org (Armin Rigo) Date: Sun, 22 Nov 2009 12:29:24 +0100 Subject: [pypy-dev] os.wait() implementation In-Reply-To: <1258833638.15793.3.camel@StormEagle> References: <1258833638.15793.3.camel@StormEagle> Message-ID: <20091122112924.GA14384@code0.codespeak.net> Hi Dan, On Sat, Nov 21, 2009 at 12:00:38PM -0800, Dan Roberts wrote: > I now have an application-level implementation of os.wait() complete. > It's built on top of os.waitpid(), but according to the documentation > I've found, the behavior should be the same. Thank you ! > + def wait(): > + import os > + return os.waitpid(-1, 0) It's more a general issue with app_posix.py, but I think that it should avoid these costly "import os" inside application-level functions. You already have the posix module imported (see the start of app_posix.py), so you can return posix.waitpid(-1, 0). The same comment applies to other places too, e.g. popenfile.close(). A bientot, Armin. From ademan555 at gmail.com Wed Nov 25 09:27:27 2009 From: ademan555 at gmail.com (Dan Roberts) Date: Wed, 25 Nov 2009 00:27:27 -0800 Subject: [pypy-dev] os.wait() implementation In-Reply-To: <20091122112924.GA14384@code0.codespeak.net> References: <1258833638.15793.3.camel@StormEagle> <20091122112924.GA14384@code0.codespeak.net> Message-ID: <1259137647.13743.23.camel@StormEagle> Hi Armin, Thanks for the reply, I've attached a new version of my patch. At first glance it would appear I've done little to address your concerns, however there's good reason for this. As it turns out, our implementation of popen() depends on execvp(), which is only implemented in the os module (specifically, the one borrowed from CPython). I did write an interpreter level version of execvp(), which would have allowed me to remove the imports of os from popen(), however I don't think it's wise to replace our existing application level implementation with my interpreter level implementation. Because of that, I can't remove the os dependency from popen(). For consistency, i left os in both popen() and popenfile because they directly interact. I did, however, modify wait() to use posix instead. Even though I didn't eliminate the os imports, my test *did* improve a bit from the old version, so this iteration isn't totally useless. :-) All posix tests are passing again, including the new os.wait() test. I'll be happy to address any other concerns you, or anyone else have, and if you'd like to remove those os imports, I'd like to talk to you about how to best approach that. Cheers, Dan On Sun, 2009-11-22 at 12:29 +0100, Armin Rigo wrote: > Hi Dan, > > On Sat, Nov 21, 2009 at 12:00:38PM -0800, Dan Roberts wrote: > > I now have an application-level implementation of os.wait() complete. > > It's built on top of os.waitpid(), but according to the documentation > > I've found, the behavior should be the same. > > Thank you ! > > > + def wait(): > > + import os > > + return os.waitpid(-1, 0) > > It's more a general issue with app_posix.py, but I think that it should > avoid these costly "import os" inside application-level functions. You > already have the posix module imported (see the start of app_posix.py), > so you can return posix.waitpid(-1, 0). The same comment applies to > other places too, e.g. popenfile.close(). > > > A bientot, > > Armin. -------------- next part -------------- A non-text attachment was scrubbed... Name: pypy_os_wait_complete.diff Type: text/x-patch Size: 3237 bytes Desc: not available URL: From fijall at gmail.com Thu Nov 26 00:47:42 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Thu, 26 Nov 2009 00:47:42 +0100 Subject: [pypy-dev] PyPy docs on codespeak Message-ID: <693bc9ab0911251547p5811452dyaf84222b7b634d6a@mail.gmail.com> Hello. Can someone make sure that docs on codespeak point to trunk not dist? Too many people get confused about that. (even better, how do I change it?). Cheers, fijal From fijall at gmail.com Thu Nov 26 02:22:02 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Thu, 26 Nov 2009 02:22:02 +0100 Subject: [pypy-dev] Numpy RPython support Message-ID: <693bc9ab0911251722l1c9feacbx3841908e8426f78b@mail.gmail.com> Hello. Is anyone using Numpy RPython support? It's a feature that does not stand in anyone's way, but it adds to source code and I wonder if anyone uses it. If not, I would like to delete it, simply because it's unused. Cheers, fijal From santagada at gmail.com Thu Nov 26 05:30:36 2009 From: santagada at gmail.com (Leonardo Santagada) Date: Thu, 26 Nov 2009 02:30:36 -0200 Subject: [pypy-dev] Merge request for branch/force-arch-darwin Message-ID: <03445AD3-F427-4909-AEC0-57A21B7F457C@gmail.com> I reverted the locale patch as requested and so I want to ask someone to review and merge the branch/force-arch-darwin. To garantee that everything is ok I asked to build it on macosx and linux: http://codespeak.net:8099/builders/own-macosx-x86-32/builds/19 http://codespeak.net:8099/builders/own-linux-x86-32/builds/659 this plus the locale work halves the bugs on mac os x. Theres a ton of bugs about unicode being 2 bytes on python and 4 on wchar_t and then theres the work on the jit. thanks for reading and/or reviewing the patches, -- Leonardo Santagada santagada at gmail.com From arigo at tunes.org Thu Nov 26 11:24:37 2009 From: arigo at tunes.org (Armin Rigo) Date: Thu, 26 Nov 2009 11:24:37 +0100 Subject: [pypy-dev] os.wait() implementation In-Reply-To: <1259137647.13743.23.camel@StormEagle> References: <1258833638.15793.3.camel@StormEagle> <20091122112924.GA14384@code0.codespeak.net> <1259137647.13743.23.camel@StormEagle> Message-ID: <20091126102437.GA14675@code0.codespeak.net> Hi Dan, On Wed, Nov 25, 2009 at 12:27:27AM -0800, Dan Roberts wrote: > Thanks for the reply, I've attached a new version of my patch. At first > glance it would appear I've done little to address your concerns, > however there's good reason for this. As it turns out, our > implementation of popen() depends on execvp(), which is only implemented > in the os module (specifically, the one borrowed from CPython). Ah, ok. I see now why there is 'import os' there. So that means that your patch with 'posix.waitpid' instead of 'os.waitpid' is fine. A bientot, Armin. From arigo at tunes.org Thu Nov 26 11:28:26 2009 From: arigo at tunes.org (Armin Rigo) Date: Thu, 26 Nov 2009 11:28:26 +0100 Subject: [pypy-dev] PyPy docs on codespeak In-Reply-To: <693bc9ab0911251547p5811452dyaf84222b7b634d6a@mail.gmail.com> References: <693bc9ab0911251547p5811452dyaf84222b7b634d6a@mail.gmail.com> Message-ID: <20091126102826.GB14675@code0.codespeak.net> Hi Maciej, On Thu, Nov 26, 2009 at 12:47:42AM +0100, Maciej Fijalkowski wrote: > Can someone make sure that docs on codespeak point to trunk not dist? > Too many people get confused about that. (even better, how do I change > it?). Is there a reason to keep dist in our subversion repository? I think that we should say it's ok to overwrite dist with trunk every now and then, at least as long as the tests are happy. Note that neither trunk nor dist docs are automatically updated right now, I think. Someone with codespeak root access needs to run "svn up && py.test" in /www/codespeak.net/htdocs/pypy/dist/pypy/doc/. A bientot, Armin. From fijall at gmail.com Thu Nov 26 11:47:33 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Thu, 26 Nov 2009 11:47:33 +0100 Subject: [pypy-dev] os.wait() implementation In-Reply-To: <20091126102437.GA14675@code0.codespeak.net> References: <1258833638.15793.3.camel@StormEagle> <20091122112924.GA14384@code0.codespeak.net> <1259137647.13743.23.camel@StormEagle> <20091126102437.GA14675@code0.codespeak.net> Message-ID: <693bc9ab0911260247u1f359d6vff9c7182863bc01d@mail.gmail.com> Commited On Thu, Nov 26, 2009 at 11:24 AM, Armin Rigo wrote: > Hi Dan, > > On Wed, Nov 25, 2009 at 12:27:27AM -0800, Dan Roberts wrote: >> Thanks for the reply, I've attached a new version of my patch. ?At first >> glance it would appear I've done little to address your concerns, >> however there's good reason for this. ?As it turns out, our >> implementation of popen() depends on execvp(), which is only implemented >> in the os module (specifically, the one borrowed from CPython). > > Ah, ok. ?I see now why there is 'import os' there. ?So that means that > your patch with 'posix.waitpid' instead of 'os.waitpid' is fine. > > > A bientot, > > Armin. > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > From holger at merlinux.eu Thu Nov 26 14:24:15 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 26 Nov 2009 14:24:15 +0100 Subject: [pypy-dev] Numpy RPython support In-Reply-To: <693bc9ab0911251722l1c9feacbx3841908e8426f78b@mail.gmail.com> References: <693bc9ab0911251722l1c9feacbx3841908e8426f78b@mail.gmail.com> Message-ID: <20091126132415.GI29390@trillke.net> Hi Maciej, On Thu, Nov 26, 2009 at 02:22 +0100, Maciej Fijalkowski wrote: > Hello. > > Is anyone using Numpy RPython support? It's a feature that does not > stand in anyone's way, > but it adds to source code and I wonder if anyone uses it. If not, I > would like to delete it, simply > because it's unused. there may be a bit of a chicken/egg problem wrt using PyPy/Numpy. What about posting to a Numpy list, telling about examples that work and asking if anybody is interested in using/extending/feedbacking on it? cheers, holger From anto.cuni at gmail.com Sat Nov 28 01:16:39 2009 From: anto.cuni at gmail.com (Antonio Cuni) Date: Sat, 28 Nov 2009 01:16:39 +0100 Subject: [pypy-dev] [pypy-svn] r69710 - in pypy/trunk/pypy/module/oracle: . test In-Reply-To: <20091127183029.6A3E1168101@codespeak.net> References: <20091127183029.6A3E1168101@codespeak.net> Message-ID: <4B106BE7.6080504@gmail.com> afa at codespeak.net wrote: > Log: > Now the cx_Oracle module translates, compiles, and works! > Tested on Windows. great work! I think it's worth a blog post. ciao, Anto From holger at merlinux.eu Sat Nov 28 01:34:08 2009 From: holger at merlinux.eu (holger krekel) Date: Sat, 28 Nov 2009 01:34:08 +0100 Subject: [pypy-dev] ciss-0.1: code-centered issue tracking Message-ID: <20091128003408.GR29390@trillke.net> Hi all, just released ciss-0.1, my attempt at (what i call) code-centered issue tracking. ciss is: - a command line tool for managing your ISSUES.txt - code-centered: associate issues to files in your project - extensible: assign tags for status/milestone/custom usage. - ueber-powerful issue editing: your text editor! - well tested (more tests than code) If that appeals to you somewhat, check it out: http://codespeak.net/ciss And in case you wonder, why i don't use pitz or ditz? For one, I don't want to edit my issues from an interactive Python prompt, sorry. Second, they create directories and pickle-files and whatnot - i just want to keep a plain text file for a number of projects and using a text editor and a nice cmdline tool is the fastest way i can imagine. Oh, and I do see use in web-based issue interaction but keeping issues close-to-code (tm) and easy-to-edit (tm) is just so much more fun. Besides, i believe 'ciss' could learn to round-trip with existing trackers. anyway, have fun, holger From pedronis at openend.se Mon Nov 30 16:08:14 2009 From: pedronis at openend.se (Samuele Pedroni) Date: Mon, 30 Nov 2009 16:08:14 +0100 Subject: [pypy-dev] lib-python and app-level (py.test -A) tests unified Message-ID: <4B13DFDE.7070504@openend.se> FYI, I have unified the builders for lib-python and py.test -A tests for compiled pypy-c. These means that each night we compile less pypy-c and reuse them more. Builders with "app-level" in their name usually imply now running the lib-python tests too. Stackless tests still run only the py.test -A ones, pypy-c-jit tests the lib-python one plus the jit quality ones. Samuele