Hi, The somepbc-refactoring branch has been merged. Thanks to Michael for participation! What is still broken: * pypy/bin/translator.py -- the Translator class is going away, the functionality we need should probably be moved into this bin/translator.py for now. But ideally this should be replaced by an interface based on translator/goal/driver.py. * pdbplus, the pdb extension you get at the end of translate_pypy.py, has probably commands that need fixing. * translate_pypy --backend=llvm crashes apparently when building non-standalone targets; standalone targets appear to work fine (didn't try the whole of PyPy, however). All llvm tests work too, so it's hard to understand exactly what the problem is. * Christian: we did not completely port your r19917 because it needs some adaptations to the new world. The Translator class is being replaced by a much thinner TranslationContext. Most importantly, your changes to translator/c/pyobj.py haven't been merged -- they will also need adaptation to work on graphs instead of functions, as we did for the rest of pyobj.py. It was also difficult to know exactly what was needed because of the absence of tests. However, there is a tag of the trunk before we merged, so that a working pypy with your changes is still in http://codespeak.net/svn/pypy/tag/dist-ext-someobject . That's it ! A bientot, Armin & Samuele (& Michael, sadly not on-line when we merged -- or more probably happily so :-)
Hi Armin & Samuele! On Fri, 2 Dec 2005, Armin Rigo wrote:
The somepbc-refactoring branch has been merged. Thanks to Michael for participation!
Cool!
What is still broken:
* translate_pypy --backend=llvm crashes apparently when building non-standalone targets; standalone targets appear to work fine (didn't try the whole of PyPy, however). All llvm tests work too, so it's hard to understand exactly what the problem is.
Actually, I dont think any have ever worked - so no problem! :-) The interface for extensions is minimal to say the least. There is a todo on the llvm backend to remove the (somewhat legacy) pyrex interface wrapper and support a richer set of objects that can be passed to and from CPython. Thanks for doing a fix up of the llvm backend. Cheers, Richard
Armin Rigo wrote: ...
* Christian: we did not completely port your r19917 because it needs some adaptations to the new world. The Translator class is being replaced by a much thinner TranslationContext. Most importantly, your changes to translator/c/pyobj.py haven't been merged -- they will also need adaptation to work on graphs instead of functions, as we did for the rest of pyobj.py. It was also difficult to know exactly what was needed because of the absence of tests. However, there is a tag of the trunk before we merged, so that a working pypy with your changes is still in http://codespeak.net/svn/pypy/tag/dist-ext-someobject .
That's fine with me. I didn't consider my patches more than a quick hack to get things going, and the major purpose was to hack in what was needed, just to convince the EWT people that PyPy is the way to go for their future (which worked very well). This part of code generation (concerning extensions and how to handle certain external objects) was kind of under-developed all the time. After my initial tests, I have a better picture what's needed, and I would like to discuss a couple of ways to create a nice interface for building extension modules, and also new builtin modules! This is because after a while of thinking, I figured out that this is the best way to support hard-to-port things like Stackless Python ATM: Instead of again patching all the newly grown extension modules to support some half-hearted Stackless support, I want to build a Stackless-PyPy hybrid implementation, based upon CPython 2.4, but with certain modules removed from the source and replaced by PyPy generated source code. This source code will be generated from RPython implementations, which are then both used in PyPy and in Stackless. One example of these should be the itertools, another one the Stackless module itself (and of course the new deque objects, which I ported to RPy in the states,already). With this approach, I hope to make PyPy productive right now, before we have the advanced technologies, to simplify porting new features to Stackless, and to make more companies interested in using PyPy for their code. I have a sack full of small features which are needed for this. Nothing too hard, but enough for quite some work. I think it makes sense, because PyPy becomes productive right now, and we need that to have an argument for being used in production code. cheers -- chris -- Christian Tismer :^) <mailto:tismer@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
participants (4)
-
Armin Rigo -
Christian Tismer -
Richard Emslie -
Sanghyeon Seo