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