[NEW] Stream library ready
Leopold Toetsch
> Hi all,
> here is a working version of my new Stream library. I will add more
> documentation later this month, the examples should be enough to
> understand the usage.
Looks good. Should it go into CVS?
BTW: some C<getprop>s still survived.
leo
Jens Rieks
> Looks good. Should it go into CVS?
> BTW: some C<getprop>s still survived.
getprop? I found two delprops, removed.
Can I get commit privs?
I also have a Data::Dumper patch nearly ready that removes the F<onload.imc>
and F<objects.imc> usage. It is very time consuming to send patches by mail.
> leo
jens
Leopold Toetsch
Leopold Toetsch
> here is a working version of my new Stream library. I will add more
> documentation later this month, the examples should be enough to
> understand the usage.
I'm currently investigating a bunch of SIGSEGVs when tracing the examples.
They are all coming from Stream::Sub's usage of continuations:
,--[ Stream::Sub ]------------------------------------------------------
| This special "method" can call C<write>, which will internally create
| a Continuation to return to the current execution point when read is
| called the next time. The C<read> method creates a continuation before
| invoking the provided sub or the continuation captured by the write
| method. C<read>'s continuation is used to return the string parameter
| passed to C<write> as the return value of the read method.
`-----------------------------------------------------------------------
The problem seems to be context handling. When C<write> creates the
Continuation, it saves a different context as that one that is inplace
and will be restored, when the Continuation is invoked.
Further, in C<rawRead> P1 is stored away (and invoked later), which
isn't allowed. But cloning it doesn't help because the continuation
context is still wrong.
I think to get that right we need some more support to copy contexts
around.
How exactly should these contexts look like for these two
continuations?
leo
Jens Rieks
> Jens Rieks <par...@jensbeimsurfen.de> wrote:
> > here is a working version of my new Stream library. I will add more
> > documentation later this month, the examples should be enough to
> > understand the usage.
>
> I'm currently investigating a bunch of SIGSEGVs when tracing the examples.
> They are all coming from Stream::Sub's usage of continuations:
running parrot with -G works, and it crashes only after processing some lines.
> ,--[ Stream::Sub ]------------------------------------------------------
>
> | This special "method" can call C<write>, which will internally create
> | a Continuation to return to the current execution point when read is
> | called the next time. The C<read> method creates a continuation before
> | invoking the provided sub or the continuation captured by the write
> | method. C<read>'s continuation is used to return the string parameter
> | passed to C<write> as the return value of the read method.
>
> `-----------------------------------------------------------------------
>
> The problem seems to be context handling. When C<write> creates the
> Continuation, it saves a different context as that one that is inplace
> and will be restored, when the Continuation is invoked.
>
> Further, in C<rawRead> P1 is stored away (and invoked later), which
> isn't allowed. But cloning it doesn't help because the continuation
> context is still wrong.
>
> I think to get that right we need some more support to copy contexts
> around.
>
> How exactly should these contexts look like for these two
> continuations?
It should be a snapshot of the current execution chain, so that exactly the
same context is restored when invoking the continuation.
It is some kind of "context swapping":
main exec chain sub chain
---------------------------------------------
Stream::Sub created
sub created
stored as "source"
read()
create "read cont"
call "source"
execution start
do something
write()
create continuation
store it as new "source"
call "read cont"
back in read, directly
after the invokation of
the "source" sub/cont
return the value passed to
the "read cont" as return
values of read()
do something
read()
create "read cont"
back in write
return from write
do something
write()
create "write cont"
call "read cont"
...
> leo
jens
Dan Sugalski
I'm fine with it too. Set up a perl.org account (pointers to it from
bugs.perl.org) and mail me your login and I'll get things in motion.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> On Wednesday 07 April 2004 17:42, Leopold Toetsch wrote:
>>
>> Further, in C<rawRead> P1 is stored away (and invoked later), which
>> isn't allowed. But cloning it doesn't help because the continuation
>> context is still wrong.
I've this now running.
$ ../parrot -t --gc-debug examples/streams/SubHello.imc 2>/dev/null
read:[hello]
read:[world!]
read:[parrot]
read:[is cool]
Where a return continuation is reused the code
should look like:
$P1 = clone P1
# store $P1
The "clone" for return continuation resets the recycle flag (on both
sides) so that e.g. a Sub can exit through this P1 multiple times.
The code is quite hackish and I'm still not sure, if we can keep this
optimization, we'll see.
leo
Jens Rieks
I'll check it in now.
There is also a new Stream::Writer, an inside-turned-out version of
Stream::Sub. You can call "write" in the normal call chain; the reading is
done in the sub one provides.
> leo
jens
Leopold Toetsch
> There is also a new Stream::Writer,
Wasn't The Plan to move over to runtime/parrot/lib or library?
> jens
leo
Jens Rieks
> Wasn't The Plan to move over to runtime/parrot/lib or library?
I'm waiting for a final decision where everyting should be moved to.
I vote for:
- runtime/parrot/library
- t/library
If parrot is modified to search files in runtime/parrot, everything should
continue to work with the paths currently in use.
If parrot is going to be installed somewhere, it needs a place where it can
find all files anyway. I have no clue what has to be done till everything
will be found at the new location. I think IMCC and load_bytecode needs some
work to make the relocation possible.
I can have a look at it after the 16th, have to learn for two written
examinations this week.
> leo
jens
Leopold Toetsch
>
> I vote for:
> - runtime/parrot/library
> - t/library
Ok.
> If parrot is modified to search files in runtime/parrot, everything should
> continue to work with the paths currently in use.
I'll have a look at that.
> I can have a look at it after the 16th, have to learn for two written
> examinations this week.
Ok, thanks.
leo