On Sun, Sep 20, 2009 at 7:01 PM, John Meacham wrote:

On Sun, Sep 20, 2009 at 06:26:30PM -0400, David Roundy wrote:

...

This patch adds support for popen/pclose.  It's a bit hokey, and doesn't quite work right.  In particular, I get an error if I try to use getErrno in openPipe.  gcc complains about errno not being defined, because errno.h isn't included.  For the moment, openPipe just doesn't check for errors, but that isn't a great long-term solution.

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

...

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.

...

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). -- David Roundy

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

On Wed, Sep 23, 2009 at 09:23:19AM -0700, Taral wrote:

On Tue, Sep 22, 2009 at 9:19 PM, John Meacham wrote:

...

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.

C requires that all lvalues have an address. The standard merely states that the address is volatile (i.e. don't use it).

Not all lvalues have addresses.

register int x; &x;

is an error for instance. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/