Bill Clementson's Blog

Dynamically Edit/Debug Lisp Web Apps with SLIME

Wednesday, June 8, 2005

I discussed a while back some of the different CL Web Server Options that are available. I've also discussed how it is possible to dynamically change running Lisp code (see postings here, here, here). Well, there has recently been a nice exchange on c.l.l. where Marco Baringer described how SLIME can be used to edit/debug remote web apps. Here is a (slightly edited) copy of the discussion:

Ulrich Hobelmann: I have two questions:

1. How do I run a Lisp on a remote server (Debian), where I have a normal user SSH account (CLISP, possibly SBCL or CMUCL)? I read that SLIME is supposed to be able to run as a server, but does this include security, so that no other local user or guy on the Internet can connect to the SLIME, only me over SSH or SSL?
2. If I run a Lisp webserver, such as PortableAserve or Araneida, maybe with multiple threads, how can I debug it (i.e. - catch bad conditions/errors etc.)? I only read a Paul Graham article once where he mentioned that it's nice to have people make your web app crash and you are sitting right at the debugger :)

Marco Baringer:

1. SWANK (the name for SLIME's server) binds a local port, so you can't connect to it from anywhere. This, combined with an SSH tunnel and detachtty is a perfect setup. SWANK does the Lisp stuff, detacchtty does whatever-you-call-what-detacchtty-does and SSH keeps it all nice and encrypted. (you may still have issues with other local users connecting to your socket though).
2. Here's a brief overview of SLIME's important features as far as web apps go:
   1. The function slime-list-threads gives you a buffer listing of all the active threads. You can attach a debugger or a REPL to any (or many) of them.
   2. If you set *debugger-hook* to swank:swank-debugger-hook, then any bug in any thread opens up an SLDB buffer. Note that swank-debugger-hook returns if there's no SLIME connection, so you can let your regular error handling deal with things when you're debugging and SLIME automagically kicks in when you're connected to it.
   3. There are some hooks in place to make C-c C-k (slime-compile-and-load-file) and C-c C-l (slime-load-file) work across different file systems. NB: this is, AFAIK, a little used feature and may or may not be production-ready yet. (Note: One of the problems when working with remote files is that you need to be able to translate between file locations in the different file systems. Zach Beane points out that the SLIME custom variables "slime-translate-from-lisp-filename-function" and "slime-translate-to-lisp-filename-function" make this fairly straightforward.)
   4. Since SLIME can (and is) run as a remote server you don't need anything other than a few Lisp files on the remote server (no big Emacs or X11 install) even if you develop inside a big, convenient, customized emacs.
   Finally, if you're developing a web app, SLIME provides a nice and portable interface to the Lisp's debugging and introspection features (this is the only reason UCW has an inspectable backtrace error page).