Hi Armin,
If you look at md5.py, you'll see that it *is* already almost restricted Python. I can just move almost all functions over to the interpreter level.
But not by hand :-)
Yes, only some code is "essentially" application-level code. Some other code is quite "C-ish" already, and doesn't in any essential way need to correspond to space.xyz() calls. It can just "do its job" and return a result.
Yes
In this respect md5.py and sha.py are similar to _formatting.py: they are all general Python code (so meant for app-level) that is almost RPythonic enough that we could put the code at interp-level with only some amount of uglifying.
Yes
Didn't your mind go a full circle back to its starting point? I seem to remember that you started work on genrpy precisely to avoid to uglify _formatting.py by hand. Now you say that md5.py should better be put to interp-level manually...
No no. I'm getting further. I'm trying to figure out what can be just taken as is, as interpreter level code, and what needs to go into app space calls.
I'm just not really decided what's right. I can start as I started: everything is a space.wrap of a space.whatever, and we need to have another simplification step. The alternative is to try to keep code as it is, if it is rpythonic, and just to identify the operations that RPython doesn't have, only wrap these, call the space, and immediately unwrap the result.
This happened to me, when I saw that md5 is just already in shape togo into interp level, just a little class thing is needed.
While this is of course possible, the idea of genrpy was to do it
automatically. I know the generated code must look incredible right now,
because it's just calls to space.xyz().
Yes, and I have a simple problem running the stuff: What do I do over the space, and what do I directly? I think my generated functions should not be called via space,since the interface is interplevel,already. The things which I don't translate are those which use the space calls. Right?
But the idea is to run the annotation stuff over the graphs -- which assumes some restrictions, which are generally fine for the kind of app-level code we are considering. Then genrpy can be extended to use the annotations, e.g. when it knows that a given variable is an integer, it should use a real integer in the produced code too, instead of a space.wrap(value), and real '+' '-' etc operations instead of space.add(), space.sub(), etc.
SO what you are saying is that I don't careand just translate away? I thought it is a waste for stuff which is perfectly interplevel already, and I'd like to find this out and avoid translation.
In this way we produce interp-level code that will be:
* unreadable * fast * automatically integrated with the rest of the interp-level code * still containing some space.xyz() operations if needed -- i.e. we can still use app-level code as a "macro language" to compactly write things like space.is_true(space.eq(space.getitem(w_list, space.wrap(i)), w_value)).
Ok. But another thing that annoys me is that this macro language still has rpythonic restrictions, when I use the unmodified flow space. I think it should be full Python. I had the strong feeling that I did a whole mess with no real benefit. But I might be wrong.
cheers - chris -- Christian Tismer :^) <mailto:[EMAIL PROTECTED]> 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/ _______________________________________________ [EMAIL PROTECTED] http://codespeak.net/mailman/listinfo/pypy-dev
