5 ms·

A Debugger is a REPL is a Debugger

45 points by ingve 2y ago

porridgeraisin 2y ago
$ alias breakpoint alias breakpoint=' while read -p"Debugging(Ctrl-d to exit)> " debugging_line do eval "$debugging_line" done ' Good breakpoint repl you can insert anywhere in a bash script
- JoelMcCracken 2y ago
  Nice. I recently have been doing a bash deep dive and realizing that treating it like repl driven development is very useful. Been wondering if this is worth writing about for others. You can also just execute another ‘bash’ process, of course the environment is a bit different
shmerl 2y ago
With nvim-dap-ui you can evaluate an expression by selecting it, and it would try to evaluate anything custom you do in the editor that wasn't in the original code. Try something like this: :lua require('dapui').eval() For running to the current cursor: :lua require('dap').run_to_cursor() Assign that to keys that you want. It works with gdb's DAP adapter.
nilskch 2y ago
When writing Python in VSCode you get a REPL when you hit a break point and I think that's sweet.
- jasonjmcghee 2y ago
  This isn't unique to vscode. It's standard in ides and clients of DAP for interpreted languages
attila-lendvai 2y ago
in (Common) Lisp it has been like that forever. the debugger is just a REPL started in a peculiar environment that has e.g. some extra restarts registered by the error handler.
fooker 2y ago
Sure, a 1980s debugger. Modern debuggers have specialized capabilities way beyond the reach of REPLs. Reverse debugging and debugging optimized programs come to mind.
- eadmund 2y ago
  Why couldn’t a sufficiently smart REPL have those things as well? Anything can happen after the read and around the execute stage!
  - fooker 2y ago
    A sufficiently smart anything can do anything. What makes modern debuggers special is the insane amount of engineering to make it work. LLDB is close to a thousand man years of engineering iirc.
    - eadmund 2y ago
      Imagine if that man-millennium of engineering had been spent working on a decent language and ecosystem instead of C, C++ and Objective-C! That’s what gets me: better languages are able to scrape by with several orders of magnitude less investment, precisely because they are better — but imagine how much more progress we as an industry would have made had we only invested a little more in those more promising ecosystems and a little less in the terrible ones.
- taeric 2y ago
  I'm curious what features you have in mind that you can't do from the Common LISP REPL?
- pjmlp 2y ago
  Only if you ignore Smalltalk and Lisp environments. There is still some catching up missing from other programming stacks.
  - whitten 2y ago
deleted 2y ago
[deleted]
Moomoomoo309 2y ago
If you're using IntelliJ, you can also right click the breakpoints and set conditions, or set a breakpoint to not suspend execution, but to activate another breakpoint so you can wait for a condition or line of code to be reached before the other breakpoint does anything. Super useful for debugging specific scenarios so you don't need to set up the context repeatedly.
john-h-k 2y ago
`b line` and `expr expr` both work fine in lldb. I agree the ergonomics are less excellent, but that doesn't seem a reason to completely abandon lldb/gdb to me. Maybe I am missing something

45 points by ingve 2y ago

$ alias breakpoint alias breakpoint=' while read -p"Debugging(Ctrl-d to exit)> " debugging_line do eval "$debugging_line" done ' Good breakpoint repl you can insert anywhere in a bash script

JoelMcCracken 2y ago
Nice. I recently have been doing a bash deep dive and realizing that treating it like repl driven development is very useful. Been wondering if this is worth writing about for others. You can also just execute another ‘bash’ process, of course the environment is a bit different

shmerl 2y ago

With nvim-dap-ui you can evaluate an expression by selecting it, and it would try to evaluate anything custom you do in the editor that wasn't in the original code. Try something like this: :lua require('dapui').eval() For running to the current cursor: :lua require('dap').run_to_cursor() Assign that to keys that you want. It works with gdb's DAP adapter.

nilskch 2y ago

When writing Python in VSCode you get a REPL when you hit a break point and I think that's sweet.

jasonjmcghee 2y ago
This isn't unique to vscode. It's standard in ides and clients of DAP for interpreted languages

attila-lendvai 2y ago

in (Common) Lisp it has been like that forever. the debugger is just a REPL started in a peculiar environment that has e.g. some extra restarts registered by the error handler.

fooker 2y ago

Sure, a 1980s debugger. Modern debuggers have specialized capabilities way beyond the reach of REPLs. Reverse debugging and debugging optimized programs come to mind.

eadmund 2y ago
Why couldn’t a sufficiently smart REPL have those things as well? Anything can happen after the read and around the execute stage!
- fooker 2y ago
  A sufficiently smart anything can do anything. What makes modern debuggers special is the insane amount of engineering to make it work. LLDB is close to a thousand man years of engineering iirc.
  - eadmund 2y ago
    Imagine if that man-millennium of engineering had been spent working on a decent language and ecosystem instead of C, C++ and Objective-C! That’s what gets me: better languages are able to scrape by with several orders of magnitude less investment, precisely because they are better — but imagine how much more progress we as an industry would have made had we only invested a little more in those more promising ecosystems and a little less in the terrible ones.
taeric 2y ago
I'm curious what features you have in mind that you can't do from the Common LISP REPL?
pjmlp 2y ago
Only if you ignore Smalltalk and Lisp environments. There is still some catching up missing from other programming stacks.
- whitten 2y ago

deleted 2y ago

[deleted]

Moomoomoo309 2y ago

If you're using IntelliJ, you can also right click the breakpoints and set conditions, or set a breakpoint to not suspend execution, but to activate another breakpoint so you can wait for a condition or line of code to be reached before the other breakpoint does anything. Super useful for debugging specific scenarios so you don't need to set up the context repeatedly.

john-h-k 2y ago

`b line` and `expr expr` both work fine in lldb. I agree the ergonomics are less excellent, but that doesn't seem a reason to completely abandon lldb/gdb to me. Maybe I am missing something