On 4/22/06, Ian Lynagh <[EMAIL PROTECTED]> wrote:
>
> [replying to 2 messages in one]
>
> On Sat, Apr 22, 2006 at 10:15:07AM -0700, Jason Dagit wrote:
> >
> > I found some time tonight to start implementing a different format for
> > hunks. Very simple but meant to allow skipping over data.
> >
> > hunk <filename> <line#> <#bytes of old content> <#bytes new content>
> > <dump of old lines><dump of new lines>
>
> I don't know where in the list archives or bug trackers it is OTTOMH,
> but what the new format should look like has been discussed before.
Yes, I thought it had been as well. But for some reason finding those
emails is not easy for me (I searched on gmane mostly). I couldn't
find them after about an hour of searching so I figured I'd just go
for it.
>
> I think it looked something like
>
> hunk <file> <byte#> <line#> <#old bytes> <#old lines> <#new bytes> <#new
> lines>
> old:
> <the old data>
> new:
> <the new data>
>
> (#lines is probably length . filter ('\n' ==))
Why is it useful to store the byte# and #old lines/#new lines? It's
not clear to my why that's useful. Plus the calculation, even if it
doesn't increase the algorithmic complexity would increase the
constant, whereas lengthPS is O(1) according to a recent email from
Don Stewart on the Haskell-Cafe list. I'm probably missing something,
I just don't know what.
> There was also a discussion about how to indicate that this is version 2
> of the hunk patch type, but I don't remember the conclusion (or if there
> was one).
Yeah, maybe instead of 'hunk' it woul be 'hunk-offsets' or something
like that. I think it's pretty easy to change that so that old style
patches continue to be parsable. Also, there is the RepoFormat module
that allows us to specify that a given repository supports or prefers
a certain patch type. It looks like it would be pretty easy to add
'hunk-offsets' to that format. Although it might be wise to bump the
darcs version number if a new patch format is adopted. For example,
darcs 1.1.0 instead of darcs 1.0.8.
> > 1) How many bytes do line endings add to the length of the old or new
> > content? Is it okay to assume line endings are exactly one byte in
> > patches? I know this will hold in unix-land, but what about win32?
>
> You should treat line endings compatibly with current darcs (which,
> again OTTOMH, I think means exactly '\n').
Based on Tommy's email that seems to be what everyone agrees on :) I
was mostly asking because showHunk creates a Doc object and since you
don't know at that time how many bytes will be used in the 'rendering'
of the Doc you have to guess. Perhaps the values of the run-lengths
should be computed at a lower level so that they will be correct
regardless of the rendering.
> > 2) Currently when using darcs interactively (in darcs record for
> > example) what you see on the screen is a dump of what goes into the
> > patch file. So the direct result of my new patch format is that the
> > patch goes from being easily readable by humans to a bunch of garbage
> > all lumped together.
>
> The new format should probably be pretty-printed into something like the
> current format when being shown to the user, if that's what you're
> asking.
Okay, and perhaps darcs should check DARCS_PAGER for hunks which take
more than say 10 lines and use a pager to display them. It could help
for really large patches. A friend requested that feature the other
day and I think he's on to something there.
>
> > My new hunk reading code is
> > essentially:
> >
> > lines (take n s)
> > where
> > n = length in bytes of either old or new
> > s = patch data as a Stringalike
>
> Why are you calling lines? The point of the new format is that, for most
> operations (all but pretty-printing?), it stays as a single string.
Because I was afraid to change the Hunk data constructor which looks like:
Hunk !Int [PackedString] [PackedString]
So I figured that meant I had to break the lines myself before
constructing the hunk object.
I guess I could try not splitting it and see what happens.
Thanks,
Jason
_______________________________________________
darcs-devel mailing list
[email protected]
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
