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
