Re: Problems with M-x slime-disconnect

>  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 :(

Just use:

(swank:create-server :port 4005 :dont-close t)

That should fix it.
  Ignas Mikalajūnas

>  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 :(

Just use:

(swank:create-server :port 4005 :dont-close t)

That should fix it.
  Ignas Mikalajūnas

[patch] closing connections with :fd-handler style

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.

Attached is the patch.

--

-- 
Stephen Compall
http://scompall.nocandysoftware.com/blog

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

Re: [patch] closing connections with :fd-handler style

On 12/1/05, Alexis Rondeau <alexis.rondeau <at> gmail.com> wrote:
>
>
>
> On 12/1/05, Stephen Compall <s11 <at> 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)

Re: [patch] closing connections with :fd-handler style

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.

Patch for slime-load-file

Any objections to this proposed change?  (BTW, what's the rationale of
stripping the filename extension here?)

2005-12-02  Matthias Koeppe  <mkoeppe <at> mail.math.uni-magdeburg.de>

	* slime.el (slime-load-file): Strip the extension from the file
	name of the current buffer only if it is ".lisp".  Much more
	convenient when you try to load the .asd file in the current
	buffer. 

--- slime.el.~1.566.~	2005-12-01 13:32:54.000000000 +0100
+++ slime.el	2005-12-02 16:37:38.678149000 +0100
 <at>  <at>  -6520,9 +6520,13  <at>  <at> 
   (interactive (list 
 		(read-file-name "Load file: " nil nil
 				nil (if (buffer-file-name)
-                                        (file-name-sans-extension
-                                         (file-name-nondirectory 
-                                          (buffer-file-name)))))))
+                                        (let ((file-name 
+                                               (file-name-nondirectory 
+                                                (buffer-file-name))))
+                                          (if (string= (file-name-extension file-name)
+                                                       "lisp")
+                                              (file-name-sans-extension file-name)
+                                            file-name))))))
   (let ((lisp-filename (slime-to-lisp-filename (expand-file-name filename))))
     (slime-eval-with-transcript `(swank:load-file ,lisp-filename))))

--

-- 

Re: Patch for slime-load-file

* Matthias Koeppe [2005-12-02 16:42+0100] writes:

> Any objections to this proposed change?

I would very much appreciate if you could rewrite so that it needs
less than 80 columns.

>  (BTW, what's the rationale of
> stripping the filename extension here?)

Without the extension it's possible to load fasl files with the same
command, just as you can load fasl files with CL:LOAD.

Re: Patch for slime-load-file

On Fri, 02 Dec 2005 16:42:16 +0100, Matthias Koeppe <mkoeppe+slime <at> mail.math.uni-magdeburg.de> wrote:

> +                                          (if (string= (file-name-extension file-name)
> +                                                       "lisp")

Lisp source files sometimes also have the extension "cl" or "lsp".

Cheers,
Edi.

Has anyone thought about implementing this?

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 <at> 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.

XEmacs-nomule, slime cvs 20051202, sbcl 0.9.7

Hi.  I'm having trouble with the above configuration.  I saw this thread:

http://article.gmane.org/gmane.lisp.slime.devel/4367
http://article.gmane.org/gmane.lisp.slime.devel/4368

that looks like it might be the same or a related problem.  I'm not really
sure.  Looked around the mailing list, did some web searching, I don't think 
this is a duplicate report.

Anyway, if I try to M-x slime with XEmacs-nomule (which is what I normally use)
I get:

Invalid slime-net-coding-system: nil. (iso-latin-1-unix iso-8859-1-unix bina

(cuts off, I don't know how to read more of the minibuffer) as an error.

If I try the mule version, which my distribution packages, I get a segmentation
fault from XEmacs (this, of course, is probably better reported as an XEmacs
bug, which I'm planning on doing.)

This is XEmacs 21.4.17 with slime cvs 20051202 and sbcl 0.9.7.  This is my 
first time trying to start things up.  (That is to say, I had no working
previous configuration.)

I really don't know what to make of this, but here's what I get if I try it 
after setting debug-on-error to t:

Debugger entered--Lisp error: (error "Invalid slime-net-coding-system: nil. (iso-latin-1-unix
iso-8859-1-unix binary utf-8-unix emacs-mule-unix euc-jp-unix)")
  signal(error ("Invalid slime-net-coding-system: nil. (iso-latin-1-unix iso-8859-1-unix binary

Re: Patch for slime-load-file

Helmut Eller <heller <at> common-lisp.net> writes:

> * Matthias Koeppe [2005-12-02 16:42+0100] writes:
>
>> Any objections to this proposed change?
>> (BTW, what's the rationale of stripping the filename extension
>> here?)
> Without the extension it's possible to load fasl files with the same
> command, just as you can load fasl files with CL:LOAD.

I see, this is what I suspected.  As Edi Weitz pointed out, the
various Lisp implementations use several default source extensions, so
it is not easy to decide which source file can be loaded without
specifying the extension.  Therefore, I have revised my approach to
improve slime-load-file.  What do you think of this change?  

2005-12-03  Matthias Koeppe  <mkoeppe <at> mail.math.uni-magdeburg.de>

	* slime.el (slime-load-file):  Load the FASL file if it exists.   
	Offer to recompile it if FASL file exists but is not current.
	Don't try to use or update FASL files of .asd files (using
	slime-load-file-no-compile-regexps), since .asd files are never
	compiled and often there exists a .lisp file with the same name. 
	(slime-load-file-no-compile-regexps): New variable.

--- slime.el.~1.566.~	2005-12-01 13:32:54.000000000 +0100
+++ slime.el	2005-12-03 20:06:52.667146000 +0100
 <at>  <at>  -6515,18 +6515,47  <at>  <at> 
   (slime-eval-async `(swank:undefine-function ,symbol-name)
                     (lambda (result) (message "%s" result))))