Helmut Eller e9626484@stud3.tuwien.ac.at writes:

CREATE-SWANK-SERVER has also a DONT-CLOSE argument to keep the socket open.

For the record, it looks like DONT-CLOSE is respected only if the STYLE argument is :spawn. Also of note: The :spawn style is not supported by all backends.

Helmut Eller e9626484@stud3.tuwien.ac.at writes:

Fixed in CVS.

Looking at swank::setup-server, I'm not sure that passing DONT-CLOSE through will make any difference for styles different from :spawn.

The :spawn style enables serve-connection to be called in a loop. Keeping the server socket open has the advantage of being able to serve more than one connection serially through the same server socket.

If the style is not :spawn, serve-connection will only be called once. Keeping the server socket open after that one connection gets serviced won't help any subsequent operations.

Perhaps we should loop over several serial connections when DONT-CLOSE is non-nil, even if we can't spawn a separate thread or process to handle a particular connection. Here is an version, untested for the :spawn case for lack of a suitable Lisp implementation here:

(defun setup-server (port announce-fn style dont-close) (declare (type function announce-fn)) (let* ((socket (create-socket *loopback-interface* port)) (port (local-port socket))) (funcall announce-fn port) (flet ((serve () (serve-connection socket style dont-close))) (let ((serve-function (if dont-close #'(lambda () (loop do (serve))) #'serve))) (case style (:spawn (spawn serve-function :name "Swank")) (otherwise (funcall serve-function))))) port))

To summarize, we loop if DONT-CLOSE is non-nil, serve a single connection otherwise; spawn if STYLE is :spawn, make a normal call otherwise.

If you don't agree with the idea of looping even when STYLE is not :spawn, then I recommend reverting the DONT-CLOSE pass-through change to make the DONT-CLOSE option irrelevant in the non-:spawn cases.

"Steven E. Harris" seharris@raytheon.com writes:

If the style is not :spawn, serve-connection will only be called once. Keeping the server socket open after that one connection gets serviced won't help any subsequent operations.

Are you sure? The current CVS version looks like this:

(defun setup-server (port announce-fn style dont-close) (declare (type function announce-fn)) (let* ((socket (create-socket *loopback-interface* port)) (port (local-port socket))) (funcall announce-fn port) (ecase style (:spawn (spawn (lambda () (loop do (serve-connection socket :spawn dont-close) while dont-close)) :name "Swank")) ((:fd-handler :sigio) (add-fd-handler socket (lambda () (serve-connection socket style dont-close)))) ((nil) (unwind-protect (loop do (serve-connection socket style dont-close) while dont-close) (close-socket socket)))) port))

For style=NIL we loop and subsequent connections are served sequentially. I install an fd-handler for both :sigio and :fd-handler, because it didn't seems necessary to do signal driven io on the server socket. I didn't test it extensively, but I fail to see why this version can't handle multiple connections.

Helmut.

"Steven E. Harris" seharris@raytheon.com writes:

Sorry for posting an outdated patch. Moving forward, I'll have to set up a CVS sandbox against the the head for these kinds of proposals.

I'd recommend using the HEAD instead of FAIRLY-STABLE in daily usage since you read the list. HEAD tends to work better overall.

Historically we've set FAIRLY-STABLE right before major rewrites that are likely to break things. It meant "FAIRLY-STABLE compared with how it will be for the next few days". Lately we aren't doing much rewriting so the tag isn't getting moved very often.

For now I just moved FAIRLY-STABLE from March 8 onto the current code in HEAD so there're a bunch of new goodies (like REPL shortcuts) in there.

-Luke

"Steven E. Harris" seharris@raytheon.com writes:

I just updated this morning, and found another new goodie: SLIME is dead in the water with CLISP, so now I'm stuck. Now, that doesn't seem to be "fairly stable" to me. Can the tag be backed up, or can you perhaps post a CVS recipe to pull the previous FAIRLY-STABLE version out again?

You can see all tags with cvs status -v ChangeLog. Currently FAIRLY-STABLE is the same as SLIME-0-12. To get the previous version just use SLIME-0-11.

I have been trying to figure out the CLISP problem for about an hour, but it would sure help to have a usable SLIME available to experiment with the cutting-edge version and its attendant problems.

I fixed the CLISP problem in CVS HEAD.

Helmut.

Marco Baringer mb@bese.it writes:

David Steuber david@david-steuber.com writes:

...

Anyone have any recipes for doing this? It seems like something that people would do.

run (swank:create-server 0) in the lisp image, this will return a port number (if you want a porticular port pass that to create-server instead of 0). Use M-x slime-connect to connect to that host and port, you'll need to set up an ssh tunnel if your doing this remotely and want it encrypted. the way things are currently structured the server created can only be used once, once you do a slime-disconnect you'll need to start a new serve in the app to be able to connect again.

Is there a way around this one connection limitation? So far, the only thing that worked for me was to run attachtty to get into my app and re-run (swank:create-server 4005) as you said. I don't know how to put this in a shell script which would make it a little better.

It would be very nice to be able to reuse the server connection. How hard would this be? What are the security implications of doing this? It seems that another user on the system can connect to a swank server.

It's not really feasable for me to remain connected all the time, otherwise I wouldn't worry about it. My current workflow is something like this:

ssh -X myserver

run this schell script:

#!/bin/sh

# # Start SBCL as a detachtty process and start listening to Apache #

rm /home/david/usr/var/run/* 2>/dev/null

export SBCL_HOME=/home/david/usr/lib/sbcl

/usr/bin/detachtty --dribble-file /home/david/usr/var/run/lisp-dribble \ --log-file /home/david/usr/var/run/detachtty.log \ --pid-file /home/david/usr/var/run/lisp.pid \ /home/david/usr/var/run/lisp-socket \ /home/david/usr/bin/sbcl \ --eval '(ml:modlisp-start :port 3000)' \ --eval '(swank:create-swank-server 4005)'

My SBCL has this in its sbclrc file:

(require :asdf) (require :asdf-install) (asdf:operate 'asdf:load-op 'modlisp) (asdf:operate 'asdf:load-op 'cl-ppcre) (asdf:operate 'asdf:load-op 'lml2) (asdf:operate 'asdf:load-op 'swank)

At this point, Apache can talk to my Lisp image. So far nothing interesting is done. I just have the mod_lisp debug page returned for any arbitrary request (well, at least GET requests).

I can also now start up Emacs and do M-x slime-connect. As you said, once I do M-x slime-disconnect, that is that.

I've also been sent this code by Tim Lavoie which I have in my .emacs file:

(defun slime-sbclremote () "connect to sbcl already running with detachtty" (interactive) (let ((inferior-lisp-program "attachtty /home/david/usr/var/run/lisp-socket") (coding-system-for-read 'us-ascii-dos)) (slime)))

It also is subject to a one time use limit once I do M-x slime-disconnect.

I don't get to use each of them once. It is either/or.

I expect that in the near term, what I have is good enough. It's not like I have to enter a running Lisp at any time to fix it. Not yet. Down the road, I can see that being a good thing to be able to do. If I knew how to do it right now, I would send a patch.

Helmut Eller e9626484@stud3.tuwien.ac.at writes:

David Steuber david@david-steuber.com writes:

...

Is there a way around this one connection limitation? So far, the only thing that worked for me was to run attachtty to get into my app and re-run (swank:create-server 4005) as you said. I don't know how to put this in a shell script which would make it a little better.

It would be very nice to be able to reuse the server connection. How hard would this be? What are the security implications of doing this? It seems that another user on the system can connect to a swank server.

Perhaps you haven't received or read my previous message in this thread. I already mentioned that the DONT-CLOSE argument to SWANK:CREATE-SWANK-SERVER can be used to keep the socket open. See also http://home.comcast.net/~bc19191/blog/040304.html

I missed it somehow. Sorry. But thanks for this reply. It is so nice to have a feature request that is already implemented.

The security implication is, that everybody who is able to connect to the swank socket can execute arbitrary in your Lisp.

I figured as much. I know that matters in many installations, but in my case that is not a big issue. Maybe someone who wants it can come up with some sort of authentication mechanism.

Thanks again.