On Sat, Sep 03, 2005 at 08:57:00PM -0700, Bill Trost wrote: > David Roundy writes: > > Bill, were you interested in implementing some of this support? i.e. > > are you either a haskeller or one who'd be interested/willing to learn > > haskell? > > I did a major project in SML/NJ back as a gradual student, and have taken > a look at Erlang recenly, so I was a little surprised when I took a look > at the code for "darcs get" and found it nearly impenetrable. I've since > read the _Gentle Introduction to Haskell_, and think I was having a > problem with the I/O system and the fact that I was reading the source in > a proportional font, which makes the layout even more confusing. I'm > going to look for a Haskell book tomorrow.
Yeah, you definitely need not only a fixed-width font, but I'd recommend a haskell-aware editor. The haskell-mode for emacs works pretty well (which is what I use). > As to your first question -- clearly, I'm thinking about it, but I'm not > at all convinced I'll get there in a timely fashion. I won't be offended > or surprised if someone beats me to it. Great! > Regarding the actual proposal, there's the question of the actual file > format for this new binary patch format before someone actually starts > coding. Here's an off-the-cuff proposal: > > binary-diff FILENAME DIFF-ALGORITHM > old-start START > old-length LENGTH > new-start START > new-length LENGTH > *HEXHEXHEX > *... > ...repeat with "old-start" for each chunk... I think I'd vote for a non-hexified patch format. We've talked about this recently, and I think the consensus was that we wouldn't mind for binary patches to be binary--in either case the patch content isn't human-readable, and it's not going to be displayed by darcs anyways. And using raw bytes for the binary patch should be considerably faster to parse (and take less disk space/bandwidth) than converting to hex. > I added DIFF-ALGORITHM so that "darcs optimize" has an easy way of > deciding if there's something to optimize -- it's not actually needed > for applying the patch. I think I'd lean against including a diff-algorithm flag. You're right that it could be useful but it's also something we'd have to live with indefinitely, and I don't like that. I'd prefer to add a flag to optimize to rediff binary patches and let the user decide. I think I'd also lean towards sticking the starts and lengths all on the same line with the "binary-diff" and not labelling them. Or we could label them with just a + and -. And don't old-start and new-start have to be identical? binary-diff FILENAME START -OLDLENGTH +NEWLENGTH which looks quite similar to the hunk format, so it should be moderately readable. I might call it binary-xor... I'd prefer "binary", except that that's already taken for the old binary patch format. -- David Roundy http://www.darcs.net _______________________________________________ darcs-devel mailing list [email protected] http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
