I use GNU Emacs: as an editor since 2003, as a religion since 2008
Also known as: scymtym on #rudel on the freenode IRC network
Okay… I just upgraded to Ubuntu Lucid, which installed emacs23 (23.1.1). Canonical has now also removed Rudel, so I installed the latest tarball from the link above and it won’t start. I get the following error on initializing with global-rudel-minor-mode:
Loading /usr/share/emacs23/site-lisp/rudel/rudel-loaddefs.el (source)…done For information about GNU Emacs and the GNU system, type C-h C-a. Making completion list… Initializing Zeroconf … eval: Wrong number of arguments: #[(type backend) “ D B ” [type backend rudel-zeroconf-service-types] 2 (”/usr/share/emacs23/site-lisp/rudel/zeroconf/rudel-zeroconf.elc” . 1445)], 3
I wasn’t aware of the existence of a Rudel package for Ubuntu, but since your problem description presumably refers to the version available from sourceforge, it doesn’t matter anyway.
From your description, I would assume that the previously installed version of Rudel (the Ubuntu package, if I understand correctly) left behind compiled Emacs Lisp files in /usr/share/emacs23/site-lisp/rudel/. As a first step, you could make sure that only files belonging to the newly installed Rudel version remain on your system. If that does not help, please set
‘debug-on-error’ before calling
‘global-rudel-minor-mode’ and paste the resulting backtrace along with the contents of the *Messages* buffer. Please also include the install location of the new Rudel version.
Hope that helps. --JanMoringen
Interestingly enough, the Deb version of emacs has no
‘debug-on-error’; however, here is what was recorded in the messages window:
Initializing Zeroconf … eval: Wrong number of arguments: #[(type backend) “ D B ” [type backend rudel-zeroconf-service-types] 2 (”/usr/share/emacs23/site-lisp/rudel/zeroconf/rudel-zeroconf.elc” . 1445)], 3
If you have any suggestions for an alternative to the
‘debug-on-error’, let me know.
Thanks for your patience.
The error seems to happen when the byte-compiled version of the Zeroconf backend is loaded from /usr/share/emacs23/site-lisp/rudel/zeroconf/rudel-zeroconf.elc. It looks like files from more than one Rudel version got mixed up on your system.
To get a better picture, I need more information. Could you please answer the following questions:
Please also provide the complete contents of the *Messages* buffer if there is no confidential information in it.
‘debug-on-error’: Did you try to call it as a function via M-x? You have to use M-x
‘toggle-debug-on-error’ or the menu-entry Options > Debugger on Error.
Good luck. --JanMoringen
Okay… I got this sorted out. It wasn’t rudel at all, actually. It was sepia. Apparently there’s some issue with sepia in Ubuntu Lucid/emacs23. Once I removed sepia and let dpkg reconfigure the debian version of emacs23, then hand reinstalled rudel, it works. We’re back in business!
(Now, why did Canonical remove rudel from their list, hmmmm? :> )
Okay, after all that I had a catestrophic system crash and have had to do a complete reinstall (new mother board, etc. etc.) and now rudel is not cooperating again. I left you a message over on the rudel page of the wiki with the loading error.
sorry to hear that. I hope the advice on the Rudel page is of some help. Otherwise feel free to ask here or visit the #rudel IRC channel.
Good luck. --JanMoringen
I’m sorry to be such a pain, Jan, but I can’t figure out why rudel won’t work. I’ve never had such a problem with an emacs package in my 14 years of using emacs. Not blaming you, it’s just bloody mystifying!
I compiled a version of the latest snapshot (emacs18.104.22.168) I replaced rudel with the latest version you’ve updated over at git (latest dated files are 6/5); and rudel acts like it can’t find eieio, or some other package that it needs. I’ve tried installing the CVS version of cedet and forcing the cedet load-path, both in my local
.emacs and by editing your
compile.el Nothing changes the errors.
This just can't be that hard, but I can’t think of anything else to try!
Michael, don’t say that. Actually, I’m feeling like causing you a lot of pain, not the other way around. However, I wouldn’t blame myself either, nor Eric, the Emacs developers or Canonical. These kinds of errors are so hard to prevent/figure out. For example, I often have problems compiling CEDET despite being a regular contributor and knowing the code quite well. It seems to me like the way compilation and dependencies work in Emacs is just very error prone.
I actually use the same setup: latest Emacs snapshot and CEDET from CVS. Regarding this error, I’m out of ideas as well.
You can try and disable line 82 in
rudel-compile.el (where byte-recompile-directory is called). Maybe you can at least generate the autoloads in
Thanks Jan. And my last class in coding was fortan in 1978. So I’m really in trouble.
Yeah, that allows the
rudel-compile.el to generate, but it doesn’t solve the eieio problem:
Debugger entered--Lisp error: (void-function eieio-defclass-autoload)
And so everything else that extends from that, preventing rudel from running. I also notice that
speedbar isn’t loading, even though I tell it too in my
;; Load speedbar (define-key-after (lookup-key global-map [menu-bar tools]) [speedbar] '("Speedbar" . speedbar-frame-mode) [calendar])
Doesn’t generate any errors, it simply doesn’t exist. Another indication that neither the CVS version of CEDET nor the one incluced in emacs24 is being found and/or used by the build. (Had the same problem with emacs23, BTW.)
Just for grins, I also added a path load to CEDET, to see if that would change something:
(add-to-list 'load-path "../cedet/") (load-file "/usr/share/emacs/site-lisp/rudel/rudel-loaddefs.el")
As usual, it didn’t change anything, which is the most mystifying part of this. No matter how I try to get CEDET (either the in included one or the CVS version, I don’t care which) to be “found” and included, nothing I try seems to make a difference.
P.S. I’ve been keeping the #rudel channel up, just in case.