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-requ...@lists.parrot.org <parrot-dev-requ...@lists.parrot.org>: > Send parrot-dev mailing list submissions to > parrot-dev@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-requ...@lists.parrot.org > > You can reach the person managing the list at > parrot-dev-ow...@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 <wknight8...@gmail.com> > To: parrot-dev@lists.parrot.org > Subject: More IO Changes (need feedback) > Message-ID: > <caepdb4rbmho3ip9ttpa6louuzrpbvo72nglqu7e1twmjz8q...@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" <jonat...@leto.net> > To: Andrew Whitworth <wknight8...@gmail.com> > Cc: parrot-dev <parrot-dev@lists.parrot.org> > Subject: Re: More IO Changes (need feedback) > Message-ID: > <cabqg1arqk0738n-lpluubk0kvsm765xzj3unztn9bbkukzq...@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 > <wknight8...@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 <jonat...@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 <christ...@mksig.org> > To: parrot-dev@lists.parrot.org > Subject: Re: More IO Changes (need feedback) > Message-ID: > <1353295909.13538.140661155327489.1a3e4...@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]wknight8...@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]jonat...@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:wknight8...@gmail.com > 2. http://lists.parrot.org/mailman/listinfo/parrot-dev > 3. mailto:jonat...@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 > ***************************************** > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
