Current CVS HEAD SBCL breaks Slime again. I cheerfully submit that this is "not SBCL's fault" as the interfaces that have changed were unexported and unsupported:
1) SB-DEBUG::PRINT-CODE-LOCATION-SOURCE-FORM was replaced by SB-DEBUG::CODE-LOCATION-SOURCE-FORM; do the printing as you please.
2) SB-DEBUG::PRINT-FRAME-CALL now takes a second required argument, the stream to print to.
The attached patch should fixes things for both bleeding edge and older versions, but still uses the unexported interfaces and is hence liable to break again. :/
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
Nikodemus Siivola tsiivola@cc.hut.fi writes:
The attached patch should fixes things for both bleeding edge and older versions, but still uses the unexported interfaces and is hence liable to break again. :/
Thanks! I've applied the patch after stripping away the backwards compatibility, SBCL users are afforded no such luxury :-)
To avoid crufty backwards compatibility code in both SBCL and SLIME we just keep the latest of each compatible and suggest that people upgrade them together.
Cheers, Luke
Luke Gorrie luke@synap.se writes:
Nikodemus Siivola tsiivola@cc.hut.fi writes:
The attached patch should fixes things for both bleeding edge and older versions, but still uses the unexported interfaces and is hence liable to break again. :/
Thanks! I've applied the patch after stripping away the backwards compatibility, SBCL users are afforded no such luxury :-)
Ooops, I misunderstood: I thought by "bleeding edge" you meant the brand-new release, not the brand-new CVS changes that aren't included in the brand-new release :-)
I'm putting the backwards-compatibility back in but let's remove it as soon as the next SBCL is released.
Cheers, Luke (bleeding)
On Thu, 3 Mar 2005, Luke Gorrie wrote:
I'm putting the backwards-compatibility back in but let's remove it as soon as the next SBCL is released.
Heh, sorry, I should have been clearer about that.
Anyways, if Slime was to present a wishlist debugger interface (not "export everything we use", but "here's a list of abstract functionalities we need"), I might have a look at providing actually supported ways of doing doing what you're doing in SBCL.
An idle thought: how stable is the SWANK protocol? If it was documented then implementations could potentially support it directly: sb-swank as a contrib kind of thing.
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
Nikodemus Siivola tsiivola@cc.hut.fi writes:
Anyways, if Slime was to present a wishlist debugger interface (not "export everything we use", but "here's a list of abstract functionalities we need"), I might have a look at providing actually supported ways of doing doing what you're doing in SBCL.
That would be great.
The nearest we have is swank-backend.lisp. That is a clean and documented specification of all non-standard functionality that we need from the backends. This interface is not generalized beyond our own immediate needs though so one wouldn't adopt it as-is.
In swank-acl.lisp you can see that ACL's debugging API supports our needs fairly directly.
An idle thought: how stable is the SWANK protocol? If it was documented then implementations could potentially support it directly: sb-swank as a contrib kind of thing.
I think the SLIME<->SWANK interface has been changing incompatibly much more than the SWANK<->SBCL interface in our history so far.
-
Luke Gorrie -
Nikodemus Siivola