announcing darcs

David Roundy droundy@marbles.mit.edu
Wed, 9 Apr 2003 13:42:00 -0400


On Wed, Apr 09, 2003 at 05:40:31PM +0100, Alastair Reid wrote:
> 
> David Roundy <droundy@abridgegame.org> 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