* David Lichteblau [2008-02-24 19:04+0100] writes:
I'm sorry my reproduction recipe doesn't work for you, but thank you for trying anyway.
Unfortunately I can reproduce this failure mode reliably using current clbuild from darcs, current slime from CVS, current SBCL from CVS, and emacs 22.1.1 as included with Debian on AMD 64.
Since clbuild doesn't read ~/.sbclrc by default, and emacs -q doesn't read ~/.emacs, I'm unsure which details of my environment would affect this problem.
There might be something in your ~/.swank.lisp. You can also try to remove ~/.slime/fasl/*.
What's the right way to do this with current slime?
Reading something like http://www.chiark.greenend.org.uk/~sgtatham/bugs.html would be a good start.
I'm looking for documentation explaining swank's behaviour when included in a core file, and details about how slime-backend needs to be set up to make this configuration work.
There is a section "Loading Swank faster" in the manual. It's not quite up-to-date but the basics are still the same. These days you need to call swank-loader:init. Also note, that swank-loader:init doesn't reload Swank if the package already exists, i.e. the same setup can be used if Swank is the core or not.
To build the core file, load up everything you need, like so:
$ sbcl # sbcl with a clean core cl-user> (load "swank-loader.lisp") cl-user> (swank-loader:init) ;; If you want to include contribs also do the following: ;; cl-user> (mapc #'swank::swank-require swank-loader::*contribs*) cl-user> (save-lisp-and-die "sbcl.core-with-swank")
For the Emacs side initialization, clbuild seems to set slime-backend to .../clbuild/.swank-loader.lisp. This works and it should also work if Swank isn't in the core. You could also create a setup like the one in the manual. E.g.
(setq slime-lisp-implementations '((clbuild (".../clbuild/clbuild" "preloaded") :init (lambda (file coding) (format "(swank:start-server %S :coding-system %S)\n" file (slime-coding-system-cl-name coding))))))
Helmut.