[darcs-devel] announcing darcs 2.0.0pre1, the first prerelease for darcs 2

David Roundy daveroundy at gmail.com
Wed Dec 19 15:42:29 UTC 2007

On Dec 19, 2007 9:53 AM, Dmitry Kurochkin <dmitry.kurochkin at gmail.com> wrote:
> I have created a Libwww.hs module and hslibwww.c. Libwww.hs provides
> getUrl and getUrls functions. I have changed copyRemotesNormal to use
> getUrls. And it is ready for testing. But I get compilation errors on
> hslibwww.c.
> It is compiled with GHC, not GCC. If I run GCC by hand it works fine. Errors
> say that there are redefined symbols in libwww header files, like:
> In file included from /usr/include/w3c-libwww/WWWLib.h:50,
>                  from src/hslibwww.c:5:0:
> /usr/include/w3c-libwww/wwwsys.h:1099:1:
>      warning: "strchr" redefined
> Any ideas? Why is GHC used for C sources?

I think ghc is used for C sources just to keep the build/configure
process simple.  ghc knows how to compile C files, and this way we
only need to identify one compiler... although the configure script
does actually identify a C compiler also.

Hmmm.  I'm not sure this should be an error, it says it's only a warning...

> > So a much nicer feature would be something that can work with lazy
> > downloading, and somehow add URLs to the pipelined queue as we go.  I
> > don't know if libwww will work with this approach, but I suspect it'd
> > require the least reworking of darcs' code.
> If I understand correctly the only way to implement this is a background thread.
> Or some kind of event loop inside darcs...
> Multithreading with FFI is a tricky point.
> What is the problem with getting all filenames before starting a download?

Right.  That, and we'd like to be able to start using files before
they're all downloaded, which means we'd require something a little
asynchronous.  For example, when doing darcs changes -s, it'd be nice
to be able to start displaying patches before they're all downloaded
(as is currently the case).

> Do not we know in advance what patches we need?

That's right.  There are a couple of complexities.  One is that we
currently support "lazy" downloading of files, where we only download
those that we need.  The second is that the caching system means that
for hashed repositories we don't always download all the files that we
need, since some of them may already be available locally.  The latter
issue isn't too hard, as we could just filter the files, but lazy
downloading is really nice in terms of keeping the code simple and
avoiding needless downloads, so I'd like to keep it.

> If which patches we need to download depends somehow on content of patch
> we have just downloaded we can provide a callback for darcs. When
> libwww completes
> another transfer it calls a callback and darcs based on content of this patch
> adds new downloads to event queue.

Hmmm.  This does sound like it could be used to implement an
asynchronous download queue.

> The question here is, can we call haskell functions from C? I have no
> experience here...

Yes, we can call haskell from C, but it's a bit scary.  Maybe you'd
want to write a C callback and have the Haskell code stick stuff into
a global queue for the C code to access?

> > But definitely rewriting copyRemotes is a good starting point.
> > Ideally we wouldn't remove the libcurl code, but would enable
> > configure checks to use libwww if we can, otherwise use libcurl if
> > it's present, and finally fall back on wget, etc if no librarys are
> > present.
> Yes, this should be the first step. I hope to resolve compilation
> issues soon. After
> that some more changes are needed (like printing progress).
> I am not familiar with configure stuff, so help is welcome here.

I can definitely handle the configure stuff, so if you send in a
working patch without configure support (that just assumes libwww is
available), along with a note to this effect, I'll see about adding
the configure bits.  Thanks!


More information about the darcs-devel mailing list