4 ms·

Programming in the debugger is a massively overlooked paradigm. We use gdb for interactive usage. You could become a super-productive programmer if you can use

Programming in the debugger is a massively overlooked paradigm. We use gdb for interactive usage. You could become a super-productive programmer if you can use gdb programmatically. The possibilities are endless. The problem: gdb developers don't think of that kind of usage as a core part of the software (let alone making programmability more important than interactivity, something I believe in). And that's why it's one of my goals to develop a programmable debugger in the future if I get some time.

nn3 9y ago
You should check out ups http://ups.sourceforge.net/ http://ups.sourceforge.net/ It has a builtin C interpreter which allowed you to dynamically add and change code while debugging. Unfortunately the code has somewhat bitrotted, so it's hard to use on a modern Linux system
- shakna 9y ago
  Similarly, Cling, from CERN [0], not the easiest thing to set up, but interactive C++ programming using a JIT interpreter. And I can't mention Cling without what they're trying to replace CINT [1], which gives you C and C++ programming, but with a rather slow interpreter. [0] https://root.cern.ch/cling https://root.cern.ch/cling [1] https://root.cern.ch/cint https://root.cern.ch/cint
meken 9y ago
> Programming in the debugger is a massively overlooked paradigm. I wonder if the tool I mentioned in [1] facilitates the workflow you have in mind? It promotes a workflow of setting a breakpoint at the beginning of a function, attach a jupyter notebook to it, dump your code into a jupyter notebook, edit the code in there, and then paste the result back into the code buffer (once you've verified everything checks out locally). One reason I suspect the debugger is not seen as part of the software engineering process (i.e. to extend or modify code) is because of the editing capabilities within a debugger CLI are usually very primitive. At least with pynt, the "debugger" (i.e. the jupyter notebook) is still in emacs so you can leverage all the strengths of your editor while doing interactive programming. > let alone making programmability more important than interactivity, something I believe in Can you elaborate on what you mean here? Maybe give an example of a programmable gdb feature that you think would be useful? - [1] https://news.ycombinator.com/item?id=16899023 https://news.ycombinator.com/item?id=16899023
- fizixer 9y ago
  I thought about this idea at a deeper level long time ago and don't remember all the details (and don't have the notes in front of me) but here are two points related to that: - Programmable debugger would be a massive benefit to compiled langauges like C, and not as much of a benefit for interpretive systems like Python. Especially with the REPL mode of programming in Python (you run something, don't like the results, try something else, then move to next step) is already a pretty effective way to do exploratory prototyping. A programmable gdb would allow REPL like workflow for C. - As an example, let's say a C program seg-faults at a certain point in code. If you run your C program inside gdb, gdb will stop there and let you do some exploration. That exploration is very tedious if you can't programmatically manipulate your registers and memory areas. In principle, you should be able to write an arbitrarily complex program to bring the seg-faulted state back into a functioning state, and then when the code continues, you don't get the seg-fault again, and you didn't even have to rerun the code. One use case in which this is massively useful is long running scientific programs. You start a complex scientific simulation based on a C program and it is expected to run for, let's say, 48 hours, but it seg-faults in the 46th hour! If you run it in a programmable gdb you could fix the seg-fault right then and there, and continue the program instead of trial and error of multiple runs, each run taking 46 hours before you know if your fix worked or not. I think this scenario might require more than just a programmable gdb, e.g., it might require a way for the program to be recompiled and put in memory replacing the older buggy program, before the program has actually finished. But a programmable gdb would be a big part of that system.

nn3 9y ago

You should check out ups http://ups.sourceforge.net/ http://ups.sourceforge.net/ It has a builtin C interpreter which allowed you to dynamically add and change code while debugging. Unfortunately the code has somewhat bitrotted, so it's hard to use on a modern Linux system

shakna 9y ago
Similarly, Cling, from CERN [0], not the easiest thing to set up, but interactive C++ programming using a JIT interpreter. And I can't mention Cling without what they're trying to replace CINT [1], which gives you C and C++ programming, but with a rather slow interpreter. [0] https://root.cern.ch/cling https://root.cern.ch/cling [1] https://root.cern.ch/cint https://root.cern.ch/cint

meken 9y ago

> Programming in the debugger is a massively overlooked paradigm. I wonder if the tool I mentioned in [1] facilitates the workflow you have in mind? It promotes a workflow of setting a breakpoint at the beginning of a function, attach a jupyter notebook to it, dump your code into a jupyter notebook, edit the code in there, and then paste the result back into the code buffer (once you've verified everything checks out locally). One reason I suspect the debugger is not seen as part of the software engineering process (i.e. to extend or modify code) is because of the editing capabilities within a debugger CLI are usually very primitive. At least with pynt, the "debugger" (i.e. the jupyter notebook) is still in emacs so you can leverage all the strengths of your editor while doing interactive programming. > let alone making programmability more important than interactivity, something I believe in Can you elaborate on what you mean here? Maybe give an example of a programmable gdb feature that you think would be useful? - [1] https://news.ycombinator.com/item?id=16899023 https://news.ycombinator.com/item?id=16899023

fizixer 9y ago
I thought about this idea at a deeper level long time ago and don't remember all the details (and don't have the notes in front of me) but here are two points related to that: - Programmable debugger would be a massive benefit to compiled langauges like C, and not as much of a benefit for interpretive systems like Python. Especially with the REPL mode of programming in Python (you run something, don't like the results, try something else, then move to next step) is already a pretty effective way to do exploratory prototyping. A programmable gdb would allow REPL like workflow for C. - As an example, let's say a C program seg-faults at a certain point in code. If you run your C program inside gdb, gdb will stop there and let you do some exploration. That exploration is very tedious if you can't programmatically manipulate your registers and memory areas. In principle, you should be able to write an arbitrarily complex program to bring the seg-faulted state back into a functioning state, and then when the code continues, you don't get the seg-fault again, and you didn't even have to rerun the code. One use case in which this is massively useful is long running scientific programs. You start a complex scientific simulation based on a C program and it is expected to run for, let's say, 48 hours, but it seg-faults in the 46th hour! If you run it in a programmable gdb you could fix the seg-fault right then and there, and continue the program instead of trial and error of multiple runs, each run taking 46 hours before you know if your fix worked or not. I think this scenario might require more than just a programmable gdb, e.g., it might require a way for the program to be recompiled and put in memory replacing the older buggy program, before the program has actually finished. But a programmable gdb would be a big part of that system.