[pypy-dev] PyPy JVM Backend

Carl Friedrich Bolz cfbolz at gmx.de
Sat Apr 28 19:56:11 CEST 2007


Antonio Cuni wrote:
 > Hi Niko, hi Paul!
 > Here are some remarks/suggestions about your discussion.
 > I'm also CC-ing pypy-dev, so we can also catch someone else's
 > suggestions, if any :-).

I have one :-).

 >> First, there are those things are absolutely necessary to do to get 
PyPy
 >> to translate:
 >>
 >> 1. weak refs
 >> 2. I don't know what else goes here --- try and see I guess
 >
 > Apart from weak refs, I think the other big feature missing is support
 > for external functions (mostly I/O functions).
 > Unfortunately this part is a bit of a mess: since in the old days pypy's
 > only targets were low-level platforms the I/O model of RPython is
 > modeled after the unix file descriptors. This means that at the moment
 > high level backends need to emulate the fd interface and forward the
 > real work to the native I/O functions: to see how gencli does, look at
 > the ll_os class in translator/cli/src/ll_os.cs. I guess this would be
 > the easiest way also for genjvm, and probably for now we should pick
 > this solution.
 >
 > I know, this it's both ugly and hackish; the good news is that I and
 > Carl did some work towards a better solution: at the moment all the I/O
 > inside the standard interpreter is done using the (interp-level)
 > rlib/streamio.py library, which in turns uses the low-level file
 > descriptor interface; the long-term solution would be to provide an
 > alternative implementation of streamio.py that uses .NET/Java streams
 > and let the backends using that instead of the current one.

I think it is the time now to do away with the file descriptor
simulation, it was useful at one point but is very silly now. Instead, a
subclass of pypy.rlib.streamio.Stream should be created that only
delegates to the Java/.NET Stream classes, probably making use of the
facilities for buffering that the platforms offer. I think it is
perfectly reasonable to not have os.open and friends on pypy.net as long
as file works. If another placeof pypy still uses os.open I am strongly
for fixing that.

Cheers,

Carl Friedrich



More information about the Pypy-dev mailing list