Here are a couple comments,
At 03:18 PM 11/4/2003 +0100, Juergen Boemmels wrote:
currently there is no (simple) way to open a file on an other layer than the default layer. But this is necessary if we want to take advantage from the layered approach.
So i added two new functions: pio_open_with_layer and pio_fdopen_with_layer which create IO-Objects on different layers. I'm not keen on the names, but I didn't find better ones.
An alternative is to add an optional layer parameter to PIO_open and company. If it is null you can use the default.
But there are some issues: * During layer initialisation the layers want to register the handles for stdin, stdout and stderr. I went around this by conditionally only compiling the handle init if stdio is the base IO systems. Is this a good solution?
It is probably time to have the layer specific init (PIO_unit_init, etc.) pass back an array of standard handles rather than explicilty setting them into the interpreter as it does now? This will allow us to ignore them at the top level if need be. You are right, currently it isn't really easy to mix "terminal" layers because of this.
* I needed many casts from PIOHANDLE to FILE * and vice versa. I'm not sure if this one fits all approach of PIOHANDLE is the right way. Maybe its better to make PIOHANDLE a union. But what to do then with the fdopen and getfd ops. It is not guaranteed that a union can be casted to an INTVAL and back.
I think it works with casts, unless there are cases where our INTVAL cannot hold a pointer. There are currently 2 cases:
PIOHANDLE is a low level OS handle (UNIX or Win32) and we to create a ParrotIO around it. PIOHANDLE is a stdio FILE * and we need to create a ParrotIO around it.
I'm really ok if the io_stdio.c is a mega hack since STDIO is only there for convenience and bootstrap where there is no other IO alternative.
In either case, it is the bytecode op that is the unsure part, and whether we have to use the INTVAL type or we have to change it to a STRING buffer.
* Modifying the same file through different layers might lead to very unpredictable results. But thats already a problem with unix-handles/stdio-handles.
What do you mean by modifying here?
* PIO_isatty and PIO_getblksize are macros which are coded at compile-time to some layer, and not as read, write etc go through a LayerAPI.
Those need to be changed as well. They break the whole layer plan, as you point out.
Actually isatty() can be called inside PIO_fdopen and the result stored into the PIO header as a bit flag. Then PIO_isatty() can simply be a flag check against the PIO.
Finally, the rest of the compile time macros definitely need to go away since they make it impossible to use 2 terminal layers at the same time.
-Melvin
