9:08 p.m.
This bug report will be sent to the XEmacs Development Team,
not to your local site managers!!
Please write in English, because the XEmacs maintainers do not have
translators to read other languages for them.
In XEmacs 21.2 (beta36) "Notus" [Lucid] (sparc-sun-solaris2.5.1, Mule) of Wed
Oct 4 2000 on zephyr
configured using `configure --prefix=/usr2/paulk --bindir=/usr2/paulk/bin/sparc-sunos5
--with-gnu-make --cflags=-O6 --site-includes=/usr2/paulk/include:/usr/local/include
--site-libraries=/usr2/paulk/lib/sparc-sunos5:/usr/local/lib
--site-runtime-libraries=/usr/dt/lib:/usr/local/lib:/usr2/paulk/lib/sparc-sunos5:/usr/openwin/lib
--with-mule --with-x11 --with-tooltalk --with-workshop --with-sound=native
--native-sound-lib=/usr2/paulk/lib/sparc-sunos5/libaudio.a'
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
I believe this happens whenever display-warning-buffer is called. I've
seen this happen randomly off and on since I started using xemacs-21.2-b36
but in trying to track it down today, I started a second instance of XEmacs
on a different server than I normally do and got a tooltalk error on startup.
The tooltalk error was normally but it triggered the following as soon as I
tried to open a file at the splash screen:
(1) (tooltalk/warning) Warning: unable to connect to a ToolTalk server.
(2) (error/warning) error: (wrong-number-of-arguments windows-of-buffer 3)
(3) (error/warning) error: (wrong-number-of-arguments windows-of-buffer 3)
(4) (error/warning) error: (wrong-number-of-arguments windows-of-buffer 3)
(5) (error/warning) error: (wrong-number-of-arguments windows-of-buffer 3)
I had debug-on-error set so I got the following lisp traceback:
Signaling: (wrong-number-of-arguments windows-of-buffer 3)
windows-of-buffer(#<buffer "*Warnings*"> nil t)
display-warning-buffer()
This is repeatable.
Once I get this error, I cannot clear it. Any keyboard or mouse activity
causes another error.
Recent keystrokes:
Recent messages (most recent first):
--
Paul Keusemann Computer Network Technology
email: paul_keusemann(a)cnt.com 6000 Nathan Lane
http://www.cnt.com Plymouth, MN 55442
9:04 a.m.
Paul Keusemann <Paul_Keusemann(a)cnt.com> writes:
I had debug-on-error set so I got the following lisp traceback:
Signaling: (wrong-number-of-arguments windows-of-buffer 3)
windows-of-buffer(#<buffer "*Warnings*"> nil t)
display-warning-buffer()
What does C-h f windows-of-buffer print?
I get
`windows-of-buffer' is an alias for `get-buffer-window-list', a compiled Lisp
function
-- loaded from "/src/xemacs/lisp/window-xemacs.elc"
(windows-of-buffer &optional BUFFER MINIBUF FRAME)
--
Yoshiki Hayashi
3:51 p.m.
On Tue, Oct 31, 2000 at 06:04:25PM +0900, Yoshiki Hayashi wrote:
Paul Keusemann <Paul_Keusemann(a)cnt.com> writes:
> I had debug-on-error set so I got the following lisp traceback:
>
> Signaling: (wrong-number-of-arguments windows-of-buffer 3)
> windows-of-buffer(#<buffer "*Warnings*"> nil t)
> display-warning-buffer()
What does C-h f windows-of-buffer print?
I get
`windows-of-buffer' is an alias for `get-buffer-window-list', a compiled Lisp
function
-- loaded from "/src/xemacs/lisp/window-xemacs.elc"
(windows-of-buffer &optional BUFFER MINIBUF FRAME)
I get:
`windows-of-buffer' is an alias for `get-buffer-window-list', a compiled Lisp
function
-- loaded from
"/usr2/paulk/summitfs1/dl/Editors/XEmacs/Builds/xemacs-21.2.36/lisp/window-xemacs.elc"
(windows-of-buffer BUFFER)
Which seems to explain the problem. Are you running 21.2.36 or a more
recent CVS version?
--
Paul Keusemann pkeusem(a)visi.com
4266 Joppa Court (612) 894-7805
Savage, MN 55378
4:35 p.m.
Paul Keusemann writes:
On Tue, Oct 31, 2000 at 06:04:25PM +0900, Yoshiki Hayashi wrote:
> Paul Keusemann <Paul_Keusemann(a)cnt.com> writes:
>
> > I had debug-on-error set so I got the following lisp traceback:
> >
> > Signaling: (wrong-number-of-arguments windows-of-buffer 3)
> > windows-of-buffer(#<buffer "*Warnings*"> nil t)
> > display-warning-buffer()
>
> What does C-h f windows-of-buffer print?
Thanks for the pointer, by the way. I've figured it out, just not
sure how to fix it yet. I'm running on a Sun machine and am loading
the Sun/Tooltalk stuff which seems to be shadowing the one from apel.
Did the one in apel change or was it adde or did the usage change?
> I get
>
> `windows-of-buffer' is an alias for `get-buffer-window-list', a compiled
Lisp function
> -- loaded from "/src/xemacs/lisp/window-xemacs.elc"
> (windows-of-buffer &optional BUFFER MINIBUF FRAME)
>
I get:
`windows-of-buffer' is an alias for `get-buffer-window-list', a compiled Lisp
function
-- loaded from
"/usr2/paulk/summitfs1/dl/Editors/XEmacs/Builds/xemacs-21.2.36/lisp/window-xemacs.elc"
(windows-of-buffer BUFFER)
Which seems to explain the problem. Are you running 21.2.36 or a more
recent CVS version?
--
Paul Keusemann pkeusem(a)visi.com
4266 Joppa Court (612) 894-7805
Savage, MN 55378
--
Paul Keusemann Computer Network Technology
email: paul_keusemann(a)cnt.com 6000 Nathan Lane
http://www.cnt.com Plymouth, MN 55442
4:39 a.m.
Paul Keusemann <Paul_Keusemann(a)cnt.com> writes:
> `windows-of-buffer' is an alias for
`get-buffer-window-list', a compiled Lisp function
> -- loaded from
"/usr2/paulk/summitfs1/dl/Editors/XEmacs/Builds/xemacs-21.2.36/lisp/window-xemacs.elc"
> (windows-of-buffer BUFFER)
Thanks for the pointer, by the way. I've figured it out, just
not
sure how to fix it yet. I'm running on a Sun machine and am loading
the Sun/Tooltalk stuff which seems to be shadowing the one from apel.
Did the one in apel change or was it adde or did the usage change?
It's correctly defalias'ed, but somehow it gets wrong
definition. What does C-h f get-buffer-window-list show?
What I get is:
`get-buffer-window-list' is a compiled Lisp function
-- loaded from "/src/xemacs/lisp/subr.elc"
(get-buffer-window-list &optional BUFFER MINIBUF FRAME)
I grepped tooltalk package but I couldn't find any place
which redefined it. APEL won't redefine functions if they
are already defined. I tested it on Solaris 2.6 with
tooltalk enabled but I couldn't reproduce it. Does it
happen when you do xemacs -vanilla?
--
Yoshiki Hayashi
1:50 p.m.
Yoshiki Hayashi writes:
Paul Keusemann <Paul_Keusemann(a)cnt.com> writes:
> > `windows-of-buffer' is an alias for `get-buffer-window-list', a
compiled Lisp function
> > -- loaded from
"/usr2/paulk/summitfs1/dl/Editors/XEmacs/Builds/xemacs-21.2.36/lisp/window-xemacs.elc"
> > (windows-of-buffer BUFFER)
> Thanks for the pointer, by the way. I've figured it out, just not
> sure how to fix it yet. I'm running on a Sun machine and am loading
> the Sun/Tooltalk stuff which seems to be shadowing the one from apel.
> Did the one in apel change or was it adde or did the usage change?
It's correctly defalias'ed, but somehow it gets wrong
definition. What does C-h f get-buffer-window-list show?
What I get is:
`get-buffer-window-list' is a compiled Lisp function
-- loaded from "/src/xemacs/lisp/subr.elc"
(get-buffer-window-list &optional BUFFER MINIBUF FRAME)
What I get is:
`get-buffer-window-list' is a compiled Lisp function
-- loaded from "sun-eos-debugger-extra"
(get-buffer-window-list BUFFER)
I grepped tooltalk package but I couldn't find any place
which redefined it. APEL won't redefine functions if they
are already defined. I tested it on Solaris 2.6 with
tooltalk enabled but I couldn't reproduce it. Does it
happen when you do xemacs -vanilla?
It's in the Sun package in sun-eos-debugger-extra.el, which is
required for the SPARCworks integration. I realized after I sent the
last email that the real definition of get-buffer-window-list should
be coming from subr.el. That's what threw me in the first place, I
didn't find the one in sun-eos-debugger-extra.el until after you asked
what C-h f windows-of-buffer showed
As a workaround, I have prefixed the sun-eos-debugger-extra definition
of get-buffer-window-list with `eos::' but it would be nice if the
maintainer would fix it. I guess I should try sending email to
eduardo.pelegri-llopart(a)Eng.Sun.COM.
Let me know if you have any better suggestions for a fix and thanks again.
--
Paul Keusemann Computer Network Technology
email: paul_keusemann(a)cnt.com 6000 Nathan Lane
http://www.cnt.com Plymouth, MN 55442
2:56 p.m.
>>>> "Paul" == Paul Keusemann
<Paul_Keusemann(a)cnt.com> writes:
Paul> It's in the Sun package in sun-eos-debugger-extra.el, which is
Paul> required for the SPARCworks integration. I realized after I sent the
Paul> last email that the real definition of get-buffer-window-list should
Paul> be coming from subr.el. That's what threw me in the first place, I
Paul> didn't find the one in sun-eos-debugger-extra.el until after you asked
Paul> what C-h f windows-of-buffer showed
Paul> As a workaround, I have prefixed the sun-eos-debugger-extra definition
Paul> of get-buffer-window-list with `eos::' but it would be nice if the
Paul> maintainer would fix it. I guess I should try sending email to
Paul> eduardo.pelegri-llopart(a)Eng.Sun.COM.
No, Eduardo stopped maintaining eos back in 1995 when I joined Sun, and
I never maintained it while at Sun. I'm surprised that eos would be
loaded by the Sparcworks integration (which I did maintain for a
while).
Historical: eos is "Eduardo's Own version of Sparcworks".
Please submit your symbol renaming patch to xemacs-patches(a)xemacs.org.
Try to see where sun-eos-debugger-extra.el is being loaded from.
Martin
5:21 p.m.
Martin Buchholz writes:
>>>>> "Paul" == Paul Keusemann
<Paul_Keusemann(a)cnt.com> writes:
Paul> It's in the Sun package in sun-eos-debugger-extra.el, which is
Paul> required for the SPARCworks integration. I realized after I sent the
Paul> last email that the real definition of get-buffer-window-list should
Paul> be coming from subr.el. That's what threw me in the first place, I
Paul> didn't find the one in sun-eos-debugger-extra.el until after you asked
Paul> what C-h f windows-of-buffer showed
Paul> As a workaround, I have prefixed the sun-eos-debugger-extra definition
Paul> of get-buffer-window-list with `eos::' but it would be nice if the
Paul> maintainer would fix it. I guess I should try sending email to
Paul> eduardo.pelegri-llopart(a)Eng.Sun.COM.
No, Eduardo stopped maintaining eos back in 1995 when I joined Sun, and
I never maintained it while at Sun. I'm surprised that eos would be
loaded by the Sparcworks integration (which I did maintain for a
while).
Historical: eos is "Eduardo's Own version of Sparcworks".
Please submit your symbol renaming patch to xemacs-patches(a)xemacs.org.
Will do. Actually, I'm not sure that we can't just comment it out but
I haven't tested that yet.
N.B. I'm a C hacker. Lisp makes my head hurt, not as much as it used
to but any lisp code I submit should be closely scrutinized.
Try to see where sun-eos-debugger-extra.el is being loaded from.
OK.
Here's what I have in my .emacs:
(if (>= emacs-major-version 21)
(progn
(require 'mime-setup)
(when (featurep 'tooltalk)
(load "tooltalk-macros")
(load "tooltalk-util")
(load "tooltalk-init"))
(require 'cc-mode)
(when (featurep 'sparcworks)
(require 'sunpro "sunpro-init")
(require 'ring)
(require 'comint)
(require 'annotations)
(sunpro-startup))
))
This became necessary in XEmacs-21 when the sunpro startup support got
yanked out of xemacs-base I believe. Before that, SPARCWorks was
detected during configuration and compiled in. I asked the list at that time
if this looked reasonable and I believe the only response I got was
from Martin who gave me Tor Norbye's name as the person to contact at
Sun. At any rate it works, so I was happy.
In my case, the call to sunpro-startup adds the SPARCworks menu item,
does a bunch of stuff and eventually loads sun-eos-debugger-extra
among other things.
--
Paul Keusemann Computer Network Technology
email: paul_keusemann(a)cnt.com 6000 Nathan Lane
http://www.cnt.com Plymouth, MN 55442
9130
days inactive
9137
days old
7 comments
4 participants
participants (4)
-
Martin Buchholz -
Paul Keusemann -
Paul Keusemann -
Yoshiki Hayashi