[darcs-devel] [patch1880] decouple RepoPatchV3 impl from NamedPrim

Ben Franksen bugs at darcs.net
Tue Aug 27 21:42:14 UTC 2019


Ben Franksen <ben.franksen at online.de> added the comment:

>>>   The laziness property of 'seal' doesn't seem to be actually
>>>   needed by any test and is unlikely to have any performance
>>>   impact.
>>
>> Back to normal after I obliterated this one and rebuilt. I should have
>> known, of course. Still, interesting to observe how much of a difference
>> this makes in practice.
> 
> OK, seems this one needs to be handled with extreme care. I shall do so.
> It's still horrible though :-)

It is. On the other hand, the way we use unsafeInterleaveIO for reading
hashed files is safe, and it saves us from a lot of hassle we'd
otherwise have, to make sure we don't read more from disk (or even
download) than necessary. I am almost sure that streaming libraries a la
conduit aren't up to the task, given that we want to read both
inventories and patches on demand and that everything we produce is
witness typed.

An (as yet unsent) patch in my Repository refactors reduces the pattern
to two occurrences, defines a local function make_lazy for it, and also
documents why we do this.

I am quite glad we have tests that fail if we make a mistake here.
tests/issue2293-laziness-amend.sh is particularly drastic: the repo it
unpacks misses the parent inventory of _darcs/hashed_inventory so we run
into an error as soon as we try to read more than the top-level
inventory (which has only the tag and a single patch).

Perhaps the "unseal seal <$>" could be avoided if we are willing to
incur some major upheaval. I believe the reason we need this are the
pattern matches on the Sealed constructor. These ultimately stem from
the type of readPatch, which returns a Sealed p. I think we could change
that to return the un-Sealed patch with two witnesses (so the caller
gets to choose them at will). I may play with this idea.

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/patch1880>
__________________________________


More information about the darcs-devel mailing list