More IO Changes (need feedback)

[Christoph Otto]

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