Re: Question: LispWorks IDE with different CL engine?

You can use code coverage in LW to find things which are never used, and then just nuke them, also who calls and calls who of course.

You can also do a lot of things programmatically in LW to analyse the code.  dspecs are very helpful.

Ignoring compiler warnings is a huge mistake in my opinion.  You need to make them go away, both because every warning is the compiler telling you 'I think this is a bug' and you shouldn't ignore bugs, and because anything that compiles with a vast spew of noise means you never see the noise that matters: it's the 'all the warning lights have come on on the control panel and I have no idea what is happening now' while all the coolant pours out of the reactor problem.

You *can* ignore notes and perhaps style warnings in SBCL.  See here: https://www.sbcl.org/manual/#Controlling-Verbosity.  Ignoring notes is a good start, ignoring style warnings is may be something you want to do initially.

--tim

> On 3 Feb 2026, at 09:23, Uģis Lācis <[email protected]> wrote:
> 
> Hi,
>  Yes, this is sort of what I am doing now, but the positive answer to my original question would accelerate the progress.
>  Reason is, often when I get LispWorks running state into SBCL, it does fail in different place due to reasons which are often very hard to find. Point taken about not all warnings and notes addressed, but sadly, due to very large code base, this is actually not a good idea (as it is often with legacy code bases, it is not clear if that part of code is used and if the warning/note patching on that part is even a useful work) ...
>  Best,
> Ugis
>  From: Marco Antoniotti <[email protected]>
> Sent: Tuesday, 3 February 2026 10:17
> To: Uģis Lācis <[email protected]>
> Cc: Tim Bradshaw <[email protected]>; Yuri Davidovsky <[email protected]>; [email protected]
> Subject: Re: Question: LispWorks IDE with different CL engine?
>  Hi
>  My suggestion is what others have made.  Get it to run on LW and then pass it in SBCL trying to satisfy its often annoying notes and warnings.
>  That's the way I work, and it has served me well.  Portability is another issue.
>  MA
>  On Tue, Feb 3, 2026 at 10:07 AM Uģis Lācis (as ugis dot lacis at equa dot se) <[email protected]> wrote:
> 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 t
 o 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 CLright 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.
> 
> 
> -- Marco Antoniotti, Professor, Director         tel. +39 - 02 64 48 79 01
> DISCo, University of Milan-Bicocca U14 2043   http://dcb.disco.unimib.it
> Viale Sarca 336
> I-20126 Milan (MI) ITALY
> REGAINS: https://regains.disco.unimib.it/



_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html