[darcs-users] David's darcs

[Jason Dagit]

On Wed, Jul 22, 2009 at 6:55 AM, Petr Rockai <me at mornfall.net> wrote:

>
> (This is, hunks operating on abstract files that are never added or
> removed. Instead, the abstract files are added or removed from the
> "working"
> set by a separate patch type, say "incarnate <some-uuid-thingy>
> <path>". Conflicts on this level are very simple, and all other conflicts
> are
> confined within a given abstract file. It may involve some trickiness on
> the UI
> level, but the core part is trivial and fixes a whole lot of existing
> "core"
> issues.)


It would be interesting to see someone write down the commutation rules for
those patches relative to the other patch types.


>
>
> Also, we probably want Camp to provide us with new core bits, at least for
> the
> things that happen inside these abstract files -- commuting and merging
> hunks. I have no idea what happens to the megapatches (changesets) of Camp
> and
> how we map things to darcs. I don't know how will the camp-core API look
> like. Most of this is an open question.


Interesting.  I didn't realize there were plans to incorporate bits from
Camp.


>
> This will be a little more challenging in darcs, since for the other
> project,
> we could afford to throw away the UI, since it was mostly trivial, and
> write it
> from scratch, so it was not part of the legacy code library. But I assert
> this
> would be definitely possible.


The darcs UI has some non-trivial bits in places like SelectChanges, but for
the most part the stuff in the Commands/* modules is pretty light.  We have
some implicit zippers in the UI code too that could probably be farmed out
to a library modulo some low level unsafePerformIO hacks we have in there
for optimizations.  (At some place we have a pure interface and under the
hood it stores references and mutates them but the caller can't tell so it's
still safe.)

I think we basically agree about the approach to clean things up.  My
opinion is that more unit tests, more minispecs, and better source level
documentation would improve the situation more than a rewrite would.  We
need those artifacts (unit tests, minispecs, documentation) in both
scenarios (refactor vs. rewrite).  There is a lot of code that I wanted to
refactor more aggressively when I was doing the type witness stuff, but I
just didn't know why the code was there or what API it was expected to have
versus what it really had.  I know from experience that when I don't
understand a bunch of source code and it's hard to read that I usually just
want to throw it all away and start over.  But, I also know from experience
that refactoring in place until the code is readable again is usually
better.  In other words, I'm hesitant to take a bunch of code from Camp or
throw away a bunch of stuff.  Incremental refactoring is better in my
opinion in this case.


>
> Well, left fold is great abstraction, but it has some issues when it comes
> to
> darcs... That is, folding is nice for streaming, but many darcs operations
> require random access -- this is not something I expect to translate well
> into
> iteratee-like approach. Basically, the only operations that would really
> take
> advantage of this would be those that work from the top of the patch stack
> linearly downwards: applying and unapplying patches, and even then only for
> the
> patch input -- the working copy needs to stay random-access.


For things like grabbing a file and inserting/deleting a hunk this may very
well be true.  But, I also know that a lot of the execution paths that eat
up a ridiculous amount of resources tend to stream things "lazily".  Yes
patch formats could be optimized so that we can fseek to the data, take
slices from the inventory, and we need to jump to directory entries
efficiently, but I don't think this is the end of the story.  I'd love to be
able to tell people that darcs never uses more than X megs of ram and you
can specify X on the command line.  I think iteratees will get us much
closer to this goal than lazy IO will.  Partially, I simply think lazy IO is
broken and I'd love to try just about anything that can replace it.

Just my $0.02,
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090722/cba8822d/attachment-0001.htm>