Howdy,
I just checked in some incompatible changes to the backend interface. I've only updated the CMUCL backend so far, and I'm hoping to fix SBCL (and maybe LispWorks) this evening. Backend hackers please join in :-). The ChangeLog gives the gist, and diff'ing swank-cmucl.lisp against FAIRLY-STABLE will show how the CMUCL backend was updated.
Everyone else might want to stick to FAIRLY-STABLE (just updated) for a day or two 'til the dust settles.
The basic change is to move most of the protocol logic into portable code. Now the backends provide a generic callback-based TCP server interface which is used by swank.lisp to implement the basic protocol, parts of I/O redirection, and the dedicated output channel. Hopefully it also buys enough generality that multithreading experiments can go forward without breaking backends again.
It should be mostly a matter of deleting code and adapting what remains. The new interfaces are documented in swank-backend.lisp.
Questions & flames welcome :-)
Cheers, Luke
I've updated SBCL to work again, and also the gray-streams code on the way through. The MAKE-FN-STREAMS method from swank-sbcl.lisp should work verbatim in other gray-streams backends.
Having a stab at LispWorks now.
-Luke
Luke Gorrie luke@bluetail.com writes:
Questions & flames welcome :-)
I've a question about the 'background' arguments to create-socket-server. The new open-dedicated-output-stream sets :handle-background to t which causes some complications. CLISP has no threads and AFAIK no SERVE-EVENT, so everything that runs in background is quite difficult to implement there. Most other implementations don't have SERVER-EVENT and we would need 2 threads (messy with signal handling) just to setup the connection. Wouldn't it be nicer if we could, at least optionally, do everything without threads? That was possible until now, so it's probably just a matter of reorganizing open-dedicated-output-stream.
Helmut.
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Luke Gorrie luke@bluetail.com writes:
Questions & flames welcome :-)
I've a question about the 'background' arguments to create-socket-server. The new open-dedicated-output-stream sets :handle-background to t which causes some complications. CLISP has no threads and AFAIK no SERVE-EVENT, so everything that runs in background is quite difficult to implement there. Most other implementations don't have SERVER-EVENT and we would need 2 threads (messy with signal handling) just to setup the connection. Wouldn't it be nicer if we could, at least optionally, do everything without threads? That was possible until now, so it's probably just a matter of reorganizing open-dedicated-output-stream.
Right. How about this: remove the :handle-background argument and allow the :init-fn to return NIL, meaning "I don't expect any input".
Then the dedicated-stream's INIT-FN can return NIL to avoid an endless loop. Sound like it would work?
I hadn't realised how much variation there is across Lisp networking interfaces when I defined that interface.
BTW, do you know a way to run LispWorks Personal Edition without the GUI? It's driving me nuts :-)
-Luke
Luke Gorrie luke@bluetail.com writes:
Right. How about this: remove the :handle-background argument and allow the :init-fn to return NIL, meaning "I don't expect any input".
Then the dedicated-stream's INIT-FN can return NIL to avoid an endless loop. Sound like it would work?
Maybe :) What about a function that corresponds to socket/listen/accept and returns a lisp stream? It seems that could be implemented in all implementations. Perhaps with an announce callback for bootstrapping.
I hadn't realised how much variation there is across Lisp networking interfaces when I defined that interface.
Yeah it's annoying.
BTW, do you know a way to run LispWorks Personal Edition without the GUI? It's driving me nuts :-)
I've a "creative" config file with a #. macro that gives you a listener in the tty. You still get the GUI with annoying popup windows, though. Add the following to ~/.lispworks-config/4.3/Environment/LISPWORKS-TOOLS/LISTENER/.values:
;; -*- lisp -*-
#.(progn (format t "~%; Lispworks init hack in ~A~%" *load-truename*) (load "/home/helmut/.lispworks"))
(("Window Positions:1024x768" (373 98 650 500)))
Any other config file in this directory should work too. Then make this file read-only, so that Lispworks cannot overwrite it on the next exit. And in ~/.lispworks:
(mp:initialize-multiprocessing) (mp:process-run-function "TTY Listener" () #'system::listener-top-level *terminal-io*)
I also rename/delete /usr/local/lib/LispWorksPersonal/lib/4-3-0-0/app-defaults/Lispworks, so that I get the default motif colors. I cannot stand Lispworks color scheme. I'm always impressed how amazingly badly configured Lispworks demo version is :-)
Helmut.
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Maybe :) What about a function that corresponds to socket/listen/accept and returns a lisp stream? It seems that could be implemented in all implementations. Perhaps with an announce callback for bootstrapping.
Okay, you have talked some sense into me. I had assumed all Lisps would have socket interfaces similar to CMUCL/serve-event. Oops.
I re-replaced the socket interface with a much simpler one. I've re-ported CMUCL and SBCL, also LispWorks but without the dedicated output channel sofar. I also updated the CLISP backend, but haven't tested it! I seem incapable of building and installing a recent version of CLISP, I end up with this funky stuff:
luke@dodo:~/src/clisp-2.32/src$ ls -l full total 40 lrwxr-xr-x 1 luke foo 81 Jan 13 05:12 libavcall.a -> /home/luke/src/clisp-2.32/src/base?/home/luke/src/clisp-2.32/src/base/libavcall.a lrwxr-xr-x 1 luke foo 83 Jan 13 05:12 libcallback.a -> /home/luke/src/clisp-2.32/src/base?/home/luke/src/clisp-2.32/src/base/libcallback.a
which then fails to install.
Cheers, Luke
Luke Gorrie luke@bluetail.com writes:
I also updated the CLISP backend, but haven't tested it! I seem incapable of building and installing a recent version of CLISP, I end up with this funky stuff: [...] which then fails to install.
Perhaps, try to build in a separate directory
./configure [options] build-dir
The CLISP backend works fine, at least with *use-dedicated-output-stream* set to t. Running the test suite a couple of times gives 10 failed tests of 23, as before. There's a problem with slime-disconnect, though.
With *use-dedicated-output-stream* set to nil, it seems that SLIME doesn't come back to idle state at the end of the test suite.
Wolfgang
Luke Gorrie luke@bluetail.com writes:
Okay, you have talked some sense into me. I had assumed all Lisps would have socket interfaces similar to CMUCL/serve-event. Oops.
I did the next round of refactoring. It turned out that all backends, with the exception of Lispworks, have indeed a very similar socket interface. I used some internal Lispworks functions to implement the same interface there. There are now more, but simpler functions. The interface also includes 'add-input-handler' and a function to spawn new processes. The idea is that the "start server in background" logic can be implemented in swank.lisp, but that's not done yet. All backends are currently simple sequential servers.
I re-replaced the socket interface with a much simpler one. I've re-ported CMUCL and SBCL, also LispWorks but without the dedicated output channel sofar. I also updated the CLISP backend, but haven't tested it! I seem incapable of building and installing a recent version of CLISP, I end up with this funky stuff:
When I install CLISP 2.32, I did something like this:
- install libsigsegv - create a directory 'build' - run 'configure build' - 'cd build' - './makemake --with-dynamic-ffi --with-nogettext --without-unicode --with-module=bindings/glibc --with-module=regexp --with-module=syscalls > Makefile' - make config.lisp - make - make check - make install
Helmut.
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
I did the next round of refactoring. It turned out that all backends, with the exception of Lispworks, have indeed a very similar socket interface.
Nice! This could be useful outside SLIME too.
Luke Gorrie writes:
BTW, do you know a way to run LispWorks Personal Edition without the GUI? It's driving me nuts :-)
I seem to have heard that this would involve dumping an image, which is disabled in the Personal Edition.
Paolo
Paolo Amoroso amoroso@mclink.it writes:
Luke Gorrie writes:
BTW, do you know a way to run LispWorks Personal Edition without the GUI? It's driving me nuts :-)
I seem to have heard that this would involve dumping an image, which is disabled in the Personal Edition.
seems right.
however: if you can do whatever you want to do without ever touching the GUI (and I guess you can, or else you wouldn't want it to go away?), you can run LW with DISPLAY pointing at an Xvfb instance (under Debian, install the package "xvfb").
-
Helmut Eller -
Luke Gorrie -
Michael Livshin -
Paolo Amoroso -
Wolfgang Jenkner