[darcs-users] index format

[Eric Kow]

On Tue, Jun 09, 2009 at 12:01:30 +0200, Petr Rockai wrote:
> >           name = snd $ case dirlen of
> >                          Just split -> BS.splitAt split path_noslash
> >                          Nothing -> BS.spanEnd (/= '/') path_noslash

> I'm not sure it's very cool, but I guess the opposition to
> error/undefined is too strong for whatever reason. (I'm just wondering if one
> of these days when we get HPC reports of darcs, people will complain about
> never-executed code lines ...) And I guess we should now bury this discussion?

Sorry to drag this out some more.  Just remember that I'm only here to
offer alternative suggestions if they can break us out of a loop.

My personal ranking is
 1. Avoiding the problem altogether (lateral shift)
 2. error "reason why we never expect this to be executed"
 3. undefined
 4. Code for a case which we never expect to run

I just assumed that you had figured out a #1, but if you're saying that
this is more of a #4, then I agree with you.

By all means, "Crash Early" (The Pragmatic Programmer [*]).

> > Yet another question
> > --------------------
> Ahw about hyperlinks. As for tacking newlines between entries, I'm not sure
> it's really useful, since the file contains binary garbage in-between
> anyway.

Likewise, let me stress that I'm happy to drop this part of the
discussion at any time :-)

What I figured was that
  <garbage>/foo/bar<garbage>hash<garbage>
  <garbage>/foo/bar/baz<garbage>hash<garbage>
  <garbage>/foo/bar/quux<garbage>hash<garbage>
is better than nothing.

Here's a real world snippet using [[]] to simulate the reverse video
bits.  Compare:

[[^B^@^@^@]]/[[^@]]1ea69d21549ab5043ef03f2a9eaa0ae345485ec6a7e2b6d9edeca5b1832606894[[^B^@^@^@^@^@^@<E2>^G^@^@^@ ^@^@^@ ^@^@^@]]Storage/[[^@]]2b5fd777f083ab04290114a783ec47e6228571d5f610335a0340b4344ae48f45[[<BA>^@^@^@^@ ^@^@^@u^D^@^@^@^@^@^@^P^@^@^@]]Storage/Hashed/[[^@]]9f7b5c2ba81dabdc09561448d48e7f75fb7283316dcbc14a55777a3cb95807b8[[<81>^B^@^@^@^@^@^@^O^D^@^@^@^@^@^@]]

with

[[^B^@^@^@]]/[[^@]]1ea69d21549ab5043ef03f2a9eaa0ae345485ec6a7e2b6d9edeca5b1832606894[[^B^@^@^@^@^@^@<E2>^G^@^@^@]]
[[^@^@^@ ^@^@^@]]Storage/[[^@]]2b5fd777f083ab04290114a783ec47e6228571d5f610335a0340b4344ae48f45[[<BA>^@^@^@^@ ^@^@^@u^D^@^@^@^@^@^@]]
[[ ^P^@^@^@]]Storage/Hashed/[[^@]]9f7b5c2ba81dabdc09561448d48e7f75fb7283316dcbc14a55777a3cb95807b8[[<81>^B^@^@^@^@^@^@^O^D^@^@^@^@^@^@]]

Hmm, maybe you're right that the improvement is negligible, if not the
utility :-)

> I guess I'll extend the listing format to include hashes and entry types. Maybe
> add specialised code to dump also timestamps (those are internal to the Index
> and there's no external interface to access them).

Sounds good.

(*) Here are those tips again for anybody who's enjoyed that book
    http://pragprog.com/the-pragmatic-programmer/extracts/tips

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090609/ab5b2703/attachment-0001.pgp>