Jens Rieks <par...@jensbeimsurfen.de> wrote: > 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.
On Wednesday 07 April 2004 08:19, Leopold Toetsch wrote:
> Looks good. Should it go into CVS?
Yes it can.
> 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.
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:
,--[ 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?
On Wednesday 07 April 2004 17:42, Leopold Toetsch wrote:
> 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:
Oops yes, I forgot to mention that. I though it is related to string handling, running parrot with -G works, and it crashes only after processing some lines.
> | 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
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
Jens Rieks <par...@jensbeimsurfen.de> wrote: > 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.
> Jens Rieks <par...@jensbeimsurfen.de> wrote: > > 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.
> 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.
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.
On Friday 09 April 2004 15:48, Leopold Toetsch wrote:
> Wasn't The Plan to move over to runtime/parrot/lib or library?
Hmm, good question. 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.
