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: 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: 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: 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: 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: signature.asc Type: application/pgp-signature Size: 481 bytes Desc: Digital signature URL: 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: signature.asc Type: application/pgp-signature Size: 481 bytes Desc: Digital signature URL: 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: 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature URL: 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: 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: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: 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: 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: 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