[slime-devel] sbcl-related TODOs (was Re: SLIME User Survey)

[Christophe Rhodes]

Luke Gorrie <luke at bluetail.com> writes:

> "Thomas F. Burdick" <tfb at 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 at 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
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)