Well, back from GSOC, was a fun and busy weekend. Wish I would’ve slept, y’know… some, I was suboptimal 🙂 Incredibly fun, met some übergeeks, learned a fair bit.

Lisp on FBSD

With SBCL happily chugging on the mbp, it’s time to prepare an image for the “production” machine. In this case, a recent -STABLE install of FreeBSD on a coloc x86.

Install SBCL with “Enable experimental threading support”. It’s in /usr/ports/lang/sbcl.

After that, the setup for slime and the ASDF stuff is identical to the mac approach to keep things similar. All done!

Deployment

This is neat. I put all my source and shtuff in CVS to give me an easy way to synchronize, undo, and jog my memory on various things. When I decide it’s time to deploy and my laptop is all committed up, I log into the FBSD host and do an update there. Since I’m running SBCL inside of screen, I can merely screen -r to get the prompt back and execute “(asdf:operate ‘asdf:load-op ‘myproject)”. That’s it. No restart or anything, no data migration concerns (structs and classes automatically update instances when they are changed). It’s done 😀 test and be happy. It only recompiles what it needs to and it saves the output to fasl’s so you can reload quickly when you need to restart due to a new kernel, new sbcl, or the colo facility screws up.

I’m not exactly sure what happens if a function chain is altered in a way that would break an existing thread. Hopefully, it will either retain the old functions for the thread to wind and unwind its stack correctly or will wait for all threads to complete and yield before executing the recompile. If it doesn’t, I may need to either fix asdf or wrap those operations somehow. We’ll see.