Hopefully, these changes will not particularly affect anyone not actively touching the jvm directory. The only changes in oosupport are the addition of various "prepare_" methods to the Generator class. These methods give the jvm backend an opportunity to push a this pointer here and there, but for those methods I added a default "do-nothing" implementation. For example, there is a "prepare_call_primitive()" which is called before the arguments for a primitive are pushed onto the stack.
I think that the oosupport code could probably be refactored, though I'm not precisely sure how right now. Right now it is basically a thin layer that extracts some useful information from the 'op' objects and passes it to the generators; furthermore, it uses this stack-based API which doesn't give much information to the backend about why something is being pushed (i.e., is it a function argument? if so, to what function? etc). This is ok as far as it goes, but maybe there is something more elegant? As I said, I don't have any precise suggestions right now, but it's something to think about. Niko On Nov 29, 2007, at 8:24 PM, amit wrote: > Hi Niko, > > I am working on the "CLR" module --- ..pypy/module/clr/ > Just trying to play around with "interp_clr.py" and > "app_clr.py" in there. > Hope your commits will make it more better. > > regards, > AmitReg > > > > Maciej Fijalkowski wrote: >> As noone answers... I think amitReg is doing some CLI related >> stuff, which means you can stomp on each other on oosupport, but >> he's doing rather library integration, so sounds very unlikely. >> Besides, I'm not aware of anyone. >> >> Cheers, >> fija >> >> On Nov 29, 2007 7:46 PM, Niko Matsakis <[EMAIL PROTECTED] <mailto:[EMAIL >> PROTECTED] >> >> wrote: >> >> I have been making small improvements to the JVM backend: I am >> aiming >> towards eliminating any remaining conformance problems, and also >> towards fixing a few warts in the implementation. >> >> Right now I am wringing out the last few bugs from a check-in that >> would allow multiple PyPy-generated interpreters to be used >> simultaneously. Currently, the code uses a few static fields that >> would conflict if, for example, someone tried to load both a >> Python >> and a Smalltalk interpreter into the same JVM. These static >> fields >> were used to allow the helper code (src/PyPy.java and friends) to >> create instances of exception classes and other RPython-generated >> code. The new code creates a single instance of the PyPy helper >> class >> per generated interpreter and use non-static-methods instead, >> which >> should be better. >> >> Anyway, I just want to be sure I am not stepping on anyone's >> toes if I >> check this in, since it makes small changes all over the place to >> ensure that the proper PyPy object is pushed onto the stack, etc. >> >> >> Niko >> _______________________________________________ >> [email protected] <mailto:[email protected]> >> http://codespeak.net/mailman/listinfo/pypy-dev >> <http://codespeak.net/mailman/listinfo/pypy-dev> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> [email protected] >> http://codespeak.net/mailman/listinfo/pypy-dev > _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
