* gnus-sync-save fails with "wrong-type-argument number-or-marker-p"
@ 2011-11-23 19:55 Steinar Bang
2011-11-23 20:27 ` Steinar Bang
0 siblings, 1 reply; 15+ messages in thread
From: Steinar Bang @ 2011-11-23 19:55 UTC (permalink / raw)
To: ding
I now have the same failure (or almost the same failure, I'm not sure if
the GUID/hash is the same...) on two recently updated gnusen. They fail
with the message:
Wrong type argument: number-or-marker-p, "7-bcd0b5ad46256ed1b4940142b85ec4e2"
The stack trace, is:
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p "7-bcd0b5ad46256ed1b4940142b85ec4e2")
1+("7-bcd0b5ad46256ed1b4940142b85ec4e2")
(cons (1+ to) ret)
(setq ret (cons (1+ to) ret))
(push (1+ to) ret)
(while ranges (setq range (pop ranges)) (if (atom range) (setq from range to range) (setq from ... to ...)) (push from ret) (push (1+ to) ret))
(let ((ranges ...) ret range from to) (while ranges (setq range ...) (if ... ... ...) (push from ret) (push ... ret)) (reverse ret))
(append (quote (invlist)) (let (... ret range from to) (while ranges ... ... ... ...) (reverse ret)))
gnus-sync-range2invlist(("7-bcd0b5ad46256ed1b4940142b85ec4e2"))
(cons (car mark-entry) (gnus-sync-range2invlist (cdr mark-entry)))
(lambda (mark-entry) (cons (car mark-entry) (gnus-sync-range2invlist ...)))((_deleted_conflicts "7-bcd0b5ad46256ed1b4940142b85ec4e2"))
mapcar((lambda (mark-entry) (cons (car mark-entry) (gnus-sync-range2invlist ...))) ((tick 2513 2531 2539 2661 (2781 . 2783) 2786 2789) (subscribe-all) (_deleted_conflicts "7-bcd0b5ad46256ed1b4940142b85ec4e2") (subscribe-all nil)))
(append (when revision (list ...)) (list (cons ... k)) passed-props (list (cons ... ...) (cons ... ...)) (if topic (list ...) nil) (if topic-offset (list ...) nil) (list (cons ... ...)) (mapcar (lambda ... ...) (nth 3 nentry)))
(\` ((\,@ ...) (_id \, k) (\,@ passed-props) (source ...) (\, ...) (\,@ ...) (\,@ ...) (\, ...) (\,@ ...)))
(let* ((loc "gnus-sync-lesync-save-group-entry") (k ...) (revision ...) (sname gnus-sync-lesync-name) (topic ...) (topic-offset ...) (sources ...)) (\` (... ... ... ... ... ... ... ... ...)))
gnus-sync-lesync-pre-save-group-entry("http://lesync.mydomain.com/myuser" ("nntp+news.gmane.org:gmane.comp.db.postgresql.devel.win32" 6 ((1 . 3010)) ((tick 2513 2531 2539 2661 ... 2786 2789) (subscribe-all) (_deleted_conflicts "7-bcd0b5ad46256ed1b4940142b85ec4e2") (subscribe-all nil)) "nntp:news.gmane.org") (float-time . 1322077746.089012))
(lambda (entry) (gnus-sync-lesync-pre-save-group-entry (cadr gnus-sync-backend) entry (cons ... ftime)))(("nntp+news.gmane.org:gmane.comp.db.postgresql.devel.win32" 6 ((1 . 3010)) ((tick 2513 2531 2539 2661 ... 2786 2789) (subscribe-all) (_deleted_conflicts "7-bcd0b5ad46256ed1b4940142b85ec4e2") (subscribe-all nil)) "nntp:news.gmane.org"))
mapcar((lambda (entry) (gnus-sync-lesync-pre-save-group-entry (cadr gnus-sync-backend) entry (cons ... ftime))) (("nntp+news.gwene.org:gwene.no.vegvesen.om.statens.vegvesen.media.nyhetsarkiv.rss" 3 (...) (... ...) (nntp "news.gwene.org")) ("nntp+news.gwene.org:gwene.no.njk.jernbane.nyheter" 3 (...) (... ...) (nntp "news.gwene.org")) ("nntp+news.gwene.org:gwene.no.tu.rss.jobb" 3 (...) (... ...) (nntp "news.gwene.org")) ("nntp+dough.gmane.org:gmane.spam.reported.unspam" 6 (...) (... ... ...) (nntp "dough.gmane.org") (...)) ("nntp+dough.gmane.org:gmane.spam.reported.spam" 3 (...) (... ...) (nntp "dough.gmane.org") (...)) ("nntp+news.gmane.org:gmane.linux.drivers.ndiswrapper.general" 6 (...) (... ... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.linux.swsusp.devel" 6 (...) (... ... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.linux.acpi.support" 6 (...) (... ... ...) "nntp:news.gmane.org" nil) ("nntp+news.gmane.org:gmane.linux.acpi.devel" 6 (...) (... ... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.comp.web.rdfweb" 6 (...) (... ... ...) "nntp:news.gmane.org" nil) ("nntp+news.gmane.org:gmane.comp.web.rdf.logic" 6 (...) (... ... ...) "nntp:news.gmane.org" nil) ("nntp+news.gmane.org:gmane.comp.web.rdf" 6 (...) (... ... ... ...) "nntp:news.gmane.org" nil) ("nntp+news.gmane.org:gmane.comp.mozilla.devel.rdf" 6 (...) (... ... ... ...) "nntp:news.gmane.org" nil) ("nntp+news.gmane.org:gmane.comp.misc.ontology.protege.owl" 6 (...) (... ... ... ...) "nntp:news.gmane.org" nil) ("nntp+news.gmane.org:gmane.comp.misc.ontology.protege.general" 6 (...) (... ... ... ...) "nntp:news.gmane.org" nil) ("nntp+news.gmane.org:gmane.comp.misc.ontology.protege.beta" 6 (...) (... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.comp.misc.ontology.protege.announce" 6 (...) (... ... ...) "nntp:news.gmane.org" nil) ("nntp+news.gmane.org:gmane.comp.misc.ontology.general" 6 (...) (... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.comp.lang.smalltalk.squeak.squeakland" 6 (...) (... ... ... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.comp.lang.smalltalk.squeak.general" 3 (... ... ... 153920 ... ... 153941 ... ... ... ... 154013 ... 155107 ... ... ... ... ... 156509 156511 156514 ... 156524 ... 156531 ... ... ... ... ... ... 157940 157942 157947 157949 ... 157957 157960 157964 ... 157970 ... 157979 ... 157988 157993 157995 157997 ... ...) (... ... ...) "nntp:news.gmane.org") ("nntp+news.opera.com:opera.beta" 6 (...) (... ... ... ... ... ...) (nntp "news.opera.com")) ("nntp+news.gmane.org:gmane.comp.java.maven-plugins.mojo.devel" 3 (...) (... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.comp.java.maven-plugins.mojo.user" 3 (...) (... ... ... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.comp.version-control.bazaar-ng.general" 6 (...) (... ... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.comp.version-control.bazaar-ng.announce" 6 (...) (... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.network.vpnc.devel" 6 (...) (... ... ... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.comp.java.maven-plugins.user" 3 (...) (... ... ... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.comp.apache.felix.devel" 3 (...) (... ... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.comp.apache.maven.devel" 6 (3823) (... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.comp.ide.eclipse.plugins.m2eclipse.user" 3 (...) (... ... ... ... ...) "nntp:news.gmane.org") ("nntp+news.eclipse.org:eclipse.technology.m2e" 3 (...) (... ... ... ...) (nntp "news.eclipse.org")) ("nntp+news.eclipse.org:eclipse.technology.iam" 3 (...) (... ... ...) (nntp "news.eclipse.org")) ("nntp+news.gmane.org:gmane.comp.jakarta.turbine.maven.user" 3 (...) (... ... ... ... ...) "nntp:news.gmane.org" (...)) ("nntp+news.gmane.org:gmane.comp.java.abbot.user" 6 (...) (... ... ... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.comp.editors.jemacs.general" 3 (...) (... ... ...) "nntp:news.gmane.org") ("nntp+news.eclipse.org:eclipse.modeling.gmf" 3 (...) (... ... ... ...) (nntp "news.eclipse.org")) ("nntp+news.gmane.org:gmane.comp.java.netbeans.devel" 6 (...) (... ... ...) "nntp:news.gmane.org") ("nntp+news.eclipse.org:eclipse.tools.emf" 3 (...) (... ... ... ...) (nntp "news.eclipse.org")) ("nntp+news.eclipse.org:eclipse.tools.gef" 3 (...) (... ... ... ...) (nntp "news.eclipse.org")) ("nntp+news.eclipse.org:eclipse.platform.swt" 3 (...) (... ... ... ...) (nntp "news.eclipse.org")) ("nntp+news.eclipse.org:eclipse.platform" 3 (...) (... ... ... ...) (nntp "news.eclipse.org")) ("nntp+news.gmane.org:gmane.comp.ide.eclipse.pde.devel" 3 (...) (... ... ... ... ...) "nntp:news.gmane.org") ("nntp+news.eclipse.org:eclipse.technology.equinox" 3 (...) (... ... ...) (nntp "news.eclipse.org")) ("nntp+news.eclipse.org:eclipse.platform.rcp" 3 (...) (... ... ... ... ...) (nntp "news.eclipse.org")) ("nntp+news.gmane.org:gmane.comp.java.springframework.rcp.devel" 6 (...) (... ... ...) "nntp:news.gmane.org") ("nntp+news.eclipse.org:eclipse.newcomer" 6 (...) (... ... ... ... ... ...) (nntp "news.eclipse.org")) ("nntp+news.gmane.org:gmane.comp.version-control.subversion.cvs2svn.user" 3 (...) (... ... ... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.comp.version-control.subversion.cvs2svn.devel" 3 (...) (... ... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.comp.version-control.subversion.cvs2svn.announce" 3 (...) (... ... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.comp.version-control.subversion.user" 3 (...) (... ... ... ... ... ...) "nntp:news.gmane.org") ...))
(let* ((ftime ...) (url ...) (entries ...) (sync ...)) (mapcar (lambda ... ...) sync))
(cond ((and ... ... ...) (when force ...) (let* ... ...)) ((stringp gnus-sync-backend) (gnus-message 7 "gnus-sync-save: saving to backend %s" gnus-sync-backend) (let ... ...)) (nil))
gnus-sync-save(nil)
call-interactively(gnus-sync-save t nil)
execute-extended-command(nil)
call-interactively(execute-extended-command nil nil)
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: gnus-sync-save fails with "wrong-type-argument number-or-marker-p" 2011-11-23 19:55 gnus-sync-save fails with "wrong-type-argument number-or-marker-p" Steinar Bang @ 2011-11-23 20:27 ` Steinar Bang 2011-12-06 21:17 ` Steinar Bang 0 siblings, 1 reply; 15+ messages in thread From: Steinar Bang @ 2011-11-23 20:27 UTC (permalink / raw) To: ding Hm... turns out that on the netbook I only needed to do a `gnus-sync-read' to be able to do a `gnus-sync-save' without an error. However, on the home desktop, doing `gnus-sync-read' wasn't enough to fix the issue. I still get the error message (or a similar one) on all attempts to `gnus-sync-save'. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gnus-sync-save fails with "wrong-type-argument number-or-marker-p" 2011-11-23 20:27 ` Steinar Bang @ 2011-12-06 21:17 ` Steinar Bang 2011-12-08 14:50 ` Ted Zlatanov 0 siblings, 1 reply; 15+ messages in thread From: Steinar Bang @ 2011-12-06 21:17 UTC (permalink / raw) To: ding >>>>> Steinar Bang <sb@dod.no>: > However, on the home desktop, doing `gnus-sync-read' wasn't enough to > fix the issue. I still get the error message (or a similar one) on all > attempts to `gnus-sync-save'. On the home desktop (debian testing, GNU Emacs 23.3.1), I get the following message in the mini-buffer when trying to do `gnus-sync-save': Wrong type argument: number-or-marker-p, "8-54ce40d61d4b92eda3bffb29c6e0b1c6" The stack trace, is: (lambda (entry) (gnus-sync-lesync-pre-save-group-entry (cadr gnus-sync-backend) entry (cons ... ftime)))(("nntp+nntp.dod.no:no.alt.motorsykler" 6 ((1 . 33536)) ((subscribe-all) (_deleted_conflicts "8-54ce40d61d4b92eda3bffb29c6e0b1c6") (subscribe-all nil)) (nntp "nntp.dod.no") ((charset . iso-8859-1)))) mapcar((lambda (entry) (gnus-sync-lesync-pre-save-group-entry (cadr gnus-sync-backend) entry (cons ... ftime))) (("nntp+nntp.dod.no:no.alt.motorsykler" 6 (...) (... ... ...) (nntp "nntp.dod.no") (...)) ("nntp+news.gmane.org:gmane.linux.drivers.bcm54xx.devel" 6 (...) (... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.discuss" 3 (...) (... ... ... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.comp.db.postgresql.german" 7 nil (... ...) "nntp:news.gmane.org"))) (let* ((ftime ...) (url ...) (entries ...) (sync ...)) (mapcar (lambda ... ...) sync)) (cond ((and ... ... ...) (when force ...) (let* ... ...)) ((stringp gnus-sync-backend) (gnus-message 7 "gnus-sync-save: saving to backend %s" gnus-sync-backend) (let ... ...)) (nil)) gnus-sync-save(nil) call-interactively(gnus-sync-save t nil) execute-extended-command(nil) call-interactively(execute-extended-command nil nil) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gnus-sync-save fails with "wrong-type-argument number-or-marker-p" 2011-12-06 21:17 ` Steinar Bang @ 2011-12-08 14:50 ` Ted Zlatanov 2011-12-08 19:07 ` Steinar Bang 0 siblings, 1 reply; 15+ messages in thread From: Ted Zlatanov @ 2011-12-08 14:50 UTC (permalink / raw) To: ding [-- Attachment #1: Type: text/plain, Size: 2275 bytes --] On Tue, 06 Dec 2011 22:17:57 +0100 Steinar Bang <sb@dod.no> wrote: >>>>>> Steinar Bang <sb@dod.no>: >> However, on the home desktop, doing `gnus-sync-read' wasn't enough to >> fix the issue. I still get the error message (or a similar one) on all >> attempts to `gnus-sync-save'. SB> On the home desktop (debian testing, GNU Emacs 23.3.1), I get the SB> following message in the mini-buffer when trying to do `gnus-sync-save': SB> Wrong type argument: number-or-marker-p, "8-54ce40d61d4b92eda3bffb29c6e0b1c6" SB> The stack trace, is: SB> (lambda (entry) (gnus-sync-lesync-pre-save-group-entry (cadr gnus-sync-backend) entry (cons ... ftime)))(("nntp+nntp.dod.no:no.alt.motorsykler" 6 ((1 . 33536)) ((subscribe-all) (_deleted_conflicts "8-54ce40d61d4b92eda3bffb29c6e0b1c6") (subscribe-all nil)) (nntp "nntp.dod.no") ((charset . iso-8859-1)))) SB> mapcar((lambda (entry) (gnus-sync-lesync-pre-save-group-entry (cadr gnus-sync-backend) entry (cons ... ftime))) (("nntp+nntp.dod.no:no.alt.motorsykler" 6 (...) (... ... ...) (nntp "nntp.dod.no") (...)) ("nntp+news.gmane.org:gmane.linux.drivers.bcm54xx.devel" 6 (...) (... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.discuss" 3 (...) (... ... ... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.comp.db.postgresql.german" 7 nil (... ...) "nntp:news.gmane.org"))) SB> (let* ((ftime ...) (url ...) (entries ...) (sync ...)) (mapcar (lambda ... ...) sync)) SB> (cond ((and ... ... ...) (when force ...) (let* ... ...)) ((stringp gnus-sync-backend) (gnus-message 7 "gnus-sync-save: saving to backend %s" gnus-sync-backend) (let ... ...)) (nil)) SB> gnus-sync-save(nil) SB> call-interactively(gnus-sync-save t nil) SB> execute-extended-command(nil) SB> call-interactively(execute-extended-command nil nil) I'm at a conference so I can't do the code fix properly, but I think if you try the attached patch it will fix the issue. The root of the problem is that CouchDB saw a conflict and inserted a parameter telling you so, and gnus-sync.el thinks the parameter is a mark. It's not a big deal. The patch skips any such unused (by gnus-sync.el) parameters with a warning but I'll think about better handling at the root of the problem, when your save conflicts with another. Ted [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: sync-junk.patch --] [-- Type: text/x-diff, Size: 1658 bytes --] diff --git a/lisp/gnus-sync.el b/lisp/gnus-sync.el index 612e586..765e759 100644 --- a/lisp/gnus-sync.el +++ b/lisp/gnus-sync.el @@ -105,7 +105,7 @@ :version "24.1" :group 'gnus) -(defcustom gnus-sync-newsrc-groups `("nntp" "nnrss") +(defcustom gnus-sync-newsrc-groups '("nntp" "nnrss") "List of groups to be synchronized in the gnus-newsrc-alist. The group names are matched, they don't have to be fully qualified. Typically you would choose all of these. That's the @@ -488,10 +488,18 @@ Updates `gnus-sync-lesync-props-hash'." ;; the read marks ,(cons 'read (gnus-sync-range2invlist (nth 2 nentry))) ;; the other marks - ,@(mapcar (lambda (mark-entry) - (cons (car mark-entry) - (gnus-sync-range2invlist (cdr mark-entry)))) - (nth 3 nentry))))) + ,@(delq nil (mapcar (lambda (mark-entry) + (if (listp (cdr mark-entry)) + (cons (car mark-entry) + (gnus-sync-range2invlist + (cdr mark-entry))) + (progn ; else this is not a list + (gnus-message 9 "%s: non-list param %s in %s" + loc + (car mark-entry) + (nth 3 nentry)) + nil))) + (nth 3 nentry)))))) (defun gnus-sync-lesync-post-save-group-entry (url entry) (let* ((loc "gnus-sync-lesync-post-save-group-entry") ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gnus-sync-save fails with "wrong-type-argument number-or-marker-p" 2011-12-08 14:50 ` Ted Zlatanov @ 2011-12-08 19:07 ` Steinar Bang 2011-12-10 7:11 ` Steinar Bang 2011-12-10 11:07 ` gnus-sync-save fails with "wrong-type-argument number-or-marker-p" Ted Zlatanov 0 siblings, 2 replies; 15+ messages in thread From: Steinar Bang @ 2011-12-08 19:07 UTC (permalink / raw) To: ding >>>>> Ted Zlatanov <tzz@lifelogs.com>: > I'm at a conference so I can't do the code fix properly, but I think > if you try the attached patch it will fix the issue. Unfortunately it didn't. I still get Wrong type argument: number-or-marker-p, "8-54ce40d61d4b92eda3bffb29c6e0b1c6" on `gnus-sync-save'. Here's what I did: 1. Save the attachment to /tmp/sync-junk.patch 2. Apply the patch: #+begin_src sh cd git/gnus git apply /tmp/sync-junk.patch #+end_src 3. Rebuild gnus: #+begin_src sh (cd ~/git/gnus; make clean; make; cd lisp; make tags) #+end_src 4. Start a new Emacs with a new Gnus 5. Run `gnus-sync-read', followed by `g' 6. Visit a gmane group to make things dirty 7. Run `gnus-sync-save'. and the issue occurs: #+begin_example Wrong type argument: number-or-marker-p, "8-54ce40d61d4b92eda3bffb29c6e0b1c6" #+end_example ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gnus-sync-save fails with "wrong-type-argument number-or-marker-p" 2011-12-08 19:07 ` Steinar Bang @ 2011-12-10 7:11 ` Steinar Bang 2011-12-10 7:29 ` Steinar Bang 2011-12-10 11:07 ` gnus-sync-save fails with "wrong-type-argument number-or-marker-p" Ted Zlatanov 1 sibling, 1 reply; 15+ messages in thread From: Steinar Bang @ 2011-12-10 7:11 UTC (permalink / raw) To: ding Now I got the issue on my netbook as well, ie. get "wrong-type-argument number-or-marker-p", and an annoying effect is that if I take `gnus-sync-read' followed by `g', I seem to lose marks set in the previous session. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gnus-sync-save fails with "wrong-type-argument number-or-marker-p" 2011-12-10 7:11 ` Steinar Bang @ 2011-12-10 7:29 ` Steinar Bang 2011-12-10 8:10 ` Backquotes and commas and ",@" (Was: gnus-sync-save fails with "wrong-type-argument number-or-marker-p") Steinar Bang 0 siblings, 1 reply; 15+ messages in thread From: Steinar Bang @ 2011-12-10 7:29 UTC (permalink / raw) To: ding >>>>> Steinar Bang <sb@dod.no>: > Now I got the issue on my netbook as well, ie. get "wrong-type-argument > number-or-marker-p", and an annoying effect is that if I take > `gnus-sync-read' followed by `g', I seem to lose marks set in the > previous session. (...and the reason it is hard to do anything about it myself, is that backquotes, "," and ",@", are the bits of emacs lisp I've never been able to wrap my head around. I mean: You can also "splice" an evaluated value into the resulting list, using the special marker `,@'. Like... huh...? Anyway, I guess I must try harder...) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Backquotes and commas and ",@" (Was: gnus-sync-save fails with "wrong-type-argument number-or-marker-p") 2011-12-10 7:29 ` Steinar Bang @ 2011-12-10 8:10 ` Steinar Bang 2011-12-10 9:04 ` Backquotes and commas and ",@" Andreas Schwab 2011-12-10 10:39 ` Ted Zlatanov 0 siblings, 2 replies; 15+ messages in thread From: Steinar Bang @ 2011-12-10 8:10 UTC (permalink / raw) To: ding >>>>> Steinar Bang <sb@dod.no>: > (...and the reason it is hard to do anything about it myself, is that > backquotes, "," and ",@", are the bits of emacs lisp I've never been > able to wrap my head around. I mean: > You can also "splice" an evaluated value into the resulting list, > using the special marker `,@'. > Like... huh...? Anyway, I guess I must try harder...) Trying harder: Backquotes means quoting a list (quoting a list I, sort of, knows what means), in a way where you can evaluate parts of the list, by putting a "," in front of them. Ok, I understood that bit. I also understood the example in the elisp manual (comparing a regular quoted list, to a backqouted list with one element comma'd and evaluated). So, what's still unclear, is: 1. Why backquote (or for that matter: "why quote?") the body of a defun? What does that mean? #+begin_src emacs-lisp (defun gnus-sync-lesync-pre-save-group-entry (url nentry &rest passed-props) (let* ((loc "gnus-sync-lesync-save-group-entry") (k (car nentry)) (revision (gnus-sync-lesync-get-prop 'rev k)) (sname gnus-sync-lesync-name) (topic (gnus-group-topic k)) (topic-offset (gnus-sync-topic-group-position k topic)) (sources (gnus-sync-lesync-get-prop 'source k))) ;; set the revision so we don't have a conflict `(,@(when revision ... #+end_src 2. What does ",@" mean? "Splice the result of the evaluation into the list"...? Ah... I think I actually understand now. Looking at the elisp manual examples for ",@", I see that it means that if the result of the comma-evaluation is a list, the elements are added as element of the list, not as a single element that is a list. And the backqoute is just a convenient way of constructing a list. This means that the gnus-sync-lesync-pre-save-group-entry function returns a list. And that list, is: - If there is a revision, start the list with the symbol '_rev followed by the revision - Then the list will have an element that is a two element list, consisting of the symbol '_id and the first element of the nentry argument to the function (I don't understand why you have to have the "." there, though...?) - Then passed props are spliced in (what happens if there is no passed-props argument sent to the function? It's optional...?) - Then an element that is a list starting with "source" (whatever that is), followed by the result of evaluating the "if" - Then an element that is a two element list starting with 'level and with a number(?) as the second element - Then splice in the elements resulting from evaluating two "if"s relating to topics - Then an element that is a list containing the read marks - Then an element that is a list containing other marks, and this is the one that broke down for me, because it got a conflict marker instead of the other marks And I'm guessing this list is a translation of JSON into lisp lists... ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Backquotes and commas and ",@" 2011-12-10 8:10 ` Backquotes and commas and ",@" (Was: gnus-sync-save fails with "wrong-type-argument number-or-marker-p") Steinar Bang @ 2011-12-10 9:04 ` Andreas Schwab 2011-12-10 9:52 ` Steinar Bang 2011-12-10 10:39 ` Ted Zlatanov 1 sibling, 1 reply; 15+ messages in thread From: Andreas Schwab @ 2011-12-10 9:04 UTC (permalink / raw) To: ding Steinar Bang <sb@dod.no> writes: > This means that the gnus-sync-lesync-pre-save-group-entry function > returns a list. More specifically, it returns an alist of key/value pairs. > - Then the list will have an element that is a two element list, It's a cons whose car is the key and cdr is the value. > consisting of the symbol '_id and the first element of the nentry > argument to the function (I don't understand why you have to have > the "." there, though...?) Because you want the cdr to be the value of the key, not the cadr. > - Then passed props are spliced in (what happens if there is no > passed-props argument sent to the function? It's optional...?) Splicing the empty list will splice nothing. > - Then an element that is a two element list starting with 'level and > with a number(?) as the second element Again, it is a cons, not a two element list. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Backquotes and commas and ",@" 2011-12-10 9:04 ` Backquotes and commas and ",@" Andreas Schwab @ 2011-12-10 9:52 ` Steinar Bang 0 siblings, 0 replies; 15+ messages in thread From: Steinar Bang @ 2011-12-10 9:52 UTC (permalink / raw) To: ding >>>>> Andreas Schwab <schwab@linux-m68k.org>: > Steinar Bang <sb@dod.no> writes: >> This means that the gnus-sync-lesync-pre-save-group-entry function >> returns a list. > More specifically, it returns an alist of key/value pairs. Right! That makes sense. >> - Then the list will have an element that is a two element list, > It's a cons whose car is the key and cdr is the value. Right! And a cons cell isn't a two element list. A two element list would have been two cons cells, with the car of each cell holding the elements. >> consisting of the symbol '_id and the first element of the nentry >> argument to the function (I don't understand why you have to have >> the "." there, though...?) > Because you want the cdr to be the value of the key, not the cadr. And refreshing my lisp knowledge: - cdr is the second slot of a cons cell, ie. the one pointing to the next cons cell of the list - cadr is the car of the cdr ie. (cadr '(1 2)) is 2. However '(1 2) creates a two element list (ie. two cons cells with the car of the first cons cell being 1 and the car of the second cons cell being 2). And indeed (cadr (1 . 2)) fails (as one would expect from cadr's definition Ah... "value of the key" is somewhat ambigous. I took that to mean, well... the value of the key. While you meant the value that can be looked up, using the key, and in which case your sentence makes sense. So... I looked up the definition of alist, and it's indeed a list of cons cells (which isn't surprising when one stops to think about it). > Splicing the empty list will splice nothing. I suspected that this might be the case, but didn't stop to look it up. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Backquotes and commas and ",@" 2011-12-10 8:10 ` Backquotes and commas and ",@" (Was: gnus-sync-save fails with "wrong-type-argument number-or-marker-p") Steinar Bang 2011-12-10 9:04 ` Backquotes and commas and ",@" Andreas Schwab @ 2011-12-10 10:39 ` Ted Zlatanov 1 sibling, 0 replies; 15+ messages in thread From: Ted Zlatanov @ 2011-12-10 10:39 UTC (permalink / raw) To: ding On Sat, 10 Dec 2011 09:10:55 +0100 Steinar Bang <sb@dod.no> wrote: SB> So, what's still unclear, is: SB> 1. Why backquote (or for that matter: "why quote?") the body of a SB> defun? What does that mean? #+begin_src emacs-lisp (defun gnus-sync-lesync-pre-save-group-entry (url nentry &rest passed-props) (let* ((loc "gnus-sync-lesync-save-group-entry") (k (car nentry)) (revision (gnus-sync-lesync-get-prop 'rev k)) (sname gnus-sync-lesync-name) (topic (gnus-group-topic k)) (topic-offset (gnus-sync-topic-group-position k topic)) (sources (gnus-sync-lesync-get-prop 'source k))) ;; set the revision so we don't have a conflict `(,@(when revision ... #+end_src The function returns a list. It was more convenient to build the list all at once, with interpolation, than imperatively with push/pop or cons. SB> 2. What does ",@" mean? "Splice the result of the evaluation into SB> the list"...? Ah... I think I actually understand now. Looking SB> at the elisp manual examples for ",@", I see that it means that if SB> the result of the comma-evaluation is a list, the elements are SB> added as element of the list, not as a single element that is a SB> list. ,@ says "whatever list follows, splice it in." If the list is empty, nothing happens; it's convenient when you want some content to appear only if it's not nil. So for example #+begin_src emacs-lisp ,@(if topic (list (cons 'topic topic)) nil) #+end_src will result in an alist member like '(topic "xyz") if the `topic' variable was defined, and nothing will be inserted otherwise. SB> This means that the gnus-sync-lesync-pre-save-group-entry function SB> returns a list. And that list, is: SB> - If there is a revision, start the list with the symbol '_rev SB> followed by the revision SB> - Then the list will have an element that is a two element list, SB> consisting of the symbol '_id and the first element of the nentry SB> argument to the function (I don't understand why you have to have SB> the "." there, though...?) SB> - Then passed props are spliced in (what happens if there is no SB> passed-props argument sent to the function? It's optional...?) SB> - Then an element that is a list starting with "source" (whatever SB> that is), followed by the result of evaluating the "if" SB> - Then an element that is a two element list starting with 'level and SB> with a number(?) as the second element SB> - Then splice in the elements resulting from evaluating two "if"s SB> relating to topics SB> - Then an element that is a list containing the read marks SB> - Then an element that is a list containing other marks, and this is SB> the one that broke down for me, because it got a conflict marker SB> instead of the other marks SB> And I'm guessing this list is a translation of JSON into lisp lists... It's prep work for the actual save to JSON, converting arbitrary group data (especially marks) into a more neutral format that json.el can handle. Ted ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gnus-sync-save fails with "wrong-type-argument number-or-marker-p" 2011-12-08 19:07 ` Steinar Bang 2011-12-10 7:11 ` Steinar Bang @ 2011-12-10 11:07 ` Ted Zlatanov 2011-12-10 14:19 ` Steinar Bang 1 sibling, 1 reply; 15+ messages in thread From: Ted Zlatanov @ 2011-12-10 11:07 UTC (permalink / raw) To: ding On Thu, 08 Dec 2011 20:07:30 +0100 Steinar Bang <sb@dod.no> wrote: >>>>>> Ted Zlatanov <tzz@lifelogs.com>: >> I'm at a conference so I can't do the code fix properly, but I think >> if you try the attached patch it will fix the issue. SB> Unfortunately it didn't. I still get SB> Wrong type argument: number-or-marker-p, "8-54ce40d61d4b92eda3bffb29c6e0b1c6" SB> on `gnus-sync-save'. SB> Here's what I did: SB> 1. Save the attachment to /tmp/sync-junk.patch SB> 2. Apply the patch: #+begin_src sh cd git/gnus git apply /tmp/sync-junk.patch #+end_src SB> 3. Rebuild gnus: #+begin_src sh (cd ~/git/gnus; make clean; make; cd lisp; make tags) #+end_src SB> 4. Start a new Emacs with a new Gnus SB> 5. Run `gnus-sync-read', followed by `g' SB> 6. Visit a gmane group to make things dirty SB> 7. Run `gnus-sync-save'. and the issue occurs: #+begin_example Wrong type argument: number-or-marker-p, "8-54ce40d61d4b92eda3bffb29c6e0b1c6" #+end_example The stack trace you sent me was not complete (because of the default Emacs behavior, which in this case doesn't help), I need to know your data and the full invocation. Do (setq print-level nil print-length nil) and then redo that error and send me the full backtrace (it will have all your sync data, I think). It seems like gnus-sync.el has allowed some CouchDB parameters to creep into the newsrc, which is causing your problem. A quick fix, after you've prepped the backtrace, is to exit Gnus, back up and then edit your newsrc.eld to remove the paired cons list that matches the error string above. It will probably look like (deleted_conflicts "8-54ce40d61d4b92eda3bffb29c6e0b1c6") I'll try to get this resolved with you quickly but until Tuesday next week I'll be travelling; I apologize in advance for the slow responses. Thanks Ted ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gnus-sync-save fails with "wrong-type-argument number-or-marker-p" 2011-12-10 11:07 ` gnus-sync-save fails with "wrong-type-argument number-or-marker-p" Ted Zlatanov @ 2011-12-10 14:19 ` Steinar Bang 2011-12-10 14:45 ` Steinar Bang 0 siblings, 1 reply; 15+ messages in thread From: Steinar Bang @ 2011-12-10 14:19 UTC (permalink / raw) To: ding >>>>> Ted Zlatanov <tzz@lifelogs.com>: > The stack trace you sent me was not complete (because of the default > Emacs behavior, which in this case doesn't help), I need to know your > data and the full invocation. Do > (setq print-level nil > print-length nil) > and then redo that error and send me the full backtrace (it will have > all your sync data, I think). Ok, I will try this and send you the trace in email. Actually, I already have. It still looks like it doesn't print everything. Lot's of "..." in the lisp structures printed. > It seems like gnus-sync.el has allowed some CouchDB parameters to > creep into the newsrc, which is causing your problem. A quick fix, > after you've prepped the backtrace, is to exit Gnus, back up and then > edit your newsrc.eld to remove the paired cons list that matches the > error string above. It will probably look like (deleted_conflicts > "8-54ce40d61d4b92eda3bffb29c6e0b1c6") Ok, I will try that. > I'll try to get this resolved with you quickly but until Tuesday next > week I'll be travelling; I apologize in advance for the slow > responses. Well... er... since I'm using software that others share out of their good will, I don't expect any support out over what they are prepared to give at any given time. So, no apologies needed. Honest! :-) My postings comes from that I need to think out loud when I work my way through issues, and for gnus-sync, the gnus list seems like the right forum to do so in. :-) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gnus-sync-save fails with "wrong-type-argument number-or-marker-p" 2011-12-10 14:19 ` Steinar Bang @ 2011-12-10 14:45 ` Steinar Bang 2011-12-10 14:49 ` Steinar Bang 0 siblings, 1 reply; 15+ messages in thread From: Steinar Bang @ 2011-12-10 14:45 UTC (permalink / raw) To: ding >>>>> Steinar Bang <sb@dod.no>: >> It seems like gnus-sync.el has allowed some CouchDB parameters to >> creep into the newsrc, which is causing your problem. A quick fix, >> after you've prepped the backtrace, is to exit Gnus, back up and then >> edit your newsrc.eld to remove the paired cons list that matches the >> error string above. It will probably look like (deleted_conflicts >> "8-54ce40d61d4b92eda3bffb29c6e0b1c6") > Ok, I will try that. Ok, I had three _deleted_conflicts conses, and I had to remove all of them, before I was allowed to do a gnus-sync-save. When I did a gnus-sync-save, the minibuffer got a lot of these: gnus-sync-lesync-post-save-group-entry: use `gnus-sync-read' to resolve the conflict synchronizing nntp+news.gmane.org:gmane.comp.db.postgresql.german to http://lesync.bang.priv.no/sb: Document update conflict. One for each group handled by the gnus-sync, it looks like. The *Messages* buffer has overflowed with them. If I do gnus-sync-read, I suspect two things will happen: 1. I will lose my recent tick marks 2. I will again be unable to save because of the "wrong-type-argument number-or-marker-p" issue I will try doing a gnus-sync-read and report back what happened. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gnus-sync-save fails with "wrong-type-argument number-or-marker-p" 2011-12-10 14:45 ` Steinar Bang @ 2011-12-10 14:49 ` Steinar Bang 0 siblings, 0 replies; 15+ messages in thread From: Steinar Bang @ 2011-12-10 14:49 UTC (permalink / raw) To: ding >>>>> Steinar Bang <sb@dod.no>: > If I do gnus-sync-read, I suspect two things will happen: > 1. I will lose my recent tick marks That did indeed happen. All tick marks made by me since Thursday, lost. > 2. I will again be unable to save because of the "wrong-type-argument > number-or-marker-p" issue That did not happen. But this time I answered "n" to all requests for adding topics or groups. I think the last time I answered "y" to them (just to get them out of the way). So... I can either restore the .newsrc.eld with the right tick marks, or re-read them now that I can save them. Going for the latter, I think. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2011-12-10 14:49 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-11-23 19:55 gnus-sync-save fails with "wrong-type-argument number-or-marker-p" Steinar Bang 2011-11-23 20:27 ` Steinar Bang 2011-12-06 21:17 ` Steinar Bang 2011-12-08 14:50 ` Ted Zlatanov 2011-12-08 19:07 ` Steinar Bang 2011-12-10 7:11 ` Steinar Bang 2011-12-10 7:29 ` Steinar Bang 2011-12-10 8:10 ` Backquotes and commas and ",@" (Was: gnus-sync-save fails with "wrong-type-argument number-or-marker-p") Steinar Bang 2011-12-10 9:04 ` Backquotes and commas and ",@" Andreas Schwab 2011-12-10 9:52 ` Steinar Bang 2011-12-10 10:39 ` Ted Zlatanov 2011-12-10 11:07 ` gnus-sync-save fails with "wrong-type-argument number-or-marker-p" Ted Zlatanov 2011-12-10 14:19 ` Steinar Bang 2011-12-10 14:45 ` Steinar Bang 2011-12-10 14:49 ` Steinar Bang
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 NNTP newsgroup(s).