Hi all,
Don just pointed out this discussion, and suggested I drop by with a
status
update.
First off, you're right that we're very short on developers for darcs.
None of our experienced developers have much time just for darcs
development just now (with the exception of myself), and we've had a
distinct drop in the number of new developers joining the project.
I'm not
quite sure why that is, but I think in part it is because darcs is Good
Enough for most developers. It's almost exclusively large projects (like
ghc) that run into the major infelicities of darcs, and most
developers who
work on large projects don't have much time to contribute to darcs, while
haskellers who work on small projects are happy with darcs as it is.
I've been working on the conflicts problem (as some of you are aware)
pretty much exclusively (apart from time spent with my Physics PhD
student)
for the past few months (since August). As of last week, I've got an
implementation of the internals that passes all tests I've been able to
throw at it, and I am now in the process of adjusting the high-level code
to use the new patch semantics. If I didn't have a grant proposal due
next
Monday, I'd expect to have a working version of darcs in the next week,
it's moving that fast. It helps that the new code implements
semantics are
very similar to the existing semantics.
Darcs 2 will use the new "hashed inventory" repository format that
some of
you are familiar with. The format cleans up the concept of a "partial"
repository basically by allowing lazy downloading of patches as
needed. I
believe this will address most of the problems ghc folks have reported
with
--partial repositories, which is why I developed this format. It also
has
advantages in terms of atomicity and in that it enables easy signing of
repositories to verify the complete contents.
I suspect there will be major performance regressions, however, with the
new code, because much of it was written with scaling and correctness in
mind, but without special care to ensure laziness to keep down memory
use.
So hopefully once the test version is out, we can get some serious
performance testing. I plan on devoting what time I can to fixing
performance (and correctness) issues over the next semester, although
I'll
also need to devote more time to Physics than I have this semester.
I do plan on writing a paper on darcs' semantics and submitting it to
POPL.
Oh yes, and also in the plans is a couple of new formats for darcs
patches,
particularly hunk patches, which should greatly improve parsing and
file-writing times as well as memory consumption. Basically, the idea is
to store the new and old version as contiguous blocks of bytes
(without the
'+' and '-' at the beginning of each line), so that we can skip right
over
hunk patches when parsing.
I'm sure that I haven't addressed all of the concerns that have been
expressed here, but hopefully you've got a somewhat clearer idea as to
what's been going on in darcs-land. To reiterate, we *are* very short of
developers. Most of us (former and current darcs maintainers) seem to in
academic jobs which don't leave us much time for hobbies.
Contributions to
the development effort would be very much appreciated!
Incidentally, at this point, darcs development is also provides an
opportunity to play with GADTs and existential type witnesses, as we've
gotten that going in the code. I expect I'll end up writing a separate
paper on that subject, since it's a neat set of tricks to statically
eliminate rather a large class of bugs.
--
David Roundy
Department of Physics
Oregon State University
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
