Luke Gorrie luke@bluetail.com writes:
"Thomas F. Burdick" tfb@OCF.Berkeley.EDU writes:
The compilation notes buffer always pops up when there is exactly one STYLE-WARNING (usually a redefinition warning, ug), but not when there are some notes, which I might actually want to see.
Yes, that shits me too. The reason it pops up is that those "redefining:" style warnings are signalled without any source-path information, so we don't know where to annotate them and fall back to popping up the buffer.
I've hacked those warnings out of my local SBCL and started a nagging campaign on Christophe.
This is hard. David Lichteblau looked at doing something similar, but the problem in essence is (I think -- I'm certainly no expert in this, and probably won't become one in the next two months) that the SBCL fasl file format first contains new definitions, etc, and then backpatches the new definitions with source file information. So at the time of function (re)definition, all that neat debugging information simply isn't associated with the function.
So, fixing this right probably involves messing around with the fasl format, which is annoying and non-trivial.
Christophe Rhodes csr21@cam.ac.uk writes:
I would like to see a little more work on coordination between slime and implementations (not just SBCL, though obviously that's where my focus is). There's a load of complicated code in swank-sbcl.lisp that I'd just love to break on the grounds that no-one asked me for PERMISSION to use MY symbols... on the other hand, I can imagine hordes of angry lispers turning up in London (or Cambridge, at the weekend ;-) and lynching me if I've broken their SLIME 1.0.
Christophe and I have talked about this off-list. We've suggested that for whatever internal SBCL functions we're still calling towards the release, we'll call them indirectly via an "sb-slime"-or-such package which will be part of SBCL. This level of indirection means that the SBCL guys can change the internals that we're accessing and still be SLIME-1.0 compatible so long as they update sb-slime in terms of the new internals.
I should say that this won't happen automagically. (Welcome to Free software...) The more users who can distill unsupported functionality used by slime into entry points _with tests_, so that SBCL developers stand a chance of knowing when they've broken something, the more successful this attempt at providing a certain amount of stability will be. In particular, if you feel that you would appreciate not having to upgrade slime and sbcl whenever either team decides to change something, then now is the time to make your efforts felt.
Cheers,
Christophe