Hacker News Reader

Comment by abhinav22 | Hacker News Reader

Would you be able to expand on this? I’m very basic when it comes to debugging in Lisp :)

So you are running a second server to test issues away from production? I thought this is possible in other languages / frameworks, so I must be missing something

I read the cook book but still didn’t get the main benefits of it. However the quote was very cool:

That’s how Ron Garret debugged the Deep Space 1 spacecraft from the earth in 1999:

We were able to debug and fix a race condition that had not shown up during ground testing. (Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem.

View on HN

You have your normal application, accessible on some port serving HTTP requests (or whatever). Then you start a thread (with `bt`, bordeaux-threads, a very common multi-threading library) and run a Swank server listening on some other port on it. Swank is the backend used by SLIME, it allows manipulation of the Lisp environment. A remote server is still the same Lisp environment as when you run it on your machine, so you can use Emacs to connect to it (M-x slime-connect) and debug live.

Swank doesn't allow remote connections though, otherwise anyone could connect and mess with your server. You must connect through the loopback interface. Easiest way is to set up an ssh tunnel, like: ssh abc@example.com -L 4200:localhost:4200

Whether you can call the Swank server a second server or not is a somewhat philosophical question I guess. There's one application serving different kinds of requests on different ports.

Does that mean the swank thread still gets all the inputs of the live process and you can debug in isolation there and then push changes to the main thread? Sorry if I’m stupid (no need to reply), I need to read into this more.

You don't need to "push changes to the main thread", you can mutate the state of the whole process during debugging, and in Lisp that includes compiling and loading new code that gets used immediately by whatever application you're trying to debug.

It's probably worth mentioning that you usually don't want to make changes in a live production environment, and even when you do, you probably want to capture those changes in a file as well, so that you have a record of what you did. It's possible to make arbitrary changes to a live, running system in Lisp with no other record of what changes you made, but it's not usually a good idea to do that.

This repo has an example of running hunchentoot with a swank server: https://github.com/vseloved/flight-recorder/blob/master/hunc...

> So you are running a second server to test issues away from production? I thought this is possible in other languages / frameworks, so I must be missing something

The Swank connection runs on a different thread, not on a different server.

Ah that might be able to help bridge the gap for me. I still don’t quite follow, but I guess having multiple threads allows for easier testing of the interface with other components, perhaps? Sorry I am out of my depth on this one. Will Google more tonight

Reply on news.ycombinator.com