* 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).