Debugging Lisp: fix and resume a program from any point in the stack - how Common Lisp stands out.
Why Hacker News recommends it
HN Lisp fans repeatedly link it as a short, concrete demonstration of Common Lisp's interactive debugging advantage.
What it is
A five-minute demo of the Common Lisp debugger fixing a bug, recompiling a single function, and resuming execution from the failed stack frame. It shows how to avoid re-running long computations.
Recommended by 1 HN commenters across 1 different months, 2023 to 2025.
What Hacker News said
Recommends vindarel · 2023-11 · on “Interactive Common Lisp Development”
To really discover what interactive, image-based CL development is about, my pointers: - [this video] (5min) my demo to show how to resume execution of a long running program, from the stack frame right before the bug, after having fixed and recompiled the function, without quitting the debugger hence without stopping the program, thus without restarting everything from zero. - [LINK] (20min)showing what saving and restoring an image does, differences between SBCL and LispWorks. - [LINK] developing a 3D graphics software. - [LINK] - debugging CL tools: [LINK] - and no: while we could deploy a ball of mud to production, we can also not and use traditional tools and techniques: build an executable
Cites vindarel · 2023-01 · on “Debugging Lisp: trace options, break on conditions”
Related to debugging, the follow up article: how to fix and resume a program from any point in the stack. Have the debugger pop-up, read the error message, go to the erroneous line ("v"), fix the code, compile the function (C-c C-c), come back to the debugger, press "r" on any point in the stack, see the program succeed. You did not have to re-run everything from zero. [LINK] [this video] and some more: [LINK]
Cites vindarel · 2023-05 · on “Why Lisp?”
Best of both worlds: write unit tests with an interactive debugger o/ Tell the test runner to not catch errors and let them pass through up to the debugger. Have a test fail, get the debugger, go to the buggy line (without quitting the debugger), fix the bug, compile the function with a keystroke (yes, one function), come back to the debugger, restart not the full operation, but the function call, the debugger frame where the error happened, and see the test succeed. You ran the test exactly once and fixed everything in the process, very quickly. This is exactly what we do everyday with the debugger, with trivial or complex code, with unit tests or regular code. An example: [this video] not with
Cites vindarel · 2023-07 · on “It's 2023, so of course I'm learning Common Lisp”
> lots of interoperability libraries That's true. For cases when you want to start with a good set of libraries (json, csv, databases, HTTP client, CLI args, language extensions…), I am putting up this collection together: [LINK] It can be used as a normal Quicklisp library, or as a core image (it then starts up instantly) or as a binary. It can run scripts nearly instantly too (so it isn't unlike Babashka). We are ironing out the details, not at v1.0 yet. > handling a runtime error by just fixing the broken code--in-place, without any restarts [from the blog] Also (second shameless plug) I should have illustrated this here: [this video] We run a long and intensive computation and, bad luck, we g
Cites vindarel · 2023-09 · on “Spinneret: A modern Common Lisp HTML generator”
That's a short video I made to show this: [this video] It's a feature that is useful everyday, if only to speed up trivial things.
Cites vindarel · 2023-10 · on “Common Lisp: An Interactive Approach (1992) [pdf]”
*and not only paste, but write, in the source file, the new definition, re-compile it (C-c C-c), and resume execution from a stackframe before this call. (a clarification for folks who would think we must paste in the REPL) That's useful not only for breakpoints but for errors. We can fix an error without re-running everything from zero. [this video]
Cites vindarel · 2024-02 · on “Why is Common Lisp not the most popular programming language?”
not true, sorry! And if some languages took features, the combination of them is unique in CL. Image-based REPL interactivity, condition system, interactive debugger, restarts, compile-time computing, compile-time checks, incremental typing, speed, a different object system, stability, single-file binaries, connecting to a remote system… Here we restart a buggy program from a single point in the stack: [this video] so we don't re-run everything from zero.
Cites vindarel · 2024-05 · on “A Road to Common Lisp (2018)”
I suggest: do you find yourself often quitting the debugger and re-running the same test, the same task from the start? You can avoid that in CL. Just leave the debugger open, go to the buggy line ("v" on a stacktrace in Slime), fix the function, re-compile it on the fly (C-c C-c in Slime), come back to the debugger, resume the program from the stackframe you want, now it passes. If the first steps were taking 10 minutes, you just saved yourself some time. You don't need special needs for that, it's a fast workflow I use everyday. demo: [this video] debugging a complex stacktrace: Python VS CL: [LINK] Another important point: we debug everything while keeping the current state in memory (in the i