unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 36341@debbugs.gnu.org, Deus Max <deusmax@gmx.com>
Subject: bug#36341: 27.0.50; Reading from the Gnus dribble file leaves data inconsistent
Date: Sun, 07 Jul 2019 16:56:36 -0700	[thread overview]
Message-ID: <87sgrhz9e3.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <m3pnmngyes.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sat, 06 Jul 2019 14:06:35 +0200")

[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I don't know why that happens, given that the entry in the hashtable and
>> the alist are identical lisp objects, or at least they are everywhere
>> else. But at least the solution is in sight!
>
> Great.  :-)

I think it has to be done the ugly way -- setting the hashtable and
alist separately.

The problem (I write this more as part of digesting the issue than
anything else) is that the alist is full of elements that look like
'("group" 4 ((1 2 3) (4 5 6))), whereas the corresponding value in the
hashtable looks like '(25 ("group" 4 ((1 2 3) (4 5 6)))).

The alist element is `eq' to the `cadr' of the hashtable value: they're
the same list object.

If you reach inside that list and change values (ie set 4 to 7), they
remain the same list, and the change is reflected in both hashtable and
alist.

If you replace the entire ("group"...) list, in the hashtable, it is no
longer the same object as that in the alist, and you get divergence.
This seems sensible in hindsight, but took me quite a while to figure
out.

I think `gnus-group-set-info' is the only place that happens, so it
isn't too terrible to just explicitly set both hashtable and alist in
that function. I've attached the commit that does that.

My plan for avoiding this class of errors in the future is to change the
representation of Gnus groups from lists to EIEIO objects. Then
`gnus-newsrc-alist' would merely be a disk serialization format, and the
hashtable would be the source of authority. That would also make the
"dummy.group" unnecessary. But let's see if I get there, and if the
changes are accepted...

Eric


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Make-sure-gnus-group-set-info-sets-both-the-hashtabl.patch --]
[-- Type: text/x-patch, Size: 1377 bytes --]

From c0b8589b1686d8488b4765783536217b7bb77b6c Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <eric@ericabrahamsen.net>
Date: Sun, 7 Jul 2019 16:25:14 -0700
Subject: [PATCH] Make sure gnus-group-set-info sets both the hashtable and
 alist

* lisp/gnus/gnus-group.el (gnus-group-set-info): Apparently this
  method of updating the group info will only apply to the
  gnus-newsrc-hashtb, not gnus-newsrc-alist. Do the alist explicitly.
---
 lisp/gnus/gnus-group.el | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/lisp/gnus/gnus-group.el b/lisp/gnus/gnus-group.el
index ea695aaa97..2668e4fb7c 100644
--- a/lisp/gnus/gnus-group.el
+++ b/lisp/gnus/gnus-group.el
@@ -4506,7 +4506,14 @@ gnus-group-set-info
 	    (when (and (not (eq (car entry) t))
 		       (gnus-active (gnus-info-group info)))
 	      (setcar entry (length
-			     (gnus-list-of-unread-articles (car info))))))
+			     (gnus-list-of-unread-articles (car info)))))
+	    ;; The above `setcar' will only affect the hashtable, not
+	    ;; the alist: update the alist separately.
+	    (push info (cdr (setq gnus-newsrc-alist
+				   (remove (assoc-string
+					    (gnus-info-group info)
+					    gnus-newsrc-alist)
+					   gnus-newsrc-alist)))))
 	(error "No such group: %s" (gnus-info-group info))))))
 
 ;; Ad-hoc function for inserting data from a different newsrc.eld
-- 
2.22.0


  reply	other threads:[~2019-07-07 23:56 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-23 14:30 bug#36341: 27.0.50; Reading from the Gnus dribble file leaves data inconsistent Lars Ingebrigtsen
2019-06-23 15:34 ` Eric Abrahamsen
2019-06-23 15:41   ` Lars Ingebrigtsen
2019-06-23 16:35     ` Eric Abrahamsen
2019-06-23 18:25     ` Deus Max
2019-06-23 18:38       ` Eric Abrahamsen
2019-06-23 18:40         ` Lars Ingebrigtsen
2019-06-28 22:30           ` Eric Abrahamsen
2019-06-29 10:22             ` Lars Ingebrigtsen
2019-07-03 19:46               ` Eric Abrahamsen
2019-07-04 13:43                 ` Lars Ingebrigtsen
2019-07-05 19:24                   ` Eric Abrahamsen
2019-07-06 12:06                     ` Lars Ingebrigtsen
2019-07-07 23:56                       ` Eric Abrahamsen [this message]
2019-07-08 16:22                         ` Lars Ingebrigtsen
2019-07-08 17:29                           ` Eric Abrahamsen
2019-07-08 17:37                             ` Lars Ingebrigtsen
2019-07-09  4:53                               ` Eric Abrahamsen
2019-07-09 17:50                                 ` Eric Abrahamsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sgrhz9e3.fsf@ericabrahamsen.net \
    --to=eric@ericabrahamsen.net \
    --cc=36341@debbugs.gnu.org \
    --cc=deusmax@gmx.com \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).