From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/85283 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: Sun, 16 Nov 2014 11:24:19 +0800 Message-ID: <87zjbr3k0s.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> <87mw82jdbf.fsf@ericabrahamsen.net> <87bnoff9fq.fsf@lifelogs.com> <8761ej8fvx.fsf@ericabrahamsen.net> <87bno8ymyv.fsf@uwo.ca> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1416108019 4813 80.91.229.3 (16 Nov 2014 03:20:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Nov 2014 03:20:19 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M33527@lists.math.uh.edu Sun Nov 16 04:20:10 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 1XpqNl-0006vM-33 for ding-account@gmane.org; Sun, 16 Nov 2014 04:20:09 +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 1XpqNC-00049F-Pt; Sat, 15 Nov 2014 21:19:34 -0600 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1XpqN9-00048w-Qa for ding@lists.math.uh.edu; Sat, 15 Nov 2014 21:19:31 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1XpqN7-0005YK-63 for ding@lists.math.uh.edu; Sat, 15 Nov 2014 21:19:31 -0600 Original-Received: from plane.gmane.org ([80.91.229.3]) by quimby.gnus.org with esmtp (Exim 4.80) (envelope-from ) id 1XpqN5-0002Zm-4A for ding@gnus.org; Sun, 16 Nov 2014 04:19:27 +0100 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XpqN5-0006jJ-0y for ding@gnus.org; Sun, 16 Nov 2014 04:19:27 +0100 Original-Received: from 221.218.160.248 ([221.218.160.248]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Nov 2014 04:19:27 +0100 Original-Received: from eric by 221.218.160.248 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Nov 2014 04:19:27 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 41 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 221.218.160.248 User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (gnu/linux) Cancel-Lock: sha1:eGl/5XdNlAvZTPuFZFVayBs7XEI= X-Spam-Score: 0.3 (/) X-Spam-Report: SpamAssassin (3.3.1 2010-03-16) analysis follows Bayesian score: 0.0000 Ham tokens: 0.000-2387--18927h-0s--0d--H*u:Emacs, 0.000-376--2980h-0s--0d--H*u:Gnus, 0.000-376--2980h-0s--0d--H*UA:Gnus, 0.000-360--2850h-0s--0d--H*u:linux, 0.000-360--2850h-0s--0d--H*UA:linux Spam tokens: 0.991-26765--1411h-107201s--0d--HTo:D*gnus.org, 0.991-27770--1464h-111227s--0d--HX-Spam-Relays-External:quimby.gnus.org, 0.991-27770--1464h-111227s--0d--H*RU:quimby.gnus.org, 0.989-27486--1749h-111232s--0d--HX-Spam-Relays-Internal:quimby.gnus.org, 0.989-27486--1749h-111232s--0d--H*RT:80.91.231.51 Autolearn status: no -1.0 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [80.91.229.3 listed in list.dnswl.org] -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.2 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 2.0 FSL_HELO_BARE_IP_2 FSL_HELO_BARE_IP_2 List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:85283 Archived-At: Dan Christensen writes: > Eric Abrahamsen writes: > >> 1. The big one changes the database structure, combining :max-hard and >> :max-soft into :max-size > > Does this mean that precious entries will *never* get pruned? > Will that be a problem? > > Also, if precious entries count towards the total, then once > you have as many precious entries as the total size, no other > entries will ever be kept... > > What are precious entries currently used for? Yup, the whole point of precious entries is that you don't want them to be pruned. This was how the registry was supposed to operate to begin with, it just wasn't working correctly. And yes, the registry refuses to add new entries over the total size, precious or not. When it hits the limit, it tries to prune. If all the entries in the registry are precious, it will lock up. I'd be mighty surprised if anyone ever gets to this situation. *No* entries are made precious in the default registry setup, so my changes here won't affect anyone who hasn't gone and used preciousness for their own purposes. I think that's why no one has run into this problem before. Users and package authors who make heavy use of this feature should probably have a secondary "pruning" routine on hand that removes the precious keys from entries that no longer need them. The registry could probably do a little more to signal that it was full of precious entries, so those routines could be run automatically. I'd be happy to discuss how all this should work, and make any changes that Ted is okay with. I think the registry is a great idea, and one that's currently underutilized. Eric