[darcs-devel] [patch1979] better shrinking for patches

Ganesh Sittampalam bugs at darcs.net
Mon Feb 24 07:15:10 UTC 2020


Ganesh Sittampalam <ganesh at earth.li> added the comment:

On 24/02/2020 06:58, Ben Franksen wrote:

> I have taken a closer look at that now. Yes the implementation for
> sequences and pairs is non-trivial. But since it is based on the
> instances for the components, it still doesn't do anything. Yet. This is
> not crititcism, I just want to understand which part of the code is
> actually actively shrinking things and which is mere infrastructure for
> future (or pending) improvements.

The instances for sequences actually drop patches. You don't need to do
any shrinking of the components to get a smaller test case that way.

> Regarding the implementations for pairs and FL. I have looked (again) at
> the documentation for the shrink method in QC. It says the returned list
> should start with the most aggressive shrinks, suggesting that QC stops
> at the first element of the list that fails the property under test. For
> sequences this suggests to me that we should put (Sealed/FlippedSeal
> NilFL) at the head of the result for both shrinkAtStart and shrinkAtEnd.

Yes, probably. I didn't pay too much attention to making shrinking fast,
getting something partially effective has taken long enough :-)

Overall I am not actually entirely sure that Shrinkable in its current
form is that useful. shrinkInternally may not have any useful
implementation, and shrinkAtStart doesn't fit that well with the idea of
propagating a shrinking fixup from the start of the repository. It might
be that it would be better to integrate Shrinkable into the
ShrinkModel/PropagateShrink infrastructure instead.

But as I've said before, good shrinking is complicated enough that it
may well need tests of its own.

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


More information about the darcs-devel mailing list