[slime-devel] Halp, slime isn't working any more (for me)
Hello all, I have somehow completely broked my slime or emacs. After doing M-x slime the *inferior-lisp* buffer is left on display and in minibuffer it says "Connecting to Swank on port NNNN..", but it doesn't proceed from there. I can do M-x slime-repl which will give me a *slime-repl nil* but then it refuses to show the arglist of functions. Since this is the other major feature of slime for me (the other being autocompletion, which works), I'd like to get it back. Any hints? I'm also missing the cheezy animation at start-up ... Taneli
* T Taneli Vahakangas [2007-08-27 23:31+0200] writes:
Hello all,
I have somehow completely broked my slime or emacs. After doing M-x slime the *inferior-lisp* buffer is left on display and in minibuffer it says "Connecting to Swank on port NNNN..", but it doesn't proceed from there. I can do M-x slime-repl which will give me a *slime-repl nil* but then it refuses to show the arglist of functions. Since this is the other major feature of slime for me (the other being autocompletion, which works), I'd like to get it back. Any hints?
Have you tried to delete everything in ~/.slime/fasl before restarting? That helps sometimes. If it doesn't help, can you post the content of the *inferior-lisp*, *slime-events*, and the last part of the *messages* buffer? Helmut.
On Tue, Aug 28, 2007 at 10:50:08PM +0200, Helmut Eller wrote:
* T Taneli Vahakangas [2007-08-27 23:31+0200] writes:
Hello all,
I have somehow completely broked my slime or emacs. After doing M-x slime the *inferior-lisp* buffer is left on display and in minibuffer it says "Connecting to Swank on port NNNN..", but it doesn't proceed from there. I can do M-x slime-repl which will give me a *slime-repl nil* but then it refuses to show the arglist of functions. Since this is the other major feature of slime for me (the other being autocompletion, which works), I'd like to get it back. Any hints?
Have you tried to delete everything in ~/.slime/fasl before restarting? That helps sometimes.
Yes, currently I'm doing that after every cvs update, and also cleaned up ${SBCL_HOME} for good measure ... probably not necessary but I'm a little desperate.
If it doesn't help, can you post the content of the *inferior-lisp*, *slime-events*, and the last part of the *messages* buffer?
Attached. They feature emacs22 from CVS, slime from CVS (just updated) and SBCL 1.0.7. It behaves the same with emacs23, slime-2.0 and SBCL git master from boinkor. Taneli
* T Taneli Vahakangas [2007-08-29 09:53+0200] writes:
Attached. They feature emacs22 from CVS, slime from CVS (just updated) and SBCL 1.0.7. It behaves the same with emacs23, slime-2.0 and SBCL git master from boinkor.
Hmm... nothing unusual in the logs. Could you try a different communication style? E.g. create a file ~/.swank.lisp with (setq swank:*communication-style* nil). Does somebody else see this problem? Helmut.
On Wed, Aug 29, 2007 at 10:14:32AM +0200, Helmut Eller wrote:
* T Taneli Vahakangas [2007-08-29 09:53+0200] writes:
Attached. They feature emacs22 from CVS, slime from CVS (just updated) and SBCL 1.0.7. It behaves the same with emacs23, slime-2.0 and SBCL git master from boinkor.
Hmm... nothing unusual in the logs. Could you try a different communication style? E.g. create a file ~/.swank.lisp with (setq swank:*communication-style* nil).
That results in: 1) SBCL REPL prompt (the asterisk) doesn't show up in *inferior-lisp* and it doesn't accept input, 2) *slime-repl nil* just pipelines requests but doesn't get answers. Maybe this was expected. :sigio and :fd-handler work the same way as the default (which I gather is :spawn since I have :sb-thread enabled in sbcl build). Taneli
T Taneli Vahakangas <vahakang@cs.helsinki.fi> writes:
Hello all,
I have somehow completely broked my slime or emacs. After doing M-x slime the *inferior-lisp* buffer is left on display and in minibuffer it says "Connecting to Swank on port NNNN..", but it doesn't proceed from there.
Some chap on #lisp just reported the following: (01:07:03) hnaz: hm. emacs-23.0.50 + slime-cvs + sbcl-1.0.8.19 + linux-2.6.23-rc4 won't work together (01:07:28) hnaz: hangs at `Connecting to swank on port 23...' (01:07:50) hnaz: the sbcl is up and running, it evaluates expressions, but the repl won't come up (01:08:18) hnaz: running the same software on linux-2.6.22.1 works fine. This sounds a lot like your issue. If really so, could you try a different kernel version, please? -T.
On Fri, Aug 31, 2007 at 01:26:14AM +0200, Tobias C. Rittweiler wrote:
T Taneli Vahakangas <vahakang@cs.helsinki.fi> writes:
Hello all,
I have somehow completely broked my slime or emacs. After doing M-x slime the *inferior-lisp* buffer is left on display and in minibuffer it says "Connecting to Swank on port NNNN..", but it doesn't proceed from there.
Some chap on #lisp just reported the following:
(01:07:03) hnaz: hm. emacs-23.0.50 + slime-cvs + sbcl-1.0.8.19 + linux-2.6.23-rc4 won't work together (01:07:28) hnaz: hangs at `Connecting to swank on port 23...' (01:07:50) hnaz: the sbcl is up and running, it evaluates expressions, but the repl won't come up (01:08:18) hnaz: running the same software on linux-2.6.22.1 works fine.
This sounds a lot like your issue. If really so, could you try a different kernel version, please?
This is the bug! I can confirm that 2.6.21-ish kernel works ok, while 2.6.23-rc3 fails. Many thanks Tobias! Now I'm curious why is that ... let's see if hnaz is still on #lisp Taneli
On Fri, Aug 31, 2007 at 01:39:18PM +0300, T Taneli Vahakangas wrote:
On Fri, Aug 31, 2007 at 01:26:14AM +0200, Tobias C. Rittweiler wrote: [snip]
This sounds a lot like your issue. If really so, could you try a different kernel version, please?
This is the bug! I can confirm that 2.6.21-ish kernel works ok, while 2.6.23-rc3 fails. Many thanks Tobias!
The guilty commit to the kernel is: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif... (found by bisecting) Currently I don't have time to investigate further, so I'm just dumping this on the list, hoping that somebody else will take a look. The kernel patch makes slight changes to how /proc files are accessed, why would that have any effect on slime or sbcl? Mysterious. Taneli
* T Taneli Vahakangas [2007-09-03 00:17+0200] writes:
Currently I don't have time to investigate further, so I'm just dumping this on the list, hoping that somebody else will take a look. The kernel patch makes slight changes to how /proc files are accessed, why would that have any effect on slime or sbcl?
Slime calls (unnecessarily) MACHINE-VERSION, which seems to open /proc/cpuinfo in SBCL. Helmut.
On Mon, Sep 03, 2007 at 12:57:48PM +0200, Helmut Eller wrote:
* T Taneli Vahakangas [2007-09-03 00:17+0200] writes:
Currently I don't have time to investigate further, so I'm just dumping this on the list, hoping that somebody else will take a look. The kernel patch makes slight changes to how /proc files are accessed, why would that have any effect on slime or sbcl?
Slime calls (unnecessarily) MACHINE-VERSION, which seems to open /proc/cpuinfo in SBCL.
Thanks, Helmut, for the info. In the end, I contacted Alexey Dobriyan who introduced the bug ;) and now fixed it with the kernel patch that follows. It applies cleanly at least against 2.6.23-rc5. Taneli --- a/fs/proc/inode.c +++ b/fs/proc/inode.c @@ -11,6 +11,7 @@ #include <linux/string.h> #include <linux/stat.h> #include <linux/completion.h> +#include <linux/poll.h> #include <linux/file.h> #include <linux/limits.h> #include <linux/init.h> @@ -232,7 +233,7 @@ static ssize_t proc_reg_write(struct file *file, const char __user *buf, size_t static unsigned int proc_reg_poll(struct file *file, struct poll_table_struct *pts) { struct proc_dir_entry *pde = PDE(file->f_path.dentry->d_inode); - unsigned int rv = 0; + unsigned int rv = POLLIN | POLLOUT | POLLRDNORM | POLLWRNORM; unsigned int (*poll)(struct file *, struct poll_table_struct *); spin_lock(&pde->pde_unload_lock);
T Taneli Vahakangas <vahakang@cs.helsinki.fi> writes:
Thanks, Helmut, for the info. In the end, I contacted Alexey Dobriyan who introduced the bug ;) and now fixed it with the kernel patch that follows. It applies cleanly at least against 2.6.23-rc5.
The patch was just posted to LKML by A. Dobriyan: http://marc.info/?l=linux-kernel&m=118901508115279&w=2 Thanks to him, and Taneli for taking care about this issue. -T.
participants (3)
-
Helmut Eller -
T Taneli Vahakangas -
Tobias C. Rittweiler