Juergen Boemmels <[EMAIL PROTECTED]> wrote: > Leopold Toetsch <[EMAIL PROTECTED]> writes:
> At the moment I have just a patch under construction to remove the > INTVAL Filehandles like print I0, P0. Don't know if we want to keep > this ops around for the next release. These ops are redundant, when all io ops are PMC based. We probably need just 2 opcodes that translate fd's to PMCs and vv to be abled to pass fd's on to C library functions. >> I think, putting the IO PMCs into the ParrotIOTable would do it for now. > I tried something like this in the first versions of my ParrotIO->PMC > transition. It turn out that the memory system is not initialized when > the IO-system opens its file-descriptors. So I used a PIO_F_SHARED > hack to prevent the standard ios from getting closed. Maybe its better > to just change the initialisation of the memory system before the > IO-system, but this might have impact on the whole memory subsystem. Ah. yes. I think, we can change init/deinit order. What we need is a PIO_eprintf() that can be used early in interpreter startup, when IO and or memory subsystems are not running yet. But we have this already, so I don't see a problem here. Then we could initialize the memory subsystem and then IO. So the IO subsystem could e.g. use a list instead of the table. > It turns out that memory and the IO-system are much more coupled than > it first seems. Yes. As there are major changes necessary to repair it really, we can for now just leave it as it is. > bye > boe leo
