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?
> 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.
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.
> > 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?
Err, yes.
> 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.
> > 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.
> 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 :-)
Thanks
Ian
_______________________________________________
darcs-devel mailing list
[email protected]
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
