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/