3 ms·

I skimmed over the article, but I think it misses my favourite part: running a Swank server for live debugging! Something along the lines of: (bt:make-thread (

I skimmed over the article, but I think it misses my favourite part: running a Swank server for live debugging! Something along the lines of: (bt:make-thread (lambda () (swank:create-server :port port :dont-close t)) then connect with M-x slime-connect I've debugged many tricky to reproduce issues like this. Also it's just damn cool.

abhinav22 6y ago
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.
- kagevf 6y ago
  This repo has an example of running hunchentoot with a swank server: https://github.com/vseloved/flight-recorder/blob/master/hunch.lisp https://github.com/vseloved/flight-recorder/blob/master/hunc...
- dj_mc_merlin 6y ago
  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.
  - abhinav22 6y ago
    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.
    - jhgb 6y ago
      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.
      - mikelevins 6y ago
        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.
- jhgb 6y ago
  > 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.
  - abhinav22 6y ago
    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

abhinav22 6y ago

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.

kagevf 6y ago
This repo has an example of running hunchentoot with a swank server: https://github.com/vseloved/flight-recorder/blob/master/hunch.lisp https://github.com/vseloved/flight-recorder/blob/master/hunc...
dj_mc_merlin 6y ago
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.
- abhinav22 6y ago
  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.
  - jhgb 6y ago
    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.
    - mikelevins 6y ago
      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.
jhgb 6y ago
> 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.
- abhinav22 6y ago
  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