[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