Re: announcing darcs

On Wed, Apr 09, 2003 at 04:02:36PM +0100, Alastair Reid wrote:

[moved from cafe to libraries]

David Roundy 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/