Hi Armin, all, I've put quite some work into genrpy.py in the last few weeks. It seems to produce usefulcode, although it could of course be nicer with some more effort. The speed effect appears to be somewhere around 40% over interpreted appspace code, not really disappointing, but also not really overwhelming. The real effect of such translation lies probably in opening things to further optimization in a later code generation step. The code works fine with _formatting.py, md5.py and strutil.py. These all appear to obey RPython restrictions, as probably many others. There are some enhancements possible: Right now, I'm using the flow space as it is, but I do not try to create specialized functions for constant arguments. Flow space provides some way to do this, but translator doesn't allow it. I'm thinking to play with this. It would make much sense in the md5 module, where many small functions with constant arguments could be curryfied. In effect, with some more support, the flowspace could identify more constants than it does now. The way I'm creating the function interfaces is working, but less than optimum. I stupidly followed the pattern that Armin used for C code generation. Later on I figured out that I could create functions with names and default arguments directly. Armin, I'm referring to the distinction of f_<funcname> and fastf_<funcname>. Instead of using the pattern def f_<funcname>(space, *args_w) and later plumbing the defaults in, I could have done it in the function header, directly. I will enhance this later, provided that we want to use this module at all. How do we want to integrate this stuff? First I think it needs a different name. Then, there is the question whether there should be one huge module generated from the union of all app-space implementations, or if there should be onefile for every app-spacemodule part? I thought of acontainerlike pypy.appspace.generated where all stuff could be accumulated. Do we want togenerate stuff on demand, based upon modification time of modules, or better do it by hand? Another questio is if it is so good to loose all the local names early,or if I should try to regenerate local names wherever possible? Another thing I was considering is not to create all these goto blocks, but to turn them into simple functions. This would give us massive recursion, but if we add a tail recursion feature to pypy, this would show up quite nicely. It would make the source shorter and would really allow to use given local names, because each code block has its own closure, then. I have done a lot of local tests. The test code is still sitting in the module and should go elsewhere. I did not yet tryto integrate it into the app space calls of stdobjspace. This is easy to do,but I need consensus how wewant this to happen. Please review. You can select a few test functions by changing line 1084. For the current main function, you need to create an importable appspace/generated folder. You also will needto change the temp output file for your needs, at the moment this is "d:/tmp/look.py" :-) I will supply a real entrypoint and a cleaner interface when I have some feedback. all the best -- 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/