Re: [PATCH] Two issues with the gnus-registry

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>>
>>>> Ted Zlatanov <tzz@lifelogs.com> writes:
>>>
>>> [...]
>>>
>>>>> The registry has ERT tests, which I thought covered this case.  Can you
>>>>> look at `tests/gnustest-registry.el'?  As a first step, can you try
>>>>> making tests to demonstrate the problems?
>>>>
>>>> Will do.
>>>
>>> Okay, turns out there were tests, but the bit that tests pruning was
>>> commented out :)
>>>
>>> This is the first in a (gradual) series of patches. It does very little
>>> except:
>>>
>>> 1. Adjust `registry-prune' to do what the docstring says: return the
>>> total number of entries pruned
>>>
>>> 2. Uncomment the pruning test and adjust it so it correctly catches the
>>> number of pruned entries.
>>>
>>> Test should fail. Over the next couple of days I'll add another test to
>>> check that entries are sorted correctly before pruning, and then take a
>>> stab at fixing the pruning itself.
>>
>> Okay I realized it didn't make too much sense to patch gnus just to make
>> it fail, so here's a complete patch, with passing tests, that preserves
>> precious entries when pruning. I haven't done the sorting yet, that will
>> be a separate patch.
>
> And of course seconds later I realized that the test didn't quite match
> the logic of the function, here's a new version.

Nope, I still can't make this work -- I just don't get the relationship
between max-hard and max-soft. If max-soft is higher than max-hard, then
it will never get used at all. When the registry reaches max-hard in
size it will get pruned back, but pruned back to what size? To (*
max-soft prune-factor)? But that's likely already higher than
max-hard. To (* max-hard prune-factor)? In which case, what's the point
of max-soft?

If max-soft is less than max-hard, then it makes more sense -- when we
reach max-hard, we prune down to max-soft. But in that case the
prune-factor isn't really useful -- we might as well just prune directly
to max-soft, since pruning won't happen again until we're back up to
max-hard.

So unless I'm really missing something, my proposal is:

1. Only provide one limit: max-size.
2. Allow customization of prune-factor.

That seems like all the customization you'd need. Cap the size, and
provide a reasonable control of how often the registry gets pruned.

That would require a change in the object signature, which would mean
some extra handling code for "upgrading". But once we're doing that, we
could also take the opportunity to add :prune-function and
:sort-function slots on the base registry object, which would be
nice. We could even change the default store filename from its "eioio"
extension to "eieio". :)

Eric