More IO Changes (need feedback)

[Jonathan "Duke" Leto]

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.html>