On Tue, Sep 22, 2009 at 09:19:57PM -0700, John Meacham wrote:
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.
Yeah, that'd be great! (and *that* is something I could easily hack on...)
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.
I can certainly understand that. I wonder, though, if it wouldn't be reasonable to present a nice interface for creating Handles that aren't backed by FILEs. I've always been annoyed that Haskell provides no standard way to create a Handle, e.g. using gzopen, so you can't reuse any of the standard library. How many "raw" functions do we actually use on Handles? Perhaps we could define a Handle like data Handle = GenericHandle { handleName :: String, handleClose :: IO (), handleReadLine :: IO String, handleWrite :: String -> IO (), ... } | Handle { handleName :: String, handleFile :: Ptr FILE, ... and then maybe expose an interface like... class HandleLike h where hname :: h -> String ... createHandle :: HandleLike h => h -> Handle so that libraries could generate Handles on their own? So long as it's only exported from Jhc.Handle, it needn't be terribly elegant or stable, but that would at least allow the process library to be ported to jhc. David