Thanks for the reply Holger hpk@trillke.net (holger krekel) wrote on 30/08/2005 10:56:01:
Hi Ben, hi all,
On Tue, Aug 30, 2005 at 10:31 +0100, Ben.Young@risk.sungard.com wrote:
Congratulations everyone one the release! It looks really good!
thanks, also for your constant support!
So what's the next priority? Speed or more customisability (or both!)?
we had a brief discussion at the end of the sprint and apart from working on the bytecode compiler (which makes the interactive speed appear so slow) we intend to cleanup translation driving and various other areas before heading off to the next phases of the project. Also we currently plan the next sprint in Paris (10th-17th October) which we should announce soon. It's quite likely we are discussing/starting on the next efforts there regarding JIT compilation and massive multithreading and what not.
There also is the ongoing effort of integrating Carl Friedrich's GC code into the actual translated PyPy and improving flexilibity around threading, completing some crucial external functions (like os.listdir) and whatnot.
Will there eventually be a way for existing c extension modules to talk to the generated pypy? Or will people have to reimplement their extensions (perhaps using a c-types style notation). I guess the hard bit is making it cross-backend compatiable (for instance the way ironpython/jython can both automatically see the platform objects)
Personally, i hope i will find some time to seriously improve the testing framework on various levels. With PyPy, we begin to have lots of options and variants in testing our own code base, the standard python library's tests as well as testing translation targets and variants. I'd like to implement an approach that allows completely peer-driven testing and sending of reports to a central site where they can be queried according to os/processor/python. I intend to implement this in a PyPy neutral manner so that the numerous other users of py.test can reuse our efforts for their projects. Additionally, i'd like to have tests become interactively distributable to multiple machines (listed via ssh-account login information) from a single (possibly modified) working copy.
Have you come up with any solutions to make the annotation/translation process a bit less fragile, as it appears a small fix somewhere in the code can accidently produce huge amounts of confusion in the annotator. Perhaps some "checkpoints" in places in the code, where if an object doesn't have a particular annotation then we stop at that point?
Also, for the EU side of things some of us will need to invest time into reporting and writing papers. We intend to keep as much of that work reusable on the website as we have no inclination to just produce dead paper.
Last but not least we are still looking for sprint places end of this and the whole next year. There appear to be possibilities in Istanbul (Turkey), Bern (Switzerland) and Romania but none of these are concrete at this point. It would also already be good to know if there is interest in doing a PyPy sprint at Pycon US in the next year.
Thanks for your patience in my incessant questioning! Cheers, Ben
cheers,
holger