JanMoringen

Last edit

Summary: mention dbus-proxy and moped

Added:

> * [https://launchpad.net/~scymtym/+junk/dbus-proxy dbus-proxy] (initiator)
> * [https://launchpad.net/moped Moped] (initiator)


Contents

  1. About Me
  2. Talk

About Me

I use GNU Emacs: as an editor since 2003, as a religion since 2008

Projects:

Also known as: scymtym on #rudel on the freenode IRC network

Talk

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

Help?

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.

--Michael

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:

  • Is the tarball installed in /usr/share/emacs23/site-lisp/rudel/?
  • If not, where is it installed?
  • Did you remove or keep the Rudel Ubuntu package?
  • How is Rudel loaded in your initialization file?

Please also provide the complete contents of the *Messages* buffer if there is no confidential information in it.

Regarding ‘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? :> )

--Michael

Jan,

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.

Thanks!

--Michael

Hi Micheal,

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 (emacs24.0.50.1) 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

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 rudel-loaddefs.el then.

--JanMoringen

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 .emacs:

;; 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.

– Michael

P.S. I’ve been keeping the #rudel channel up, just in case. :)


CategoryHomepage