Re: Question: LispWorks IDE with different CL engine?

I second that.

SBCL is really fussy.  But you must nuke all warnings if you can (and
usually you can; I know, I just did it for CL3270 -- I know: I am sick :) )

Cheers

MA


On Tue, Feb 3, 2026 at 12:06 PM Tim Bradshaw <[email protected]> wrote:

> 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 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
> 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/
>
>
>

-- 
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/