Maciek Fijalkowski wrote:
Part of it is a SoC anyway, so I don't think we care in what order SoC
is done. (and personally I think it makes sense to provide Java bindings
first and than to care about the translation).
Well, strictly speaking java bindings for rpython are not part of Paul's
Anto,
I think this is a good strategy for me. It'll allow me to put something
material to the information I gained from your thesis and gain knowledge
that will help me in the long run with PyPy.
The tasks for me will be:
1.) Port tests, fix uncovered bugs
2.) Java bindings
3.) I/O layer as
Carl Friedrich Bolz wrote:
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
Maciek Fijalkowski wrote:
Probably one good step would be to make our tools (mostly py.test) work
without applevel os.dup and friends (it uses it in few places, also for
capturing, but that's quite shallow and capturing can be even tuned with
options).
+1
(and maybe add a new --noposix
Hi Anto!
Antonio Cuni wrote:
I agree, and this is why I mentioned the problem :-).
I think there are two ways to make it working:
1) write a dummy CliFile (or JvmFile) subclass of stream, then
special-case that class in the backend to map directly to
System.Io.FileStream (or the
Hi Armin!
Armin Rigo wrote:
On Sat, Apr 28, 2007 at 07:56:11PM +0200, Carl Friedrich Bolz wrote:
If another placeof pypy still uses os.open I am strongly
for fixing that.
There is the app-level os.open(), which of course uses the interp-level
os.open(). It means that if a backend only
Armin Rigo wrote:
Hi Carl,
On Sat, Apr 28, 2007 at 07:56:11PM +0200, Carl Friedrich Bolz wrote:
If another placeof pypy still uses os.open I am strongly
for fixing that.
There is the app-level os.open(), which of course uses the interp-level
os.open(). It means that if a backend
