[darcs-devel] darcs patch: Remove compat.c

[David Roundy]

On Fri, Jul 29, 2005 at 05:03:13PM +0100, Ian Lynagh wrote:
> On Fri, Jul 29, 2005 at 07:59:39AM -0400, David Roundy wrote:
> > On Thu, Jul 28, 2005 at 03:29:07PM +0100, Ian Lynagh wrote:
> > > 
> > > I'd really like to get rid of compat.c. The attached patch does it
> > > for Linux+ghc6.4 (minus a few niggles: Needing to import GHC.IOBase
> > > and not giving a stderr handle to exec).
> > 
> > I'm not so keen on this transition, although I'm not against it.  It's
> > just that I've been bitten by changes in the Posix API (I think this
> > was when moving to the heirarchical libraries).
> 
> Hmm, are you sure you aren't thinking of GHC.Handle.openFd?

I think you're right.

> > There's also the factor that I'd prefer to move in the direction of not
> > using FilePaths, for a couple of reasons.  One is that I fear that for some
> > operations (imagine whatsnew with no changes on a repository with many,
> > many files) the conversion to and from haskell strings may be a significant
> > performance penalty.  The other is that if ghc ever supports unicode
> > characters in FilePaths, we would have to scramble to work around that
> > feature (which is why FilePaths will probably never be unicode strings).
> > So my preference would be to move more towards the FFI rather than away
> > from it for filesystem access.
> 
> I'd prefer to see this handled on the Haskell side rather than the darcs
> side if possible. I should mail the libraries list about it and see what
> opinions are like.

That's a good idea.

> If we do end up wanting to manipulate C filenames ourselves then I'd
> rather we had a module that just did FFI imports of standard functions
> (and perhaps one on top of that reimplementing System{.Posix,}.IO with
> this filename style) rather than writing the rest of the code in C files
> too. We might be able to get the functions we need from
> System.Posix.Internals, but then we probably have stability worries.

Yeah, that would be fine with me (FFI importing the POSIX functions and
calling from haskell).  Although we might run into trouble handling macros
that way--they'd require C wrappers.

It's just that given a choice between using the POSIX C API and the
System.Posix API, I'd rather go with the former, since it'd allow us to
safely interoperate with other C libraries (e.g. zlib and curl) without
relying on the non-standard haskell property that a FilePath converted to a
CString with withCString is actually the C string that points to the same
file.

There's also the factor that System.Posix doesn't support all POSIX
functions (most notably, mmap is absent), so we will in any case have to
use the POSIX C API for at least some of our code, and will need to use C
filenames ourselves (even if we ignore the factor of zlib and libcurl).

> > In any case, I'd rather not go this route.  I'd prefer to just wait
> > until ghc 6.2 is old enough that we no longer care about it (has this
> > already happened?), and then just switch to runProcess.  Are there any
> > systems with ghc 6.2 but not 6.4 that we want to support?
> 
> Debian stable will have 6.2.2 for at least a year.
> darcs.net has 6.2.2.
> 
> That said, I'd like not to be tied down by old ghcs too; I was just
> expecting resistance from you on that front. The ghc6 6.4 in unstable
> ought to be installable on Debian sarge systems, so you should be able
> to put that on darcs.net. I expect to make a stable backport for 6.4.1.

Actually, I had forgotten that ghc 6.4 wasn't in sarge (I think I had it
mixed up in my head).  I would definitely like to maintain compatibility
with ghc 6.2.

That said, replacing the current Exec implementation would be a Very Good
Thing, probably well worth the ugliness of including some of ghc 6.4's code
in darcs.  But to justify replacing the current implementation, I'd like to
see an extension of what we're actually able to do.  In particular, one of
the most annoying problems (in my office, anyways) with the current exec is
that one can't access the stdout of the process until it's complete, so
while the test suite runs during a darcs push (which takes over two hours)
you get no output at all.  I think that runProcess is sufficiently powerful
to allow one to attach the output of the process directly to stdout? Or at
least to access it as a lazy string while we wait for the process to
finish?

> > > The raw mode stuff should probably be pulled out to a win32/RawMode.hsc
> > > (which I think can use something like {-# type DWORD #-} to handle the
> > > types correctly).
> > 
> > Or perhaps rather we should move without_buffering into DarcsUtils or
> > Compat (or something).  It really doesn't belong in SelectChanges.
> 
> We can do that too. I just thought it would be simplest if the minimum
> of code was in .hsc files.

Right, it would definitely make more sense to put the conditional code in
haskell.

> > On the whole, I'd rather see this as several smaller patches.
> 
> OK, sure, I'll do that. It'll just take a bit more time to make sure
> it's compilable at each step  :-)

Great!
-- 
David Roundy
http://www.darcs.net