[pypy-dev] PyPy JVM Backend

[Antonio Cuni]

Carl Friedrich Bolz wrote:

>  >   2) make CliFile or JvmFile real classes, using the interpret-level
>  > bindings to forward the methods;
> 
> This is indeed the solution that I had in mind. Of course I forgot that
> there are no interpreter-level bindings for Java yet, how hard would it
> be to get them? We will need them anyway later. And writing them might
> still be less work than writing the file descriptor implementation.

The implementation of file descriptor by itself is quite easy, but I 
agree that in this case the correct solution is to develop java bindings 
for RPython, which will probably also be useful for next tasks such as 
JSR-223. Also, java bindings could share (as usual :-)) most of the 
rtyper code used by the .NET bindings.

>  > then, we should modify open_file_as_stream and construct_stream_tower to
>  > instantiate these classes instead of the standard ones.
> 
> The result will be very cool because you can then use rlib.streamio and
> get good cross-platform behavior.

this would be a big bonus. Going further, how hard would it be to rtype 
the builtin "file" to use streamio?

> I don't think it is so bad. If you don't want to map the Python
> semantics to the .NET ones, you can use the .NET stream only as the
> lowestone in the stream tower and leave buffering and line endings to
> the existing code. Or you can find an intermediate solution.

Yes, it makes sense.
.NET streams are always buffered when reading, I don't know if/how 
another layer of buffering could affect performances.

Moreover, I think there is no easy way to open a stream in "text" mode: 
  on Windows if you open a text file with the low level stream interface 
you get "\r\n" at the end of lines, so it might be necessary to insert 
another layer that does the conversion (the same as I'm doing now in the 
C# implementation -- see the CRLFTextFile class in cli/srs/ll_os.cs).

>  > About the app-level os.* functions; I also think that for now we could
>  > simply omit them, but in the long term we should write an alternative
>  > implementation based on streamio (IronPython does it in a similar way).
> 
> Yes, but this can probably even be done on applevel.

sure, and it would be probably reusable both for cli and jvm!

ciao Anto