I'm having two issues with SLIME:
1. When using SLIME with CMUCL, GC operations have a tendency to
lock up SLIME in strange ways. For instance, if I start a fresh
SLIME with CMUCL, and then do two (gc :full t)'s or two
(room)'s, on the second one SLIME acts as if it's waiting for a
computation to finish, but just seems to hang. The CMUCL
process sticks around after I kill SLIME and uses a steady 50%
of CPU. This is happening on two different machines. If I
perform any kind of ASDF operation that triggers a GC, it will
also lock up. Any of these commands typed directly into a CMUCL
command line at the shell will succeed without any of these
problems. CMUCL 19a, latest CVS SLIME, recent CVS Emacs. Can
anyone reproduce this?
2. I am trying unsuccessfully to connect SLIME to a remote SBCL
image over an SSH tunnel. I have no problems using
slime-connect over a nonencrypted link. I open an SSH tunnel
with "ssh -L 4005:127.0.0.1:4005 myservername". I then
slime-connect to 4005 on 127.0.0.1. In SLIME I immediately get
"Lisp connection closed unexpectedly: connection broken by
remote peer" and the SSH session prints out "channel 3: open
failed: connect failed: Connection refused". I start Swank
before creating the tunnel. What am I doing wrong here?
Bill
From: Marco Baringer
Subject: Re: Two SLIME questions
Date:
Message-ID: <m2r747ys7d.fsf@bese.it>
Bill Atkins <············@rpi.edu> writes:
> 2. I am trying unsuccessfully to connect SLIME to a remote SBCL
> image over an SSH tunnel. I have no problems using
> slime-connect over a nonencrypted link. I open an SSH tunnel
> with "ssh -L 4005:127.0.0.1:4005 myservername". I then
> slime-connect to 4005 on 127.0.0.1. In SLIME I immediately get
> "Lisp connection closed unexpectedly: connection broken by
> remote peer" and the SSH session prints out "channel 3: open
> failed: connect failed: Connection refused". I start Swank
> before creating the tunnel. What am I doing wrong here?
slime uses a second socket to send the output of the various streams,
this is an optimization which the ssh tunnel breaks. do (setf
swank:*use-dedicated-output-stream* nil) on the remote lisp before
attempting to connect.
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
Marco Baringer <··@bese.it> writes:
> slime uses a second socket to send the output of the various streams,
> this is an optimization which the ssh tunnel breaks. do (setf
> swank:*use-dedicated-output-stream* nil) on the remote lisp before
> attempting to connect.
Thanks, that did it.
+ Bill Atkins <············@rpi.edu>:
| 1. When using SLIME with CMUCL, GC operations have a tendency to
| lock up SLIME in strange ways. [...]
| CMUCL 19a, latest CVS SLIME, recent CVS Emacs. Can
| anyone reproduce this?
Yes. This problem is what finally pushed me to upgrading to cmucl
19c. Haven't seen this sort of thing since. (And so I haven't
bothered to find out more about what went wrong earlier.)
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + Bill Atkins <············@rpi.edu>:
>
> | 1. When using SLIME with CMUCL, GC operations have a tendency to
> | lock up SLIME in strange ways. [...]
> | CMUCL 19a, latest CVS SLIME, recent CVS Emacs. Can
> | anyone reproduce this?
>
> Yes. This problem is what finally pushed me to upgrading to cmucl
> 19c. Haven't seen this sort of thing since. (And so I haven't
> bothered to find out more about what went wrong earlier.)
Thanks!