Invalid byte code in Emacs 24.1.50

[agentultra]

The full error is:

hyperspec-lookup: Invalid byte code in /usr/share/emacs/24.1.50/lisp/emacs-lisp/cl-extra.elc

I installed from quicklisp on Ubuntu 11.10 using a recently compiled SBCL 1.0.56 and am obviously running Emacs 24.1.50

I've also moved the ~/quicklisp path to ~/Libraries/quicklisp if that helps any.

[Hexstream]

Hello,

I have some guesses, and we could try some workarounds blindly, but it would be better to just have a look at the full backtrace.

Please use (setq debug-on-error t) to enable the debugger, and then trigger the error again. This should give you a full backtrace that you can paste here. If the error happens while loading Emacs (more specifically, your .emacs init file), then you can just start Emacs with --debug-init instead.

I know that Emacs 24 has some new goodies like default lexical binding, and it's quite possible that I'm using an obsolete idiom or construct somewhere, because I'm an Emacs Lisp newb. (One thing I realize now is that in clhs-use-local.el I could have used defvar to declare variables, especially "user options".) That might trigger the bytecode bug. We'll need the full backtrace (at least) to tell for sure.

Note that all currently released versions of the clhs wrapper completely assume that the quicklisp directory is in the home directory. I haven't yet gotten to making that configurable, but I intend to do so relatively soon.

Meanwhile, a workaround would be to manually copy clhs-use-local.el into your quicklisp directory, and edit the "~/quicklisp/" path within to "~/Libraries/quicklisp/". You'll obviously also need to change the Emacs form in your init file to point to the correct location, but that has probably already been done. Alternatively, another workaround would be to put the quicklisp directory back into your home directory. ;) (This would at least help confirm if that's what triggers the bug.)

Hope this helps! I'll be waiting for that backtrace.

[agentultra]

I just tested it on GNU Emacs 24.1.50.1 and the issue has disappeared
oddly enough.

Thanks for the quick and thorough reply... I was just about to dig
into this with you when the package repository I'm following to get
snapshot updates released a new minor version (and I though, what the
heck?).

Bleeding edge packages do tend to break every once in a while... if
you want I can still checkout the previous minor release and reproduce
there.

Either way, thanks for a great package... I'm going to toy with
getting it to open in w3m tonight.

On Tue, Apr 24, 2012 at 3:13 PM, Jean-Philippe Paradis
reply@reply.github.com
wrote:

Hello,

I have some guesses, and we could try some workarounds blindly, but it would be better to just have a look at the full backtrace.

Please use (setq debug-on-error t) to enable the debugger, and then trigger the error again. This should give you a full backtrace that you can paste here. If the error happens while loading Emacs (more specifically, your .emacs init file), then you can just start Emacs with --debug-init instead.

I know that Emacs 24 has some new goodies like default lexical binding, and it's quite possible that I'm using an obsolete idiom or construct somewhere, because I'm an Emacs Lisp newb. (One thing I realize now is that in clhs-use-local.el I could have used defvar to declare variables, especially "user options".) That might trigger the bytecode bug. We'll need the full backtrace (at least) to tell for sure.

Note that all currently released versions of the clhs wrapper completely assume that the quicklisp directory is in the home directory. I haven't yet gotten to making that configurable, but I intend to do so relatively soon.

Meanwhile, a workaround would be to manually copy clhs-use-local.el into your quicklisp directory, and edit the "~/quicklisp/" path within to "~/Libraries/quicklisp/". You'll obviously also need to change the Emacs form in your init file to point to the correct location, but that has probably already been done. Alternatively, another workaround would be to put the quicklisp directory back into your home directory. ;)  (This would at least help confirm if that's what triggers the bug.)

Hope this helps! I'll be waiting for that backtrace.

---

Reply to this email directly or view it on GitHub:
#5 (comment)

[Hexstream]

So I guess that's an happy ending! (No need to investigate the previous minor release further.)

Support for w3m is not something I had thought about, maybe I could add instructions at the end of the README (with the other instructions for using another browser) for how to do it (probably not too hard to figure oneself, but I want this thing to become really user-friendly).