parrot-dev Digest, Vol 51, Issue 7

Mon Nov 19 16:14:08 UTC 2012

Hi,

Long story short, I need the userhandle branch for mod_parrot, to move
the standard output to apache output (and input, as well). If we can
get an API figured out I am more than happy to contribute tests.

Kind regards,
Bart

2012/11/19, parrot-dev-request at lists.parrot.org
<parrot-dev-request at lists.parrot.org>:
> Send parrot-dev mailing list submissions to
> 	parrot-dev at lists.parrot.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.parrot.org/mailman/listinfo/parrot-dev
> or, via email, send a message with subject or body 'help' to
> 	parrot-dev-request at lists.parrot.org
>
> You can reach the person managing the list at
> 	parrot-dev-owner at lists.parrot.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of parrot-dev digest..."
>
>
> Today's Topics:
>
>    1. More IO Changes (need feedback) (Andrew Whitworth)
>    2. Re: More IO Changes (need feedback) (Jonathan "Duke" Leto)
>    3. Re: More IO Changes (need feedback) (Christoph Otto)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 18 Nov 2012 18:43:17 -0500
> From: Andrew Whitworth <wknight8111 at gmail.com>
> To: parrot-dev at lists.parrot.org
> Subject: More IO Changes (need feedback)
> Message-ID:
> 	<CAEPDB4rBmho3ip9TTpA6LoUUZRpbVo72nGLQU7E1twmJZ8Q4hw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I've got three new branches that I've been playing with today to make
> even more changes to the IO system. I'd like some feedback on these
> changes before I do any more work on these. I haven't spent much time
> on these yet, so if people don't like what they're doing I can abandon
> ship without losing too much effort.
>
> 1) whiteknight/pipe_pmc This branch separates out File and Pipe logic
> into two separate pmcs. FileHandle is for file IO only and a new Pipe
> PMC is for pipes only. The mode format specifier "p" is no longer
> valid and throws an exception in this branch. This is a breaking
> change. The other branches I've worked on build on this foundation, so
> if we don't like this we can forget about all of it.
>
> 2) whiteknight/io_vtable_lookup In Parrot master, we lookup
> information about the IO_VTABLE and the read/write IO_BUFFERs using
> VTABLE_get_pointer_keyed_int. This is a bad system. In this branch,
> IO_VTABLE is looked up using a type map instead, so a FileHandle
> always maps to the filehandle vtable, and a Pipe always maps to the
> Pipe vtable (same for Socket, StringHandle, etc). This branch also
> adds a new IOBuffer PMC which, while early in development, gives
> direct access to IO buffer logic. IOBuffer PMCs are now stored as
> named properties on the PMC (not attributes), which means they can be
> looked up, attached, and used without any raw get_pointer/set_pointer
> accesses.
>
> 3) whiteknight/io_userhandle This branch brings together the previous
> ideas and makes the IO system fully polymorphic. In this branch you
> can use ANY arbitrary PMC as a handle type for purposes of the IO
> system, without needing to subclass from or delegate to a built-in
> handle type. So long as your PMC implements a common set of methods,
> you can use it for all IO operations.
>
> Again, these branches are all very early in development. The
> FileHandle/Pipe change is the only breaking change, everything else is
> completely internal. If people like these ideas I can continue to work
> on them and we can talk about timelines and an upgrade path to limit
> breakages in NQP/Rakudo. If people don't like these things I can go
> back to the drawing board.
>
> Thanks,
>
> --Andrew Whitworth
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 18 Nov 2012 18:42:36 -0800
> From: "Jonathan \"Duke\" Leto" <jonathan at leto.net>
> To: Andrew Whitworth <wknight8111 at gmail.com>
> Cc: parrot-dev <parrot-dev at lists.parrot.org>
> Subject: Re: More IO Changes (need feedback)
> Message-ID:
> 	<CABQG1aRQK0738n-LPLUubK0KVsM765Xzj3UnzTn9BBKUkzq_tQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Howdy,
>
> Can you explain a bit about where your motivation for these branches comes
> from? What issues does it solve?
>
> If these get merged, are these changes likely to make the threads branch
> harder to merge?
>
> We are so close to getting threads merged, so I don't want to anything to
> push us further away from that happening.
>
> Duke
>
>
> On Sun, Nov 18, 2012 at 3:43 PM, Andrew Whitworth
> <wknight8111 at gmail.com>wrote:
>
>> I've got three new branches that I've been playing with today to make
>> even more changes to the IO system. I'd like some feedback on these
>> changes before I do any more work on these. I haven't spent much time
>> on these yet, so if people don't like what they're doing I can abandon
>> ship without losing too much effort.
>>
>> 1) whiteknight/pipe_pmc This branch separates out File and Pipe logic
>> into two separate pmcs. FileHandle is for file IO only and a new Pipe
>> PMC is for pipes only. The mode format specifier "p" is no longer
>> valid and throws an exception in this branch. This is a breaking
>> change. The other branches I've worked on build on this foundation, so
>> if we don't like this we can forget about all of it.
>>
>> 2) whiteknight/io_vtable_lookup In Parrot master, we lookup
>> information about the IO_VTABLE and the read/write IO_BUFFERs using
>> VTABLE_get_pointer_keyed_int. This is a bad system. In this branch,
>> IO_VTABLE is looked up using a type map instead, so a FileHandle
>> always maps to the filehandle vtable, and a Pipe always maps to the
>> Pipe vtable (same for Socket, StringHandle, etc). This branch also
>> adds a new IOBuffer PMC which, while early in development, gives
>> direct access to IO buffer logic. IOBuffer PMCs are now stored as
>> named properties on the PMC (not attributes), which means they can be
>> looked up, attached, and used without any raw get_pointer/set_pointer
>> accesses.
>>
>> 3) whiteknight/io_userhandle This branch brings together the previous
>> ideas and makes the IO system fully polymorphic. In this branch you
>> can use ANY arbitrary PMC as a handle type for purposes of the IO
>> system, without needing to subclass from or delegate to a built-in
>> handle type. So long as your PMC implements a common set of methods,
>> you can use it for all IO operations.
>>
>> Again, these branches are all very early in development. The
>> FileHandle/Pipe change is the only breaking change, everything else is
>> completely internal. If people like these ideas I can continue to work
>> on them and we can talk about timelines and an upgrade path to limit
>> breakages in NQP/Rakudo. If people don't like these things I can go
>> back to the drawing board.
>>
>> Thanks,
>>
>> --Andrew Whitworth
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>
>
>
>
> --
> Jonathan "Duke" Leto <jonathan at leto.net>
> Leto Labs LLC http://labs.leto.net
> 209.691.DUKE http://dukeleto.pl
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.parrot.org/pipermail/parrot-dev/attachments/20121118/c2789145/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 18 Nov 2012 19:31:49 -0800
> From: Christoph Otto <christoph at mksig.org>
> To: parrot-dev at lists.parrot.org
> Subject: Re: More IO Changes (need feedback)
> Message-ID:
> 	<1353295909.13538.140661155327489.1A3E4527 at webmail.messagingengine.com>
> 	
> Content-Type: text/plain; charset="us-ascii"
>
> I did a test merge between his branches and threads, and the only
> conflict was in the root makefile template.  As far as merge order,
> whiteknight++'s branches and the threads branch won't interfere with
> each other significantly.  If he's ready and has something that looks
> like a consensus, I don't see any problems.  Unfortunately threads
> still has a few issues to get sorted out, but it's my first priority
> and rurban++ has been doing some great work.
> Since this is a breaking change, it'll need some feedback from Rakudo
> at some point.  Once I understand the motivation and code well enough
> (i.e. not tonight) I'll drop by #perl6 and see what the fine folks
> there think.  If whiteknight beats me to the punch, that's fine too.
> Christoph
>
>
>
> On Sun, Nov 18, 2012, at 18:42, Jonathan Duke Leto wrote:
>
> Howdy,
>
>
>
> Can you explain a bit about where your motivation for these branches
> comes from? What issues does it solve?
>
>
>
> If these get merged, are these changes likely to make the threads
> branch harder to merge?
>
>
>
> We are so close to getting threads merged, so I don't want to anything
> to push us further away from that happening.
>
>
>
> Duke
>
>
>
> On Sun, Nov 18, 2012 at 3:43 PM, Andrew Whitworth
> <[1]wknight8111 at gmail.com> wrote:
>
>   I've got three new branches that I've been playing with today to
>   make
>   even more changes to the IO system. I'd like some feedback on these
>   changes before I do any more work on these. I haven't spent much
>   time
>   on these yet, so if people don't like what they're doing I can
>   abandon
>   ship without losing too much effort.
>   1) whiteknight/pipe_pmc This branch separates out File and Pipe
>   logic
>   into two separate pmcs. FileHandle is for file IO only and a new
>   Pipe
>   PMC is for pipes only. The mode format specifier "p" is no longer
>   valid and throws an exception in this branch. This is a breaking
>   change. The other branches I've worked on build on this foundation,
>   so
>   if we don't like this we can forget about all of it.
>   2) whiteknight/io_vtable_lookup In Parrot master, we lookup
>   information about the IO_VTABLE and the read/write IO_BUFFERs using
>   VTABLE_get_pointer_keyed_int. This is a bad system. In this branch,
>   IO_VTABLE is looked up using a type map instead, so a FileHandle
>   always maps to the filehandle vtable, and a Pipe always maps to the
>   Pipe vtable (same for Socket, StringHandle, etc). This branch also
>   adds a new IOBuffer PMC which, while early in development, gives
>   direct access to IO buffer logic. IOBuffer PMCs are now stored as
>   named properties on the PMC (not attributes), which means they can
>   be
>   looked up, attached, and used without any raw
>   get_pointer/set_pointer
>   accesses.
>   3) whiteknight/io_userhandle This branch brings together the
>   previous
>   ideas and makes the IO system fully polymorphic. In this branch you
>   can use ANY arbitrary PMC as a handle type for purposes of the IO
>   system, without needing to subclass from or delegate to a built-in
>   handle type. So long as your PMC implements a common set of methods,
>   you can use it for all IO operations.
>   Again, these branches are all very early in development. The
>   FileHandle/Pipe change is the only breaking change, everything else
>   is
>   completely internal. If people like these ideas I can continue to
>   work
>   on them and we can talk about timelines and an upgrade path to limit
>   breakages in NQP/Rakudo. If people don't like these things I can go
>   back to the drawing board.
>   Thanks,
>   --Andrew Whitworth
>   _______________________________________________
>   [2]http://lists.parrot.org/mailman/listinfo/parrot-dev
>
>
>
>
> --
> Jonathan "Duke" Leto <[3]jonathan at leto.net>
> Leto Labs LLC [4]http://labs.leto.net
> 209.691.DUKE [5]http://dukeleto.pl
>
> _______________________________________________
>
> [6]http://lists.parrot.org/mailman/listinfo/parrot-dev
>
> References
>
> 1. mailto:wknight8111 at gmail.com
> 2. http://lists.parrot.org/mailman/listinfo/parrot-dev
> 3. mailto:jonathan at leto.net
> 4. http://labs.leto.net/
> 5. http://dukeleto.pl/
> 6. http://lists.parrot.org/mailman/listinfo/parrot-dev
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.parrot.org/pipermail/parrot-dev/attachments/20121118/fca9c420/attachment-0001.html>
>
> ------------------------------
>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
>
> End of parrot-dev Digest, Vol 51, Issue 7
> *****************************************
>