This was a more fraught release than previous, maybe because we're playing around with some low-level suboptimalities; obviously we want to fix them, but the time scale is quite challenging. The good news is that it seems that Dan's stack checking stuff (a) has landed and (b) is here to stay. It's a much better scheme architecturally, and it also means that I can read disassembly without having to filter out n calls to SB-KERNEL:%DETECT-STACK-EXHAUSTION...
The bad news? Well. F'rinstance, there's the vexing matter of floating point arithmetic. I was so pleased to have fixed SBCL's signal handling code on x86/ and PPC/Linux. Ha. One of the problems of testing on only one machine (per architecture/os combination) is that you don't necessarily catch all your assumptions. In this case, when I tried the nice shiny new code on Dan's iMac:
* (/ 1.0 0.0) 1.0
Ouch. So, I went back over to the Sourceforge compile farm machine (IBM RS6000, running Debian), and tried it there, just to check that I wasn't going completely mad:
* (/ 1.0 0.0) Segmentation fault
The temptation to weep and curse was fairly strong; however, before turning myself in for crimes against good programming I did note that the machine in question had just changed from running a 2.4.high kernel to a 2.2.low one; given my previous experience with signals on SPARC/Linux, I'm willing to believe that it's not my fault.
Still, on the plus side, we appear to have a fan, even if he hasn't actually used the system. Off to sing in Paris for a week, so my two outstanding strange problems are left in the capable hands of my co-maintainers. Phew.