Re: Question: LispWorks IDE with different CL engine?

There is also sly , a fork from Slime:

https://github.com/joaotavora/sly

I'm not using it, so I can't say how useful it is. But some people seem to like it.

I also prefer the LispWorks IDE on the usual current systems. There are also some remote IDE capabilities for LispWorks, which have been added a few years ago (IIRC) - for example to debug LispWorks on Apple iOS. 
See:

https://www.lispworks.com/documentation/lw81/ide-m/ide-remote-debugging.htm

https://www.lispworks.com/documentation/lw81/lw/lw-debugger-ug-7.htm

This allows to use the LispWorks IDE with a remote LispWorks.

Maybe one could convince Martin to extend this functionality to something like SBCL?

Regards

Rainer


> Am 03.02.2026 um 10:05 schrieb Uģis Lācis (as ugis dot lacis at equa dot se) <[email protected]>:
> 
> Hi Tim (and everyone who chimed in the discussion),
>  
> Thanks for all the responses, interesting read. What I am doing, really, is working in an old closed-source LISP code-base, which we are trying to port from ACL 3.0.2 to modern LISP. Our aim is actually to be portable, i.e., we hope to be able to use both LispWorks and SBCL (and potentially some other LISP) for running our code.
>  
> We have bought LispWorks primarily for the same reason as Paul mentioned, ease of use and convenient debugging. This part I have found much harder to use in SBCL (I have tried both SLIME and VSCode + Alive extension). What I have determined is that SLIME is much more capable than VSCode (at least in terms of inspecting CLOS structures), however, tricky to keep as everyday tool (I guess EMACS buffers is the culprit ... I just have not had time or managed to churn through the workflows there to come up with my own and fix a cheat sheet ...). And due to this, my progress with SBCL is lagging behind that of LispWorks. Sadly, as code base is quite large, we do not have the option to (re)write it in LispWorks and run in SBCL; the fact is – the current state does run worse in SBCL compared to LispWorks.
>  
> So this is basically what I want to do – have as good debugging in SBCL as I have in LispWorks.
>  
> Regarding basic REPL, tracing, rudimentary breakpoints and annoying stepping ... That works out of the box in VSCode + Alive, nothing needs implementation there.
>  
> Best,
> Ugis
>  
> From: Tim Bradshaw <[email protected]>
> Sent: Monday, 2 February 2026 19:48
> To: Yuri Davidovsky <[email protected]>
> Cc: Uģis Lācis <[email protected]>; [email protected]
> Subject: Re: Question: LispWorks IDE with different CL engine?
>  
> The question is not whether you can persuade the LW IDE to talk to SBCL but what use is that, and is is worth the candle?
>  
> If you're using the LW IDE you have a high-quality, deeply integrated CL right there, in the same Lisp image as the IDE.  That gives you most of the things people liked about LispMs: the LW IDE is, by margin, the closest thing to using a LispM I know of (it's not very like a LispM in interface but the all-in-one-image thing is a big deal).  Getting an implementation that is sitting at the end of a bit of string to be anything like that nice is going to be ... well, good luck with it
>  
> I think we need to know what OP wants to achieve.