21–28 of 28 posts
Does the Clojure debugger give a live Repl, where one can examine values of locals and restart execution if required, likes the elisp debugger in Emacs?
https://github.com/clojure-emacs/cider/discussions/2999
If anything Clojure needs this more than ELisp b/c of the crazy error stacks and b/c of how the laziness makes things blow up in all sorts of weird places
Could `scope-capture` be used to capture state before a crash? What would be nice is a GDB-like state along with stacktraces when you get a crash. Clojure stack traces are notoriously long and spooky. You learn to read the tea leaves, but even if you manage to identify where the crash happened and what triggered it (not always obvious..) you then need to pepper things with `println` to figure out the last local state…
Assuming the crash doesn't cause the process to completely exit, you could indeed use `scope-capture` for this. This works well for local dev. In theory, you could use `sc.api/spy` in production code, and then attach a remote repl to diagnose any crashes. I wouldn't recommend this though, I think it would be best to use a good logging library like Mulog: https://github.com/BrunoBonacci/mulog
The first example about spyscope potentially confuses the reader a bit by using it in context of println debugging. The point of it is you can stick it in front of any form. For a better example, see https://github.com/dgrnbrg/spyscope#spyp Otherwise great article, I hadn't heard about scope-capture.
Thanks! Perhaps the wording isn't great in that paragraph, I intended the phrase "println debugging" to mean the general style of debugging, rather than specifically using the println function.
For those of us using CIDER don't forget #break / #dbg! https://docs.cider.mx/cider/debugging/debugger.html#using-th...
That allows you to step through code. but it doesn't break when you get a crash (like gdb). At least when I just tested: #dbg(defn get-first [input] (nth input 0)) (get-first [4 2 3]) ;; 4 (get-first 5) ;; gives me a stack trace and no program state So it's nice to have, but I think this is maybe only useful if you're working through someone else's code?
In conjunction with scope-capture, it is trivial to run that failing code again to have a closer look, and modify it to your liking till it runs as expected.
There are also conditional restart systems for Clojure that offer much more than this.
Could `scope-capture` be used to capture state before a crash? What would be nice is a GDB-like state along with stacktraces when you get a crash. Clojure stack traces are notoriously long and spooky. You learn to read the tea leaves, but even if you manage to identify where the crash happened and what triggered it (not always obvious..) you then need to pepper things with `println` to figure out the last local state…
println (or other logging/tracing, eg using tap) works for seeing where things go wrong, but stepping through code with a debugger works too if you're so inclined, or experimeting at the repl.
Sure, it's not always obvious what caused bad input that evnetually leads to an uncaught exception, just like in other languages.. it might have come through an event loop or other layer of indirection that doesn't show the real caller, for example.
Could `scope-capture` be used to capture state before a crash? What would be nice is a GDB-like state along with stacktraces when you get a crash. Clojure stack traces are notoriously long and spooky. You learn to read the tea leaves, but even if you manage to identify where the crash happened and what triggered it (not always obvious..) you then need to pepper things with `println` to figure out the last local state…
I find the stack traces to be fine as long as there's some middleware in use to filter out the Java stack frames from non-Clojure code, like eg CIDER does (and probably other envs can too). Otherwise they have some noise which is a bit annoying but not showstopper. println (or other logging/tracing, eg using tap) works for seeing where things go wrong, but stepping through code with a debugger works too if you're so…
Next time I'm in a bind I'll have to try `scope-capture`. It looks like it might get me half way there
Earlier quoted context omitted.
I find the stack traces to be fine as long as there's some middleware in use to filter out the Java stack frames from non-Clojure code, like eg CIDER does (and probably other envs can too). Otherwise they have some noise which is a bit annoying but not showstopper. println (or other logging/tracing, eg using tap) works for seeing where things go wrong, but stepping through code with a debugger works too if you're so…
right, it's not like you're completely stuck with no way to figure out what's causing your problems. In pretty much every language you can get a crash stack and pepper print/logging statements. And sure, the Clojure stacks aren't always impenetrable (unless it's blowing up in some call back or lazy evaluation.. then good luck). But I don't think it should be brushed under the rug that that the debug situation in Cloj…