Debugging Lisp: fix and resume a program from any point in the stack - how Common Lisp stands out.

To really discover what interactive, image-based CL development is about, my pointers: - [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 from scratch, restart the app, reload state. But we can do everything in between too (inspect the running app, change it a bit, change it a whole lot (while staying in sync with local source code), use images to speed-up development etc).

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] [VIDEO] and some more: [LINK]

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: [VIDEO] not with unit tests, it's an example on how to restart a precise frame, how to avoid re-running everything.

> 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: [VIDEO] We run a long and intensive computation and, bad luck, we get an error in the last step. Instead of re-running everything again from zero, we get the interactive debugger, we go to the erroneous line, we compile the fixed function, we come back to the debugger, we choose a point on the stackframe to resume execution from (the last step), and we see our program pass. Hope this illustrates the feature well!

That's a short video I made to show this: [VIDEO] It's a feature that is useful everyday, if only to speed up trivial things.

*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. [VIDEO]

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: [VIDEO] so we don't re-run everything from zero.

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: [VIDEO] debugging a complex stacktrace: Python VS CL: [LINK] Another important point: we debug everything while keeping the current state in memory (in the image). We don't have to re-create our test data. All the program state is kept live, until we restart the image.