Gnus development mailing list
 help / color / mirror / Atom feed
From: Kevin Greiner <kgreiner@xpediantsolutions.com>
Subject: Re: Agent categories gone.
Date: Wed, 05 Mar 2003 11:18:27 -0600	[thread overview]
Message-ID: <uk7fdlokc.fsf@xpediantsolutions.com> (raw)
In-Reply-To: <86u1eh968j.fsf@i3d.home>

Robert Epprecht <epprecht@solnet.ch> writes:

> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
>> try deleting all of the gnus *.elc files then run make.
>
> That didn't change anything.
>
>> You could try debugging the compiled code.
>
> OK, I did try (after some RTFM, as I never used the Lisp debugger before).
> Please take everything I say as coming from an absolute newbie in this
> roam... I give you the details of what I did, just in case I did something
> stupid:

For a newbie with the debugger, you did a fabulous job.  I'm at work
right now so I can't pursue this just now.  I did want to let you know
that your stack trace identified the problem as the mapcar* statement.
If you look at the stack trace below, the mapcar* line is immediately
followed by lines that select then kill the temp buffer.  Those
statements were created by the with-temp-buffer macro so this
indicates that mapcar* threw an error that is now unwinding the
execution stack.

OK, let's see... mapcar* is part of cl and RMS, as I was recently
informed :), doesn't approve of using run-time cl (In fact, that IS
the problem.  The (require 'cl) in gnus-agent is wrapped up in a
eval-when-compile form so the cl package hasn't been loaded and
mapcar* is undefined). That doesn't explain why it is defined for me
but... so what.

I'll write a replacement expression later today.

Kevin



> cvs update, removing all *,.elc files, calling ./configure and make, then:
>
> emacs -f gnus
> M-x debug-on-entry <RET> gnus-category-read <RET>
> M-: (gnus-category-read) <RET>
>
> I always paste the line that the point is on,
> press 'd' and give the 'returning value' (If any).
> (please excuse the long lines).
>
> * gnus-category-read()
>
> * (byte-code "ÂÃÄ!!\x18ÅŽr\bqˆÆÇȏ+†\x18
>
> * generate-new-buffer-name(" *temp*")
>   generate-new-buffer-name(" *temp*")	returning value: " *temp*"
> * get-buffer-create(" *temp*")
>   get-buffer-create(" *temp*")          returning value: #<buffer  *temp*>
>
> * (byte-code "ÃÄ\bÅ\"!ˆebˆÆp!\x19ÇÈɏ‰\x1aƒ^[
>
> * nnheader-concat("~/News/agent/" "lib/categories")
> * file-name-as-directory("~/News/agent/")
>   file-name-as-directory("~/News/agent/")    returning value: "~/News/agent/"
> * apply(concat "~/News/agent/" ("lib/categories"))
> * concat("~/News/agent/" "lib/categories")
>   concat("~/News/agent/" "lib/categories")
>       returning value: "~/News/agent/lib/categories"
>   apply(concat "~/News/agent/" "lib/categories") returning value: "~/News/agent/lib/categories"
>   nnheader-concat("~/News/agent/" "lib/categories") returning value: "~/News/agent/lib/categories"
> * nnheader-insert-file-contents("~/News/agent/lib/categories")
> * mm-insert-file-contents("~/News/agent/lib/categories" nil nil nil nil)
> * mm-auto-mode-alist()
>   mm-auto-mode-alist()  returning value: (("\\.~?[0-9]+\\.[0-9][-.0-9]*~?\\'" ignore t))
> * insert-file-contents("~/News/agent/lib/categories" nil nil nil nil)
>
> ' *temp*' looks like this now:
> ((header false nil nil) (all true nil ("comp.lang.forth" "gnu.emacs.sources")) (default high file nil))
>
> * format-decode(nil 103 nil)
> * buffer-modified-p()
>   buffer-modified-p()        returning value: t
> * (set-buffer-modified-p mod)
>   set-buffer-modified-p(t)   returning value: t
>   format-decode(nil 103 nil) returning value: 103
>   insert-file-contents("~/News/agent/lib/categories" nil nil nil nil)
>        returning value: ("/home/m/News/agent/lib/categories" 103)
>   mm-insert-file-contents("~/News/agent/lib/categories" nil nil nil nil)
>        returning value: ("/home/m/News/agent/lib/categories" 103)
>   nnheader-insert-file-contents("~/News/agent/lib/categories")
>        returning value: ("/home/m/News/agent/lib/categories" 103)
> * read(#<buffer  *temp*>)
>   read(#<buffer  *temp*>)
>        returning value: ((header false nil nil) (all true nil ("comp.lang.forth" "gnu.emacs.sources")) (default high file nil))
> * (byte-code "Ap!\207" [read] 2)
> * read(#<buffer  *temp*>)
>
> * mapcar(#[(c) "\bÁÂÃÄ\bAÅ#\"¡ˆ\b‡" [c delq nil mapcar* #[... "\b…\a
>
> * #[(c) "\bÁÂÃÄ\bAÅ#\"¡ˆ\b‡" [c delq nil mapcar* #[... "\b…\a
>
> * mapcar*(#[(valu symb) "\b…\a
>
> * (byte-code "Á\b!ƒ\n
> * buffer-name(#<buffer  *temp*>)
>   buffer-name(#<buffer  *temp*>)    returning value: " *temp*"
> * kill-buffer(#<buffer  *temp*>)
> * run-hooks(kill-buffer-hook)
> * register-swap-out()
>   register-swap-out()            returning value: nil
>   run-hooks(kill-buffer-hook)    returning value: nil
>   kill-buffer(#<killed buffer>)  returning value: t
>   byte-code("Á\b!ƒ\n
>      returning value: buffer-name
>
>   byte-code("ÂÃÄ!!\x18ÅŽr\bqˆÆÇȏ+†\x18
>     returning value: ((default (agent-predicate . false)))
>
>   gnus-category-read()
>     returning value: ((default (agent-predicate . false)))
>
> * prin1(((default (agent-predicate . false))) t)
>   prin1(((default (agent-predicate . false))) t)
>        returning value: ((default (agent-predicate . false)))
>
> * run-hooks(post-command-hook)
> * gnus-undo-boundary()
>   gnus-undo-boundary()            returning value: t
>   run-hooks(post-command-hook)    returning value: nil
> * (mode-line-mode-name)
> * (normal-top-level)
> [ ... ]
>
>
> I hope that gives you some clues!
> (I interpret the lines given below the ones the cursor is at as a kind of
>  'nesting stack' or similar. I hope you can guess that from context).
>
>
> BTW: As a Lisp newbie I'm a bit surprised.  Does this mean, that byte
> compiled Lisp can give different results than interpreted one? (I hope
> the term 'interpreted' is right in Lisp)  Is this normal or a bug of the
> compiler?
>
> Robert Epprecht



  reply	other threads:[~2003-03-05 17:18 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-03 17:22 Robert Epprecht
2003-03-03 17:50 ` Kevin Greiner
2003-03-03 18:09   ` Robert Epprecht
2003-03-03 19:13   ` David S Goldberg
2003-03-03 19:56     ` Robert Epprecht
2003-03-03 22:11       ` Kevin Greiner
2003-03-04  5:22         ` Robert Epprecht
2003-03-04  5:51           ` Kevin Greiner
2003-03-04 13:29             ` Robert Epprecht
2003-03-04 22:29               ` Kevin Greiner
2003-03-05 15:35                 ` Robert Epprecht
2003-03-05 17:18                   ` Kevin Greiner [this message]
2003-03-05 17:34                     ` David S Goldberg
2003-03-05 20:20                       ` Kai Großjohann
2003-03-05 18:35                     ` Robert Epprecht
2003-03-06  6:55                       ` R e: " Kevin Greiner
2003-03-06 13:22                         ` Robert Epprecht
2003-03-06 15:46                           ` Kevin Greiner
2003-03-06 19:01                             ` Robert Epprecht

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=uk7fdlokc.fsf@xpediantsolutions.com \
    --to=kgreiner@xpediantsolutions.com \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).