announcing darcs

[David Roundy]

On Wed, Apr 09, 2003 at 04:02:36PM +0100, Alastair Reid wrote:
> 
> [moved from cafe to libraries]
> 
> David Roundy <droundy@abridgegame.org> writes:
> > [darcs] contains a few bits of code that you might find useful,
> > such as an interface to libcurl (for lazily reading files over http
> > or ftp)
> 
> This sounds like it would be a valuable contribution all by itself.
> Could you make it available as a package with its own (copy of the)
> license?  A very brief look at the existing network support suggests 
> that Network/C_URL might be a good place to put it.

I'd be happy to package the curl stuff as a library, except that I am not
sure my current code is portable beyond POSIX systems.  And also, it's such
a small amount of code (about 150 lines), that it seems weird to package it
separately...

> A quick glance at libcurl documentation suggests that it is quite
> portable (unix and win32).

Indeed, libcurl is nicely portable, but I doubt my code to lazily link to
the libcurl library is portable.  I use pthread_create and pipe to let curl
do the downloading asynchronously...  I'm not sure how portable either of
those system calls are.  If pthread_create is a problem, I could always use
fork() instead, if that is more portable, but I have no idea whether that
might be the case.  pipe() I don't see how to get around, and I have no
idea if it is supported on windows.  Any idea if these are available on
windows?

> > darcs is currently unix-only (counting MacOS X as unix).  A port to
> > windows would be a fair amount of work, but probably would mostly be
> > straightforward (mostly dealing with slashes versus backslashes and
> > getting libcurl to work under windows). 
> 
> This reminds me of a library I have been wanting for a while:
> functions for manipulating filenames in a portable way.  The main
> requirement is that you should be able to manipulate a filepath as
> though it was structured something like so:
> 
>   (Maybe [Directory], Maybe Filename, Maybe Suffix)
> 
> For example, on a Unix system, /usr/lib/libcurl.so would be
> treated something like this:
> 
>   (Just ["/","usr","lib"], "libcurl", Just "so")

For my purposes, I think a simpler system would be acceptable (partly
because I don't deal with filename suffixes), which would simply swap
between a "canonical" pathname (which might be user defined, or could
just be required to be unix-like) and a "local" pathname.

I imagine something like a (using a regexp paraphrase a la perl)

canonical_to_local = s/\//\\/g (this is on windows, on unix it would be
                                identity)
and

readFileCanonical = readFile . canonical_to_local

so that replacing readFile with readFileCanonical would magically make your
program accept unix-style filenames rather than windows ones.  Of course,
we'd also need to deal with unix filenames that have backslashes in them,
so it wouldn't be this simple...

> ... and there is
> (presumably) much reinvention of the wheel when people decide to 
> implement functions which really work.

If I ever get around to porting to windows (which I'm unlikely do myself,
since I don't have windows, and don't relish the idea of trying to set up
an mingw ghc cross-compiler) I'll see if I can figure out a nice way to
package the filename code...  :)

> Oh yes, I should say that 'darcs' sounds quite cool as well...

Thanks!
-- 
David Roundy
http://civet.berkeley.edu/droundy/