I have some problems with the File-Descriptors in Parrot. Some of the operations in io.ops just take an INT File-Descriptor, which takes its infromation from a table in the Interpreter-Structure. This hinders garbage-collection of the IOs in this descriptor-table, because every interger can possibly be a File-Descriptor. Furthermore this table needs to be initialised early in the startup of parrot, at the moment even the memory-subsystem is not running when the IO is initialised.
Since the I/O system is currently a combination of Melvin's IO stuff implemented on top of a dodgy specification and all the hackish ops I threw in so we could at least do *some* IO while I was futzing around with the Async IO and events spec, feel free to get the machete out and hack away at what's in there. We need to build a spec for the stuff at some point, and now is as good a point as anay.
There's some preliminary design of the ops for I/O in PDD06, but that's a bit out of date. Whatever we do, however, needs to take into account the fact that we have the potential for IO filters (and lots of them) in the style of PerlIO filters or SysV stream processing modules (minus the SysV quirks), as well as asynchronous I/O, I/O callback routines, and events to wedge in there.
For right now, the stuff you propose:
Therefor I propose: Remove the integer-valued File-Descriptors. The ParrotIO-objects (wrapped in PMCs) are the only way to access IO. The standard-descriptors stdin/stdout/stderr can be obtained by new ops get_stdin (out PMC) get_stdout (out PMC) get_stderr (out PMC) respectivly the macros PIO_STDIN(interpreter); PIO_STDOUT(interpreter); PIO_STDERR(interpreter);
works just fine for me, and makes it easier for embedders to override the filehandles (as they can poke stuff into the right spot on startup). Tossing most of the I/O ops and leaving us with a base core of:
open close readw writew readline print
works for me. (Note the w's on the end of some of the op names, since these'll be the blocking versions) We can add in more later, without having to change the semantics of these.
Print and readline probably ought to go away, but they are just so handy when writing code by hand I'd like to keep them for now, though I'm OK with print being an alias for writew.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
