[PATCH] Add a String IO Layer.
Chromatic
to add a stringy IO layer and to fix a few typos.
This or a similar feature is (eventually) necessary for HLLs that don't
necessarily quite always want to let their output escape into the world,
instead preferring to think it over before hitting send.
It'll also help with the embedded version of Parrot::Test. That's my
immediate goal.
Use it as you would any other IO layer. The test patch offers a very slender
example.
--- cage cleaners bait starts here ---
NB that you have to touch a lot of files to add a new IO layer. This could be
easier.
The documentation of certain functions is far out of date. For example, try
to figure out how "read $P0, $I0" translates into the arguments passed into
PIO_xxx_read.
I have a vague sense of how layers work now and can look over the
documentation in more detail, but here's a section of the code that could use
some cleaning.
--- signature and patch follow ---
-- c
Leopold Toetsch
> Here's a patch (for discussion, but I'll apply it if there are no
> objections) to add a stringy IO layer and to fix a few typos.
Looks as a good base to start [1] with, and ...
> --- cage cleaners bait starts here ---
[ ... ]
... yep, indeed.
The whole IO layer system was totally static, when I started trying to extend
it a bit. It's still lacking a lot of flexibility and it needs some
rewriting.
Before doing so, we'd need some clarification though, mainly: which structures
are/can be shared amongst threads? How does IO look like with multiple
interpreters using e.g. stdout?
Another problem currently is that the STDIO layer can't be used concurrently
with the low-level OS layer due to compile-time #ifdefs. I think that the
STDIO layer should always be present - likely as the lowest layer in the
stack.
leo
[1] A nice extension would be seekability by managing the current r/w
position.