From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/85244 Path: news.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.general Subject: Re: [PATCH] Two issues with the gnus-registry Date: Sat, 08 Nov 2014 16:39:48 +0800 Message-ID: <87mw82jdbf.fsf@ericabrahamsen.net> References: <87egtx70hy.fsf@ericabrahamsen.net> <87wq7lsggo.fsf@lifelogs.com> <87zjchxr1v.fsf@ericabrahamsen.net> <87h9yogjer.fsf@ericabrahamsen.net> <87a942lg39.fsf@ericabrahamsen.net> <8761eqlfvk.fsf@ericabrahamsen.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1415435781 21957 80.91.229.3 (8 Nov 2014 08:36:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Nov 2014 08:36:21 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M33488@lists.math.uh.edu Sat Nov 08 09:36:11 2014 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xn1VC-0003NG-DQ for ding-account@gmane.org; Sat, 08 Nov 2014 09:36:10 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1Xn1U8-0005Z4-KV; Sat, 08 Nov 2014 02:35:04 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Xn1U4-0005Ym-70 for ding@lists.math.uh.edu; Sat, 08 Nov 2014 02:35:00 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Xn1U2-0008Iw-Ex for ding@lists.math.uh.edu; Sat, 08 Nov 2014 02:34:59 -0600 Original-Received: from plane.gmane.org ([80.91.229.3]) by quimby.gnus.org with esmtp (Exim 4.80) (envelope-from ) id 1Xn1U0-0005Og-G3 for ding@gnus.org; Sat, 08 Nov 2014 09:34:56 +0100 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xn1Ty-0002K8-9e for ding@gnus.org; Sat, 08 Nov 2014 09:34:54 +0100 Original-Received: from 103.244.102.210 ([103.244.102.210]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 08 Nov 2014 09:34:54 +0100 Original-Received: from eric by 103.244.102.210 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 08 Nov 2014 09:34:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 72 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 103.244.102.210 User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (gnu/linux) Cancel-Lock: sha1:DRtXUm5P10fYkxOWyiKnq4mwAa8= X-Spam-Score: -0.8 (/) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:85244 Archived-At: Eric Abrahamsen writes: > Eric Abrahamsen writes: > >> Eric Abrahamsen writes: >> >>> Eric Abrahamsen writes: >>> >>>> Ted Zlatanov 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