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).
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 think for older ghc's we might need to forward port a couple of bits
> (like runProcess) from GHC's sources.
You mean backwards port?
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?
> Some of Compat.hs will probably need to be written differently for win32
> too, but I think some of it can be done with the System.Posix.Internals
> that it has.
>
> 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.
On the whole, I'd rather see this as several smaller patches. One
advantage of that, is that then the windows developers wouldn't be stuck
with a monolithic transition. The runProcess code, for example, should
already be portable. Some other bits, like your error handling changes,
also look portable.
The file handling stuff (symlinks and whatnot) definitely requires that the
win32 folks do some porting, so I'd rather have that isolated into a
separate patch.
--
David Roundy
http://www.darcs.net
_______________________________________________
darcs-devel mailing list
[email protected]
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
