Hi,
I'm having trouble starting slime when swank is already in the core.
This is what I'm trying to do:
$ clbuild dumpcore slime $ echo 'START_SLIME_USING_CORE=42' >>clbuild.conf $ clbuild slime -nw -q
which used to work, but now I get this:
------------------------------------------------------------------------------- Control stack exhausted (no more space for function call frames). This is prob$ [Condition of type SB-KERNEL::CONTROL-STACK-EXHAUSTED]
Restarts: 0: [ABORT] Exit debugger, returning to top level.
Backtrace: 0: (SB-KERNEL::CONTROL-STACK-EXHAUSTED-ERROR) 1: ("foreign function: #x41FFA2") 2: ("foreign function: #x2B346806F000") 3: (READ-CHAR #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-STANDARD-INPUT* {204F0$ 4: (READ-CHAR #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-STANDARD-INPUT* {204F0$ ...
What's the right way to do this with current slime?
Thanks, David
* David Lichteblau [2008-02-23 16:40+0100] writes:
Hi,
I'm having trouble starting slime when swank is already in the core.
This is what I'm trying to do:
$ clbuild dumpcore slime $ echo 'START_SLIME_USING_CORE=42' >>clbuild.conf $ clbuild slime -nw -q
Seems to work for me.
[...]
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.
Helmut.
Quoting Helmut Eller (heller@common-lisp.net):
$ clbuild dumpcore slime $ echo 'START_SLIME_USING_CORE=42' >>clbuild.conf $ clbuild slime -nw -q
Seems to work for me.
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.
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.
d.
* 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.
Hi,
Quoting Helmut Eller (heller@common-lisp.net):
There might be something in your ~/.swank.lisp.
thank you, that was it. I'm using (setf swank:*globally-redirect-io* t) and that causes trouble in combination with the recent SWANK-LOADER::INIT changes.
Dumping a core file with *globally-redirect-io* worked before the new SWANK-LOADER::INIT was introduced, and it still worked for the brief time period where swank.asd was still unchanged.
The problem occurs since rev 1.6 of swank.asd, which runs SWANK-LOADER::INIT during compilation, and hence before saving the core file.
Reverting rev 1.6 fixes things for me. Not sure what the -right- solution is though.
Thanks for the help in debugging this, d.
* David Lichteblau [2008-02-25 00:48+0100] writes:
Hi,
Quoting Helmut Eller (heller@common-lisp.net):
There might be something in your ~/.swank.lisp.
thank you, that was it. I'm using (setf swank:*globally-redirect-io* t) and that causes trouble in combination with the recent SWANK-LOADER::INIT changes.
Dumping a core file with *globally-redirect-io* worked before the new SWANK-LOADER::INIT was introduced, and it still worked for the brief time period where swank.asd was still unchanged.
The problem occurs since rev 1.6 of swank.asd, which runs SWANK-LOADER::INIT during compilation, and hence before saving the core file.
Reverting rev 1.6 fixes things for me. Not sure what the -right- solution is though.
Hmm... Calling swank::revert-global-io-redirection before saving the core should work. Having separate compile, load, and init operations would probably be TRT. I don't know if ASDF supports that directly.
Helmut.
Quoting Helmut Eller (heller@common-lisp.net): [...]
Having separate compile, load, and init operations would probably be TRT. I don't know if ASDF supports that directly.
When another system depends on swank just in order to use some of the functions in the swank package, isn't it the right thing to skip initialization completely (hence postponing it until the emacs side starts up)?
Assuming that is the right approach, should SWANK::INIT be skipped entirely or only the after-init-hook?
Here is a patch skipping just the hook, which is enough to solve the issue with *globally-redirect-io*.
Thanks, d.
* David Lichteblau [2008-02-25 14:44+0100] writes:
Quoting Helmut Eller (heller@common-lisp.net): [...]
Having separate compile, load, and init operations would probably be TRT. I don't know if ASDF supports that directly.
When another system depends on swank just in order to use some of the functions in the swank package, isn't it the right thing to skip initialization completely (hence postponing it until the emacs side starts up)?
Assuming that is the right approach, should SWANK::INIT be skipped entirely or only the after-init-hook?
User init files should probably also be skipped.
Here is a patch skipping just the hook, which is enough to solve the issue with *globally-redirect-io*.
I committed something along these line. I named the parameter :setup instead of :run-hooks. INIT is now a rather confusing name for this function :-)
Helmut.
Helmut Eller heller@common-lisp.net writes:
I committed something along these line.
I checked out and started up a fresh Emacs, and I wasn't able to start SLIME: "Package SWANK not found". The patch below fixed it, but I don't claim I understand if it's the right fix or not. :)
Zach
Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.913 diff -u -r1.913 slime.el --- slime.el 24 Feb 2008 16:50:48 -0000 1.913 +++ slime.el 25 Feb 2008 19:03:58 -0000 @@ -1403,7 +1403,7 @@ (format "%S\n\n" `(progn (load ,(expand-file-name loader) :verbose t) - (funcall (read-from-string "swank-loader:init")) + (funcall (read-from-string "swank-loader:init") :setup t) (funcall (read-from-string "swank:start-server") ,port-filename :coding-system ,encoding)))))
* Zach Beane [2008-02-25 20:04+0100] writes:
I checked out and started up a fresh Emacs, and I wasn't able to start SLIME: "Package SWANK not found". The patch below fixed it, but I don't claim I understand if it's the right fix or not. :)
Funny that the patch made a difference, because :setup is t by default.
Does somebody else have startup problems with the current CVS version?
Helmut.
Helmut Eller heller@common-lisp.net writes:
- Zach Beane [2008-02-25 20:04+0100] writes:
I checked out and started up a fresh Emacs, and I wasn't able to start SLIME: "Package SWANK not found". The patch below fixed it, but I don't claim I understand if it's the right fix or not. :)
Funny that the patch made a difference, because :setup is t by default.
Does somebody else have startup problems with the current CVS version?
I can't reproduce the problem, now. Sorry for the misleading report.
Zach
-
David Lichteblau -
Helmut Eller -
Zach Beane