slime-devel December 2005

slime-devel@common-lisp.net

41 participants
46 discussions

[slime-devel] local variables lost in cmucl
by Giorgos Pontikakis 06 Dec '05

06 Dec '05

Hi, I'm using CMUCL 19c and Slime from CVS. I get this strange behaviour when I debug a lisp program: -- When I compile and load my files with the following: (dolist (i *source-files*) (declaim (optimize (speed 0) (space 0) (safety 3) (debug 3))) (compile-file (concatenate 'string i ".lisp"))) (dolist (i *source-files*) (declaim (optimize (speed 0) (space 0) (safety 3) (debug 3))) (load (concatenate 'string i ".x86f"))) I can use the 'v' command of the slime-debugger to see my source code, but I lose information for local variables -- When I just load the files using the following: (dolist (i *source-files*) (declaim (optimize (speed 0) (space 0) (safety 3) (debug 3))) (load (concatenate 'string i ".lisp"))) I have information for local variables, but the 'v' command of the debugger does not jump to the source code. Instead, it presents me with some representation of the code which I believe that is the interpreted one, and is much more difficult to use. Is there something that I'm doing wrong, or is it a limitation of slime? thank you very much Giorgos

2 3

[slime-devel] Daily ChangeLog diff
by lgorrie＠common-lisp.net 06 Dec '05

06 Dec '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.814 slime/ChangeLog:1.815 --- slime/ChangeLog:1.814 Tue Nov 22 21:44:14 2005 +++ slime/ChangeLog Mon Dec 5 21:20:43 2005 @@ -1,3 +1,8 @@ +2005-12-05 Helmut Eller <heller(a)common-lisp.net> + + * slime.el (slime-find-coding-system): Use check-coding-system + only if it's actually fbound. + 2005-11-22 Marco Monteiro <masmxx(a)gmail.com> * slime.el (slime-connect): Use slime-net-coding system if the

1 0

[slime-devel] Has anyone thought about implementing this?
by Fred Gilham 05 Dec '05

05 Dec '05

It seems to me that the ability to bring up new frames that act as typeout windows for the various standard streams would be useful. That is, it would be nice to be able to bring up a frame where all the stuff from the *debug-output* or *error-output* stream was sent. It might even be nice to be able to bring up a frame that manages *query-io* so that it doesn't get mixed in with the REPL. Has anyone thought of doing this? Would it be hard to do if someone wanted to try it as a first slime implementation project? Or is it already done as an undocumented feature? -- Fred Gilham gilham(a)csl.sri.com I'm skeptical about attempts to proclaim hell to people that don't already have the taste of it in their mouths. Hell as the ultimate loss of relationship, of health, of even sanity, makes sense to someone who already sees the beginnings of that process taking hold in his own life. Hell as an imaginary place that is like being sent to your room for a long, long time, with the heat turned up really high, doesn't make sense.

2 1

Re: [slime-devel] [patch] closing connections with :fd-handler style
by Stephen Compall 02 Dec '05

02 Dec '05

On Thu, 2005-12-01 at 09:26 +0000, Alexis Rondeau wrote: > Thank you for the patch, but still I get a new kind of error from sbcl > which brings me in the same situation. This patch affects only code used by :sigio and :fd-handler communication styles, not code used in the :spawn style. If you'd like to try the patch, please pass `:style :fd-handler' to create-server, which is the default on SBCL when threads are not available, or set *communication-style* to :fd-handler before creating a server. > Again, I can connect but on M-x slime-disconnect in emacs this happens > now > > * (swank:create-server :port 4005 :dont-close t) > ;; Swank started at port: 4005. > > 4005 > * ;; Connection to Emacs lost. > ;; [end of file on #<SB-SYS:FD-STREAM for "a constant > string" {985B171}>] > > debugger invoked on a SIMPLE-ERROR in thread #<THREAD > "auto-flush-thread" {9987D91}>: > #<SB-SYS:FD-STREAM for "a constant string" {985D5F1}> is closed. I am not experienced with SBCL, but the :spawn-style-related code seems to close the connections correctly. I am not sure how the "auto-flush-thread" is operating, but would be slow to blame it before something in the :spawn code. -- Stephen Compall http://scompall.nocandysoftware.com/blog

1 0

Re: [slime-devel] [patch] closing connections with :fd-handler style
by Alexis Rondeau 01 Dec '05

01 Dec '05

On 12/1/05, Alexis Rondeau <alexis.rondeau(a)gmail.com> wrote: > > > > On 12/1/05, Stephen Compall <s11(a)member.fsf.org> wrote: > > As far as I can tell, the only way a Swank connection object with > > style :fd-handler will ever be closed due to EOF (with > > close-connection) is if either the fd-handler implementation detects > > the EOF state and knows how to destroy Swank connections, or a > > condition is raised in the dynamic context of > > with-reader-error-handler. Looking at the topmost form > in that > > context, however, it can only happen if (listen socket) answers T, so > > that the attempt to read can proceed and raise an eof-error, which > > gets wrapped up, etc. > > > I modified process-available-input to test (listen socket) only after > > calling FN at least once; after all, it always returns T when the > > handler is called for a normal input state. Without this patch, my > > fd-handler backend gets into an endless loop calling the handler in > > install-fd-handler (with the :eof state); with this patch, the socket > > is closed, removed from *connections*, and from the fd-handler backend > > properly. > > Thank you for the patch, but still I get a new kind of error from sbcl > which brings me in the same situation. I removed my ~/.slime directory > before starting sbcl to make sure everything is reloaded and recompiled and > reinstalled my emacs21-*. Still this is what happens on the host-lisp: > > * (swank:create-server :port 4005 :dont-close t) > ;; Swank started at port: 4005. > > > * (swank:create-server :port 4005 :dont-close t) > ;; Swank started at port: 4005. > > 4005 > Again, I can connect but on M-x slime-disconnect in emacs this happens now > * ;; Connection to Emacs lost. > ;; [end of file on #<SB-SYS:FD-STREAM for "a constant string" {985B171}>] > > debugger invoked on a SIMPLE-ERROR in thread #<THREAD "auto-flush-thread" > {9987D91}>: > #<SB-SYS:FD-STREAM for "a constant string" {985D5F1}> is closed. > > > > Attached is the patch. > > I patched my file but still more or less the same problem. I am on a 2.6.11 > kernel here, could this mean something? > > > -- > > Stephen Compall > > http://scompall.nocandysoftware.com/blog > > Thank you Stephen for your time and effort! > > Alexis > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.2 (GNU/Linux) > > > > > iD8DBQBDjrinYWjD35Pp0wIRAg00AJ44yB7FIDcrx37iGKPKyGH8q+ZzdQCgm+XT > > eXy5zTXCNt99X91OkkpYB4k= > > =4/SK > > -----END PGP SIGNATURE----- > > > > > > _______________________________________________ > > slime-devel site list > > slime-devel(a)common-lisp.net > > http://common-lisp.net/mailman/listinfo/slime-devel > > > > > > > >

1 0

[slime-devel] Problems with M-x slime-disconnect
by Alexis Rondeau 01 Dec '05

01 Dec '05

Hi there, I have been wanting to try out to connect to a running sbcl (0.9.5 on sarge) lisp In my console, I startup slime (which I got from cvs today) and create the server: * (swank:create-server) ;; Swank started at port: 4005. 4005 This works fine. In my emacs I hit M-x slime-connect and after providing host and port, I am actually using the above started lisp. So far so good, but now the actual problem arises. Once I hit M-x slime-disconnect in Emacs I get the following error in my sbcl and cannot reconnect to the lisp: * ;; Connection to Emacs lost. ;; [end of file on #<SB-SYS:FD-STREAM for "a constant string" {AC56161}>] debugger invoked on a SIMPLE-ERROR in thread #<THREAD "auto-flush-thread" {AD822F1}>: #<SB-SYS:FD-STREAM for "a constant string" {AC5D1C1}> is closed. I have been searching all over the internet for a solution because this way I can not really work because I can only once connect to the lisp and not again. Can anyone give me a pointer on what I am doing wrong? I am totally stunned because I seem to be the only one that has this problem :( In any case, thank you for your help! Slime is working amazingly otherwise just this feature is really important to me. Alexis

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel December 2005