[jhc] darcs patch: add System.IO.Pipe.

[John Meacham]

On Mon, Sep 21, 2009 at 01:50:05PM -0400, David Roundy wrote:
> > errno.h is ISO C, so we can include it in src/data/rts/jhc_rts_header.h
> > without issue.
> 
> I'm confused, though, as to why this would be needed.  I looked at the
> foreign import that defined errno (and getErrno), and it seems like it
> specifies the header file, so I thought i would be included
> automatically...

Ah. Looks like there is a bug where include files for imported addressed
(using &) lose their C #includes at some point. thanks for finding that!
Actually, I believe 'errno' might require some special support, I seem
to recall that taking the address of it was invalid, as it may be some
sort of special #define for multi-threaded support to work properly. The
only requirement is that it is an lvalue, not that it have an address. 


> >> So far as I can discern, this is portable code, at least to mingw,
> >> which is as far into windows as I care to venture.
> >
> > cool. I should modify the regressions to test with mingw/wine when they
> > are available actually.
> 
> That'd be nice... I imagine you could look at the targets.ini files to
> see if they're available.  That's how my mingw is configured, anyhow.

True. I learned recently that debian and fedora have different names for
the mingw installed compiler. perhaps this is something the ./configure
script should test for and embed in the installed targets.ini.


> >> P.S.  I'd much rather have System.Process ported, but gave up on doing
> >> this myself after realizing that I'd have to implement much of
> >> GHC.Handle in order to do this, since we'd have to work with file
> >> descriptors rather than FILE *.  :(
> >
> > Is this true? can't we just use fdopen(3) to turn the descriptors into
> > handles?
> 
> You're absolutely right.  I had suspected that there was such a system
> call, but couldn't remember its name, and didn't come across it.
> Although the name is pretty obvious... except that you aren't actually
> opening anything.
> 
> Porting System.Process to jhc does, however, require dealing with lots
> of nasty code, and also requires that we deal with windows separately,
> which is scary.  And I'm not sure whether there is something
> fdopen-like on windows (or if it's needed).

Yeah. I would like to avoid actually re-implementing buffered IO in
haskell. presumably the OS provided implementation has been heavily
optimized and may use OS specific interfaces that are more
efficient than the portable read(2) and write(2). At least for the
provided 'Handle' type.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/