* bug#36903: 27.0.50; gnus registry vs. debbugs
@ 2019-08-03 7:11 Michael Heerdegen
2019-08-03 15:38 ` Eric Abrahamsen
0 siblings, 1 reply; 40+ messages in thread
From: Michael Heerdegen @ 2019-08-03 7:11 UTC (permalink / raw)
To: 36903
Hi,
opening articles in the groups generated by debbugs-gnu-search or
debbugs-gnu-bugs fails for me, because I have set up Gnus to use the
registry:
Debugger entered--Lisp error: (cl-no-applicable-method registry-lookup nil ("fake+none+nndoc+ephemeral:bug#19892+1"))
signal(cl-no-applicable-method (registry-lookup nil ("fake+none+nndoc+ephemeral:bug#19892+1")))
cl-no-applicable-method(#s(cl--generic :name registry-lookup :dispatches ((1 #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x1ffea8c93a83>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1ffea8c93a6b>))) (0 #s(cl--generic-generalizer :name eieio--generic-generalizer :priority 50 :tagcode-function cl--generic-struct-tag :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x15640b15a86d>)) #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x1ffea8c93a83>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1ffea8c93a6b>)))) :method-table (#s(cl--generic-method :specializers (registry-db t) :qualifiers nil :uses-cnm nil :function #f(compiled-function (db keys) #<bytecode 0x15640bae7b19>))) :options nil) nil ("fake+none+nndoc+ephemeral:bug#19892+1"))
apply(cl-no-applicable-method #s(cl--generic :name registry-lookup :dispatches ((1 #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x1ffea8c93a83>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1ffea8c93a6b>))) (0 #s(cl--generic-generalizer :name eieio--generic-generalizer :priority 50 :tagcode-function cl--generic-struct-tag :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x15640b15a86d>)) #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x1ffea8c93a83>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1ffea8c93a6b>)))) :method-table (#s(cl--generic-method :specializers (registry-db t) :qualifiers nil :uses-cnm nil :function #f(compiled-function (db keys) #<bytecode 0x15640bae7b19>))) :options nil) (nil ("fake+none+nndoc+ephemeral:bug#19892+1")))
#f(compiled-function (&rest args) #<bytecode 0x15640d67eedd>)(nil ("fake+none+nndoc+ephemeral:bug#19892+1"))
apply(#f(compiled-function (&rest args) #<bytecode 0x15640d67eedd>) nil ("fake+none+nndoc+ephemeral:bug#19892+1"))
registry-lookup(nil ("fake+none+nndoc+ephemeral:bug#19892+1"))
gnus-registry-get-or-make-entry("fake+none+nndoc+ephemeral:bug#19892+1")
gnus-registry-get-id-key("fake+none+nndoc+ephemeral:bug#19892+1" group)
gnus-registry-register-message-ids()
run-hooks(gnus-summary-prepare-hook)
apply(run-hooks gnus-summary-prepare-hook)
gnus-run-hooks(gnus-summary-prepare-hook)
gnus-summary-prepare()
gnus-summary-read-group-1("nndoc+ephemeral:bug#19892" t t nil nil nil)
gnus-summary-read-group("nndoc+ephemeral:bug#19892" t t nil nil nil nil)
gnus-group-read-group(t t "nndoc+ephemeral:bug#19892" nil)
gnus-group-read-ephemeral-group("nndoc+ephemeral:bug#19892" (nndoc "/tmp/gnus-temp-group-RfE2Ck" (nndoc-article-type mbox)) nil (#<buffer *Bugs*> . #<window-configuration>))
gnus-read-ephemeral-bug-group((19892) "https://debbugs.gnu.org/cgi/bugreport.cgi?bug=%s;m..." (#<buffer *Bugs*> . #<window-configuration>))
gnus-read-ephemeral-emacs-bug-group((19892) (#<buffer *Bugs*> . #<window-configuration>))
debbugs-read-emacs-bug-with-gnus(19892 ((cache_time . 1564812360.0822985) (unarchived) (blockedby) (forwarded) (package "emacs") (location . "db-h") (originator . "michael_heerdegen@web.de") (subject . "25.0.50; hideshow: hs-hide-all-non-comment-functio...") (severity . "normal") (fixed (item (key . 27.1) (value))) (found_versions "25.0.50") (msgid . "<87r3tonon8.fsf@web.de>") (mergedwith) (fixed_versions "27.1") (last_modified . 1564773722) (owner) (found (item (key . "25.0.50") (value))) (fixed_date) (id . 19892) (summary) (affects) (keywords "fixed") (source . "unknown") (pending . "done") (found_date) (archived) (done . "Lars Ingebrigtsen <larsi@gnus.org>") (tags "fixed") (date . 1424213161) (bug_num . 19892) (blocks) (log_modified . 1564773722)) nil)
debbugs-gnu-select-report()
AFAIU the problem is that gnus-registry-db is bound to nil *Bugs* and
that is not expected by the registry (hook) functions.
Similarly, if I do what is suggested in the header of gnus-registry.el:
;; show the marks as single characters (see the :char property in
;; `gnus-registry-marks'):
;; (defalias 'gnus-user-format-function-M 'gnus-registry-article-marks-to-chars)
I even get an error before the above one:
Debugger entered--Lisp error: (cl-no-applicable-method registry-lookup nil ("<87r3tonon8.fsf@web.de>"))
signal(cl-no-applicable-method (registry-lookup nil ("<87r3tonon8.fsf@web.de>")))
cl-no-applicable-method(#s(cl--generic :name registry-lookup :dispatches ((1 #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x1ffea8c93a83>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1ffea8c93a6b>))) (0 #s(cl--generic-generalizer :name eieio--generic-generalizer :priority 50 :tagcode-function cl--generic-struct-tag :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x15640b15a86d>)) #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x1ffea8c93a83>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1ffea8c93a6b>)))) :method-table (#s(cl--generic-method :specializers (registry-db t) :qualifiers nil :uses-cnm nil :function #f(compiled-function (db keys) #<bytecode 0x15640bae7b19>))) :options nil) nil ("<87r3tonon8.fsf@web.de>"))
apply(cl-no-applicable-method #s(cl--generic :name registry-lookup :dispatches ((1 #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x1ffea8c93a83>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1ffea8c93a6b>))) (0 #s(cl--generic-generalizer :name eieio--generic-generalizer :priority 50 :tagcode-function cl--generic-struct-tag :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x15640b15a86d>)) #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x1ffea8c93a83>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1ffea8c93a6b>)))) :method-table (#s(cl--generic-method :specializers (registry-db t) :qualifiers nil :uses-cnm nil :function #f(compiled-function (db keys) #<bytecode 0x15640bae7b19>))) :options nil) (nil ("<87r3tonon8.fsf@web.de>")))
#f(compiled-function (&rest args) #<bytecode 0x15640d67eedd>)(nil ("<87r3tonon8.fsf@web.de>"))
apply(#f(compiled-function (&rest args) #<bytecode 0x15640d67eedd>) nil ("<87r3tonon8.fsf@web.de>"))
registry-lookup(nil ("<87r3tonon8.fsf@web.de>"))
gnus-registry-get-or-make-entry("<87r3tonon8.fsf@web.de>")
gnus-registry-get-id-key("<87r3tonon8.fsf@web.de>" mark)
gnus-user-format-function-M([2 "bug#19892: 25.0.50; hideshow: hs-hide-all-non-comm..." "Michael Heerdegen <michael_heerdegen@web.de>" #("Tue, 17 Feb 2015 23:45:15 +0100" 0 1 (gnus-time (21731 50299))) "<87r3tonon8.fsf@web.de>" nil -1 117 nil ((Cc . "ttn@gnu.org, dann@ics.uci.edu") (To . "19892@debbugs.gnu.org"))])
(format "%c%c%s%s%2s%c%9s %s" gnus-tmp-unread gnus-tmp-replied (gnus-user-format-function-S gnus-tmp-header) (gnus-user-format-function-g gnus-tmp-header) (gnus-user-format-function-M gnus-tmp-header) gnus-tmp-score-char (gnus-user-date (mail-header-date gnus-tmp-header)) gnus-tmp-indentation)
(insert (format "%c%c%s%s%2s%c%9s %s" gnus-tmp-unread gnus-tmp-replied (gnus-user-format-function-S gnus-tmp-header) (gnus-user-format-function-g gnus-tmp-header) (gnus-user-format-function-M gnus-tmp-header) gnus-tmp-score-char (gnus-user-date (mail-header-date gnus-tmp-header)) gnus-tmp-indentation))
(progn (insert (format "%c%c%s%s%2s%c%9s %s" gnus-tmp-unread gnus-tmp-replied (gnus-user-format-function-S gnus-tmp-header) (gnus-user-format-function-g gnus-tmp-header) (gnus-user-format-function-M gnus-tmp-header) gnus-tmp-score-char (gnus-user-date (mail-header-date gnus-tmp-header)) gnus-tmp-indentation)) (put-text-property (point) (progn (insert (format "%-23s" (let* ((val ...) (need ...)) (if (> need 0) (concat nil val ...) val)))) (point)) 'mouse-face gnus-mouse-face) (insert " ") (add-text-properties (point) (progn (insert gnus-tmp-subject-or-nil) (point)) (cons 'face (cons (list 'font-lock-variable-name-face 'default) '(gnus-face t)))) (insert "\n"))
eval((progn (insert (format "%c%c%s%s%2s%c%9s %s" gnus-tmp-unread gnus-tmp-replied (gnus-user-format-function-S gnus-tmp-header) (gnus-user-format-function-g gnus-tmp-header) (gnus-user-format-function-M gnus-tmp-header) gnus-tmp-score-char (gnus-user-date (mail-header-date gnus-tmp-header)) gnus-tmp-indentation)) (put-text-property (point) (progn (insert (format "%-23s" (let* (... ...) (if ... ... val)))) (point)) 'mouse-face gnus-mouse-face) (insert " ") (add-text-properties (point) (progn (insert gnus-tmp-subject-or-nil) (point)) (cons 'face (cons (list 'font-lock-variable-name-face 'default) '(gnus-face t)))) (insert "\n")))
gnus-summary-prepare-threads((([2 "bug#19892: 25.0.50; hideshow: hs-hide-all-non-comm..." "Michael Heerdegen <michael_heerdegen@web.de>" #("Tue, 17 Feb 2015 23:45:15 +0100" 0 1 (gnus-time (21731 50299))) "<87r3tonon8.fsf@web.de>" nil -1 117 nil ((Cc . "ttn@gnu.org, dann@ics.uci.edu") (To . "19892@debbugs.gnu.org"))] ([3 "bug#19892: 25.0.50; hideshow: hs-hide-all-non-comm..." "Lars Ingebrigtsen <larsi@gnus.org>" #("Fri, 02 Aug 2019 21:08:54 +0200" 0 1 (gnus-time (23876 35398))) "<87ef23o055.fsf@mouse.gnus.org>" "<87r3tonon8.fsf@web.de>" -1 60 nil ((Cc . "ttn@gnu.org, dann@ics.uci.edu, 19892@debbugs.gnu.o...") (To . "Michael Heerdegen <michael_heerdegen@web.de>"))]) ([4 "bug#19892: 25.0.50; hideshow: hs-hide-all-non-comm..." "Lars Ingebrigtsen <larsi@gnus.org>" #("Fri, 02 Aug 2019 21:17:00 +0200" 0 1 (gnus-time (23876 35884))) "<87a7crnzrn.fsf@mouse.gnus.org>" "<87r3tonon8.fsf@web.de>" -1 61 nil ((Cc . "ttn@gnu.org, dann@ics.uci.edu, 19892@debbugs.gnu.o...") (To . "Michael Heerdegen <michael_heerdegen@web.de>"))])) ([5 "control message for bug #19892" "Lars Ingebrigtsen <larsi@gnus.org>" #("Fri, 02 Aug 2019 21:21:36 +0200" 0 1 (gnus-time (23876 36160))) "<878ssbnzjz.fsf@mouse.gnus.org>" nil -1 8 nil ((To . "control@debbugs.gnu.org, 19892@debbugs.gnu.org"))]) ([1 "Status: 25.0.50; hideshow: hs-hide-all-non-comment..." "bug#19892 <19892@debbugs.gnu.org>" #("Sat, 03 Aug 2019 07:07:20 +0000" 0 1 (gnus-time (23877 12968))) "fake+none+nndoc+ephemeral:bug#19892+1" nil -1 10 nil ((To . "bug#19892 <19892@debbugs.gnu.org>"))])))
gnus-summary-prepare()
gnus-summary-read-group-1("nndoc+ephemeral:bug#19892" t t nil nil nil)
gnus-summary-read-group("nndoc+ephemeral:bug#19892" t t nil nil nil nil)
gnus-group-read-group(t t "nndoc+ephemeral:bug#19892" nil)
gnus-group-read-ephemeral-group("nndoc+ephemeral:bug#19892" (nndoc "/tmp/gnus-temp-group-sYDhIR" (nndoc-article-type mbox)) nil (#<buffer *Bugs*> . #<window-configuration>))
gnus-read-ephemeral-bug-group((19892) "https://debbugs.gnu.org/cgi/bugreport.cgi?bug=%s;m..." (#<buffer *Bugs*> . #<window-configuration>))
gnus-read-ephemeral-emacs-bug-group((19892) (#<buffer *Bugs*> . #<window-configuration>))
debbugs-read-emacs-bug-with-gnus(19892 ((cache_time . 1564812360.0822985) (unarchived) (blockedby) (forwarded) (package "emacs") (location . "db-h") (originator . "michael_heerdegen@web.de") (subject . "25.0.50; hideshow: hs-hide-all-non-comment-functio...") (severity . "normal") (fixed (item (key . 27.1) (value))) (found_versions "25.0.50") (msgid . "<87r3tonon8.fsf@web.de>") (mergedwith) (fixed_versions "27.1") (last_modified . 1564773722) (owner) (found (item (key . "25.0.50") (value))) (fixed_date) (id . 19892) (summary) (affects) (keywords "fixed") (source . "unknown") (pending . "done") (found_date) (archived) (done . "Lars Ingebrigtsen <larsi@gnus.org>") (tags "fixed") (date . 1424213161) (bug_num . 19892) (blocks) (log_modified . 1564773722)) nil)
debbugs-gnu-select-report()
Hope it's not my fault, but it doesn't really look like that...
TIA,
Michael.
^ permalink raw reply [flat|nested] 40+ messages in thread* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-08-03 7:11 bug#36903: 27.0.50; gnus registry vs. debbugs Michael Heerdegen
@ 2019-08-03 15:38 ` Eric Abrahamsen
2019-08-03 23:47 ` Michael Heerdegen
0 siblings, 1 reply; 40+ messages in thread
From: Eric Abrahamsen @ 2019-08-03 15:38 UTC (permalink / raw)
To: 36903
Michael Heerdegen <michael_heerdegen@web.de> writes:
> Hi,
>
> opening articles in the groups generated by debbugs-gnu-search or
> debbugs-gnu-bugs fails for me, because I have set up Gnus to use the
> registry:
>
> Debugger entered--Lisp error: (cl-no-applicable-method registry-lookup
> nil ("fake+none+nndoc+ephemeral:bug#19892+1"))
> signal(cl-no-applicable-method (registry-lookup nil ("fake+none+nndoc+ephemeral:bug#19892+1")))
> cl-no-applicable-method(#s(cl--generic :name registry-lookup
> :dispatches ((1 #s(cl--generic-generalizer :name
> cl--generic-t-generalizer :priority 0 :tagcode-function
> #f(compiled-function (name &rest _) #<bytecode 0x1ffea8c93a83>)
> :specializers-function #f(compiled-function (tag &rest _) #<bytecode
> 0x1ffea8c93a6b>))) (0 #s(cl--generic-generalizer :name
> eieio--generic-generalizer :priority 50 :tagcode-function
> cl--generic-struct-tag :specializers-function #f(compiled-function
> (tag &rest _) #<bytecode 0x15640b15a86d>)) #s(cl--generic-generalizer
> :name cl--generic-t-generalizer :priority 0 :tagcode-function
> #f(compiled-function (name &rest _) #<bytecode 0x1ffea8c93a83>)
> :specializers-function #f(compiled-function (tag &rest _) #<bytecode
> 0x1ffea8c93a6b>)))) :method-table (#s(cl--generic-method :specializers
> (registry-db t) :qualifiers nil :uses-cnm nil :function
> #f(compiled-function (db keys) #<bytecode 0x15640bae7b19>))) :options
> nil) nil ("fake+none+nndoc+ephemeral:bug#19892+1"))
> apply(cl-no-applicable-method #s(cl--generic :name registry-lookup
> :dispatches ((1 #s(cl--generic-generalizer :name
> cl--generic-t-generalizer :priority 0 :tagcode-function
> #f(compiled-function (name &rest _) #<bytecode 0x1ffea8c93a83>)
> :specializers-function #f(compiled-function (tag &rest _) #<bytecode
> 0x1ffea8c93a6b>))) (0 #s(cl--generic-generalizer :name
> eieio--generic-generalizer :priority 50 :tagcode-function
> cl--generic-struct-tag :specializers-function #f(compiled-function
> (tag &rest _) #<bytecode 0x15640b15a86d>)) #s(cl--generic-generalizer
> :name cl--generic-t-generalizer :priority 0 :tagcode-function
> #f(compiled-function (name &rest _) #<bytecode 0x1ffea8c93a83>)
> :specializers-function #f(compiled-function (tag &rest _) #<bytecode
> 0x1ffea8c93a6b>)))) :method-table (#s(cl--generic-method :specializers
> (registry-db t) :qualifiers nil :uses-cnm nil :function
> #f(compiled-function (db keys) #<bytecode 0x15640bae7b19>))) :options
> nil) (nil ("fake+none+nndoc+ephemeral:bug#19892+1")))
> #f(compiled-function (&rest args) #<bytecode 0x15640d67eedd>)(nil
> ("fake+none+nndoc+ephemeral:bug#19892+1"))
> apply(#f(compiled-function (&rest args) #<bytecode 0x15640d67eedd>)
> nil ("fake+none+nndoc+ephemeral:bug#19892+1"))
> registry-lookup(nil ("fake+none+nndoc+ephemeral:bug#19892+1"))
> gnus-registry-get-or-make-entry("fake+none+nndoc+ephemeral:bug#19892+1")
> gnus-registry-get-id-key("fake+none+nndoc+ephemeral:bug#19892+1" group)
> gnus-registry-register-message-ids()
> run-hooks(gnus-summary-prepare-hook)
> apply(run-hooks gnus-summary-prepare-hook)
> gnus-run-hooks(gnus-summary-prepare-hook)
> gnus-summary-prepare()
> gnus-summary-read-group-1("nndoc+ephemeral:bug#19892" t t nil nil nil)
> gnus-summary-read-group("nndoc+ephemeral:bug#19892" t t nil nil nil nil)
> gnus-group-read-group(t t "nndoc+ephemeral:bug#19892" nil)
> gnus-group-read-ephemeral-group("nndoc+ephemeral:bug#19892" (nndoc
> "/tmp/gnus-temp-group-RfE2Ck" (nndoc-article-type mbox)) nil (#<buffer
> *Bugs*> . #<window-configuration>))
> gnus-read-ephemeral-bug-group((19892)
> "https://debbugs.gnu.org/cgi/bugreport.cgi?bug=%s;m..." (#<buffer
> *Bugs*> . #<window-configuration>))
> gnus-read-ephemeral-emacs-bug-group((19892) (#<buffer *Bugs*> . #<window-configuration>))
> debbugs-read-emacs-bug-with-gnus(19892 ((cache_time .
> 1564812360.0822985) (unarchived) (blockedby) (forwarded) (package
> "emacs") (location . "db-h") (originator . "michael_heerdegen@web.de")
> (subject . "25.0.50; hideshow: hs-hide-all-non-comment-functio...")
> (severity . "normal") (fixed (item (key . 27.1) (value)))
> (found_versions "25.0.50") (msgid . "<87r3tonon8.fsf@web.de>")
> (mergedwith) (fixed_versions "27.1") (last_modified . 1564773722)
> (owner) (found (item (key . "25.0.50") (value))) (fixed_date) (id .
> 19892) (summary) (affects) (keywords "fixed") (source . "unknown")
> (pending . "done") (found_date) (archived) (done . "Lars Ingebrigtsen
> <larsi@gnus.org>") (tags "fixed") (date . 1424213161) (bug_num .
> 19892) (blocks) (log_modified . 1564773722)) nil)
> debbugs-gnu-select-report()
>
> AFAIU the problem is that gnus-registry-db is bound to nil *Bugs*
Do you know why/where this is happening?
^ permalink raw reply [flat|nested] 40+ messages in thread* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-08-03 15:38 ` Eric Abrahamsen
@ 2019-08-03 23:47 ` Michael Heerdegen
2019-08-04 0:16 ` Eric Abrahamsen
0 siblings, 1 reply; 40+ messages in thread
From: Michael Heerdegen @ 2019-08-03 23:47 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 36903
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> > AFAIU the problem is that gnus-registry-db is bound to nil *Bugs*
>
> Do you know why/where this is happening?
The nil binding? That can only be `gnus-registry-clear'.
And I guess that explains why I do not see the problem always: when Gnus
is running, it works, and it also works before Gnus has started for the
first time.
Michael.
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-08-03 23:47 ` Michael Heerdegen
@ 2019-08-04 0:16 ` Eric Abrahamsen
2019-08-04 0:27 ` Eric Abrahamsen
2019-08-04 1:09 ` Michael Heerdegen
0 siblings, 2 replies; 40+ messages in thread
From: Eric Abrahamsen @ 2019-08-04 0:16 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 36903
On 08/04/19 01:47 AM, Michael Heerdegen wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> > AFAIU the problem is that gnus-registry-db is bound to nil *Bugs*
>>
>> Do you know why/where this is happening?
>
> The nil binding? That can only be `gnus-registry-clear'.
>
> And I guess that explains why I do not see the problem always: when Gnus
> is running, it works, and it also works before Gnus has started for the
> first time.
Okay, so `gnus-registry-clear' should probably also run
`gnus-registry-unload-hook'. You're not expecting the registry to be
doing it's thing when you've shut down Gnus, but are using debbugs,
right?
Would you try this definition:
(defun gnus-registry-clear ()
"Clear the registry."
(setq gnus-registry-db nil)
(gnus-registry-unload-hook))
Huh, right after the definition of `gnus-registry-unload-hook' is this
line:
(add-hook 'gnus-registry-unload-hook 'gnus-registry-unload-hook)
I wonder what that's supposed to mean. Perhaps it should have been a
gnus shutdown hook, in which case you wouldn't have seen this error...
Anyway, I still think a gnus shutdown is a better place to have this.
Eric
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-08-04 0:16 ` Eric Abrahamsen
@ 2019-08-04 0:27 ` Eric Abrahamsen
2019-08-04 0:44 ` Noam Postavsky
2019-08-04 1:09 ` Michael Heerdegen
1 sibling, 1 reply; 40+ messages in thread
From: Eric Abrahamsen @ 2019-08-04 0:27 UTC (permalink / raw)
To: 36903
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> On 08/04/19 01:47 AM, Michael Heerdegen wrote:
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> > AFAIU the problem is that gnus-registry-db is bound to nil *Bugs*
>>>
>>> Do you know why/where this is happening?
>>
>> The nil binding? That can only be `gnus-registry-clear'.
>>
>> And I guess that explains why I do not see the problem always: when Gnus
>> is running, it works, and it also works before Gnus has started for the
>> first time.
>
> Okay, so `gnus-registry-clear' should probably also run
> `gnus-registry-unload-hook'. You're not expecting the registry to be
> doing it's thing when you've shut down Gnus, but are using debbugs,
> right?
>
> Would you try this definition:
>
> (defun gnus-registry-clear ()
> "Clear the registry."
> (setq gnus-registry-db nil)
> (gnus-registry-unload-hook))
>
> Huh, right after the definition of `gnus-registry-unload-hook' is this
> line:
>
> (add-hook 'gnus-registry-unload-hook 'gnus-registry-unload-hook)
Added by RMS in 2004! Still don't see what it's supposed to do --
there's no such hook, and it's never called.
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-08-04 0:27 ` Eric Abrahamsen
@ 2019-08-04 0:44 ` Noam Postavsky
2019-08-04 1:41 ` Eric Abrahamsen
0 siblings, 1 reply; 40+ messages in thread
From: Noam Postavsky @ 2019-08-04 0:44 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 36903
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>> Huh, right after the definition of `gnus-registry-unload-hook' is this
>> line:
>>
>> (add-hook 'gnus-registry-unload-hook 'gnus-registry-unload-hook)
>
> Added by RMS in 2004! Still don't see what it's supposed to do --
> there's no such hook, and it's never called.
It could be called by unload-feature, though it would be better to
rename it gnus-registry-unload-function instead:
(defun unload-feature (feature &optional force)
[...]
(let* ([...]
(unload-hook (intern-soft (concat name "-unload-hook")))
(unload-func (intern-soft (concat name "-unload-function"))))
[...]
;; This is obsolete; FEATURE-unload-function should be used now.
(run-hooks unload-hook)
See also (info "(elisp) Unloading")
^ permalink raw reply [flat|nested] 40+ messages in thread* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-08-04 0:44 ` Noam Postavsky
@ 2019-08-04 1:41 ` Eric Abrahamsen
0 siblings, 0 replies; 40+ messages in thread
From: Eric Abrahamsen @ 2019-08-04 1:41 UTC (permalink / raw)
To: 36903
Noam Postavsky <npostavs@gmail.com> writes:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>>> Huh, right after the definition of `gnus-registry-unload-hook' is this
>>> line:
>>>
>>> (add-hook 'gnus-registry-unload-hook 'gnus-registry-unload-hook)
>>
>> Added by RMS in 2004! Still don't see what it's supposed to do --
>> there's no such hook, and it's never called.
>
> It could be called by unload-feature, though it would be better to
> rename it gnus-registry-unload-function instead:
>
> (defun unload-feature (feature &optional force)
> [...]
> (let* ([...]
> (unload-hook (intern-soft (concat name "-unload-hook")))
> (unload-func (intern-soft (concat name "-unload-function"))))
> [...]
> ;; This is obsolete; FEATURE-unload-function should be used now.
> (run-hooks unload-hook)
>
> See also (info "(elisp) Unloading")
Something new every day! Thanks for this tip.
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-08-04 0:16 ` Eric Abrahamsen
2019-08-04 0:27 ` Eric Abrahamsen
@ 2019-08-04 1:09 ` Michael Heerdegen
2019-08-04 2:10 ` Eric Abrahamsen
1 sibling, 1 reply; 40+ messages in thread
From: Michael Heerdegen @ 2019-08-04 1:09 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 36903
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> Okay, so `gnus-registry-clear' should probably also run
> `gnus-registry-unload-hook'. You're not expecting the registry to be
> doing it's thing when you've shut down Gnus, but are using debbugs,
> right?
Yes.
But I didn't say that I would not expect the registry to work with
debbugs. It would be good if it did - but I don't know if it's
technically possible.
> Would you try this definition:
>
> (defun gnus-registry-clear ()
> "Clear the registry."
> (setq gnus-registry-db nil)
> (gnus-registry-unload-hook))
Well, that fixes - only one error. I still get an error from
(defalias 'gnus-user-format-function-M
'gnus-registry-article-marks-to-chars)
so I have to redefine that one, too. And even after doing this I get an
error related to Gnorb:
Debugger entered--Lisp error: (cl-no-applicable-method registry-lookup nil ("<87ef23o055.fsf@mouse.gnus.org>"))
signal(cl-no-applicable-method (registry-lookup nil ("<87ef23o055.fsf@mouse.gnus.org>")))
cl-no-applicable-method(#s(cl--generic :name registry-lookup :dispatches ((1 #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x1fdfcf97ee83>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1fdfcf97ee6b>))) (0 #s(cl--generic-generalizer :name eieio--generic-generalizer :priority 50 :tagcode-function cl--generic-struct-tag :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1588e546ed61>)) #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x1fdfcf97ee83>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1fdfcf97ee6b>)))) :method-table (#s(cl--generic-meth
od :specializers (registry-db t) :qualifiers nil :uses-cnm nil :function #f(compiled-function (db keys) #<bytecode 0x1588e5da1709>))) :options nil) nil ("<87ef23o055.fsf@mouse.gnus.org>"))
apply(cl-no-applicable-method #s(cl--generic :name registry-lookup :dispatches ((1 #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x1fdfcf97ee83>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1fdfcf97ee6b>))) (0 #s(cl--generic-generalizer :name eieio--generic-generalizer :priority 50 :tagcode-function cl--generic-struct-tag :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1588e546ed61>)) #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x1fdfcf97ee83>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1fdfcf97ee6b>)))) :method-table (#s(cl--generi
c-method :specializers (registry-db t) :qualifiers nil :uses-cnm nil :function #f(compiled-function (db keys) #<bytecode 0x1588e5da1709>))) :options nil) (nil ("<87ef23o055.fsf@mouse.gnus.org>")))
#f(compiled-function (&rest args) #<bytecode 0x1588e6fb92f9>)(nil ("<87ef23o055.fsf@mouse.gnus.org>"))
apply(#f(compiled-function (&rest args) #<bytecode 0x1588e6fb92f9>) nil ("<87ef23o055.fsf@mouse.gnus.org>"))
registry-lookup(nil ("<87ef23o055.fsf@mouse.gnus.org>"))
gnus-registry-get-or-make-entry("<87ef23o055.fsf@mouse.gnus.org>")
gnus-registry-get-id-key("<87ef23o055.fsf@mouse.gnus.org>" gnorb-ids)
gnorb-gnus-hint-relevant-message()
run-hooks(gnus-select-article-hook)
apply(run-hooks gnus-select-article-hook)
gnus-run-hooks(gnus-select-article-hook)
gnus-summary-display-article(3 nil)
gnus-summary-select-article(nil nil pseudo)
gnus-summary-scroll-up(1)
funcall-interactively(gnus-summary-scroll-up 1)
call-interactively(gnus-summary-scroll-up nil nil)
command-execute(gnus-summary-scroll-up)
Michael.
^ permalink raw reply [flat|nested] 40+ messages in thread* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-08-04 1:09 ` Michael Heerdegen
@ 2019-08-04 2:10 ` Eric Abrahamsen
2019-08-04 2:35 ` Eric Abrahamsen
0 siblings, 1 reply; 40+ messages in thread
From: Eric Abrahamsen @ 2019-08-04 2:10 UTC (permalink / raw)
To: 36903
Michael Heerdegen <michael_heerdegen@web.de> writes:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Okay, so `gnus-registry-clear' should probably also run
>> `gnus-registry-unload-hook'. You're not expecting the registry to be
>> doing it's thing when you've shut down Gnus, but are using debbugs,
>> right?
>
> Yes.
>
> But I didn't say that I would not expect the registry to work with
> debbugs. It would be good if it did - but I don't know if it's
> technically possible.
Sounds like debbugs is either too Gnus, or not Gnus enough...
>> Would you try this definition:
>>
>> (defun gnus-registry-clear ()
>> "Clear the registry."
>> (setq gnus-registry-db nil)
>> (gnus-registry-unload-hook))
>
> Well, that fixes - only one error. I still get an error from
>
> (defalias 'gnus-user-format-function-M
> 'gnus-registry-article-marks-to-chars)
But this should have raised an error even if you hadn't started Gnus
prior to using debbugs, right?
> so I have to redefine that one, too. And even after doing this I get an
> error related to Gnorb:
I suppose the Gnorb stuff can check if the registry is initialized
before accessing it, but it all just seems a bit fragile. Debbugs has
its own summary minor mode, it seems like that could check
`gnus-alive-p' and maybe blank out some hooks if it isn't. If Gnus isn't
alive, the user's gnus.el file isn't in effect, so nearly all
customizations are inactive. Weirdly, `gnus-clear-system' makes a point
of *not* clearing `gnus-format-specs', which is what is giving you
trouble here.
Otherwise, I could try to solve the registry double-loading problem some
other way, and not clear the registry on Gnus shutdown. But it seems
like bad practice to have debbugs depend on Gnus not cleaning up after
itself.
Can't think of anything else at the moment...
Eric
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-08-04 2:10 ` Eric Abrahamsen
@ 2019-08-04 2:35 ` Eric Abrahamsen
2019-08-07 17:59 ` Lars Ingebrigtsen
0 siblings, 1 reply; 40+ messages in thread
From: Eric Abrahamsen @ 2019-08-04 2:35 UTC (permalink / raw)
To: 36903; +Cc: Lars Ingebrigtsen
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> Okay, so `gnus-registry-clear' should probably also run
>>> `gnus-registry-unload-hook'. You're not expecting the registry to be
>>> doing it's thing when you've shut down Gnus, but are using debbugs,
>>> right?
>>
>> Yes.
>>
>> But I didn't say that I would not expect the registry to work with
>> debbugs. It would be good if it did - but I don't know if it's
>> technically possible.
>
> Sounds like debbugs is either too Gnus, or not Gnus enough...
>
>>> Would you try this definition:
>>>
>>> (defun gnus-registry-clear ()
>>> "Clear the registry."
>>> (setq gnus-registry-db nil)
>>> (gnus-registry-unload-hook))
>>
>> Well, that fixes - only one error. I still get an error from
>>
>> (defalias 'gnus-user-format-function-M
>> 'gnus-registry-article-marks-to-chars)
>
> But this should have raised an error even if you hadn't started Gnus
> prior to using debbugs, right?
Oh I see, I set both pieces of the puzzle next to each other, but didn't
connect them. If you didn't start Gnus first, your format specs were
still the default and didn't contain any registry-specific stuff.
Lars, `gnus-clear-system' explicitly refrains from unsetting
`gnus-format-specs'. So if you start and stop Gnus, then start
debbugs-gnu, the user's customized format specs are still in place, and
may end up calling functions that depend on ~/.gnus.el setup stuff, and
raising errors.
Could `gnus-clear-system' also clear format specs? Obviously that
omission went in there for a reason, but I don't know what. Alternately,
could debbugs reset the specs when it starts?
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-08-04 2:35 ` Eric Abrahamsen
@ 2019-08-07 17:59 ` Lars Ingebrigtsen
2019-08-07 20:22 ` Eric Abrahamsen
0 siblings, 1 reply; 40+ messages in thread
From: Lars Ingebrigtsen @ 2019-08-07 17:59 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 36903
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> Lars, `gnus-clear-system' explicitly refrains from unsetting
> `gnus-format-specs'. So if you start and stop Gnus, then start
> debbugs-gnu, the user's customized format specs are still in place, and
> may end up calling functions that depend on ~/.gnus.el setup stuff, and
> raising errors.
>
> Could `gnus-clear-system' also clear format specs? Obviously that
> omission went in there for a reason, but I don't know what. Alternately,
> could debbugs reset the specs when it starts?
Hm. I have no idea why gnus-format-specs isn't cleared. The changelog
says, helpfully enough:
* gnus-start.el (gnus-read-newsrc-file): Don't clear
gnus-format-specs.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 40+ messages in thread* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-08-07 17:59 ` Lars Ingebrigtsen
@ 2019-08-07 20:22 ` Eric Abrahamsen
2019-08-11 23:34 ` Lars Ingebrigtsen
0 siblings, 1 reply; 40+ messages in thread
From: Eric Abrahamsen @ 2019-08-07 20:22 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 36903
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Lars, `gnus-clear-system' explicitly refrains from unsetting
>> `gnus-format-specs'. So if you start and stop Gnus, then start
>> debbugs-gnu, the user's customized format specs are still in place, and
>> may end up calling functions that depend on ~/.gnus.el setup stuff, and
>> raising errors.
>>
>> Could `gnus-clear-system' also clear format specs? Obviously that
>> omission went in there for a reason, but I don't know what. Alternately,
>> could debbugs reset the specs when it starts?
>
> Hm. I have no idea why gnus-format-specs isn't cleared. The changelog
> says, helpfully enough:
>
> * gnus-start.el (gnus-read-newsrc-file): Don't clear
> gnus-format-specs.
Yup, that's where my search ended as well :)
It seems like it has to be something to do with performance, so the
specs aren't re-evaluated? I really don't know. What do you think about
taking it out?
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-08-07 20:22 ` Eric Abrahamsen
@ 2019-08-11 23:34 ` Lars Ingebrigtsen
2019-08-12 15:24 ` Eric Abrahamsen
2019-08-12 15:36 ` Eric Abrahamsen
0 siblings, 2 replies; 40+ messages in thread
From: Lars Ingebrigtsen @ 2019-08-11 23:34 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 36903
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> It seems like it has to be something to do with performance, so the
> specs aren't re-evaluated? I really don't know. What do you think about
> taking it out?
I can't really imagine it being performance-related... computing the
specs take extremely little time.
But it's possible, I guess.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-08-11 23:34 ` Lars Ingebrigtsen
@ 2019-08-12 15:24 ` Eric Abrahamsen
2019-09-14 15:04 ` Lars Ingebrigtsen
2019-08-12 15:36 ` Eric Abrahamsen
1 sibling, 1 reply; 40+ messages in thread
From: Eric Abrahamsen @ 2019-08-12 15:24 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 36903
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> It seems like it has to be something to do with performance, so the
>> specs aren't re-evaluated? I really don't know. What do you think about
>> taking it out?
>
> I can't really imagine it being performance-related... computing the
> specs take extremely little time.
>
> But it's possible, I guess.
I'll patch locally and run it for a while.
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-08-12 15:24 ` Eric Abrahamsen
@ 2019-09-14 15:04 ` Lars Ingebrigtsen
2019-09-15 0:27 ` Eric Abrahamsen
0 siblings, 1 reply; 40+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-14 15:04 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 36903
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>> I can't really imagine it being performance-related... computing the
>> specs take extremely little time.
>>
>> But it's possible, I guess.
>
> I'll patch locally and run it for a while.
So I think we arrived at the conclusion that removing that removal
should be safe (i.e., a noop) -- did you apply the patch?
I'm not sure how this related to the other registry stuff... What was
the conclusion there?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-09-14 15:04 ` Lars Ingebrigtsen
@ 2019-09-15 0:27 ` Eric Abrahamsen
2019-09-15 12:20 ` Lars Ingebrigtsen
0 siblings, 1 reply; 40+ messages in thread
From: Eric Abrahamsen @ 2019-09-15 0:27 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 36903
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>>> I can't really imagine it being performance-related... computing the
>>> specs take extremely little time.
>>>
>>> But it's possible, I guess.
>>
>> I'll patch locally and run it for a while.
>
> So I think we arrived at the conclusion that removing that removal
> should be safe (i.e., a noop) -- did you apply the patch?
I didn't, because it doesn't solve anything, and it seemed like a proper
fix would probably include this.
> I'm not sure how this related to the other registry stuff... What was
> the conclusion there?
The conclusion is I don't know what to do. Users who have customized
`gnus-summary-line-format' to draw info from the registry will see an
error if they start Gnus, stop Gnus, then start debbugs-gnu. That's
because stopping Gnus clears the registry, but starting debbugs-gnu
doesn't re-load it (because it doesn't load the users gnus.el file), and
the summary line format continues trying to access the registry object.
I naively tried *adding* `gnus-format-specs' to the list of variables to
clear, but of course that doesn't work because
`gnus-summary-line-format' remains customized, and `gnus-format-specs'
is simply re-built from that customized value when `debbugs-gnu' is
started.
This didn't use to be a problem because stopping Gnus used to leave the
registry hanging around. I changed that in 2815174f as part of
preventing the registry from being loaded twice at startup, and I just
think it's good practice not to leave this (potentially huge) data
structure lingering after shutdown.
I can imagine a few possible solutions, but none of them are very
appealing. debbugs-gnu seems stuck somewhere between "too Gnus" and "not
Gnus enough".
Eric
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-09-15 0:27 ` Eric Abrahamsen
@ 2019-09-15 12:20 ` Lars Ingebrigtsen
2019-09-15 23:31 ` Eric Abrahamsen
0 siblings, 1 reply; 40+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-15 12:20 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 36903
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> The conclusion is I don't know what to do. Users who have customized
> `gnus-summary-line-format' to draw info from the registry will see an
> error if they start Gnus, stop Gnus, then start debbugs-gnu. That's
> because stopping Gnus clears the registry, but starting debbugs-gnu
> doesn't re-load it (because it doesn't load the users gnus.el file), and
> the summary line format continues trying to access the registry object.
Can't you just make the erroring-out functions return "" or something if
they're called before the registry is loaded? Or make them initialise
the registry if called when it's not loaded?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-09-15 12:20 ` Lars Ingebrigtsen
@ 2019-09-15 23:31 ` Eric Abrahamsen
2019-09-16 13:24 ` Lars Ingebrigtsen
0 siblings, 1 reply; 40+ messages in thread
From: Eric Abrahamsen @ 2019-09-15 23:31 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 36903
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> The conclusion is I don't know what to do. Users who have customized
>> `gnus-summary-line-format' to draw info from the registry will see an
>> error if they start Gnus, stop Gnus, then start debbugs-gnu. That's
>> because stopping Gnus clears the registry, but starting debbugs-gnu
>> doesn't re-load it (because it doesn't load the users gnus.el file), and
>> the summary line format continues trying to access the registry object.
>
> Can't you just make the erroring-out functions return "" or something if
> they're called before the registry is loaded? Or make them initialise
> the registry if called when it's not loaded?
I can do that for in-tree code, and my own packages, but who knows what
else is out there that might try something similar.
But it's probably a better solution than anything else I can think of.
I'd be inclined to just have them return an empty string. Another
possibility would be to have the formatting code wrap the user-function
funcall in `ignore-errors' and return an empty string there.
Eric
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-09-15 23:31 ` Eric Abrahamsen
@ 2019-09-16 13:24 ` Lars Ingebrigtsen
2019-09-16 22:37 ` Eric Abrahamsen
0 siblings, 1 reply; 40+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-16 13:24 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 36903
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> I can do that for in-tree code, and my own packages, but who knows what
> else is out there that might try something similar.
Well, we can't control out-of-tree code, but Gnus should (in general) be
able to generate a summary buffer without Gnus having been started -- I
mean, that's a design goal.
> But it's probably a better solution than anything else I can think of.
> I'd be inclined to just have them return an empty string. Another
> possibility would be to have the formatting code wrap the user-function
> funcall in `ignore-errors' and return an empty string there.
That doesn't sound very friendly when trying to debug errors...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-09-16 13:24 ` Lars Ingebrigtsen
@ 2019-09-16 22:37 ` Eric Abrahamsen
2019-09-19 17:39 ` Eric Abrahamsen
0 siblings, 1 reply; 40+ messages in thread
From: Eric Abrahamsen @ 2019-09-16 22:37 UTC (permalink / raw)
To: 36903
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I can do that for in-tree code, and my own packages, but who knows what
>> else is out there that might try something similar.
>
> Well, we can't control out-of-tree code, but Gnus should (in general) be
> able to generate a summary buffer without Gnus having been started -- I
> mean, that's a design goal.
Okay, I'll make that change in gnus-registry.el, and elsewhere. I'll
keep that design goal in mind, though I wouldn't be surprised if we run
into more weirdness in this situation where the user's gnus.el has been
loaded, but then Gnus itself shut down.
>> But it's probably a better solution than anything else I can think of.
>> I'd be inclined to just have them return an empty string. Another
>> possibility would be to have the formatting code wrap the user-function
>> funcall in `ignore-errors' and return an empty string there.
>
> That doesn't sound very friendly when trying to debug errors...
No, you're right, I was just throwing out ideas.
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-09-16 22:37 ` Eric Abrahamsen
@ 2019-09-19 17:39 ` Eric Abrahamsen
2019-09-21 8:40 ` Michael Albinus
0 siblings, 1 reply; 40+ messages in thread
From: Eric Abrahamsen @ 2019-09-19 17:39 UTC (permalink / raw)
To: 36903-done
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> I can do that for in-tree code, and my own packages, but who knows what
>>> else is out there that might try something similar.
>>
>> Well, we can't control out-of-tree code, but Gnus should (in general) be
>> able to generate a summary buffer without Gnus having been started -- I
>> mean, that's a design goal.
>
> Okay, I'll make that change in gnus-registry.el, and elsewhere. I'll
> keep that design goal in mind, though I wouldn't be surprised if we run
> into more weirdness in this situation where the user's gnus.el has been
> loaded, but then Gnus itself shut down.
Okay, that's done and pushed.
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-09-19 17:39 ` Eric Abrahamsen
@ 2019-09-21 8:40 ` Michael Albinus
2019-09-21 21:31 ` Eric Abrahamsen
0 siblings, 1 reply; 40+ messages in thread
From: Michael Albinus @ 2019-09-21 8:40 UTC (permalink / raw)
To: 36903; +Cc: eric, michael_heerdegen
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
Hi,
>> Okay, I'll make that change in gnus-registry.el, and elsewhere. I'll
>> keep that design goal in mind, though I wouldn't be surprised if we run
>> into more weirdness in this situation where the user's gnus.el has been
>> loaded, but then Gnus itself shut down.
>
> Okay, that's done and pushed.
FWIW, I still get an error running the scenario Michael H. has
given. Emacs compiled after a recent pull. The backtrace is
--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (wrong-type-argument consp nil)
gnus-group-set-info(((timestamp . 1569055022) (quit-config #<buffer *Bugs*> . #<window-configuration>)) "nndoc+ephemeral:bug#37474" params)
gnus-group-set-parameter("nndoc+ephemeral:bug#37474" timestamp 1569055022)
gnus-group-set-timestamp()
run-hooks(gnus-select-group-hook)
apply(run-hooks gnus-select-group-hook)
gnus-run-hooks(gnus-select-group-hook)
gnus-summary-read-group-1("nndoc+ephemeral:bug#37474" t t nil nil nil)
gnus-summary-read-group("nndoc+ephemeral:bug#37474" t t nil nil nil nil)
gnus-group-read-group(t t "nndoc+ephemeral:bug#37474" nil)
gnus-group-read-ephemeral-group("nndoc+ephemeral:bug#37474" (nndoc "/tmp/gnus-temp-group-jz0Jgo" (nndoc-article-type mbox)) nil (#<buffer *Bugs*> . #<window-configuration>))
gnus-read-ephemeral-bug-group((37474) "https://debbugs.gnu.org/cgi/bugreport.cgi?bug=%s;m..." (#<buffer *Bugs*> . #<window-configuration>))
gnus-read-ephemeral-emacs-bug-group((37474) (#<buffer *Bugs*> . #<window-configuration>))
debbugs-read-emacs-bug-with-gnus(37474 ((cache_time . 1569055009.0235832) (forwarded) (date . 1569052622) (msgid . "<87k1a2ozfn.fsf@gmail.com>") (pending . "pending") (keywords "patch") (blockedby) (source . "unknown") (tags "patch") (location . "db-h") (severity . "normal") (subject . "[PATCH] gnu: libomp: Fix test target.") (archived) (done) (found_versions) (affects) (mergedwith) (last_modified . 1569052622) (found) (package "guix-patches") (unarchived) (originator . "\"Boris A. Dekshteyn\" <boris.dekshteyn@gmail.com>") (fixed_date) (owner) (blocks) (fixed_versions) (log_modified . 1569052622) (bug_num . 37474) (id . 37474) (summary) (fixed) (found_date)) nil)
debbugs-gnu-select-report()
funcall-interactively(debbugs-gnu-select-report)
call-interactively(debbugs-gnu-select-report nil nil)
command-execute(debbugs-gnu-select-report)
--8<---------------cut here---------------end--------------->8---
Best regards, Michael.
^ permalink raw reply [flat|nested] 40+ messages in thread* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-09-21 8:40 ` Michael Albinus
@ 2019-09-21 21:31 ` Eric Abrahamsen
2019-09-22 1:04 ` Michael Heerdegen
0 siblings, 1 reply; 40+ messages in thread
From: Eric Abrahamsen @ 2019-09-21 21:31 UTC (permalink / raw)
To: Michael Albinus; +Cc: 36903, michael_heerdegen
Michael Albinus <michael.albinus@gmx.de> writes:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
> Hi,
>
>>> Okay, I'll make that change in gnus-registry.el, and elsewhere. I'll
>>> keep that design goal in mind, though I wouldn't be surprised if we run
>>> into more weirdness in this situation where the user's gnus.el has been
>>> loaded, but then Gnus itself shut down.
>>
>> Okay, that's done and pushed.
>
> FWIW, I still get an error running the scenario Michael H. has
> given. Emacs compiled after a recent pull. The backtrace is
Yeah, I was too hasty with this whole thing. The backtrace you posted
seems to be unrelated to the registry issue I was trying to fix (at
least, I can't immediately see how it could arise from that), but I'll
see if I can reproduce. Unfortunately different users are likely to run
into different problems, because their gnus.el files will contain
different customizations.
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-09-21 21:31 ` Eric Abrahamsen
@ 2019-09-22 1:04 ` Michael Heerdegen
2019-09-22 2:36 ` Eric Abrahamsen
2019-09-25 9:39 ` Michael Heerdegen
0 siblings, 2 replies; 40+ messages in thread
From: Michael Heerdegen @ 2019-09-22 1:04 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 36903, Michael Albinus
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> Yeah, I was too hasty with this whole thing. The backtrace you posted
> seems to be unrelated to the registry issue I was trying to fix (at
> least, I can't immediately see how it could arise from that),
FWIW, your fix works for me.
> but I'll see if I can reproduce.
I can't, but I can if I do
(with-eval-after-load 'gnus
(add-hook 'gnus-select-group-hook #'gnus-group-set-timestamp))
(the function doc suggests that you can do that, but it's not done by
default)
Thanks,
Michael.
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-09-22 1:04 ` Michael Heerdegen
@ 2019-09-22 2:36 ` Eric Abrahamsen
2019-09-22 8:02 ` Michael Albinus
2019-09-25 9:39 ` Michael Heerdegen
1 sibling, 1 reply; 40+ messages in thread
From: Eric Abrahamsen @ 2019-09-22 2:36 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 36903, Michael Albinus
Michael Heerdegen <michael_heerdegen@web.de> writes:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Yeah, I was too hasty with this whole thing. The backtrace you posted
>> seems to be unrelated to the registry issue I was trying to fix (at
>> least, I can't immediately see how it could arise from that),
>
> FWIW, your fix works for me.
>
>> but I'll see if I can reproduce.
>
> I can't, but I can if I do
>
> (with-eval-after-load 'gnus
> (add-hook 'gnus-select-group-hook #'gnus-group-set-timestamp))
Okay, this is a completely different bug, coincidentally also caused by
changes I put in! The end of `gnus-group-set-info' tries to manipulate
`gnus-newsrc-alist', which is nil in the case of debbugs-gnu.
This all resulted from me trying to turn groups into objects, instead of
lists. If they were objects, we could edit them without having to worry
about breaking references to them. I can wrap this chunk of code in a
test to see if `gnus-newsrc-alist' is a list, but... I just wish groups
could be objects.
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-09-22 2:36 ` Eric Abrahamsen
@ 2019-09-22 8:02 ` Michael Albinus
0 siblings, 0 replies; 40+ messages in thread
From: Michael Albinus @ 2019-09-22 8:02 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: Michael Heerdegen, 36903
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> Yeah, I was too hasty with this whole thing. The backtrace you posted
>>> seems to be unrelated to the registry issue I was trying to fix (at
>>> least, I can't immediately see how it could arise from that),
>>
>> FWIW, your fix works for me.
>>
>>> but I'll see if I can reproduce.
>>
>> I can't, but I can if I do
>>
>> (with-eval-after-load 'gnus
>> (add-hook 'gnus-select-group-hook #'gnus-group-set-timestamp))
Confirmed. I've bisected my ~/.gnus, and when I comment out the
following line, everything works as expected:
(add-hook 'gnus-select-group-hook 'gnus-group-set-timestamp)
> Okay, this is a completely different bug, coincidentally also caused by
> changes I put in! The end of `gnus-group-set-info' tries to manipulate
> `gnus-newsrc-alist', which is nil in the case of debbugs-gnu.
>
> This all resulted from me trying to turn groups into objects, instead of
> lists. If they were objects, we could edit them without having to worry
> about breaking references to them. I can wrap this chunk of code in a
> test to see if `gnus-newsrc-alist' is a list, but... I just wish groups
> could be objects.
Take your time, therte's no rush. I've learned how to mitigate the
problem in my setup.
Best regards, Michael.
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-09-22 1:04 ` Michael Heerdegen
2019-09-22 2:36 ` Eric Abrahamsen
@ 2019-09-25 9:39 ` Michael Heerdegen
2019-09-25 16:30 ` Eric Abrahamsen
1 sibling, 1 reply; 40+ messages in thread
From: Michael Heerdegen @ 2019-09-25 9:39 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 36903, Michael Albinus
Michael Heerdegen <michael_heerdegen@web.de> writes:
> FWIW, your fix works for me.
Though, today I got this:
Debugger entered--Lisp error: (cl-no-applicable-method registry-lookup nil ("fake+none+nndoc+ephemeral:bug#37321+1"))
signal(cl-no-applicable-method (registry-lookup nil ("fake+none+nndoc+ephemeral:bug#37321+1")))
cl-no-applicable-method(#s(cl--generic :name registry-lookup :dispatches ((1 #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x1fef6cfb0adb>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1fef6cfb0ac3>))) (0 #s(cl--generic-generalizer :name eieio--generic-generalizer :priority 50 :tagcode-function cl--generic-struct-tag :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1584e6ac4ded>)) #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x1fef6cfb0adb>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1fef6cfb0ac3>)))) :method-table (#s(cl--generic-method :specializers (registry-db t) :qualifiers nil :uses-cnm nil :function #f(compiled-function (db keys) #<bytecode 0x1584e75f4c5d>))) :options nil) nil ("fake+none+nndoc+ephemeral:bug#37321+1"))
apply(cl-no-applicable-method #s(cl--generic :name registry-lookup :dispatches ((1 #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x1fef6cfb0adb>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1fef6cfb0ac3>))) (0 #s(cl--generic-generalizer :name eieio--generic-generalizer :priority 50 :tagcode-function cl--generic-struct-tag :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1584e6ac4ded>)) #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x1fef6cfb0adb>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1fef6cfb0ac3>)))) :method-table (#s(cl--generic-method :specializers (registry-db t) :qualifiers nil :uses-cnm nil :function #f(compiled-function (db keys) #<bytecode 0x1584e75f4c5d>))) :options nil) (nil ("fake+none+nndoc+ephemeral:bug#37321+1")))
#f(compiled-function (&rest args) #<bytecode 0x1584e82451e1>)(nil ("fake+none+nndoc+ephemeral:bug#37321+1"))
apply(#f(compiled-function (&rest args) #<bytecode 0x1584e82451e1>) nil ("fake+none+nndoc+ephemeral:bug#37321+1"))
registry-lookup(nil ("fake+none+nndoc+ephemeral:bug#37321+1"))
gnus-registry-get-or-make-entry("fake+none+nndoc+ephemeral:bug#37321+1")
gnus-registry-get-id-key("fake+none+nndoc+ephemeral:bug#37321+1" group)
gnus-registry-register-message-ids()
run-hooks(gnus-summary-prepare-hook)
apply(run-hooks gnus-summary-prepare-hook)
gnus-run-hooks(gnus-summary-prepare-hook)
gnus-summary-prepare()
gnus-summary-read-group-1("nndoc+ephemeral:bug#37321" t t nil nil nil)
gnus-summary-read-group("nndoc+ephemeral:bug#37321" t t nil nil nil nil)
gnus-group-read-group(t t "nndoc+ephemeral:bug#37321" nil)
gnus-group-read-ephemeral-group("nndoc+ephemeral:bug#37321" (nndoc "/tmp/gnus-temp-group-s69vaM" (nndoc-article-type mbox)) nil (#<buffer *"gc-cons-percentage" Bugs*> . #<window-configuration>))
gnus-read-ephemeral-bug-group((37321) "https://debbugs.gnu.org/cgi/bugreport.cgi?bug=%s;m..." (#<buffer *"gc-cons-percentage" Bugs*> . #<window-configuration>))
gnus-read-ephemeral-emacs-bug-group((37321) (#<buffer *"gc-cons-percentage" Bugs*> . #<window-configuration>))
debbugs-read-emacs-bug-with-gnus(37321 ((cache_time . 1569404174.2957919) (last_modified . 1569046862) (fixed_date) (date . 1567777982) (source . "unknown") (found_versions "27.0.50") (log_modified . 1569046862) (archived) (affects) (bug_num . 37321) (fixed_versions) (pending . "done") (fixed) (msgid . "<87lfv1pm5x.fsf@web.de>") (blocks) (subject . "27.0.50; Excessive gc in a use case (el-search)") (location . "db-h") (done . "Paul Eggert <eggert@cs.ucla.edu>") (tags) (mergedwith) (found (item (key . "27.0.50") (value))) (package "emacs") (severity . "normal") (unarchived) (originator . "Michael Heerdegen <michael_heerdegen@web.de>") (blockedby) (found_date) (id . 37321) (summary) (owner) (keywords) (forwarded)) nil)
debbugs-gnu-select-report()
funcall-interactively(debbugs-gnu-select-report)
call-interactively(debbugs-gnu-select-report nil nil)
command-execute(debbugs-gnu-select-report)
Michael.
^ permalink raw reply [flat|nested] 40+ messages in thread* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-09-25 9:39 ` Michael Heerdegen
@ 2019-09-25 16:30 ` Eric Abrahamsen
2019-10-01 23:27 ` Eric Abrahamsen
0 siblings, 1 reply; 40+ messages in thread
From: Eric Abrahamsen @ 2019-09-25 16:30 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 36903, Michael Albinus
Michael Heerdegen <michael_heerdegen@web.de> writes:
> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
>> FWIW, your fix works for me.
>
> Though, today I got this:
Right -- the registry shutdown should also run
gnus-registry-unload-hook. Let me play with this and test a bit, and
push it if all seems well.
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-09-25 16:30 ` Eric Abrahamsen
@ 2019-10-01 23:27 ` Eric Abrahamsen
2019-10-02 12:36 ` Michael Albinus
0 siblings, 1 reply; 40+ messages in thread
From: Eric Abrahamsen @ 2019-10-01 23:27 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 36903, Michael Albinus
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
>> Michael Heerdegen <michael_heerdegen@web.de> writes:
>>
>>> FWIW, your fix works for me.
>>
>> Though, today I got this:
>
> Right -- the registry shutdown should also run
> gnus-registry-unload-hook. Let me play with this and test a bit, and
> push it if all seems well.
Just pushed a commit that does this. The nice thing is, the unload-hook
sets gnus-registry-enabled to nil, which is a better (less
implementation-specific) test for whether we can rely on the registry
being present or not.
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-10-01 23:27 ` Eric Abrahamsen
@ 2019-10-02 12:36 ` Michael Albinus
2019-10-03 23:22 ` Eric Abrahamsen
0 siblings, 1 reply; 40+ messages in thread
From: Michael Albinus @ 2019-10-02 12:36 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: Michael Heerdegen, 36903
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
Hi Eric,
> Just pushed a commit that does this. The nice thing is, the unload-hook
> sets gnus-registry-enabled to nil, which is a better (less
> implementation-specific) test for whether we can rely on the registry
> being present or not.
Thanks. FTR, your patch still doesn't fix my problem as reported
earlier.
Best regards, Michael.
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-10-02 12:36 ` Michael Albinus
@ 2019-10-03 23:22 ` Eric Abrahamsen
2019-10-04 8:24 ` Michael Albinus
0 siblings, 1 reply; 40+ messages in thread
From: Eric Abrahamsen @ 2019-10-03 23:22 UTC (permalink / raw)
To: Michael Albinus; +Cc: Michael Heerdegen, 36903
Michael Albinus <michael.albinus@gmx.de> writes:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
> Hi Eric,
>
>> Just pushed a commit that does this. The nice thing is, the unload-hook
>> sets gnus-registry-enabled to nil, which is a better (less
>> implementation-specific) test for whether we can rely on the registry
>> being present or not.
>
> Thanks. FTR, your patch still doesn't fix my problem as reported
> earlier.
>
> Best regards, Michael.
I've just pushed a patch that ought to fix that problem.
Thanks,
Eric
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-10-03 23:22 ` Eric Abrahamsen
@ 2019-10-04 8:24 ` Michael Albinus
2019-10-04 16:59 ` Eric Abrahamsen
0 siblings, 1 reply; 40+ messages in thread
From: Michael Albinus @ 2019-10-04 8:24 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: Michael Heerdegen, 36903
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
Hi Eric,
>>> Just pushed a commit that does this. The nice thing is, the unload-hook
>>> sets gnus-registry-enabled to nil, which is a better (less
>>> implementation-specific) test for whether we can rely on the registry
>>> being present or not.
>>
>> Thanks. FTR, your patch still doesn't fix my problem as reported
>> earlier.
>
> I've just pushed a patch that ought to fix that problem.
Sorry, it still doesn't work with a fresh pulled Emacs. According to git
log, your last commit is 93dd959711222cf594051fa397d6a6e324e136fc from
Oct 1. Did you forget to push?
> Thanks,
> Eric
Best regards, Michael.
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-10-04 8:24 ` Michael Albinus
@ 2019-10-04 16:59 ` Eric Abrahamsen
2019-10-05 7:53 ` Michael Albinus
0 siblings, 1 reply; 40+ messages in thread
From: Eric Abrahamsen @ 2019-10-04 16:59 UTC (permalink / raw)
To: Michael Albinus; +Cc: Michael Heerdegen, 36903
On 10/04/19 10:24 AM, Michael Albinus wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
> Hi Eric,
>
>>>> Just pushed a commit that does this. The nice thing is, the unload-hook
>>>> sets gnus-registry-enabled to nil, which is a better (less
>>>> implementation-specific) test for whether we can rely on the registry
>>>> being present or not.
>>>
>>> Thanks. FTR, your patch still doesn't fix my problem as reported
>>> earlier.
>>
>> I've just pushed a patch that ought to fix that problem.
>
> Sorry, it still doesn't work with a fresh pulled Emacs. According to git
> log, your last commit is 93dd959711222cf594051fa397d6a6e324e136fc from
> Oct 1. Did you forget to push?
Oh, ha -- Magit was much too polite about the fact that it had failed to
push to the repo! Should be up now.
Thanks,
Eric
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-10-04 16:59 ` Eric Abrahamsen
@ 2019-10-05 7:53 ` Michael Albinus
2019-10-05 11:59 ` Eric Abrahamsen
0 siblings, 1 reply; 40+ messages in thread
From: Michael Albinus @ 2019-10-05 7:53 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: Michael Heerdegen, 36903
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
Hi Eric,
> Oh, ha -- Magit was much too polite about the fact that it had failed to
> push to the repo! Should be up now.
Thanks, the bug is solved for me now.
> Thanks,
> Eric
Best regards, Michael.
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-10-05 7:53 ` Michael Albinus
@ 2019-10-05 11:59 ` Eric Abrahamsen
2019-10-08 8:52 ` bug#37590: " Michael Heerdegen
0 siblings, 1 reply; 40+ messages in thread
From: Eric Abrahamsen @ 2019-10-05 11:59 UTC (permalink / raw)
To: Michael Albinus; +Cc: Michael Heerdegen, 36903, 37590-done, 36903-done
On 10/05/19 09:53 AM, Michael Albinus wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
> Hi Eric,
>
>> Oh, ha -- Magit was much too polite about the fact that it had failed to
>> push to the repo! Should be up now.
>
> Thanks, the bug is solved for me now.
Great! I'm closing this and a related report.
Thanks,
Eric
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37590: bug#36903: 27.0.50; gnus registry vs. debbugs
2019-10-05 11:59 ` Eric Abrahamsen
@ 2019-10-08 8:52 ` Michael Heerdegen
2019-10-08 18:40 ` bug#36903: " Eric Abrahamsen
0 siblings, 1 reply; 40+ messages in thread
From: Michael Heerdegen @ 2019-10-08 8:52 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 36903, 36903-done, Michael Albinus, 37590-done
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> Great! I'm closing this and a related report.
Hmm - same recipe as always, today I'm getting this:
Debugger entered--Lisp error: (cl-no-applicable-method registry-lookup nil ("<CABczVwdfiSF3DpZ0QprBYH_o14PDpDT6nvip__g8K_F1Eyn+..."))
signal(cl-no-applicable-method (registry-lookup nil ("<CABczVwdfiSF3DpZ0QprBYH_o14PDpDT6nvip__g8K_F1Eyn+...")))
cl-no-applicable-method(#s(cl--generic :name registry-lookup :dispatches ((1 #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x1fe70a31de9d>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1fe70a31de8d>))) (0 #s(cl--generic-generalizer :name eieio--generic-generalizer :priority 50 :tagcode-function cl--generic-struct-tag :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1578a5722cb9>)) #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x1fe70a31de9d>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1fe70a31de8d>)))) :method-table (#s(cl--generic-method :specializers (registry-db t) :qualifiers nil :uses-cnm nil :function #f(compiled-function (db keys) #<bytecode 0x1578a7918569>))) :options nil) nil ("<CABczVwdfiSF3DpZ0QprBYH_o14PDpDT6nvip__g8K_F1Eyn+..."))
apply(cl-no-applicable-method #s(cl--generic :name registry-lookup :dispatches ((1 #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x1fe70a31de9d>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1fe70a31de8d>))) (0 #s(cl--generic-generalizer :name eieio--generic-generalizer :priority 50 :tagcode-function cl--generic-struct-tag :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1578a5722cb9>)) #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode 0x1fe70a31de9d>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode 0x1fe70a31de8d>)))) :method-table (#s(cl--generic-method :specializers (registry-db t) :qualifiers nil :uses-cnm nil :function #f(compiled-function (db keys) #<bytecode 0x1578a7918569>))) :options nil) (nil ("<CABczVwdfiSF3DpZ0QprBYH_o14PDpDT6nvip__g8K_F1Eyn+...")))
#f(compiled-function (&rest args) #<bytecode 0x1578a6935d31>)(nil ("<CABczVwdfiSF3DpZ0QprBYH_o14PDpDT6nvip__g8K_F1Eyn+..."))
apply(#f(compiled-function (&rest args) #<bytecode 0x1578a6935d31>) nil ("<CABczVwdfiSF3DpZ0QprBYH_o14PDpDT6nvip__g8K_F1Eyn+..."))
registry-lookup(nil ("<CABczVwdfiSF3DpZ0QprBYH_o14PDpDT6nvip__g8K_F1Eyn+..."))
gnus-registry-get-or-make-entry("<CABczVwdfiSF3DpZ0QprBYH_o14PDpDT6nvip__g8K_F1Eyn+...")
gnus-registry-get-id-key("<CABczVwdfiSF3DpZ0QprBYH_o14PDpDT6nvip__g8K_F1Eyn+..." gnorb-ids)
gnorb-gnus-hint-relevant-message()
run-hooks(gnus-select-article-hook)
apply(run-hooks gnus-select-article-hook)
gnus-run-hooks(gnus-select-article-hook)
gnus-summary-display-article(18 nil)
gnus-summary-select-article(nil nil pseudo)
gnus-summary-scroll-up(1)
funcall-interactively(gnus-summary-scroll-up 1)
call-interactively(gnus-summary-scroll-up nil nil)
command-execute(gnus-summary-scroll-up)
so the issue reappeared (because of Gnorb?).
Regards,
Michael.
^ permalink raw reply [flat|nested] 40+ messages in thread* bug#36903: bug#37590: bug#36903: 27.0.50; gnus registry vs. debbugs
2019-10-08 8:52 ` bug#37590: " Michael Heerdegen
@ 2019-10-08 18:40 ` Eric Abrahamsen
2019-10-09 14:37 ` Michael Heerdegen
0 siblings, 1 reply; 40+ messages in thread
From: Eric Abrahamsen @ 2019-10-08 18:40 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 36903
Michael Heerdegen <michael_heerdegen@web.de> writes:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Great! I'm closing this and a related report.
>
> Hmm - same recipe as always, today I'm getting this:
Yep, I missed a spot. I've fixed that spot, and for good measure moved
Gnorb's hooking into separate functions, so the hooks are added at
startup, and removed at shutdown.
Eric
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: bug#37590: bug#36903: 27.0.50; gnus registry vs. debbugs
2019-10-08 18:40 ` bug#36903: " Eric Abrahamsen
@ 2019-10-09 14:37 ` Michael Heerdegen
0 siblings, 0 replies; 40+ messages in thread
From: Michael Heerdegen @ 2019-10-09 14:37 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 36903
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> Yep, I missed a spot. I've fixed that spot, and for good measure moved
> Gnorb's hooking into separate functions, so the hooks are added at
> startup, and removed at shutdown.
Thanks, seems to work again :-)
Regards,
Michael.
^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#36903: 27.0.50; gnus registry vs. debbugs
2019-08-11 23:34 ` Lars Ingebrigtsen
2019-08-12 15:24 ` Eric Abrahamsen
@ 2019-08-12 15:36 ` Eric Abrahamsen
2019-08-12 18:30 ` Lars Ingebrigtsen
1 sibling, 1 reply; 40+ messages in thread
From: Eric Abrahamsen @ 2019-08-12 15:36 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 36903
On 08/11/19 16:34 PM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> It seems like it has to be something to do with performance, so the
>> specs aren't re-evaluated? I really don't know. What do you think about
>> taking it out?
>
> I can't really imagine it being performance-related... computing the
> specs take extremely little time.
>
> But it's possible, I guess.
The extra-amusing thing is that gnus-format-specs wasn't in
gnus-variable-list to begin with!
^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2019-10-09 14:37 UTC | newest]
Thread overview: 40+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-08-03 7:11 bug#36903: 27.0.50; gnus registry vs. debbugs Michael Heerdegen
2019-08-03 15:38 ` Eric Abrahamsen
2019-08-03 23:47 ` Michael Heerdegen
2019-08-04 0:16 ` Eric Abrahamsen
2019-08-04 0:27 ` Eric Abrahamsen
2019-08-04 0:44 ` Noam Postavsky
2019-08-04 1:41 ` Eric Abrahamsen
2019-08-04 1:09 ` Michael Heerdegen
2019-08-04 2:10 ` Eric Abrahamsen
2019-08-04 2:35 ` Eric Abrahamsen
2019-08-07 17:59 ` Lars Ingebrigtsen
2019-08-07 20:22 ` Eric Abrahamsen
2019-08-11 23:34 ` Lars Ingebrigtsen
2019-08-12 15:24 ` Eric Abrahamsen
2019-09-14 15:04 ` Lars Ingebrigtsen
2019-09-15 0:27 ` Eric Abrahamsen
2019-09-15 12:20 ` Lars Ingebrigtsen
2019-09-15 23:31 ` Eric Abrahamsen
2019-09-16 13:24 ` Lars Ingebrigtsen
2019-09-16 22:37 ` Eric Abrahamsen
2019-09-19 17:39 ` Eric Abrahamsen
2019-09-21 8:40 ` Michael Albinus
2019-09-21 21:31 ` Eric Abrahamsen
2019-09-22 1:04 ` Michael Heerdegen
2019-09-22 2:36 ` Eric Abrahamsen
2019-09-22 8:02 ` Michael Albinus
2019-09-25 9:39 ` Michael Heerdegen
2019-09-25 16:30 ` Eric Abrahamsen
2019-10-01 23:27 ` Eric Abrahamsen
2019-10-02 12:36 ` Michael Albinus
2019-10-03 23:22 ` Eric Abrahamsen
2019-10-04 8:24 ` Michael Albinus
2019-10-04 16:59 ` Eric Abrahamsen
2019-10-05 7:53 ` Michael Albinus
2019-10-05 11:59 ` Eric Abrahamsen
2019-10-08 8:52 ` bug#37590: " Michael Heerdegen
2019-10-08 18:40 ` bug#36903: " Eric Abrahamsen
2019-10-09 14:37 ` Michael Heerdegen
2019-08-12 15:36 ` Eric Abrahamsen
2019-08-12 18:30 ` Lars Ingebrigtsen
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).