Looks like the excitement was a bit premature. The types work, and in
Haskell that often means the program works... but looks like hDupTo relies
on the `dup2` of the IODevice class, and attempts to cast one IODevice to
another IODevice. Since I'm trying to replace stdin (with IODevice type Fd)
with my own IODevice, the cast fails and raises an exception. Practically
ClassCastException.... yeesh.
On Sun, Jan 5, 2014 at 5:19 PM, Andrew Gibiansky wrote: I think we found a way! (With a *ton* of help from @aavogt - might
actually be more correct to say he found the way :) ) You can use `hDupTo` to change what a Handle points to. You can use
`mkFileHandle` in GHC.IO.Internal to create a new file handle. You can
implement your own IODevice and BufferedIO datatype to give to
`mkFileHandle` instead of using `Fd`. Then, when your "device" is being
read from, you just implement `newBuffer` and `readBuffer` to do whatever
you need them to. Results pending. -- Andrew On Sun, Jan 5, 2014 at 4:14 PM, Donn Cave I bet a quarter you can't do it. You'd need access to the process state -
whether it's blocking for I/O and whether one of the units in the input
set
is 0 ("stdin".) Even if you could get that? you'd have to poll for it,
which
would be hideous. That's the UNIX I/O model. I've always found it a little annoying,
because
I could do this with the VMS `mailbox' device, analogous to UNIX pipes -
in various ways a more sophisticated interprocess communication system
than
UNIX's. Donn
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe