Re: announcing darcs

On Wed, Apr 09, 2003 at 05:40:31PM +0100, Alastair Reid wrote:

David Roundy writes:

...

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.

Anything to do with creating threads or processes is likely to have porting problems in my experience.

I had a quick glance at the libcurl overview

http://pinkstuff.publication.org.uk/cgi-bin/man2html?libcurl+5#lbAF

and thought it could be used portably. Seems like I missed something.

libcurl certainly can be used portably, but then it must be used synchronously (unless _I_ missed something!), but I want to be able to process the file as it is downloaded. The pretty way to do this, of course, is to have a lazy read function, but in order to implement that lazy read function I had to use a separate thread for the curl function that'll be doing the reading. This is nice, as it allows me to create a readUrl which is functionally identical to readFile, but is a bit of a pain as far as portability goes. So basically, yes libcurl could be used portably, but none of the code I've written is probably portable (beyond POSIX systems running ghc).

Alastair:

...

...

This reminds me of a library I have been wanting for a while [...]

David:

...

For my purposes, I think a simpler system would be acceptable [...]

Ah, you actually want something different from what I proposed. (I thought of the possibility as I was writing it but dismissed it as being of little use - your example shows exactly when it is useful. The real world is always tricker than you like to think...)

What I proposed was that the library would parse filenames according to the local conventions on your machine - win32, unix, macintosh, etc.

What you need is a set of libraries to parse filenames according to a set of conventions. For example, you might need to convert win32 filenames to unix filenames and back again.

I see the difference. But if we had the full filename parser that you proposed, it would be trivial to use it to implement the simple filename convention transformer that I would be interested in. i.e. I could write my transformation to a canonical form as parsed_path_to_unix :: ParsedPath -> String parse_path :: String -> ParsedPath local_to_canonical = parsed_path_to_unix . parse_path Assuming here that parse_path is defined on each platform to parse the local filename conventions.

I can't help you gain access to windows but Hugs is many, many times easier to install than GHC - you don't need mingw, cygwin or anything like that. (Truth in advertising: to use the ffi (e.g., to interface to libcurl), you do need a C compiler :-()

Hmmmm. I hadn't thought of using hugs! I do need ffi (for libcurl), but I already have the mingw c/c++ cross-compiler installed (I use it to compile the windows version of my bridge game), so I may be able to port to windows with less trouble that I had thought, by running hugs under wine... -- David Roundy http://abridgegame.org