(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.
(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.
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.
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.
The Swank connection runs on a different thread, not on a different server.