From cfbolz at gmx.de Sun Jan 14 11:37:16 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sun, 14 Jan 2007 11:37:16 +0100 Subject: [pypy-dev] Leysin sprint report Message-ID: <45AA07DC.6030407@gmx.de> Hi pypy-dev! Unusually for the end of a sprint, everyone here is wide awake and fully alert here in the wonderfully pretty but remarkably snow-free ski resort of Leysin, in the Ermina B&B we have sprinted at three times before. Only joking, we are as tired as we always are. This sprint really is unusual in the sense that not very many new things were started. Slowly approaching the end of the EU-funded period, we are more in finalizing mode and try to get the results we promised (actually we had several EU related meetings to discuss some report writing plans and how to go about things in the next few weeks). It was no surprise that a lot of time went into making the JIT actually speed up code (a goal that is still not attained). There were two large subsections of this work: the relatively easy to explain task of improving the quality of the machine code the JIT produces and The Other One. Armin and Michael started the sprint with refactoring the interface to the code generators to make the lives of the backends easier, especially with regard to register allocation. This obviously broke all the backends, so the refactoring and the fixing of existing code took a day or so. Then Michael (with some later help from Niko), Armin and Eric worked on the PPC, i386, and LLVM backends respectively. They all ended up banging their heads fairly hard against various flat surfaces, especially Armin who had the wonderfully clean, regular and well designed i386 instruction set to work with. Arre and Samuele worked in the Terminology Production department, coming up with the wonderful concept of "virtualizable structures". Apparently it was much harder to implement them than to invent a term for them, so they mostly spent the whole week on it (and arrived only at "the easy part of the hard part"). To offer some hint of an explanation, virtualizable structures are data structures that live in the JIT world but can still be accessed by non-jitted code from the outside. Niko, who is funded as part of the Summer-of-PyPy program (so that's why we don't have snow: the Summer of PyPy is stronger than the Winter of Switzerland), was working with Anto on the Java backend he had started in Duesseldorf. By now a fair set of tests is passing and they managed to translate rpystone to Java bytecode (the result being roughly 20 times slower than the C version currently. although without many optimizations). After a few days Niko got fed up with Java and helped in the PowerPC efforts. The goal of Niko's project is to translate all of PyPy some time in the next few months and it seems to be well on course. A large amount of sprint energy was poured into making the Py-lib ready for release (but we all only believe it when we see it :-) ). Holger, Maciek, Guido, Carl Friedrich, Alexandre and Sylvain all worked on polishing, writing doc strings, documentation etc. for the various pieces of the package. Also a lot of functions were "unexported" to not have to deal with backward compatibility forever (which mostly broke Armin's large collection of strange conftest files in his deep and scary hack directory). Two sub-projects deserve special mention: Sylvain and Alexandre produced a debian package (which is confusingly called python-codespeak-lib, thanks to strange debian policies), including producing the mandatory man-pages for the various py-lib scripts. Otherwise the main thing the debian patches do is removing assorted cleverness from the py-lib to do with finding itself, as task which is obviously easier when you've been installed into a known location! After the success with packaging the py-lib, Sylvain and Alexandre set themselves the way scarier goal of packaging PyPy for Debian in a meaningful way. Almost disappointingly, they are dealing with the problem just fine and have a pretty good plan of how approach things: there will be a pypy-dev package which is for people developing in RPython, one or more binary packages that contain pre-translated PyPy versions (for example with stackless) and a pypy-lib package that will contain the common parts of both. An interesting point is that of dependencies: the pypy-dev package will "Depend" on those packages required to be able to run py.py, "Recommend" those packages that a developer wishing to work in RPython would need and "Suggest" some of the more eclectic packages PyPy sometimes uses. This will mean that if you set up a debian machine for working with PyPy, even if you plan to use the svn head version, installing pypy-dev will be an easy way to get all the dependencies right. The other py-lib sub-project that saw some serious polishing is the API documentation generator, "apigen". It's approach is very different from every other doc generator that we know of: instead of inspecting the source / AST / live objects and getting information from that, the tool runs all the tests of the project and observes what is happening using a trace hook. This means that it can present information about types that is inaccessible to other approaches (the information is not totally precise, of course). This also gives yet another reason for having thorough tests, since everything that is not tested will not be documented (as well as broken, as per "that which is not tested is broken"). A slightly out-of-date version of the resulting web pages can be seen at: http://johnnydebris.net/pyapi/ Another thing which was presented to the wider public for the first time is the build tool that Guido has been working on in the last months. The basic idea is that people can donate spare cycles on their machines by hooking them up to codespeak. Other people can then schedule PyPy translations which are distributed to one of the free machines. This has now reached the point where it basically works, but a lot of rough edges remain. So far it proved very useful to shine some, but not enough, light on a rather vicious and old annotation bug. We expect this tool to be useful for exploring the rather large configuration space of translation options, especially when it comes to inlining, which now has three more or less independent parameters. Samuele and Carl Friedrich ignored the fact that it was the breakday to work a bit more in the Terminology Production department. What they came up with is "shadow tracking" which does not have anything to do with OpenGL or real-time shading but is cool anyway. The idea is that every instance knows whether it shadows any attribute of any class in its MRO. This is useful information because it allows skipping the lookup in the instance dictionary if the attribute was already found in the class (a class lookup is already the first thing that is done, because of data descriptors). This led to a speedup of something like 10% for the richards benchmark, nearly no change for Pystone (which is hardly surprising since it is not an object oriented benchmark). Later they tried to implement method caching to save the lookup on the type too, at least for the most commonly called methods. This was a bit painful and lead to a rather small speedup of about 4% for richards. The hope is that this sort of optimization might also help the JIT later. Our other Summer-of-PyPy student (he is from Brazil, so it is summer for him), Leonardo, continued to explore the dark corners of the ECMAScript "specification". Antonio, Guido, Maciek and Armin all gave him moral support at various points in the sprint. A large success was that he managed (once) with Anto's help to translate the interpreter to .NET and C. It is still relying on Narcissus and Spidermonkey for parsing (parsing is boooring!). Leonardo is now working on increasing conformance and finding ambiguities in the specification. The subject of run-time modifiable syntax has been around for a long time in the PyPy world, and after a dormant period is waking up again. If you restrict yourself to py.py you can now for example add a do-while loop at runtime and during the sprint, a mixed on-/off-site team of Adrien, Michael and Sylvain worked on making this code translatable again, which involved the usual multi-layer confusions. Anto worked on improving the speed of pypy-cli by adapting and debugging various backend optimization to work with ootypes. The resulting fastest pypy-cli he got (involving --faassen and the Microsoft runtime) is roughly 10 times slower than CPython and 6 times slower than IronPython (again on the richards benchmark). Antoher step on the road to world domination. For the non-technical part, the sprint has also seen quite some skiing, long walks through the snowy landscape, star-gazing, several evenings of watching strange movies (polish karate being the strangest), lusting after Swiss Army knives with USB sticks built in and a whole night of "just one more game" of Durak (a russian card game Carl Friedrich wasted his school years with). Atenciosamente, Carl Friedrich & mwh From mwh at python.net Sun Jan 14 12:28:00 2007 From: mwh at python.net (Michael Hudson) Date: Sun, 14 Jan 2007 12:28:00 +0100 Subject: [pypy-dev] Leysin sprint report References: <45AA07DC.6030407@gmx.de> Message-ID: <87bql1luf3.fsf@starship.python.net> Carl Friedrich Bolz writes: > Hi pypy-dev! > > Unusually for the end of a sprint, everyone here is wide awake and fully > alert here in the wonderfully pretty but remarkably snow-free ski resort > of Leysin, in the Ermina B&B we have sprinted at three times before. > > Only joking, we are as tired as we always are. Somehow the two of us forgot to mention that Maciek (and anyone who got too close to him and was roped in to help) worked on simplifying the interface for declaring external functions. Before this, a task as simple as adding support for say "os.dup" involved editing roughly 42 files, and then wouldn't work because you forget the 43rd. Now there is a nice helper function that allows all the details to be in just one file, as seen in pypy/rpython/module/ll_os.py. B?sta h?lsningar, mwh & Carl Friedrich -- okay, tell me if i am crazy you are damn -- from Twisted.Quotes From paul.degrandis at gmail.com Sun Jan 14 16:53:07 2007 From: paul.degrandis at gmail.com (Paul deGrandis) Date: Sun, 14 Jan 2007 10:53:07 -0500 Subject: [pypy-dev] Leysin sprint report In-Reply-To: <87bql1luf3.fsf@starship.python.net> References: <45AA07DC.6030407@gmx.de> <87bql1luf3.fsf@starship.python.net> Message-ID: <9c0bb8a00701140753j1efbabd6o2f519b7461ead152@mail.gmail.com> Sounds awesome guys, I need to get Drexel University or next year's Summer of Code to pay to get me to some of these Sprints. In other news, my commandline Python-to-C compiler app will be seeing a lot more attention next weekend. I'll send an email to pypy-dev when it's done. Regards, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/pypy-dev/attachments/20070114/2364a629/attachment.html From holger at merlinux.de Thu Jan 18 08:12:43 2007 From: holger at merlinux.de (holger krekel) Date: Thu, 18 Jan 2007 08:12:43 +0100 Subject: [pypy-dev] py lib WARNING / cleanup works Message-ID: <20070118071243.GE16915@solar.trillke> Hi folks, this is a warning note that these days there are a number of changes and cleanups being done in py lib/py.test land. I'll do my best to keep pypy's usages in sync with those changes but it's obviously possible that i miss things. please report them on the py-dev at codespeak.net list (you need to be subscribed for getting your mails through immediately: http://codespeak.net/mailman/listinfo/py-dev) or here on the pypy-dev list. best, holger P.S.: Armin: i guess that some of your custom Session objects and other conftest customizations may need adaptation. -- merlinux GmbH Steinbergstr. 42 31139 Hildesheim http://merlinux.de tel +49 5121 20800 75 (fax 77) From santagada at gmail.com Sat Jan 20 12:05:38 2007 From: santagada at gmail.com (Leonardo Santagada) Date: Sat, 20 Jan 2007 12:05:38 +0100 Subject: [pypy-dev] means to get to the IRC Channel Message-ID: <2f2e5f950701200305l58d739c3i12481c8cececb818@mail.gmail.com> I'm finding it pretty hard to join the #pypy channel because everywere that has internet connection also has some sort of badly configured firewall. Do any one knows of a good way to make it work (like a tunnel, a web client or something?). If there is not can we put on codespeak.net a page with http://cgiirc.sourceforge.net/ for the #pypy channel? -- Leonardo Santagada (http://www.lomohomes.com/retype) N?o se preocupe com o que os outros v?o fazer. O melhor jeito de prever o futuro ? inventa-lo. - Alan Kay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/pypy-dev/attachments/20070120/f95997c9/attachment.htm From l.oluyede at gmail.com Sat Jan 20 12:28:44 2007 From: l.oluyede at gmail.com (Lawrence Oluyede) Date: Sat, 20 Jan 2007 12:28:44 +0100 Subject: [pypy-dev] means to get to the IRC Channel In-Reply-To: <2f2e5f950701200305l58d739c3i12481c8cececb818@mail.gmail.com> References: <2f2e5f950701200305l58d739c3i12481c8cececb818@mail.gmail.com> Message-ID: <9eebf5740701200328n7c261c47v3316395aab9ecc8c@mail.gmail.com> On 1/20/07, Leonardo Santagada wrote: > I'm finding it pretty hard to join the #pypy channel because everywere that > has internet connection also has some sort of badly configured firewall. Do > any one knows of a good way to make it work (like a tunnel, a web client or > something?). If there is not can we put on codespeak.net a page with > http://cgiirc.sourceforge.net/ for the #pypy channel? You can try to use http://www.ircatwork.com/ -- Lawrence From santagada at gmail.com Sat Jan 20 23:02:28 2007 From: santagada at gmail.com (Leonardo Santagada) Date: Sat, 20 Jan 2007 23:02:28 +0100 Subject: [pypy-dev] means to get to the IRC Channel In-Reply-To: <9eebf5740701200328n7c261c47v3316395aab9ecc8c@mail.gmail.com> References: <2f2e5f950701200305l58d739c3i12481c8cececb818@mail.gmail.com> <9eebf5740701200328n7c261c47v3316395aab9ecc8c@mail.gmail.com> Message-ID: <13515DFF-CDB9-4457-A0E7-665AF289A751@gmail.com> thanks a lot, I searched for a cgi:irc installed like that... sometimes even google fails me. and may this email stay as information on a good way to access irc behind a firewall. (shameless google hinting :)). Em 20/01/2007, ?s 12:28, Lawrence Oluyede escreveu: > On 1/20/07, Leonardo Santagada wrote: >> I'm finding it pretty hard to join the #pypy channel because >> everywere that >> has internet connection also has some sort of badly configured >> firewall. Do >> any one knows of a good way to make it work (like a tunnel, a web >> client or >> something?). If there is not can we put on codespeak.net a page with >> http://cgiirc.sourceforge.net/ for the #pypy channel? > > > You can try to use http://www.ircatwork.com/ > > -- > Lawrence From nytrokiss at gmail.com Sun Jan 21 02:20:31 2007 From: nytrokiss at gmail.com (James Matthews) Date: Sat, 20 Jan 2007 20:20:31 -0500 Subject: [pypy-dev] means to get to the IRC Channel In-Reply-To: <13515DFF-CDB9-4457-A0E7-665AF289A751@gmail.com> References: <2f2e5f950701200305l58d739c3i12481c8cececb818@mail.gmail.com> <9eebf5740701200328n7c261c47v3316395aab9ecc8c@mail.gmail.com> <13515DFF-CDB9-4457-A0E7-665AF289A751@gmail.com> Message-ID: <8a6b8e350701201720q48756e48h4944d1b0b7035418@mail.gmail.com> Now that the topic is about bypassing firewalls.... =) there are a bunch of java irc clients.. online searchirc.com to mention one! On 1/20/07, Leonardo Santagada wrote: > > thanks a lot, I searched for a cgi:irc installed like that... > sometimes even google fails me. > and may this email stay as information on a good way to access irc > behind a firewall. > (shameless google hinting :)). > > Em 20/01/2007, ?s 12:28, Lawrence Oluyede escreveu: > > > On 1/20/07, Leonardo Santagada wrote: > >> I'm finding it pretty hard to join the #pypy channel because > >> everywere that > >> has internet connection also has some sort of badly configured > >> firewall. Do > >> any one knows of a good way to make it work (like a tunnel, a web > >> client or > >> something?). If there is not can we put on codespeak.net a page with > >> http://cgiirc.sourceforge.net/ for the #pypy channel? > > > > > > You can try to use http://www.ircatwork.com/ > > > > -- > > Lawrence > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -- http://www.goldwatches.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/pypy-dev/attachments/20070120/4ada457f/attachment-0001.htm From holger at merlinux.de Mon Jan 22 17:00:40 2007 From: holger at merlinux.de (holger krekel) Date: Mon, 22 Jan 2007 17:00:40 +0100 Subject: [pypy-dev] pypy trillke sprints Feb/March 2007 Message-ID: <20070122160040.GT16915@solar.trillke> ========================================================================= PyPy Trillke "EU and beyond!" sprints (25-28th Feb, 1-5th March 2006) ========================================================================= .. image:: http://www.trillke.net/images/HausPanorama0304_113kb.jpg Some two years and some thousands of commits later, the EU project period of the PyPy (http://codespeak.net/pypy) project is about to close ... and a new period to begin: we are going for a sprint of three days of focusing on EU reports and administrative issues, and another three day sprint of happy hacking on the numerous interesting open ends of PyPy, the source code. We also intend to discuss and state our view on the time after the EU period (March 2007 is the last EU funded month), because clearly the project will not stop after our successful (knock knock!) completion of the EU project. It's already clear that some of us seriously plan for a relaxation time, i.e. one without having many obligations. But that should not keep us from thinking and envisioning the development from April on. So to the Sprint: we have two parts of the sprint, first the EU and second the public all-invited part:: 26th Feb - 28th Feb EU reports and adminstrative sprint 1st March break day / arrival for coding sprint 2nd March - 4th March public coding "beyond EU" sprint days All days are meant as full days, so please arrive 25th Feb / 1st March and leave 5th March if you can (this help us with pairing, introductions and logistical planning). --------------------------------------------- Possible Topics for the coding sprint --------------------------------------------- * working on .NET, Java and other backends * working on the Javascript, Prolog or a new frontend * Tuning the JIT, refining approaches `[1]`_ * Fixing PyPy-1.0 problems / improving it (PyPy-1.0 is scheduled for Mid February, btw) * improving the py lib/py.test, build environments, preparing for server administration efforts from April on * Work on/with prototypes that use the new features that PyPy enables: distribution `[2]`_ (based on transparent proxying `[3]`_), security `[4]`_, persistence `[5]`_, etc. `[6]`_. * discussion about the time after March, and how to organize/co-ordinate ourselves * all topics that are of interest otherwise (including maybe working on some particular EU related topics still!) .. _[1]: http://codespeak.net/pypy/dist/pypy/doc/jit.html .. _[2]: http://codespeak.net/svn/pypy/dist/pypy/lib/distributed/ .. _[3]: http://codespeak.net/pypy/dist/pypy/doc/proxy.html .. _[4]: http://codespeak.net/pypy/dist/pypy/doc/project-ideas.html#security .. _[5]: http://codespeak.net/pypy/dist/pypy/doc/project-ideas.html#persistence .. _[6]: http://codespeak.net/pypy/dist/pypy/doc/project-ideas.html ----------------------- Location ----------------------- The sprint takes place at the Trillke Gut Steinbergstr. 42 Hildesheim, Germany http://www.trillke.net If you come to Hildesheim main station, take the Bus Number 3 (Hildesheimer Wald) and get out at "Waldquelle". Walking back a 100 meters gets you to a small street on the right leading to a big white building, the Trillke Gut. We'll have at least one larger room for sprinting, and a kitchen for our use. ----------------------- Accomodation ----------------------- We can probably arrange for some cheap or no-cost private accomodation, in private rooms located up in the house (and being part of "living groups" of 5-10 people). There also is a nice Guest house that has been used during recent events: http://www.gaestehaus-klocke.de/ and a four-star hotel 500 meters away from the Trillke: http://www.berghoelzchen.de/ ----------------------- Registration ----------------------- please subscribe to the pypy-sprint mailing list http://codespeak.net/mailman/listinfo/pypy-sprint and register by subversion: http://codespeak.net/svn/pypy/extradoc/sprintinfo/trillke-2007/people.txt or - if you have no checkin-rights - post to the pypy-sprint list above. -- merlinux GmbH Steinbergstr. 42 31139 Hildesheim http://merlinux.de tel +49 5121 20800 75 (fax 77) From ndbecker2 at gmail.com Tue Jan 23 21:29:00 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 23 Jan 2007 15:29:00 -0500 Subject: [pypy-dev] Does/will pypy support cpython's c extension modules? Message-ID: Subject says it all. Will I be able to use my existing c (c++ actually) modules? From simon at arrowtheory.com Wed Jan 24 01:11:55 2007 From: simon at arrowtheory.com (Simon Burton) Date: Tue, 23 Jan 2007 16:11:55 -0800 Subject: [pypy-dev] Does/will pypy support cpython's c extension modules? In-Reply-To: References: Message-ID: <20070123161155.4ab9bf59.simon@arrowtheory.com> Not likely. Simon. On Tue, 23 Jan 2007 15:29:00 -0500 Neal Becker wrote: > Subject says it all. Will I be able to use my existing c (c++ actually) > modules? > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev From nytrokiss at gmail.com Wed Jan 24 03:54:56 2007 From: nytrokiss at gmail.com (James Matthews) Date: Tue, 23 Jan 2007 21:54:56 -0500 Subject: [pypy-dev] Does/will pypy support cpython's c extension modules? In-Reply-To: <20070123161155.4ab9bf59.simon@arrowtheory.com> References: <20070123161155.4ab9bf59.simon@arrowtheory.com> Message-ID: <8a6b8e350701231854w3ca6de8bi7cfa9f78943b7bb9@mail.gmail.com> Why not if Cpython can then pypy can ! On 1/23/07, Simon Burton wrote: > > > Not likely. > > Simon. > > On Tue, 23 Jan 2007 15:29:00 -0500 > Neal Becker wrote: > > > Subject says it all. Will I be able to use my existing c (c++ actually) > > modules? > > > > _______________________________________________ > > pypy-dev at codespeak.net > > http://codespeak.net/mailman/listinfo/pypy-dev > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -- http://www.goldwatches.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/pypy-dev/attachments/20070123/3cd611f7/attachment.htm From stephen at thorne.id.au Wed Jan 24 04:50:11 2007 From: stephen at thorne.id.au (Stephen Thorne) Date: Wed, 24 Jan 2007 13:50:11 +1000 Subject: [pypy-dev] Machines at uni-duesseldorf In-Reply-To: <20061227104434.GA10138@code0.codespeak.net> Message-ID: <20070124035011.17245.1633589632.divmod.quotient.9520@ohm> On Wed, 27 Dec 2006 11:44:34 +0100, Armin Rigo wrote: >Host wyvern > HostName wyvern.cs.uni-duesseldorf.de > Port 922 >Host cobra > HostName cobra.cs.uni-duesseldorf.de > Port 922 Unless these machines have the same ssh host keys, you'll experience a nasty message when you attempt to log in, unless you only ever use port 922 or port 22. Add this under the host config of each host that connects on an alternate port to make that go away: UserKnownHostsFile ~/.ssh/known_hosts.922 It will make the hosts file a different file on disk, so you won't have port 922 and 22 having different rsa fingerprints causing you grief, while retaining the ability to check that the host/port combinations rsa key. Stephen. From arigo at tunes.org Thu Jan 25 11:01:04 2007 From: arigo at tunes.org (Armin Rigo) Date: Thu, 25 Jan 2007 11:01:04 +0100 Subject: [pypy-dev] Machines at uni-duesseldorf In-Reply-To: <20070124035011.17245.1633589632.divmod.quotient.9520@ohm> References: <20061227104434.GA10138@code0.codespeak.net> <20070124035011.17245.1633589632.divmod.quotient.9520@ohm> Message-ID: <20070125100104.GB14446@code0.codespeak.net> Hi Stephen, On Wed, Jan 24, 2007 at 01:50:11PM +1000, Stephen Thorne wrote: > On Wed, 27 Dec 2006 11:44:34 +0100, Armin Rigo wrote: > >Host wyvern > > HostName wyvern.cs.uni-duesseldorf.de > > Port 922 > >Host cobra > > HostName cobra.cs.uni-duesseldorf.de > > Port 922 > > Unless these machines have the same ssh host keys, you'll experience a > nasty message when you attempt to log in, unless you only ever use port 922 > or port 22. I seems to depend on the version of ssh. In my known_hosts file I see two entries: one for 'wyvern.cs.uni-duesseldorf.de,134.99.112.213' and one for '[wyvern.cs.uni-duesseldorf.de]:922,[134.99.112.213]:922'. So at least OpenSSH_4.5p1 distinguishes by port automatically. I don't think many people other than me have an account on the port 22, too. Thanks for the note nevertheless! A bientot, Armin. From alexandre.fayolle at logilab.fr Sat Jan 27 10:08:38 2007 From: alexandre.fayolle at logilab.fr (Alexandre Fayolle) Date: Sat, 27 Jan 2007 10:08:38 +0100 Subject: [pypy-dev] translation error in a fresh checkout Message-ID: <20070127090838.GG31746@crater.logilab.fr> Hi, I'm experiencing problems when translating pypy from a fresh checkout (when testing the compilation of Debian packages) The translation crashes very early in the process: Loading grammar /home/alf/dev/pypy/dist/pypy/interpreter/pyparser/data/Grammar2.4 ******************** -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "global name 'HMASK' is not defined" Happened at file /home/alf/dev/pypy/dist/pypy/lib/_classobj.py line 21 v += HMASK This comes from > /home/alf/dev/pypy/dist/pypy/objspace/flow/objspace.py(264)build_flow() -> raise FlowingError(format_global_error(ec.graph, ec.crnt_offset, str(a))) This used to work last tuesday, but with a checkout from yesterday, the bug occurs. I was puzzled at first because I could only see this during the translation for Debian packages, and not in my usual working checkout which I update on a regular basis. After blaming the Debian package building environment and not finding anything, it turns out that my working checkout has a pypy/_cache directory, which is used. If I rename this directory, translating will fail there too. Can other people confirm the problem ? If I'm correct it should affect the build tool too, since it builds in a fresh checkout. -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations D?veloppement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science Reprise et maintenance de sites CPS: http://www.migration-cms.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: Digital signature Url : http://codespeak.net/pipermail/pypy-dev/attachments/20070127/c42bb327/attachment.pgp From arigo at tunes.org Sat Jan 27 11:51:01 2007 From: arigo at tunes.org (Armin Rigo) Date: Sat, 27 Jan 2007 11:51:01 +0100 Subject: [pypy-dev] translation error in a fresh checkout In-Reply-To: <20070127090838.GG31746@crater.logilab.fr> References: <20070127090838.GG31746@crater.logilab.fr> Message-ID: <20070127105059.GA10636@code0.codespeak.net> Hi Alexandre, On Sat, Jan 27, 2007 at 10:08:38AM +0100, Alexandre Fayolle wrote: > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > "global name 'HMASK' is not defined" > Happened at file /home/alf/dev/pypy/dist/pypy/lib/_classobj.py line 21 > > v += HMASK Oups! Sorry. Fixed in: ------------------------------------------------------------------------ r37422 | arigo | 2007-01-27 11:49:11 +0100 (Sat, 27 Jan 2007) | 5 lines Changed paths: M /pypy/dist/pypy/annotation/test/test_annrpython.py M /pypy/dist/pypy/objspace/flow/objspace.py - fix flow space crash when geninterp'ing: globals containing constants of type long have got very confused because of r37394. - add a test that shows why r37394 was introduced in the first place. - don't each the traceback in an except:reraise. -- Armin From arigo at tunes.org Sat Jan 27 11:52:43 2007 From: arigo at tunes.org (Armin Rigo) Date: Sat, 27 Jan 2007 11:52:43 +0100 Subject: [pypy-dev] Does/will pypy support cpython's c extension modules? In-Reply-To: References: Message-ID: <20070127105241.GA13001@code0.codespeak.net> Hi Neal, On Tue, Jan 23, 2007 at 03:29:00PM -0500, Neal Becker wrote: > Subject says it all. Will I be able to use my existing c (c++ actually) > modules? In theory, yes, we could do this. But it would be quite some work so we are focusing on other priorities at the moment. A bientot, Armin. From alexandre.fayolle at logilab.fr Sat Jan 27 12:25:35 2007 From: alexandre.fayolle at logilab.fr (Alexandre Fayolle) Date: Sat, 27 Jan 2007 12:25:35 +0100 Subject: [pypy-dev] translation error in a fresh checkout In-Reply-To: <20070127105059.GA10636@code0.codespeak.net> References: <20070127090838.GG31746@crater.logilab.fr> <20070127105059.GA10636@code0.codespeak.net> Message-ID: <20070127112535.GA29780@crater.logilab.fr> On Sat, Jan 27, 2007 at 11:51:01AM +0100, Armin Rigo wrote: > Hi Alexandre, Thanks for the rapid fix. -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations D?veloppement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science Reprise et maintenance de sites CPS: http://www.migration-cms.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: Digital signature Url : http://codespeak.net/pipermail/pypy-dev/attachments/20070127/75706193/attachment.pgp From fijal at genesilico.pl Mon Jan 29 14:10:42 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Mon, 29 Jan 2007 14:10:42 +0100 Subject: [pypy-dev] RSession and py-trunk users Message-ID: <45BDF252.5030207@genesilico.pl> I've implemented recently an addition, which allows to have cleanur conftest.py setup. Basically, conftest.py's dist_rsyncroots affects only directory where it is located, so in let's say pypy's parent dir you might have conftest.py with dist_rsyncroots = ['py', 'pypy', 'lib-python'] and in pypy's dir dist_rsyncroots = # all files except _cache and should work. There were different ideas how to solve that problem and from my POV this on is the simplest, but I'm open to different ones. From nytrokiss at gmail.com Mon Jan 29 19:41:12 2007 From: nytrokiss at gmail.com (James Matthews) Date: Mon, 29 Jan 2007 13:41:12 -0500 Subject: [pypy-dev] RSession and py-trunk users In-Reply-To: <45BDF252.5030207@genesilico.pl> References: <45BDF252.5030207@genesilico.pl> Message-ID: <8a6b8e350701291041k3a9dc544m594e10519d4cbb37@mail.gmail.com> Thanks that works for me! On 1/29/07, Maciek Fijalkowski wrote: > > I've implemented recently an addition, which allows to have cleanur > conftest.py setup. > > Basically, conftest.py's dist_rsyncroots affects only directory where it > is located, > so in let's say pypy's parent dir you might have conftest.py with > > dist_rsyncroots = ['py', 'pypy', 'lib-python'] > > and in pypy's dir > > dist_rsyncroots = # all files except _cache > > and should work. > > There were different ideas how to solve that problem and from my POV > this on is the simplest, but I'm open to different ones. > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -- http://www.goldwatches.com http://www.wazoozle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/pypy-dev/attachments/20070129/c96bae0f/attachment.htm From seanl at literati.org Mon Jan 29 20:07:26 2007 From: seanl at literati.org (Sean Lynch) Date: Mon, 29 Jan 2007 11:07:26 -0800 Subject: [pypy-dev] Does/will pypy support cpython's c extension modules? In-Reply-To: <8a6b8e350701231854w3ca6de8bi7cfa9f78943b7bb9@mail.gmail.com> References: <20070123161155.4ab9bf59.simon@arrowtheory.com> <8a6b8e350701231854w3ca6de8bi7cfa9f78943b7bb9@mail.gmail.com> Message-ID: <45BE45EE.5090605@literati.org> Please no. Porting modules to ctypes is well worth the effort because then they will work with Jython and IronPython as well as CPython and PyPy. IMHO the CPython extension API is the "wrong" way to extend Python and has been since the beginning, not least because it assumes implementation details of the interpreter like reference counting, object layout, etc. James Matthews wrote: > Why not if Cpython can then pypy can ! > > On 1/23/07, Simon Burton wrote: >> >> >> Not likely. >> >> Simon. >> >> On Tue, 23 Jan 2007 15:29:00 -0500 >> Neal Becker wrote: >> >> > Subject says it all. Will I be able to use my existing c (c++ >> actually) >> > modules? >> > >> > _______________________________________________ >> > pypy-dev at codespeak.net >> > http://codespeak.net/mailman/listinfo/pypy-dev >> _______________________________________________ >> pypy-dev at codespeak.net >> http://codespeak.net/mailman/listinfo/pypy-dev >> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/pypy-dev/attachments/20070129/5982581a/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://codespeak.net/pipermail/pypy-dev/attachments/20070129/5982581a/attachment.pgp From exarkun at divmod.com Mon Jan 29 20:54:15 2007 From: exarkun at divmod.com (Jean-Paul Calderone) Date: Mon, 29 Jan 2007 14:54:15 -0500 Subject: [pypy-dev] Does/will pypy support cpython's c extension modules? In-Reply-To: <45BE45EE.5090605@literati.org> Message-ID: <20070129195415.25807.680505883.divmod.quotient.2647@ohm> On Mon, 29 Jan 2007 11:07:26 -0800, Sean Lynch wrote: >Please no. Porting modules to ctypes is well worth the effort because >then they will work with Jython and IronPython as well as CPython and >PyPy. IMHO the CPython extension API is the "wrong" way to extend Python >and has been since the beginning, not least because it assumes >implementation details of the interpreter like reference counting, >object layout, etc. > If PyPy is to be a practical platform, then it would actually be beneficial for it to support the CPython extension API. The API may be crummy and undesirable in various ways, but it would still help projects moving from another runtime to PyPy if PyPy could load the extension modules they depend on until someone ports them to something better. Whether or not it is a goal for PyPy to be a practical platform right now, I don't know. This seems to be what the original poster is interested in, though, and I assume that if it is not a goal now, it will become one at some point. Jean-Paul From ndbecker2 at gmail.com Mon Jan 29 20:56:27 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 29 Jan 2007 14:56:27 -0500 Subject: [pypy-dev] Does/will pypy support cpython's c extension modules? References: <20070123161155.4ab9bf59.simon@arrowtheory.com> <8a6b8e350701231854w3ca6de8bi7cfa9f78943b7bb9@mail.gmail.com> <45BE45EE.5090605@literati.org> Message-ID: Sean Lynch wrote: > Please no. Porting modules to ctypes is well worth the effort because > then they will work with Jython and IronPython as well as CPython and > PyPy. IMHO the CPython extension API is the "wrong" way to extend Python > and has been since the beginning, not least because it assumes > implementation details of the interpreter like reference counting, > object layout, etc. I have tons of code using boost::python. Wouldn't it be a lot of work to port to ctypes? I'm guessing, it's basically a complete rewrite. > James Matthews wrote: >> Why not if Cpython can then pypy can ! >> >> On 1/23/07, Simon Burton wrote: >>> >>> >>> Not likely. >>> >>> Simon. >>> >>> On Tue, 23 Jan 2007 15:29:00 -0500 >>> Neal Becker wrote: >>> >>> > Subject says it all. Will I be able to use my existing c (c++ >>> actually) >>> > modules? >>> > >>> > _______________________________________________ >>> > pypy-dev at codespeak.net >>> > http://codespeak.net/mailman/listinfo/pypy-dev >>> _______________________________________________ >>> pypy-dev at codespeak.net >>> http://codespeak.net/mailman/listinfo/pypy-dev >>> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> pypy-dev at codespeak.net >> http://codespeak.net/mailman/listinfo/pypy-dev From nytrokiss at gmail.com Tue Jan 30 02:54:29 2007 From: nytrokiss at gmail.com (James Matthews) Date: Mon, 29 Jan 2007 20:54:29 -0500 Subject: [pypy-dev] Does/will pypy support cpython's c extension modules? In-Reply-To: References: <20070123161155.4ab9bf59.simon@arrowtheory.com> <8a6b8e350701231854w3ca6de8bi7cfa9f78943b7bb9@mail.gmail.com> <45BE45EE.5090605@literati.org> Message-ID: <8a6b8e350701291754m3af37087ub60c62468700a8dc@mail.gmail.com> Thats life eh? On 1/29/07, Neal Becker wrote: > > Sean Lynch wrote: > > > Please no. Porting modules to ctypes is well worth the effort because > > then they will work with Jython and IronPython as well as CPython and > > PyPy. IMHO the CPython extension API is the "wrong" way to extend Python > > and has been since the beginning, not least because it assumes > > implementation details of the interpreter like reference counting, > > object layout, etc. > > I have tons of code using boost::python. Wouldn't it be a lot of work to > port to ctypes? I'm guessing, it's basically a complete rewrite. > > > James Matthews wrote: > >> Why not if Cpython can then pypy can ! > >> > >> On 1/23/07, Simon Burton wrote: > >>> > >>> > >>> Not likely. > >>> > >>> Simon. > >>> > >>> On Tue, 23 Jan 2007 15:29:00 -0500 > >>> Neal Becker wrote: > >>> > >>> > Subject says it all. Will I be able to use my existing c (c++ > >>> actually) > >>> > modules? > >>> > > >>> > _______________________________________________ > >>> > pypy-dev at codespeak.net > >>> > http://codespeak.net/mailman/listinfo/pypy-dev > >>> _______________________________________________ > >>> pypy-dev at codespeak.net > >>> http://codespeak.net/mailman/listinfo/pypy-dev > >>> > >> > >> > >> > >> > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> pypy-dev at codespeak.net > >> http://codespeak.net/mailman/listinfo/pypy-dev > > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -- http://www.goldwatches.com http://www.wazoozle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/pypy-dev/attachments/20070129/431ea73c/attachment.htm From mithrandi at mithrandi.za.net Tue Jan 30 15:44:50 2007 From: mithrandi at mithrandi.za.net (Tristan Seligmann) Date: Tue, 30 Jan 2007 16:44:50 +0200 Subject: [pypy-dev] Does/will pypy support cpython's c extension modules? In-Reply-To: References: <20070123161155.4ab9bf59.simon@arrowtheory.com> <8a6b8e350701231854w3ca6de8bi7cfa9f78943b7bb9@mail.gmail.com> <45BE45EE.5090605@literati.org> Message-ID: <20070130144449.GE24191@mithrandi.za.net> * Neal Becker [2007-01-29 14:56:27 -0500]: > Sean Lynch wrote: > > > Please no. Porting modules to ctypes is well worth the effort because > > then they will work with Jython and IronPython as well as CPython and > > PyPy. IMHO the CPython extension API is the "wrong" way to extend Python > > and has been since the beginning, not least because it assumes > > implementation details of the interpreter like reference counting, > > object layout, etc. > > I have tons of code using boost::python. Wouldn't it be a lot of work to > port to ctypes? I'm guessing, it's basically a complete rewrite. Is it even feasible to wrap a C++ library with ctypes? -- mithrandi, i Ainil en-Balandor, a faer Ambar -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://codespeak.net/pipermail/pypy-dev/attachments/20070130/d3fdc12e/attachment.pgp From mwh at python.net Tue Jan 30 17:11:23 2007 From: mwh at python.net (Michael Hudson) Date: Tue, 30 Jan 2007 17:11:23 +0100 Subject: [pypy-dev] Does/will pypy support cpython's c extension modules? References: <20070123161155.4ab9bf59.simon@arrowtheory.com> <8a6b8e350701231854w3ca6de8bi7cfa9f78943b7bb9@mail.gmail.com> <45BE45EE.5090605@literati.org> <20070130144449.GE24191@mithrandi.za.net> Message-ID: <87zm80wl3o.fsf@starship.python.net> Tristan Seligmann writes: > * Neal Becker [2007-01-29 14:56:27 -0500]: > >> Sean Lynch wrote: >> >> > Please no. Porting modules to ctypes is well worth the effort because >> > then they will work with Jython and IronPython as well as CPython and >> > PyPy. IMHO the CPython extension API is the "wrong" way to extend Python >> > and has been since the beginning, not least because it assumes >> > implementation details of the interpreter like reference counting, >> > object layout, etc. >> >> I have tons of code using boost::python. Wouldn't it be a lot of work to >> port to ctypes? I'm guessing, it's basically a complete rewrite. I guess there's a chance that boost::python is sufficiently declarative that you could make code using it work for PyPy too... don't know the details at all though. > Is it even feasible to wrap a C++ library with ctypes? I guess it must be possible -- the name mangling rules aren't that hard, really -- but I don't know about feasible. Oh, hmm, templates. They'd be a pain, wouldn't they :-) Cheers, mwh -- ... but I guess there are some things that are so gross you just have to forget, or it'll destroy something within you. perl is the first such thing I have known. -- Erik Naggum, comp.lang.lisp From mwh at python.net Tue Jan 30 17:22:25 2007 From: mwh at python.net (Michael Hudson) Date: Tue, 30 Jan 2007 17:22:25 +0100 Subject: [pypy-dev] pypy 1.0 release meeting invitation Message-ID: <87veiowkla.fsf@starship.python.net> Hi PyPy-developers! The release is drawing closer (the currently planned date is February, 15th) and it is time to meet and discuss the necessary work. Therefore we invite you all to a sync-meeting on Friday, February 2nd, 2007 14.00 UTC+1 #pypy-sync Regular Topics ============== * activity reports (LAST/NEXT/BLOCKERS, everybody posts prepared comma-separated lists of things) * resolving blockers/dependencies Release Goals ============= This topic is to get a common view on what the release goals are. A preliminary list of goals is: * object optimizations * pypy.net * more working modules * some performance * maturity * build tool * JIT preview * security prototype * js backend? * debian packaging? Task Planning ============= This topic is to collect tasks to be done for the release and divide them among people. Some tasks that we could think of: * work out a timeframe for jit usefulness * fix llvm(?) * test pypy-cs, run benchmarks. * windows testing! * documentation!!! * pypy.net * object optimizations (WP6) * release announcement * improve getting-started * transparent proxies * security prototype * make build-tool useable * polish js backend? Hope to see you all on friday! Cheers, mwh -- Python enjoys making tradeoffs that drive *someone* crazy . -- Tim Peters, comp.lang.python From rxe at ukshells.co.uk Tue Jan 30 17:44:21 2007 From: rxe at ukshells.co.uk (Richard Emslie) Date: Tue, 30 Jan 2007 16:44:21 +0000 (GMT) Subject: [pypy-dev] pypy 1.0 release meeting invitation In-Reply-To: <87veiowkla.fsf@starship.python.net> References: <87veiowkla.fsf@starship.python.net> Message-ID: Hi Michael! On Tue, 30 Jan 2007, Michael Hudson wrote: > Hi PyPy-developers! > > The release is drawing closer (the currently planned date is February, 15th) cool & congrats! > > Task Planning > ============= > > This topic is to collect tasks to be done for the release and divide them > among people. Some tasks that we could think of: > > * work out a timeframe for jit usefulness > * fix llvm(?) by this do you mean implement weakrefs and other gc stuff - or it is more fundamentally broken? :-) Cheers, Richard From len-l at telus.net Tue Jan 30 18:54:34 2007 From: len-l at telus.net (Lenard Lindstrom) Date: Tue, 30 Jan 2007 09:54:34 -0800 Subject: [pypy-dev] Does/will pypy support cpython's c extension modules? In-Reply-To: <87zm80wl3o.fsf@starship.python.net> References: <20070123161155.4ab9bf59.simon@arrowtheory.com> <8a6b8e350701231854w3ca6de8bi7cfa9f78943b7bb9@mail.gmail.com> <45BE45EE.5090605@literati.org> <20070130144449.GE24191@mithrandi.za.net> <87zm80wl3o.fsf@starship.python.net> Message-ID: <45BF865A.5040400@telus.net> Michael Hudson wrote: > Tristan Seligmann writes: > > >> Is it even feasible to wrap a C++ library with ctypes? >> > > I guess it must be possible -- the name mangling rules aren't that > hard, really -- but I don't know about feasible. As long as there are no C++ exceptions to catch. > Oh, hmm, templates. > They'd be a pain, wouldn't they :-) > > Exporting templates in a shared library: that's a trick I'm unfamiliar with ;-) -- Lenard Lindstrom From seanl at literati.org Tue Jan 30 20:36:45 2007 From: seanl at literati.org (Sean Lynch) Date: Tue, 30 Jan 2007 11:36:45 -0800 Subject: [pypy-dev] Does/will pypy support cpython's c extension modules? In-Reply-To: <20070130144449.GE24191@mithrandi.za.net> References: <20070123161155.4ab9bf59.simon@arrowtheory.com> <8a6b8e350701231854w3ca6de8bi7cfa9f78943b7bb9@mail.gmail.com> <45BE45EE.5090605@literati.org> <20070130144449.GE24191@mithrandi.za.net> Message-ID: <45BF9E4D.1090604@literati.org> Tristan Seligmann wrote: >> I have tons of code using boost::python. Wouldn't it be a lot of work to >> port to ctypes? I'm guessing, it's basically a complete rewrite. >> > > Is it even feasible to wrap a C++ library with ctypes? > I have the beginnings of an automatic C and ctypes wrapper generator for C++ code. I've been successful generating the C wrapper with namespaces and non-class functions with the user telling the generator how to rename overloaded functions, and my gccxml parser supports pretty much all features of C++ except for templates now, but I still need to work on the output for class-using code and ctypes code output. The idea is to generate C wrappers for every exported function/constructor/class and to recreate the same class structure in Python with the methods calling with ctypes the appropriate C function in the wrapper. I've gotten this far with about eight hours of programming, including writing my gccxml parser, switching to pygccxml, then switching back to my own parser and finishing it when I realized that pygccxml is messy and doesn't properly support function pointers. As for boost::python, you knew you were stuck with CPython when you started, since it doesn't support IronPython or Jython either. However, given a wrapper generator like the one I've started on, you should be able to throw out all the Python-related code and just wrap the pure C++ code. I wish we could just support the gcc 3.4+ (i.e. Itanium) ABI directly, but that would be kind of pointless since VC++ doesn't support it and uses a completely undocumented and unstable ABI. It seems kind of strange to say that PyPy can't be practical without implementing the CPython extension API, since to my knowledge IronPython will not implement it (and Jython never has) and people are afraid that IronPython will be such a great Python alternative that it will fragment the Python community. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://codespeak.net/pipermail/pypy-dev/attachments/20070130/15e5c557/attachment.pgp From holger at merlinux.de Tue Jan 30 23:46:33 2007 From: holger at merlinux.de (holger krekel) Date: Tue, 30 Jan 2007 23:46:33 +0100 Subject: [pypy-dev] pypy 1.0 release meeting invitation In-Reply-To: <87veiowkla.fsf@starship.python.net> References: <87veiowkla.fsf@starship.python.net> Message-ID: <20070130224633.GQ16146@solar.trillke> Hi Michael, Carl Friedrich, thanks for inviting! it may make sense to also have a brief topic about the upcoming py lib release, and some changes that are soon going to be merged - not sure though if we wait until pypy-sync for that, so be warned already now, and please add the topic. best & thanks, holger On Tue, Jan 30, 2007 at 17:22 +0100, Michael Hudson wrote: > Hi PyPy-developers! > > The release is drawing closer (the currently planned date is February, 15th) > and it is time to meet and discuss the necessary work. Therefore we invite you > all to a sync-meeting on > > Friday, February 2nd, 2007 > 14.00 UTC+1 > #pypy-sync > > > > Regular Topics > ============== > > * activity reports (LAST/NEXT/BLOCKERS, everybody posts > prepared comma-separated lists of things) > > * resolving blockers/dependencies > > > Release Goals > ============= > > This topic is to get a common view on what the release goals are. A > preliminary list of goals is: > > * object optimizations > * pypy.net > * more working modules > * some performance > * maturity > * build tool > * JIT preview > * security prototype > * js backend? > * debian packaging? > > Task Planning > ============= > > This topic is to collect tasks to be done for the release and divide them > among people. Some tasks that we could think of: > > * work out a timeframe for jit usefulness > * fix llvm(?) > * test pypy-cs, run benchmarks. > * windows testing! > * documentation!!! > * pypy.net > * object optimizations (WP6) > * release announcement > * improve getting-started > * transparent proxies > * security prototype > * make build-tool useable > * polish js backend? > > > Hope to see you all on friday! > > Cheers, > mwh > > -- > Python enjoys making tradeoffs that drive *someone* crazy . > -- Tim Peters, comp.lang.python > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -- merlinux GmbH Steinbergstr. 42 31139 Hildesheim http://merlinux.de tel +49 5121 20800 75 (fax 77) From mwh at python.net Wed Jan 31 00:11:25 2007 From: mwh at python.net (Michael Hudson) Date: Wed, 31 Jan 2007 00:11:25 +0100 Subject: [pypy-dev] pypy 1.0 release meeting invitation References: <87veiowkla.fsf@starship.python.net> Message-ID: <87ireow1nm.fsf@starship.python.net> Richard Emslie writes: >> Task Planning >> ============= >> >> This topic is to collect tasks to be done for the release and divide them >> among people. Some tasks that we could think of: >> >> * work out a timeframe for jit usefulness >> * fix llvm(?) > > by this do you mean implement weakrefs and other gc stuff - or it is more > fundamentally broken? :-) The recent refactoring to implement more external functions using rctypes broke pypy-llvm -- llvm doesn't support some rctypes-ish operations like direct_arrayitems. But also, it turns out that just about all pypy-llvm's ever segfault when running commands like "./pypy-llvm --no-compile --backendopt translate.py targetpystonedalone.py". So, er, both, in summary :-) Will you be at PyCon? Cheers, mwh -- > So what does "abc" / "ab" equal? cheese -- Steve Holden defends obscure semantics on comp.lang.python From ndbecker2 at gmail.com Wed Jan 31 01:16:51 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 30 Jan 2007 19:16:51 -0500 Subject: [pypy-dev] Does/will pypy support cpython's c extension modules? References: <20070123161155.4ab9bf59.simon@arrowtheory.com> <8a6b8e350701231854w3ca6de8bi7cfa9f78943b7bb9@mail.gmail.com> <45BE45EE.5090605@literati.org> <20070130144449.GE24191@mithrandi.za.net> <87zm80wl3o.fsf@starship.python.net> <45BF865A.5040400@telus.net> Message-ID: Lenard Lindstrom wrote: > Michael Hudson wrote: >> Tristan Seligmann writes: >> >> >>> Is it even feasible to wrap a C++ library with ctypes? >>> >> >> I guess it must be possible -- the name mangling rules aren't that >> hard, really -- but I don't know about feasible. > > As long as there are no C++ exceptions to catch. > > >> Oh, hmm, templates. >> They'd be a pain, wouldn't they :-) >> >> > Exporting templates in a shared library: that's a trick I'm unfamiliar > with ;-) > > In case you weren't kidding, you have to export your choice of instantiations. If your object is to take your favorite generic c++ code and access it from python, that can be quite reasonable. From nytrokiss at gmail.com Wed Jan 31 01:40:56 2007 From: nytrokiss at gmail.com (James Matthews) Date: Tue, 30 Jan 2007 19:40:56 -0500 Subject: [pypy-dev] pypy 1.0 release meeting invitation In-Reply-To: <87ireow1nm.fsf@starship.python.net> References: <87veiowkla.fsf@starship.python.net> <87ireow1nm.fsf@starship.python.net> Message-ID: <8a6b8e350701301640n4dcbaed2s37addbabf1829fa1@mail.gmail.com> Thanks I can't wait! On 1/30/07, Michael Hudson wrote: > > Richard Emslie writes: > > >> Task Planning > >> ============= > >> > >> This topic is to collect tasks to be done for the release and divide > them > >> among people. Some tasks that we could think of: > >> > >> * work out a timeframe for jit usefulness > >> * fix llvm(?) > > > > by this do you mean implement weakrefs and other gc stuff - or it is > more > > fundamentally broken? :-) > > The recent refactoring to implement more external functions using > rctypes broke pypy-llvm -- llvm doesn't support some rctypes-ish > operations like direct_arrayitems. > > But also, it turns out that just about all pypy-llvm's ever segfault > when running commands like "./pypy-llvm --no-compile --backendopt > translate.py targetpystonedalone.py". > > So, er, both, in summary :-) > > Will you be at PyCon? > > Cheers, > mwh > > -- > > So what does "abc" / "ab" equal? > cheese > -- Steve Holden defends obscure semantics on comp.lang.python > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -- http://www.goldwatches.com http://www.wazoozle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/pypy-dev/attachments/20070130/df9ecb02/attachment.htm From mwh at python.net Wed Jan 31 10:27:49 2007 From: mwh at python.net (Michael Hudson) Date: Wed, 31 Jan 2007 10:27:49 +0100 Subject: [pypy-dev] Does/will pypy support cpython's c extension modules? References: <20070123161155.4ab9bf59.simon@arrowtheory.com> <8a6b8e350701231854w3ca6de8bi7cfa9f78943b7bb9@mail.gmail.com> <45BE45EE.5090605@literati.org> <20070130144449.GE24191@mithrandi.za.net> <45BF9E4D.1090604@literati.org> Message-ID: <87ejpbwnoq.fsf@starship.python.net> Sean Lynch writes: > I have the beginnings of an automatic C and ctypes wrapper generator for > C++ code. I've been successful generating the C wrapper with namespaces > and non-class functions with the user telling the generator how to > rename overloaded functions, and my gccxml parser supports pretty much > all features of C++ except for templates now, but I still need to work > on the output for class-using code and ctypes code output. The idea is > to generate C wrappers for every exported function/constructor/class and > to recreate the same class structure in Python with the methods calling > with ctypes the appropriate C function in the wrapper. I've gotten this > far with about eight hours of programming, including writing my gccxml > parser, switching to pygccxml, then switching back to my own parser and > finishing it when I realized that pygccxml is messy and doesn't properly > support function pointers. Have you seen Armin's autoctypes? https://codespeak.net/viewvc/user/arigo/hack/pypy-hack/autoctypes/ Scary code, and a rather different approach :-) > As for boost::python, you knew you were stuck with CPython when you > started, since it doesn't support IronPython or Jython either. However, > given a wrapper generator like the one I've started on, you should be > able to throw out all the Python-related code and just wrap the pure C++ > code. I wish we could just support the gcc 3.4+ (i.e. Itanium) ABI > directly, but that would be kind of pointless since VC++ doesn't support > it and uses a completely undocumented and unstable ABI. > > It seems kind of strange to say that PyPy can't be practical without > implementing the CPython extension API, since to my knowledge IronPython > will not implement it (and Jython never has) and people are afraid that > IronPython will be such a great Python alternative that it will fragment > the Python community. I don't think anyone has quite claimed that; I thought the claim was that supporting the CPython API would make PyPy a practical platform faster, and it's hard to disagree with that. Whether it's worth the effort involved is another question of course :-) The whole "interacting with the outside world" thing is a, probably /the/, most significant thing between here and a practical PyPy. Currently, there is no such thing as a PyPy extension module, and that's something that will need to change. Cheers, mwh -- Richard Gabriel was wrong: worse is not better, lying is better. Languages and systems succeed in the marketplace to the extent that their proponents lie about what they can do. -- Tim Bradshaw, comp.lang.lisp From cfbolz at gmx.de Wed Jan 31 11:05:32 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Wed, 31 Jan 2007 11:05:32 +0100 Subject: [pypy-dev] Does/will pypy support cpython's c extension modules? In-Reply-To: <87ejpbwnoq.fsf@starship.python.net> References: <20070123161155.4ab9bf59.simon@arrowtheory.com> <8a6b8e350701231854w3ca6de8bi7cfa9f78943b7bb9@mail.gmail.com> <45BE45EE.5090605@literati.org> <20070130144449.GE24191@mithrandi.za.net> <45BF9E4D.1090604@literati.org> <87ejpbwnoq.fsf@starship.python.net> Message-ID: <45C069EC.1030302@gmx.de> Michael Hudson wrote: > Have you seen Armin's autoctypes? > > https://codespeak.net/viewvc/user/arigo/hack/pypy-hack/autoctypes/ > > Scary code, and a rather different approach :-) and it does not work for wrapping C++ code, right? >> It seems kind of strange to say that PyPy can't be practical without >> implementing the CPython extension API, since to my knowledge IronPython >> will not implement it (and Jython never has) and people are afraid that >> IronPython will be such a great Python alternative that it will fragment >> the Python community. > > I don't think anyone has quite claimed that; I thought the claim was > that supporting the CPython API would make PyPy a practical platform > faster, and it's hard to disagree with that. Whether it's worth the > effort involved is another question of course :-) > > The whole "interacting with the outside world" thing is a, probably > /the/, most significant thing between here and a practical PyPy. > Currently, there is no such thing as a PyPy extension module, and > that's something that will need to change. Just a small addition, to not have wrong impressions: There _are_ PyPy extension modules. They are called mixed modules (since you can mix app-level and interpreter-level code in them). It's just that they are not really extension modules in the sense that you can compile them independently from PyPy and load them as a .so (or whatever) later. Cheers, Carl Friedrich From mwh at python.net Wed Jan 31 11:49:32 2007 From: mwh at python.net (Michael Hudson) Date: Wed, 31 Jan 2007 11:49:32 +0100 Subject: [pypy-dev] Does/will pypy support cpython's c extension modules? References: <20070123161155.4ab9bf59.simon@arrowtheory.com> <8a6b8e350701231854w3ca6de8bi7cfa9f78943b7bb9@mail.gmail.com> <45BE45EE.5090605@literati.org> <20070130144449.GE24191@mithrandi.za.net> <45BF9E4D.1090604@literati.org> <87ejpbwnoq.fsf@starship.python.net> <45C069EC.1030302@gmx.de> Message-ID: <878xfjwjwj.fsf@starship.python.net> Carl Friedrich Bolz writes: > Michael Hudson wrote: > > Have you seen Armin's autoctypes? > > > > https://codespeak.net/viewvc/user/arigo/hack/pypy-hack/autoctypes/ > > > > Scary code, and a rather different approach :-) > > and it does not work for wrapping C++ code, right? Well, I don't know; it works by compiling snippets of C++ so maybe it has a chance... > >> It seems kind of strange to say that PyPy can't be practical without > >> implementing the CPython extension API, since to my knowledge IronPython > >> will not implement it (and Jython never has) and people are afraid that > >> IronPython will be such a great Python alternative that it will fragment > >> the Python community. > > > > I don't think anyone has quite claimed that; I thought the claim was > > that supporting the CPython API would make PyPy a practical platform > > faster, and it's hard to disagree with that. Whether it's worth the > > effort involved is another question of course :-) > > > > The whole "interacting with the outside world" thing is a, probably > > /the/, most significant thing between here and a practical PyPy. > > Currently, there is no such thing as a PyPy extension module, and > > that's something that will need to change. > > Just a small addition, to not have wrong impressions: There _are_ PyPy > extension modules. They are called mixed modules (since you can mix > app-level and interpreter-level code in them). It's just that they are > not really extension modules in the sense that you can compile them > independently from PyPy and load them as a .so (or whatever) later. Right yes, that's what I meant, thanks for the clarification. Maybe I should emphasized the _extension_ part... Cheers, mwh -- I located the link but haven't bothered to re-read the article, preferring to post nonsense to usenet before checking my facts. -- Ben Wolfson, comp.lang.python From cfbolz at gmx.de Thu Feb 1 12:00:32 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Thu, 01 Feb 2007 12:00:32 +0100 Subject: [pypy-dev] pypy 1.0 release meeting invitation In-Reply-To: <87veiowkla.fsf@starship.python.net> References: <87veiowkla.fsf@starship.python.net> Message-ID: <45C1C850.9090309@gmx.de> Hi all! Michael Hudson wrote: > Task Planning > ============= > > This topic is to collect tasks to be done for the release and divide them > among people. Some tasks that we could think of: > > * work out a timeframe for jit usefulness > * fix llvm(?) > * test pypy-cs, run benchmarks. > * windows testing! > * documentation!!! > * pypy.net > * object optimizations (WP6) > * release announcement > * improve getting-started > * transparent proxies > * security prototype > * make build-tool useable > * polish js backend? Another task that I came up with: we should try to document our config options. Maybe not the more obscure ones, though :-). Imo this is quite important, since the list of options is very big and makes it hard to find what you are looking for. There should also be more "high-level" options like --allworkingmodules and --faassen (which should be renamed for the release, I guess :-) ). And maybe a small "guide through the option jungle" or something like this. Cheers, Carl Friedrich From paul.degrandis at gmail.com Thu Feb 1 15:12:09 2007 From: paul.degrandis at gmail.com (Paul deGrandis) Date: Thu, 1 Feb 2007 09:12:09 -0500 Subject: [pypy-dev] pypy 1.0 release meeting invitation In-Reply-To: <45C1C850.9090309@gmx.de> References: <87veiowkla.fsf@starship.python.net> <45C1C850.9090309@gmx.de> Message-ID: <9c0bb8a00702010612j3c347503j87dba823daa7f79f@mail.gmail.com> I think this is a good idea. Also, not so much part of the PyPy 1.0 release, but I'll have the command line compiler done this weekend. I'll host to source on my servers and email the list when it's up. Paul On 2/1/07, Carl Friedrich Bolz wrote: > > Hi all! > > Michael Hudson wrote: > > Task Planning > > ============= > > > > This topic is to collect tasks to be done for the release and divide > them > > among people. Some tasks that we could think of: > > > > * work out a timeframe for jit usefulness > > * fix llvm(?) > > * test pypy-cs, run benchmarks. > > * windows testing! > > * documentation!!! > > * pypy.net > > * object optimizations (WP6) > > * release announcement > > * improve getting-started > > * transparent proxies > > * security prototype > > * make build-tool useable > > * polish js backend? > > Another task that I came up with: we should try to document our config > options. Maybe not the more obscure ones, though :-). Imo this is quite > important, since the list of options is very big and makes it hard to > find what you are looking for. > > There should also be more "high-level" options like --allworkingmodules > and --faassen (which should be renamed for the release, I guess :-) ). > And maybe a small "guide through the option jungle" or something like > this. > > Cheers, > > Carl Friedrich > > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/pypy-dev/attachments/20070201/ddd2c6ba/attachment.htm From santagada at gmail.com Sat Feb 3 14:01:35 2007 From: santagada at gmail.com (Leonardo Santagada) Date: Sat, 3 Feb 2007 14:01:35 +0100 Subject: [pypy-dev] JS Interpreter and the mozilla testing suite Message-ID: We are able to parse most of the mozilla suite of tests, so I made a little driver (a thing that runs the mozilla suite) to run the tests against our interpreter. Most of the tests suite breaks after the parsing on some missing opcode or when trying to access some non implemented function (or object, or prototype, or constructor). The parts that get as far as finishing building the test cases are here: 6-2.js passed 5 of 5 tests 7.1-1.js passed 4 of 4 tests 7.1-2.js passed 3 of 3 tests 7.7.2.js passed 1 of 1 tests 7.7.3-1.js passed 25 of 25 tests 7.7.3.js passed 166 of 184 tests 10.1.3.js passed 15 of 15 tests 10.1.6.js passed 0 of 16 tests 10.2.3-1.js passed 0 of 2 tests 11.12-1.js passed 6 of 6 tests 11.13.2-2.js passed 2 of 58 tests 11.13.2-3.js passed 2 of 76 tests 11.13.2-4.js passed 14 of 36 tests 11.13.2-5.js passed 6 of 44 tests 11.13.js passed 6 of 6 tests 11.14-1.js passed 2 of 2 tests 11.2.2-11.js passed 1 of 1 tests 11.5.1.js passed 26 of 26 tests 11.6.3.js passed 20 of 24 tests 11.9.1.js passed 29 of 63 tests 11.9.2.js passed 29 of 63 tests 11.9.3.js passed 29 of 63 tests 12.5-1.js passed 3 of 7 tests 12.5-2.js passed 3 of 7 tests 15.1.1.1.js passed 2 of 2 tests 15.1.1.2.js passed 2 of 2 tests 15.2.2.2.js passed 2 of 2 tests 15.3.5.1.js passed 0 of 2 tests 15.4.1.3.js passed 1 of 5 tests 15.4.2.2-2.js passed 0 of 14 tests 15.6.1.js passed 19 of 19 tests 15.6.3.1-4.js passed 0 of 2 tests 15.6.3.js passed 0 of 2 tests 15.6.4.2-1.js passed 0 of 46 tests 15.7.3.1-2.js passed 0 of 2 tests 15.8-1.js passed 0 of 2 tests Not much but this is just the start. If someone wants to run all tests on their machines just checkout the latest revision and run driver.py... it will try to run all the test suite (yep, i'm planning on improving this) and write the results to result.txt while on screen you get what tests are running. Warning: this might take some hours Somehow my code crashed the python interpreter (2.4.4) on one of the test files... will try to reproduce the crash and send a bug report upstream. Now I will work on some simple stuff like the MOD operator and this kind of stuff to make more tests run :) abra?os, Leonardo Santagada From nytrokiss at gmail.com Sun Feb 4 01:13:56 2007 From: nytrokiss at gmail.com (James Matthews) Date: Sat, 3 Feb 2007 19:13:56 -0500 Subject: [pypy-dev] JS Interpreter and the mozilla testing suite In-Reply-To: References: Message-ID: <8a6b8e350702031613v72c218f5x412c8368fe5baccd@mail.gmail.com> Great! On 2/3/07, Leonardo Santagada wrote: > > We are able to parse most of the mozilla suite of tests, so I made a > little driver (a thing that runs the mozilla suite) to run the tests > against our interpreter. Most of the tests suite breaks after the > parsing on some missing opcode or when trying to access some non > implemented function (or object, or prototype, or constructor). The > parts that get as far as finishing building the test cases are here: > > 6-2.js passed 5 of 5 tests > 7.1-1.js passed 4 of 4 tests > 7.1-2.js passed 3 of 3 tests > 7.7.2.js passed 1 of 1 tests > 7.7.3-1.js passed 25 of 25 tests > 7.7.3.js passed 166 of 184 tests > 10.1.3.js passed 15 of 15 tests > 10.1.6.js passed 0 of 16 tests > 10.2.3-1.js passed 0 of 2 tests > 11.12-1.js passed 6 of 6 tests > 11.13.2-2.js passed 2 of 58 tests > 11.13.2-3.js passed 2 of 76 tests > 11.13.2-4.js passed 14 of 36 tests > 11.13.2-5.js passed 6 of 44 tests > 11.13.js passed 6 of 6 tests > 11.14-1.js passed 2 of 2 tests > 11.2.2-11.js passed 1 of 1 tests > 11.5.1.js passed 26 of 26 tests > 11.6.3.js passed 20 of 24 tests > 11.9.1.js passed 29 of 63 tests > 11.9.2.js passed 29 of 63 tests > 11.9.3.js passed 29 of 63 tests > 12.5-1.js passed 3 of 7 tests > 12.5-2.js passed 3 of 7 tests > 15.1.1.1.js passed 2 of 2 tests > 15.1.1.2.js passed 2 of 2 tests > 15.2.2.2.js passed 2 of 2 tests > 15.3.5.1.js passed 0 of 2 tests > 15.4.1.3.js passed 1 of 5 tests > 15.4.2.2-2.js passed 0 of 14 tests > 15.6.1.js passed 19 of 19 tests > 15.6.3.1-4.js passed 0 of 2 tests > 15.6.3.js passed 0 of 2 tests > 15.6.4.2-1.js passed 0 of 46 tests > 15.7.3.1-2.js passed 0 of 2 tests > 15.8-1.js passed 0 of 2 tests > > Not much but this is just the start. If someone wants to run all > tests on their machines just checkout the latest revision and run > driver.py... it will try to run all the test suite (yep, i'm planning > on improving this) and write the results to result.txt while on > screen you get what tests are running. Warning: this might take some > hours > > Somehow my code crashed the python interpreter (2.4.4) on one of the > test files... will try to reproduce the crash and send a bug report > upstream. > > Now I will work on some simple stuff like the MOD operator and this > kind of stuff to make more tests run :) > > abra?os, > Leonardo Santagada > > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -- http://www.goldwatches.com http://www.wazoozle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/pypy-dev/attachments/20070203/9f0a93f8/attachment.htm From Ben.Young at risk.sungard.com Thu Feb 8 09:24:16 2007 From: Ben.Young at risk.sungard.com (Ben.Young at risk.sungard.com) Date: Thu, 8 Feb 2007 08:24:16 +0000 Subject: [pypy-dev] [pypy-svn] r38126 - pypy/dist/pypy In-Reply-To: <20070207222934.68B941007F@code0.codespeak.net> Message-ID: Hi Carl, Did you mean to return a dictionary here? Or am I missing something obvious :) ? Good luck to everyone with the release! Cheers, Ben Ben Young - Senior Software Engineer SunGard - Enterprise House, Vision Park, Histon, Cambridge, CB24 9ZR Tel +44 1223 266042 - Main +44 1223 266000 - http://www.sungard.com/ CONFIDENTIALITY: This email (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you received this email in error, please notify the sender and delete this email from your system. Thank you. cfbolz at codespeak.net Sent by: pypy-svn-bounces at codespeak.net 07/02/2007 22:29 Please respond to pypy-dev at codespeak.net To pypy-svn at codespeak.net cc Subject [pypy-svn] r38126 - pypy/dist/pypy Author: cfbolz Date: Wed Feb 7 23:29:30 2007 New Revision: 38126 Modified: pypy/dist/pypy/conftest.py Log: add space.newlist op (to give parsing test a chance to pass). Modified: pypy/dist/pypy/conftest.py ============================================================================== --- pypy/dist/pypy/conftest.py (original) +++ pypy/dist/pypy/conftest.py Wed Feb 7 23:29:30 2007 @@ -93,6 +93,9 @@ def is_true(self, obj): return bool(obj) + def newlist(self): + return {} + class OpErrKeyboardInterrupt(KeyboardInterrupt): pass _______________________________________________ pypy-svn mailing list pypy-svn at codespeak.net http://codespeak.net/mailman/listinfo/pypy-svn From cfbolz at gmx.de Thu Feb 8 09:46:14 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Thu, 08 Feb 2007 09:46:14 +0100 Subject: [pypy-dev] [pypy-svn] r38126 - pypy/dist/pypy In-Reply-To: References: Message-ID: <45CAE356.308@gmx.de> Hi Ben! Ben.Young at risk.sungard.com wrote: > Did you mean to return a dictionary here? Or am I missing something > obvious :) ? No, I meant to write newdict instead of newslist. Thanks for watching! > Good luck to everyone with the release! Cheers, Carl Friedrich From arigo at tunes.org Thu Feb 8 12:23:21 2007 From: arigo at tunes.org (Armin Rigo) Date: Thu, 8 Feb 2007 12:23:21 +0100 Subject: [pypy-dev] JIT status Message-ID: <20070208112320.GA31391@code0.codespeak.net> Hi all, The JIT has now reached the state it will have in the upcoming PyPy release (it's still on a branch, but it will be merged). What it does is produce machine code in memory, and run it. What it does not do is gain much speed by doing so. Yet. It's just bad timing that the release and EU-driven deadlines mean that we have no time left to put the pieces together now - but essentially they are there already. We expect the jit to become useful during March, and then we'll in all likeliness do another release - if only because we promized to the EU numbers like "50% of the speed of C" for the most extremely algorithmic examples. Back to the present. Let me describe the current status. The produced machine code is kind of good (the backend performs some liftime analysis and register allocation). The "timeshifter", which produces the jit frontend, is able to handle rather incredibly tricky situations successfully. From a user point of view the jit has some rough edges but nothing fundamental, and by construction it can jit absolutely any kind of Python code - generators, nested scopes, exec statements, sys._getframe().f_back.f_back.f_locals, etc. At the moment only the interpreter's main dispatch loop (i.e. mostly only pyopcode.py) is fed to the timeshifter, so the produced jit can remove the bytecode interpretation overhead, but cannot look inside the implementation of space.add(), for example. So it gives results that look like Python2C+gcc: it produces machine code that is essentially a sequence of calls to space.add(), space.cmp(), space.is_true(), etc. As we all know, Python2C gives a ~2x speed-up; we get about the same with our jit, except that the start-up overhead is greater - calling small functions is still quite slower with the jit than without. On the other hand, Python2C doesn't emulate frames, for example, so AFAIK pypy contains the first Python compiler ever where sys._getframe() completely works (Psyco emulates frames but not at 100%). Only the 386 backend is complete; mwh guesses that there is some degree of likeliness that the ppc backend will be completed in time for the release too. How to compile a pypy-c with a jit: use translate.py on targetjit (located in pypy/jit/goal/). Then: export PYPYJITLOG=log # logs machine code into file 'log' pypy-c >>> def f(x): return x*5 >>> import pypyjit >>> pypyjit.enable(f.func_code) >>> f(7) ..../jit/codegen/i386/viewcode.py log A bientot, Armin. From arigo at tunes.org Thu Feb 8 13:26:30 2007 From: arigo at tunes.org (Armin Rigo) Date: Thu, 8 Feb 2007 13:26:30 +0100 Subject: [pypy-dev] release planning Message-ID: <20070208122630.GA11511@code0.codespeak.net> Hi, I've created extradoc/planning/1.0/ to put txt files planning the tasks of the upcoming release. If you want to help with the documentation, check if I missed something and possibly assign yourself to the items there. (I've put my name on two items only so far but I plan to do more.) Armin From arigo at tunes.org Thu Feb 8 20:35:12 2007 From: arigo at tunes.org (Armin Rigo) Date: Thu, 8 Feb 2007 20:35:12 +0100 Subject: [pypy-dev] pypy/dist => pypy/trunk Message-ID: <20070208193512.GA27892@code0.codespeak.net> Hi ! As part of the preparation for the upcoming release, we are going to implement the idea that 'pypy/trunk' will be for the future a better name for normal development to go on, and 'pypy/dist' is a better name for the place where people can get something stable. So we will soon copy pypy/dist to pypy/trunk, to get: * http://codespeak.net/svn/pypy/trunk => the normal development repo * http://codespeak.net/svn/pypy/dist => a stable snapshot The idea is that people that would like to get a known-working but recent PyPy can checkout or update the pypy/dist path, and people working on PyPy itself can work in pypy/trunk. When this is done (due sometime between tomorrow and Monday) most checkins should go to pypy/trunk. Holger will write-protect pypy/dist to avoid accidental checkins. Reminder: you can switch your existing working copy by doing: svn info # look at URL, which must be exactly http://codespeak.net/svn/pypy/dist # and then do: svn switch http://codespeak.net/svn/pypy/trunk It really works like an update, so it should keep your local changes, which you can then checkin (and they go to the new location, pypy/trunk). But never fully trust svn: if you have something important better make a backup of the working copy first. A bientot, Armin From holger at merlinux.de Fri Feb 9 01:14:37 2007 From: holger at merlinux.de (holger krekel) Date: Fri, 9 Feb 2007 01:14:37 +0100 Subject: [pypy-dev] changes from py-trunk / dist merge (38224) Message-ID: <20070209001437.GT16146@solar.trillke> Hi all, so i just merged the py-trunk branch to py-dist (which is the one used as an external by pypy-dist currently) and also did a few changes to pypy-dist itself to accomodate for the new situation. The update includes a number of internal cleanups and refactorings, most of which should not be visible from the user side (well, we also cleaned up all py.* namespaces to only provide what is supposed to be maintained in the future, that might catch you). And lots of documentation updates, including docstrings. For distributed testing the options you can put into conftest.py files have now more systematic names and meanings: * `dist_hosts`: a required list of host specifications * `dist_rsync_roots` - a list of relative locations to copy to the remote machines. * `dist_rsync_ignore` - a list of relative locations to ignore for rsyncing * `dist_remotepython` - the remote python executable to run. * `dist_nicelevel` - process priority of remote nodes. * `dist_boxed` - will run each single test in a separate process (allowing to survive segfaults for example) * `dist_taskspernode` - Maximum number of tasks being queued to remote nodes NOTE that pypy/conftest.py defines dist_rsync_roots (and dist_rsync_ignore) itself so you don't need to do that yourself anymore. Ah, and in case we didn't mention it yet, you invoke distributed testing with one of: py.test -d py.test --dist Noticeable is also that Stdout/Stderr capturing is now done FD-based instead of only patching sys.stdout/stderr. In other non-pypy related news, the tkinter and py.path.extpy classes got removed, and some other not-really-used stuff (or so i presume :). Please let us know if you experience any regressions/problems as the current py-dist is soon to become the 0.9 release (there still is a bit of documentation and packaging work to be done, and fixing bugs). best, holger with lots of help/work from fijal, guido and cf P.S.: Armin, we didn't fix htmlconftest yet. -- merlinux GmbH Steinbergstr. 42 31139 Hildesheim http://merlinux.de tel +49 5121 20800 75 (fax 77) From anto.cuni at gmail.com Fri Feb 9 14:10:48 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Fri, 09 Feb 2007 14:10:48 +0100 Subject: [pypy-dev] Status of pypy-c under Windows Message-ID: <45CC72D8.2090006@gmail.com> Hi all! As we agreed on #pypy-sync, I've spent the last days in investigating & testing the translation of pypy-c under Windows. My box runs Windows XP SP 1 under vmware. To get a C compiler I installed the C++ package of Visual Studio .NET 2003; maybe it could work also with other version of Visual Studio, I don't know. Surprisingly enough, the translation of pypy-c worked out of the box :-). I only had to install the windows version of boehm using the howto in the docstring of goal/win32/gc_path_windows.py, then ./translate. Then, I ran the lib-python tests against pypy-c.exe. The results are here: http://codespeak.net/~antocuni/pypy-c-win32-results/ Some of the failures are quite easy to explain (for example, test_thread fails because threading was disabled :-)), some other are very strange. Btw, more than 90% of tests passes. To run the tests I had to manually disable test_mailbox.py, because it couldn't cleanup the @test directory it creates and this caused next tests to fail. I tried to investigate a bit in that direction, then I remembered that windows sucks and I gave up :-). ciao Anto From joe at merlinux.de Fri Feb 9 19:03:23 2007 From: joe at merlinux.de (Martin Pajak) Date: Fri, 09 Feb 2007 19:03:23 +0100 Subject: [pypy-dev] codespeak.net downtime due to hosts switch Message-ID: <45CCB76B.4030104@merlinux.de> Hello all, in recent weeks, codespeak.net has been causing some problems, mostly internal ones but ones to be taken seriously (kernel oops - mostly resulting in the need to restart). So we plan to switch to another host system, and then investigate further on the to-be-old system. As there are releases pending, i'd like to get the migration done before that and plan to do it: Feb 10th, saturday, around 10 AM GMT+2 if nobody objects. In case of problems i will switch back to the old system by means of a DNS switch (and i'll take special care that no mails or commits go astray) greetings, Martin From scott+pypy-dev at scottdial.com Fri Feb 9 22:11:16 2007 From: scott+pypy-dev at scottdial.com (Scott Dial) Date: Fri, 09 Feb 2007 16:11:16 -0500 Subject: [pypy-dev] Status of pypy-c under Windows In-Reply-To: <45CC72D8.2090006@gmail.com> References: <45CC72D8.2090006@gmail.com> Message-ID: <45CCE374.4080402@scottdial.com> Antonio Cuni wrote: > Hi all! > > As we agreed on #pypy-sync, I've spent the last days in investigating & > testing the translation of pypy-c under Windows. > My apologies for having let my automated testing fall to pieces. Somewhere about a month ago the working copy got damaged and "svn up" stopped working bringing a halt to the whole process. I attempted to revive it last night, however I can't seem to get Armin's scripts to work anymore.. my only guess is that it is related to the "P.S.: Armin, we didn't fix htmlconftest yet." from holger. Because I can run the test suite just fine, however no html files are being generated. If anyone has a solution, then I'll get the win32 testing back up and running. Unless you are planning to run it on a regular basis, in which case I can just resign my box from doing that. Along the same lines as you, it was relatively painless. The only difference was that I am using the free VCToolkit compiler and Platform SDK instead of a full-fledge install of Visual Studio. (I accidentally sent this to only Antonio before, so sorry to Antonio for the dup.) -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu From holger at merlinux.de Fri Feb 9 22:25:57 2007 From: holger at merlinux.de (holger krekel) Date: Fri, 9 Feb 2007 22:25:57 +0100 Subject: [pypy-dev] Status of pypy-c under Windows In-Reply-To: <45CCE374.4080402@scottdial.com> References: <45CC72D8.2090006@gmail.com> <45CCE374.4080402@scottdial.com> Message-ID: <20070209212557.GE16146@solar.trillke> Hi Scott! On Fri, Feb 09, 2007 at 16:11 -0500, Scott Dial wrote: > Antonio Cuni wrote: > > Hi all! > > > > As we agreed on #pypy-sync, I've spent the last days in investigating & > > testing the translation of pypy-c under Windows. > > > > My apologies for having let my automated testing fall to pieces. > Somewhere about a month ago the working copy got damaged and "svn up" > stopped working bringing a halt to the whole process. I attempted to > revive it last night, however I can't seem to get Armin's scripts to > work anymore.. my only guess is that it is related to the "P.S.: Armin, > we didn't fix htmlconftest yet." from holger. Because I can run the test > suite just fine, however no html files are being generated. If anyone > has a solution, then I'll get the win32 testing back up and running. i think it would help. Indeed, last night was unfortunate timing ... fijal tried to fix htmlconftest, does it work for you now maybe? If not, it will be fixed in the next days, i am sure. > Unless you are planning to run it on a regular basis, in which case I > can just resign my box from doing that. if you can keep it up for now, that'd be good, i think. > Along the same lines as you, it was relatively painless. The only > difference was that I am using the free VCToolkit compiler and Platform > SDK instead of a full-fledge install of Visual Studio. could you provide a few url-references how to do this oneself? best & thanks! holger From scott+pypy-dev at scottdial.com Sat Feb 10 00:41:52 2007 From: scott+pypy-dev at scottdial.com (Scott Dial) Date: Fri, 09 Feb 2007 18:41:52 -0500 Subject: [pypy-dev] Status of pypy-c under Windows In-Reply-To: <20070209212557.GE16146@solar.trillke> References: <45CC72D8.2090006@gmail.com> <45CCE374.4080402@scottdial.com> <20070209212557.GE16146@solar.trillke> Message-ID: <45CD06C0.3000902@scottdial.com> holger krekel wrote: > On Fri, Feb 09, 2007 at 16:11 -0500, Scott Dial wrote: >> My apologies for having let my automated testing fall to pieces. >> Somewhere about a month ago the working copy got damaged and "svn up" >> stopped working bringing a halt to the whole process. I attempted to >> revive it last night, however I can't seem to get Armin's scripts to >> work anymore.. my only guess is that it is related to the "P.S.: Armin, >> we didn't fix htmlconftest yet." from holger. Because I can run the test >> suite just fine, however no html files are being generated. If anyone >> has a solution, then I'll get the win32 testing back up and running. > > i think it would help. Indeed, last night was unfortunate timing ... > fijal tried to fix htmlconftest, does it work for you now maybe? > If not, it will be fixed in the next days, i am sure. It does indeed appear to be working. I'm currently in the middle of a run. I had to revert from using svnwcrevert to update the working copy. I kept getting an AttributeError about not having a 'locked' attribute on something or other. My problem in the past was the SVN data getting out of whack, so I dunno even despite the fresh checkout. I've decided to let TortoiseSVN handle the updating.. we'll see how well that lasts. I would share with you my patches to the autotest.py but they feel very homegrown and not very generalized. Let me know if you are interested at all in that. >> Unless you are planning to run it on a regular basis, in which case I >> can just resign my box from doing that. > > if you can keep it up for now, that'd be good, i think. Will do. >> Along the same lines as you, it was relatively painless. The only >> difference was that I am using the free VCToolkit compiler and Platform >> SDK instead of a full-fledge install of Visual Studio. > > could you provide a few url-references how to do this oneself? > My build environment is derived from the tools need to build CPython extensions[1] with an extra patch[2] to keep the PATH a sane length (duplicates PATH entries). I don't remember what hackery was required to get gc6.8 to build other than info about boehm already available. For reference, I've made a patch reflecting my changes[3]. Unfortunately (as has been hashed out on python-dev quite a bit), the VC Toolkit 2003 is not made available by Microsoft anymore. I've not attempted to use the 2005 Express Edition compiler, but for the purposes of compiling pypy, it should work fine unless you are trying to build a module to load into CPython. I retain a copy of the VCToolkitSetup.exe install and it can still be found 3rd-party (MD5 90d8b963ca196aa9855b2ca6c3174c14). [1] http://www.vrplumber.com/programming/mstoolkit/ [2] http://scottdial.com/pypy-dev/msvccompiler.py.diff [3] http://scottdial.com/pypy-dev/NT_THREADS_MAKEFILE.diff -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu From scott+pypy-dev at scottdial.com Sat Feb 10 02:06:44 2007 From: scott+pypy-dev at scottdial.com (Scott Dial) Date: Fri, 09 Feb 2007 20:06:44 -0500 Subject: [pypy-dev] Status of pypy-c under Windows In-Reply-To: <45CD06C0.3000902@scottdial.com> References: <45CC72D8.2090006@gmail.com> <45CCE374.4080402@scottdial.com> <20070209212557.GE16146@solar.trillke> <45CD06C0.3000902@scottdial.com> Message-ID: <45CD1AA4.40306@scottdial.com> Scott Dial wrote: > It does indeed appear to be working. I'm currently in the middle of a > run. The run completely successfully, it can be found at the same URL it was at before: http://scottdial.com/pypytest/ -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu From holger at merlinux.de Sat Feb 10 11:20:37 2007 From: holger at merlinux.de (holger krekel) Date: Sat, 10 Feb 2007 11:20:37 +0100 Subject: [pypy-dev] codespeak.net downtime due to hosts switch In-Reply-To: <45CCB76B.4030104@merlinux.de> References: <45CCB76B.4030104@merlinux.de> Message-ID: <20070210102037.GM16146@solar.trillke> Hi again, Martin has done the switch successfully (the new codespeak.net IP address is 88.198.148.44, btw). and svn and mail seems to be in order. please report any regressions or problems to admin at codespeak.net or support at merlinux.de or ping joe_mp_ on #pypy. best, holger On Fri, Feb 09, 2007 at 19:03 +0100, Martin Pajak wrote: > Hello all, > > in recent weeks, codespeak.net has been causing some problems, > mostly internal ones but ones to be taken seriously > (kernel oops - mostly resulting in the need to restart). > So we plan to switch to another host system, and then > investigate further on the to-be-old system. As > there are releases pending, i'd like to get the > migration done before that and plan to do it: > > Feb 10th, saturday, around 10 AM GMT+2 > > if nobody objects. In case of problems i will > switch back to the old system by means of a DNS > switch (and i'll take special care that no mails > or commits go astray) > > greetings, Martin > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -- merlinux GmbH Steinbergstr. 42 31139 Hildesheim http://merlinux.de tel +49 5121 20800 75 (fax 77) From anto.cuni at gmail.com Sat Feb 10 10:21:31 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Sat, 10 Feb 2007 10:21:31 +0100 Subject: [pypy-dev] Status of pypy-c under Windows In-Reply-To: <45CD1AA4.40306@scottdial.com> References: <45CC72D8.2090006@gmail.com> <45CCE374.4080402@scottdial.com> <20070209212557.GE16146@solar.trillke> <45CD06C0.3000902@scottdial.com> <45CD1AA4.40306@scottdial.com> Message-ID: <45CD8E9B.4040306@gmail.com> Scott Dial wrote: > Scott Dial wrote: >> It does indeed appear to be working. I'm currently in the middle of a >> run. > > The run completely successfully, it can be found at the same URL it was > at before: http://scottdial.com/pypytest/ This is very cool, thank you! I've noticed that most of CLI tests are skipped because the .NET SDK is not installed: could you install it please, if it's not a problem? I've got a windows box under vmware but running all the CLI tests there on a regular basis is not very convenient: il would be very useful to have the daily tests also on windows. ciao Anto From scott+pypy-dev at scottdial.com Sat Feb 10 21:56:31 2007 From: scott+pypy-dev at scottdial.com (Scott Dial) Date: Sat, 10 Feb 2007 15:56:31 -0500 Subject: [pypy-dev] rlib.parsing.test.test_ebnfparse / test_jsonparse Message-ID: <45CE317F.5090202@scottdial.com> This test is invoking pygame despite what seems to be an attempt to have that be an option of the testing suite. This is happening on snake and my win32 box, but unfortunately my box actually has pygame installed. Thus, the testing gets halted waiting on me to click the [X]. I don't know the appropriate change to make, so I will defer patching it to whoever knows that. -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu From holger at merlinux.de Sat Feb 10 22:15:50 2007 From: holger at merlinux.de (holger krekel) Date: Sat, 10 Feb 2007 22:15:50 +0100 Subject: [pypy-dev] rlib.parsing.test.test_ebnfparse / test_jsonparse In-Reply-To: <45CE317F.5090202@scottdial.com> References: <45CE317F.5090202@scottdial.com> Message-ID: <20070210211550.GR16146@solar.trillke> Hi Scott! On Sat, Feb 10, 2007 at 15:56 -0500, Scott Dial wrote: > This test is invoking pygame despite what seems to be an attempt to have > that be an option of the testing suite. This is happening on snake and > my win32 box, but unfortunately my box actually has pygame installed. > Thus, the testing gets halted waiting on me to click the [X]. I don't > know the appropriate change to make, so I will defer patching it to > whoever knows that. that pygame-invocation should be fixed/removed now. holger From cfbolz at gmx.de Sat Feb 10 22:18:07 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sat, 10 Feb 2007 22:18:07 +0100 Subject: [pypy-dev] rlib.parsing.test.test_ebnfparse / test_jsonparse In-Reply-To: <20070210211550.GR16146@solar.trillke> References: <45CE317F.5090202@scottdial.com> <20070210211550.GR16146@solar.trillke> Message-ID: <45CE368F.2030703@gmx.de> Hi! holger krekel wrote: > On Sat, Feb 10, 2007 at 15:56 -0500, Scott Dial wrote: >> This test is invoking pygame despite what seems to be an attempt to have >> that be an option of the testing suite. This is happening on snake and >> my win32 box, but unfortunately my box actually has pygame installed. >> Thus, the testing gets halted waiting on me to click the [X]. I don't >> know the appropriate change to make, so I will defer patching it to >> whoever knows that. > > that pygame-invocation should be fixed/removed now. it is indeed now. sorry for the trouble, it was a checkin of mine. cheers, Carl Friedrich From scott+pypy-dev at scottdial.com Sun Feb 11 06:55:57 2007 From: scott+pypy-dev at scottdial.com (Scott Dial) Date: Sun, 11 Feb 2007 00:55:57 -0500 Subject: [pypy-dev] Status of pypy-c under Windows In-Reply-To: <45CD8E9B.4040306@gmail.com> References: <45CC72D8.2090006@gmail.com> <45CCE374.4080402@scottdial.com> <20070209212557.GE16146@solar.trillke> <45CD06C0.3000902@scottdial.com> <45CD1AA4.40306@scottdial.com> <45CD8E9B.4040306@gmail.com> Message-ID: <45CEAFED.8080300@scottdial.com> Antonio Cuni wrote: > I've noticed that most of CLI tests are skipped because the .NET SDK is > not installed: could you install it please, if it's not a problem? Not a problem. Done. Most of the tests that were being skipped are causing failures now.. but I was able to translate a pypy-cli without error, so I am convinced I haven't made a mistake. However let me know if I am wrong about that. Otherwise notable is the benchmark results I received: executable richards pystone size (MB) pypy-cli-38437 75124 123.0x 495.2 109.5x 8.398 pypy-c-38437 3148 5.2x 11345.0 4.8x 2.527 python 2.4.3 610 1.0x 54227.7 1.0x 1.790 -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu From tismer at stackless.com Tue Feb 13 06:10:20 2007 From: tismer at stackless.com (Christian Tismer) Date: Mon, 12 Feb 2007 21:10:20 -0800 Subject: [pypy-dev] pypy won't compile Message-ID: <45D1483C.8090209@stackless.com> Hi folks, I just tried to build pypy on my mac, but I get an annotation error. [translation:ERROR] AssertionError': built-in class not found in typename_mapping while compiling _compile [translation:ERROR] .. v500 = getattr(self_30, ('w_dict')) [translation:ERROR] .. '(pypy.interpreter.mixedmodule:34)MixedModule.getdictvalue' [translation:ERROR] Processing block: [translation:ERROR] block at 3 is a [translation:ERROR] in (pypy.interpreter.mixedmodule:34)MixedModule.getdictvalue [translation:ERROR] containing the following operations: [translation:ERROR] v501 = getattr(space_0, ('finditem')) [translation:ERROR] v500 = getattr(self_30, ('w_dict')) [translation:ERROR] v502 = simple_call(v501, v500, w_name_0) [translation:ERROR] v503 = getattr(self_30, ('lazy')) [translation:ERROR] v504 = is_true(v503) [translation:ERROR] --end-- rev. 38657 checked out on OSX, Python 2.5 I installed nothing yet. Maybe something missing? cheers - chris From scott+pypy-dev at scottdial.com Tue Feb 13 14:16:52 2007 From: scott+pypy-dev at scottdial.com (Scott Dial) Date: Tue, 13 Feb 2007 08:16:52 -0500 Subject: [pypy-dev] pypy won't compile In-Reply-To: <45D1483C.8090209@stackless.com> References: <45D1483C.8090209@stackless.com> Message-ID: <45D1BA44.9070300@scottdial.com> Christian Tismer wrote: > Hi folks, > > I just tried to build pypy on my mac, but I get an annotation > error. > > rev. 38657 checked out on OSX, Python 2.5 > > I installed nothing yet. Maybe something missing? > AFAIK, pypy is still targeted at Python 2.4 and there are still lingering bugs when using Python 2.5. -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu From tismer at stackless.com Tue Feb 13 21:55:49 2007 From: tismer at stackless.com (Christian Tismer) Date: Tue, 13 Feb 2007 12:55:49 -0800 Subject: [pypy-dev] pypy won't compile In-Reply-To: <45D1BA44.9070300@scottdial.com> References: <45D1483C.8090209@stackless.com> <45D1BA44.9070300@scottdial.com> Message-ID: <45D225D5.2010100@stackless.com> Scott Dial wrote: > Christian Tismer wrote: >> Hi folks, >> >> I just tried to build pypy on my mac, but I get an annotation >> error. >> >> rev. 38657 checked out on OSX, Python 2.5 >> >> I installed nothing yet. Maybe something missing? >> > > AFAIK, pypy is still targeted at Python 2.4 and there are still > lingering bugs when using Python 2.5. Oh, thanks! That I did not expect, thought that the upcoming release must be 2.5 for sure. ciao - chris From cfbolz at gmx.de Wed Feb 14 10:16:36 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Wed, 14 Feb 2007 10:16:36 +0100 Subject: [pypy-dev] documentation age Message-ID: <45D2D374.3070102@gmx.de> Hi all! Just a pointer to a wonderful hack [1] that Samuele implemented yesterday evening: http://wyvern.cs.uni-duesseldorf.de/~cfbolz/pypy-dist/pypy/doc/ This is a copy of parts of the PyPy documentation, but with different coloring than usual: The title gives a general age of the document in shades of gray (with white being very young and gray being very old). All the text is colored in shades of yellow, giving the *relative* age of the lines making up a paragraph (using the median of all the revisions). In addition, every paragraph has a tooltip showing its age as a revision number. In my opinion it is quite useful for finding outdated documentation. It can be improved of course, but I think even the current status is very useful. Cheers, Carl Friedrich [1] http://codespeak.net/svn/user/pedronis/docage.py From alexandre.fayolle at logilab.fr Wed Feb 14 12:05:42 2007 From: alexandre.fayolle at logilab.fr (Alexandre Fayolle) Date: Wed, 14 Feb 2007 12:05:42 +0100 Subject: [pypy-dev] news from the logilab internal sprint Message-ID: <20070214110542.GB29454@crater.logilab.fr> Hi, We are having an internal sprint at logilab this week. This mail is to keep you posted about our progress. The WP10 work is in good shape. Adrien and Sylvain managed to translate pypy with the grammar modifications, but the merging will take some time, I think. They are also working on a pylint checker for rpython which hopefully will help beginners trying to produce rpython catch some problems faster than by trying to translate their code. Coming up for the second half of the sprint is the definition of an API for the grammar changes, more stuff for "rpylint" and work on the interim report. WP09 is making rapid progress (with the writing of a rpython module for the constraint library, which will be the basis for a mixed module for CSP) (Aur?lien, Alexandre). Regarding WP11, Ludovic and David have made good progress on the report. Ludovic has done some work to write a busybox-ish tool in rpython and an HTTP server. -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations D?veloppement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science Reprise et maintenance de sites CPS: http://www.migration-cms.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: Digital signature Url : http://codespeak.net/pipermail/pypy-dev/attachments/20070214/a54e3b2b/attachment.pgp From holger at merlinux.de Wed Feb 14 17:51:16 2007 From: holger at merlinux.de (holger krekel) Date: Wed, 14 Feb 2007 17:51:16 +0100 Subject: [pypy-dev] py lib 0.9.0: py.test, distributed execution, microthreads ... Message-ID: <20070214165116.GI16146@solar.trillke> py lib 0.9.0: py.test, distributed execution, greenlets and more ====================================================================== Welcome to the 0.9.0 py lib release - a library aiming to support agile and test-driven python development on various levels. Main API/Tool Features: * py.test: cross-project testing tool with many advanced features * py.execnet: ad-hoc code distribution to SSH, Socket and local sub processes * py.magic.greenlet: micro-threads on standard CPython ("stackless-light") * py.path: path abstractions over local and subversion files * rich documentation of py's exported API * tested against Linux, OSX and partly against Win32, python 2.3-2.5 All these features and their API have extensive documentation, generated with the new "apigen", which we intend to make accessible for other python projects as well. Download/Install: http://codespeak.net/py/0.9.0/download.html Documentation/API: http://codespeak.net/py/0.9.0/index.html Work on the py lib has been partially funded by the European Union IST programme and by http://merlinux.de within the PyPy project. best, have fun and let us know what you think! holger krekel, Maciej Fijalkowski, Guido Wesdorp, Carl Friedrich Bolz From anto.cuni at gmail.com Wed Feb 14 18:44:31 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Wed, 14 Feb 2007 18:44:31 +0100 Subject: [pypy-dev] Status of pypy-c under Windows In-Reply-To: <45CEAFED.8080300@scottdial.com> References: <45CC72D8.2090006@gmail.com> <45CCE374.4080402@scottdial.com> <20070209212557.GE16146@solar.trillke> <45CD06C0.3000902@scottdial.com> <45CD1AA4.40306@scottdial.com> <45CD8E9B.4040306@gmail.com> <45CEAFED.8080300@scottdial.com> Message-ID: <45D34A7F.9040201@gmail.com> Scott Dial wrote: > Antonio Cuni wrote: >> I've noticed that most of CLI tests are skipped because the .NET SDK >> is not installed: could you install it please, if it's not a problem? > > Not a problem. Done. Most of the tests that were being skipped are > causing failures now.. but I was able to translate a pypy-cli without > error, so I am convinced I haven't made a mistake. However let me know > if I am wrong about that. > > Otherwise notable is the benchmark results I received: > > executable richards pystone size (MB) > pypy-cli-38437 75124 123.0x 495.2 109.5x 8.398 > pypy-c-38437 3148 5.2x 11345.0 4.8x 2.527 > python 2.4.3 610 1.0x 54227.7 1.0x 1.790 Hello Scott, sorry for the late answer. I've looked at the failures of gencli under windows: most of them should be easy to fix, I'll do as soon as possibile (not before next week, btw). About the benchmark, I think that the result in wrong, because it's very likely that the build couldn't be performed because of a bug in MS ilasm I've not yet found a workaround for. ciao Anto From gbowyer at fastmail.co.uk Thu Feb 15 00:05:15 2007 From: gbowyer at fastmail.co.uk (Greg Bowyer) Date: Wed, 14 Feb 2007 23:05:15 +0000 Subject: [pypy-dev] pypy won't compile In-Reply-To: <45D225D5.2010100@stackless.com> References: <45D1483C.8090209@stackless.com> <45D1BA44.9070300@scottdial.com> <45D225D5.2010100@stackless.com> Message-ID: Christian Tismer wrote: > Scott Dial wrote: >> Christian Tismer wrote: >>> Hi folks, >>> >>> I just tried to build pypy on my mac, but I get an annotation >>> error. >>> >>> rev. 38657 checked out on OSX, Python 2.5 >>> >>> I installed nothing yet. Maybe something missing? >>> >> AFAIK, pypy is still targeted at Python 2.4 and there are still >> lingering bugs when using Python 2.5. > > Oh, thanks! > That I did not expect, thought that the upcoming release > must be 2.5 for sure. > > ciao - chris > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > Whats left in terms of getting pypy happy with CPython 2.5 ? From pedronis at openendsystems.com Sat Feb 17 20:11:31 2007 From: pedronis at openendsystems.com (Samuele Pedroni) Date: Sat, 17 Feb 2007 20:11:31 +0100 Subject: [pypy-dev] PyPy 0.99 is out: new object spaces, optimizations, configuration ... Message-ID: <45D75363.8060504@openendsystems.com> First thanks to all the people that helped with the release; and to the people that contributed to PyPy so far. ================================================================= pypy-0.99.0: new object spaces, optimizations, configuration ... ================================================================= Welcome to the PyPy 0.99.0 release - a major snapshot and milestone of the last 8 months of work and contributions since PyPy-0.9.0 came out in June 2006! Main entry point for getting-started/download and documentation: http://codespeak.net/pypy/dist/pypy/doc/index.html Further below you'll find some notes about PyPy, the 0.99.0 highlights and our aims for PyPy 1.0. have fun, the PyPy team, Samuele Pedroni, Carl Friedrich Bolz, Armin Rigo, Michael Hudson, Maciej Fijalkowski, Anders Chrigstroem, Holger Krekel, Guido Wesdorp and many others: http://codespeak.net/pypy/dist/pypy/doc/contributor.html What is PyPy? ================================ Technically, PyPy is both a Python Interpreter implementation and an advanced Compiler, actually a framework for implementing dynamic languages and generating virtual machines for them. The Framework allows for alternative frontends and for alternative backends, currently C, LLVM and .NET. For our main target "C", we can can "mix in" different Garbage Collectors and threading models, including micro-threads aka "Stackless". The inherent complexity that arises from this ambitious approach is mostly kept away from the Python interpreter implementation, our main frontend. Socially, PyPy is a collaborative effort of many individuals working together in a distributed and sprint-driven way since 2003. PyPy would not have gotten as far without the coding, feedback and general support from numerous people. Formally, many of the current developers are involved in executing an EU contract with the goal of exploring and researching new approaches to Language/Compiler development and software engineering. This contract's duration is about to end March 2007 and we are working and preparing the according final review which is scheduled for May 2007. Key 0.99.0 Features ===================== * new object spaces: - Tainting: a 270-line proxy object space tracking and boxing sensitive information within an application. A tainted object is completely barred from crossing an I/O barrier, such as writing to files, databases or sockets. This allows to significantly reduce the effort of e.g. security reviews to the few places where objects are "declassified" in order to send information across I/O barriers. - Transparent proxies: allow to customize both application and builtin objects from application level code. Works as an addition to the Standard Object Space (and is translatable). For details see http://codespeak.net/pypy/dist/pypy/doc/proxy.html * optimizations: - Experimental new optimized implementations for various built in Python types (strings, dicts, lists) - Optimized builtin lookups to not require any dictionary lookups if the builtin is not shadowed by a name in the global dictionary. - Improved inlining (now also working for higher level backends) and malloc removal. - twice the speed of the 0.9 release, overall 2-3 slower than CPython * High level backends: - It is now possible to translate the PyPy interpreter to run on the .NET platform, which gives a very compliant (but somewhat slow) Python interpreter. - the JavaScript backend has evolved to a point where it can be used to write AJAX web applications with it. This is still an experimental technique, though. For demo applications see: http://play1.codespeak.net:8008/ * new configuration system: There is a new comprehensive configuration system that allows fine-grained configuration of the PyPy standard interpreter and the translation process. * new and improved modules: Since the last release, the signal, mmap, bz2 and fcntl standard library modules have been implemented for PyPy. The socket, _sre and os modules have been greatly improved. In addition we added a the pypymagic module that contains PyPy-specific functionality. * improved file implementation: Our file implementation was ported to RPython and is therefore faster (and not based on libc). * The stability of stackless features was greatly improved. For more details see: http://codespeak.net/pypy/dist/pypy/doc/stackless.html * RPython library: The release contains our emerging RPython library that tries to make programming in RPython more pleasant. It contains an experimental parser generator framework. For more details see: http://codespeak.net/pypy/dist/pypy/doc/rlib.html * improved documentation: - extended documentation about stackless features: http://codespeak.net/pypy/dist/pypy/doc/stackless.html - PyPy video documentation: eight hours of talks, interviews and features: http://codespeak.net/pypy/dist/pypy/doc/video-index.html - technical reports about various aspects of PyPy: http://codespeak.net/pypy/dist/pypy/doc/index-report.html The entry point to all our documentation is: http://codespeak.net/pypy/dist/pypy/doc/index.html What about 1.0? ====================== In the last week leading up to the release, we decided to go for tagging the release as 0.99.0, mainly because we have some efforts pending to integrate and complete research and coding work: * the JIT Compiler Generator is ready, but not fully integrated with the PyPy interpreter. As a result, the JIT does not give actual speed improvements yet, so we chose to leave it out of the 0.99 release: the result doesn't meet yet the speed expectations that we set for ourselves - and which some blogs and people have chosen as the main criterium for looking at PyPy. * the extension enabling runtime changes of the Python grammar is not yet integrated. This will be used to provide Aspect-Oriented Programming extensions and Design by Contract facilities in PyPy. * the Logic object space, which provides Logic Variables in PyPy, needs to undergo a bit more testing. A constraint problem solver extension module is ready, and needs to be integrated with the codebase. PyPy 0.99 is the start for getting to 1.0 end of March 2007, which we intend to become a base for a longer (and more relaxed :) time to come. Funding partners and organisations ===================================================== PyPy development and activities happen as an open source project and with the support of a consortium partially funded by a 28 months European Union IST research grant. The full partners of that consortium are: Heinrich-Heine University (Germany), Open End (Sweden) merlinux GmbH (Germany), tismerysoft GmbH (Germany) Logilab Paris (France), DFKI GmbH (Germany) ChangeMaker (Sweden), Impara (Germany) From johnsmithjohnxxx at yahoo.com Sat Feb 17 22:23:02 2007 From: johnsmithjohnxxx at yahoo.com (John Smith) Date: Sat, 17 Feb 2007 13:23:02 -0800 (PST) Subject: [pypy-dev] translating classes to javascript Message-ID: <766761.99865.qm@web62311.mail.re1.yahoo.com> Hi list, I'm fairly new to pypy and was only doing some experimenting with the javascript translator so far. First of all let me say that the whole project is pretty amazing! After translating a couple of functions I tried translating a class, but was unsuccessful so far but since the docs mention supporting inheritance I guess this should be possible. Is it? For instance if I have in RPython the following: class test: def __init__( self, value ): self.value = value def meth1( self ): return self.value def meth2( self ): do_something_which_is_translatable( ) then how do I get the corresponding javascript code? Since the docs say jscompile should be invoked by 'jscompile module function_names' I'm kind of lost. The same holds for rpython2javascript it expects a list of functions. Any insight or comment would be very helpful. --------------------------------- Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/pypy-dev/attachments/20070217/031097b6/attachment.htm From fijal at genesilico.pl Sat Feb 17 22:41:06 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Sat, 17 Feb 2007 22:41:06 +0100 Subject: [pypy-dev] translating classes to javascript In-Reply-To: <766761.99865.qm@web62311.mail.re1.yahoo.com> References: <766761.99865.qm@web62311.mail.re1.yahoo.com> Message-ID: <45D77672.4090704@genesilico.pl> John Smith wrote: > Hi list, > > I'm fairly new to pypy and was only doing some experimenting with the > javascript translator so far. First of all let me say that the whole > project is pretty amazing! > > After translating a couple of functions I tried translating a class, > but was unsuccessful so far but since the docs mention supporting > inheritance I guess this should be possible. Is it? > > For instance if I have in RPython the following: > > class test: > def __init__( self, value ): > self.value = value > def meth1( self ): > return self.value > def meth2( self ): > do_something_which_is_translatable( ) > > then how do I get the corresponding javascript code? Since the docs > say jscompile should be invoked by 'jscompile module function_names' > I'm kind of lost. The same holds for rpython2javascript it expects a > list of functions. > > Any insight or comment would be very helpful. > > ------------------------------------------------------------------------ > Need Mail bonding? > Go to the Yahoo! Mail Q&A > > for great tips from Yahoo! Answers > > users. > ------------------------------------------------------------------------ > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev Hi John! Because usual way of invoking javascript on your browser is to call a function, you need a function where you'll begin. Like: # class test as above def f(): test_instance = test(3) test_instance.meth() and translate function f. Your class will magically appear in translated javascript. Cheers, fijal From johnsmithjohnxxx at yahoo.com Sat Feb 17 23:33:25 2007 From: johnsmithjohnxxx at yahoo.com (John Smith) Date: Sat, 17 Feb 2007 14:33:25 -0800 (PST) Subject: [pypy-dev] translating classes to javascript In-Reply-To: <45D77672.4090704@genesilico.pl> Message-ID: <599581.71585.qm@web62315.mail.re1.yahoo.com> > I'm fairly new to pypy and was only doing some experimenting with the > javascript translator so far. First of all let me say that the whole > project is pretty amazing! > > After translating a couple of functions I tried translating a class, > but was unsuccessful so far but since the docs mention supporting > inheritance I guess this should be possible. Is it? > > For instance if I have in RPython the following: > > class test: > def __init__( self, value ): > self.value = value > def meth1( self ): > return self.value > def meth2( self ): > do_something_which_is_translatable( ) > > then how do I get the corresponding javascript code? Since the docs > say jscompile should be invoked by 'jscompile module function_names' > I'm kind of lost. The same holds for rpython2javascript it expects a > list of functions. > > Any insight or comment would be very helpful. > Because usual way of invoking javascript on your browser is to call a function, you need a function where you'll begin. Like: # class test as above def f(): test_instance = test(3) test_instance.meth() and translate function f. Your class will magically appear in translated javascript. Thanks very much for the reply, I can certainly do things this way however being able to call methods directly sounds like a reasonable thing to me (both in python and in JS). Are there plans for adding this kind of functionality or there are reasons why you think this is not necessary? Cheers, John --------------------------------- Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/pypy-dev/attachments/20070217/2dcdca30/attachment.htm From johnsmithjohnxxx at yahoo.com Sun Feb 18 00:01:04 2007 From: johnsmithjohnxxx at yahoo.com (John Smith) Date: Sat, 17 Feb 2007 15:01:04 -0800 (PST) Subject: [pypy-dev] translating classes to javascript In-Reply-To: <45D77672.4090704@genesilico.pl> Message-ID: <612588.6200.qm@web62305.mail.re1.yahoo.com> I'm really sorry for the messed up layout, yahoo mail sucks big time.... --------------------------------- Access over 1 million songs - Yahoo! Music Unlimited. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/pypy-dev/attachments/20070217/e6700ffd/attachment-0001.htm From fijal at genesilico.pl Sun Feb 18 00:49:01 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Sun, 18 Feb 2007 00:49:01 +0100 Subject: [pypy-dev] translating classes to javascript In-Reply-To: <599581.71585.qm@web62315.mail.re1.yahoo.com> References: <599581.71585.qm@web62315.mail.re1.yahoo.com> Message-ID: <45D7946D.7000304@genesilico.pl> John Smith wrote: > > > I'm fairly new to pypy and was only doing some experimenting > with the > > javascript translator so far. First of all let me say that the > whole > > project is pretty amazing! > > > > After translating a couple of functions I tried translating a > class, > > but was unsuccessful so far but since the docs mention supporting > > inheritance I guess this should be possible. Is it? > > > > For instance if I have in RPython the following: > > > > class test: > > def __init__( self, value ): > > self.value = value > > def meth1( self ): > > return self.value > > def meth2( self ): > > do_something_which_is_translatable( ) > > > > then how do I get the corresponding javascript code? Since the docs > > say jscompile should be invoked by 'jscompile module > function_names' > > I'm kind of lost. The same holds for rpython2javascript it > expects a > > list of functions. > > > > Any insight or comment would be very helpful. > > > > Because usual way of invoking javascript on your browser is to call a > function, you need a function where you'll begin. Like: > > > # class test as above > > def f(): > test_instance = test(3) > test_instance.meth() > > and translate function f. Your class will magically appear in > translated > javascript. > > > Thanks very much for the reply, I can certainly do things this way > however being able to call methods directly sounds like a reasonable > thing to me (both in python and in JS). Are there plans for adding > this kind of functionality or there are reasons why you think this is > not necessary? > Yes there are plans for such support, while there was no time to implement it yet :-( The list of ideas lay down here: http://codespeak.net/pypy/dist/pypy/doc/js/todo.html Cheers, fijal From tismer at stackless.com Sun Feb 18 04:00:59 2007 From: tismer at stackless.com (Christian Tismer) Date: Sat, 17 Feb 2007 19:00:59 -0800 Subject: [pypy-dev] PyPy 0.99 is out: new object spaces, optimizations, configuration ... In-Reply-To: <45D75363.8060504@openendsystems.com> References: <45D75363.8060504@openendsystems.com> Message-ID: <45D7C16B.6070109@stackless.com> Samuele Pedroni wrote: ... Well, this is all great and nice to read. What I'm missing in the announcement is any mention of our current supported version of CPython. In the documentation, I also could nowhere find out that PyPy does not translate with Python 2.5. Maybe this should be put somewhere since it might be quite confusing to new users? ciao - chris From holger at merlinux.de Sun Feb 18 10:07:37 2007 From: holger at merlinux.de (holger krekel) Date: Sun, 18 Feb 2007 10:07:37 +0100 Subject: [pypy-dev] PyPy 0.99 is out: new object spaces, optimizations, configuration ... In-Reply-To: <45D7C16B.6070109@stackless.com> References: <45D75363.8060504@openendsystems.com> <45D7C16B.6070109@stackless.com> Message-ID: <20070218090737.GM16146@solar.trillke> Hi Christian! On Sat, Feb 17, 2007 at 19:00 -0800, Christian Tismer wrote: > Samuele Pedroni wrote: > ... > > Well, this is all great and nice to read. > What I'm missing in the announcement is any mention > of our current supported version of CPython. > > In the documentation, I also could nowhere find out that PyPy > does not translate with Python 2.5. > > Maybe this should be put somewhere since it might be quite > confusing to new users? It's in the FAQ in the first "General" section, that PyPy aims to support Python 2.4 and that that the translation process does not fully work with 2.5: http://codespeak.net/pypy/dist/pypy/doc/faq.html I also just added an according note in the "getting-started" in the "Trying out the translator" section, as it is the main entry point apart from the release announcement which could also have mentioned it, but generally refers to documentation for technical details. best, holger From tismer at stackless.com Sun Feb 18 23:45:44 2007 From: tismer at stackless.com (Christian Tismer) Date: Sun, 18 Feb 2007 14:45:44 -0800 Subject: [pypy-dev] PyPy 0.99 is out: new object spaces, optimizations, configuration ... In-Reply-To: <20070218090737.GM16146@solar.trillke> References: <45D75363.8060504@openendsystems.com> <45D7C16B.6070109@stackless.com> <20070218090737.GM16146@solar.trillke> Message-ID: <45D8D718.2010407@stackless.com> Hi Holger, holger krekel wrote: > I also just added an according note in the "getting-started" in the > "Trying out the translator" section, as it is the main entry > point apart from the release announcement which could > also have mentioned it, but generally refers to documentation > for technical details. Yeah, that's good. From the getting started POV, nobody expects that Python 2.4 is required. thanks & ciao - chris From nytrokiss at gmail.com Mon Feb 19 03:06:56 2007 From: nytrokiss at gmail.com (James Matthews) Date: Sun, 18 Feb 2007 21:06:56 -0500 Subject: [pypy-dev] PyPy 0.99 is out: new object spaces, optimizations, configuration ... In-Reply-To: <45D8D718.2010407@stackless.com> References: <45D75363.8060504@openendsystems.com> <45D7C16B.6070109@stackless.com> <20070218090737.GM16146@solar.trillke> <45D8D718.2010407@stackless.com> Message-ID: <8a6b8e350702181806g2bec56cfs65f27626e7a4a3a1@mail.gmail.com> Thanks This is great keep up the good work! On 2/18/07, Christian Tismer wrote: > > Hi Holger, > > holger krekel wrote: > > > I also just added an according note in the "getting-started" in the > > "Trying out the translator" section, as it is the