5 ms·

a good debugger supports different kinds of breakpoints, offers rich data visualization capabilities, has a REPL for executing expressions, can show the depende

a good debugger supports different kinds of breakpoints, offers rich data visualization capabilities, has a REPL for executing expressions, can show the dependencies between threads and control their execution, can pick up changes in the source code and apply them without restarting the program, can step through the code backward and rewind the program state to any point in history, and can even record the entire program execution and visualize control flow and data flow history. I should mention that the perfect debugger doesn’t exist. People pretends Smalltalk doesn't exist?

aidenn0 4y ago
Is there a ST implementation with a time-traveling debugger? That's probably the one feature I miss when using sbcl/slime.
- igouy 4y ago
  Depends what functionality you think "a time-traveling debugger" must provide, Smalltalk implementations usually provide something like this: https://cuis-smalltalk.github.io/TheCuisBook/The-Debugger.html https://cuis-smalltalk.github.io/TheCuisBook/The-Debugger.ht...
  - aidenn0 4y ago
    To qualify as "time-travelling" You should at a minimum be able to step and run backwards and inspect the values of variables at a previous point in time. Ideally all debug features (breakpoints, watchpoints, tracepoints &c.) will work running both forwards and backwards. To meet the standard of the "perfect debugger" from the TFA intro, I would say you should be able to run backwards, modify a function, and run forwards again. I'm not aware of any debuggers that let you do this.
    - leni536 4y ago
      > Ideally all debug features (breakpoints, watchpoints, tracepoints &c.) will work running both forwards and backwards. Executing arbitrary code in the program's context is also a regular debug feature, but I don't think many reversible debuggers allow this.
      - aidenn0 4y ago
        Hence "ideally"
      - roca 4y ago
        rr lets you call program functions just like gdb does (using the same gdb commands, in fact). The limitation is that any state changed by those functions is simply dropped when the function ends. It's still super-useful for dumping program state etc. Pernosco supports this too.
    - sebastianconcpt 4y ago
      Yeah. That's the normal way to work for a Smalltalk debugger. I remember once debugging a thread without killing it. I've asked a customer to click on a link that would get to a bug while having remotely opened the IDE that was serving that user session, setting a conditional halt. Seen it halting, fixing the bug and saving the method with the halt removed and let the thread run. All the user saw was a long request that ended in service instead of that bug.
      - aidenn0 4y ago
        I don't see any "running backwards" mentioned in this story. I'm familiar with "break, fix, restart" debugging from Lisp (which had a lot of cross-pollination with smalltalk)
    - igouy 4y ago
      afaik Smalltalk implementations usually provide step backwards but don't "run backwards". "The stack of (framed) execution contexts gives a history of the computation so far. You can select any frame, view instance values in the receiver, view the arguments and method variables at that point." So step backwards, modify a method, step backwards before that method send, and resume execution with the modified method. (Note: resume rather than restart, so the modified method has the preserved context unless we manually edit that context.)
nijave 4y ago
>can step through the code backward and rewind the program state to any point in history This seems impossible for anything that modifies external state. Say 1. Open database connection 2. Commit data 3. Close database connection How would you rewind right before #2 if you've already completed step #3? You'd need the socket/connection you already closed Unless that means something more like "keep a running record of program state over time"
- fluoridation 4y ago
  Yes, that's what it means. Ideally you'd record the state of memory and CPU after each instruction. In practice you can take snapshots at regular intervals and hook system functions to record their inputs and outputs. If a call has to be replayed the debugger intercepts it and gives the debuggee a recorded result.
  - greglaw99 4y ago
    Exactly. Except there are sources of non-determinism other than syscalls. Namely asynchronous signals, thread ordering, shared memory and non-deterministic instructions. They can all be dealt with though.
- deleted 4y ago
  [deleted]
- cmontella 4y ago
  It can work but it depends on the system. One field in which it's very useful is game development. I'm working on a language that has time travel debugging as a feature, so you can rewind a game back to a previous state. I've found it useful when there's a momentary bug that would be hard to recreate. With time traveling, you pause, rewind, inspect state, fix the bug in situ, then resume from that point to check that the behavior is correct. Here's an example: http://docs.mech-lang.org/#/examples/bouncing-balls.mec http://docs.mech-lang.org/#/examples/bouncing-balls.mec If you want these kinds of features in other systems, they'll have to be architected to support them. For example, the external database will have to be rewound as well. If it doesn't support that feature, then cool language-level debugging features won't be as useful.
draegtun 4y ago
>> People pretends Smalltalk doesn't exist? And Factor and many implementations of Lisp too!
shadowofneptune 4y ago
Smalltalk images offered introspection, debugging of running processes, etc., but some of the later features listed seem quite impractical to add to the language. "Record the entire program execution," for instance. That's more or less the point the author makes on the next line: "Different tools support different features and have different limitations." The ideal debugger does not necessarily make for the most ideal programming environment, just as a plane made out of steel is great for structural stability but may not be a good plane.
HdS84 4y ago
Most of it can be done by the c# debugger, especially in the laid versions of visual studio.
jayd16 4y ago
Which of these can't visual studio or intellij do?
- pjmlp 4y ago
  hot code reload is very constrained in what can be changed. It is great that it exists, but it isn't Smalltalk where at any moment the debugger can come up, you can change the world and hit continue without any issues, with all live instances updated to the latest set of changes.
- greglaw99 4y ago
  IntelliJ can do time travel if you install the plugin: https://plugins.jetbrains.com/plugin/14767-time-travel-debug-for-java https://plugins.jetbrains.com/plugin/14767-time-travel-debug...

aidenn0 4y ago

Is there a ST implementation with a time-traveling debugger? That's probably the one feature I miss when using sbcl/slime.

igouy 4y ago
Depends what functionality you think "a time-traveling debugger" must provide, Smalltalk implementations usually provide something like this: https://cuis-smalltalk.github.io/TheCuisBook/The-Debugger.html https://cuis-smalltalk.github.io/TheCuisBook/The-Debugger.ht...
- aidenn0 4y ago
  To qualify as "time-travelling" You should at a minimum be able to step and run backwards and inspect the values of variables at a previous point in time. Ideally all debug features (breakpoints, watchpoints, tracepoints &c.) will work running both forwards and backwards. To meet the standard of the "perfect debugger" from the TFA intro, I would say you should be able to run backwards, modify a function, and run forwards again. I'm not aware of any debuggers that let you do this.
  - leni536 4y ago
    > Ideally all debug features (breakpoints, watchpoints, tracepoints &c.) will work running both forwards and backwards. Executing arbitrary code in the program's context is also a regular debug feature, but I don't think many reversible debuggers allow this.
    - aidenn0 4y ago
      Hence "ideally"
    - roca 4y ago
      rr lets you call program functions just like gdb does (using the same gdb commands, in fact). The limitation is that any state changed by those functions is simply dropped when the function ends. It's still super-useful for dumping program state etc. Pernosco supports this too.
  - sebastianconcpt 4y ago
    Yeah. That's the normal way to work for a Smalltalk debugger. I remember once debugging a thread without killing it. I've asked a customer to click on a link that would get to a bug while having remotely opened the IDE that was serving that user session, setting a conditional halt. Seen it halting, fixing the bug and saving the method with the halt removed and let the thread run. All the user saw was a long request that ended in service instead of that bug.
    - aidenn0 4y ago
      I don't see any "running backwards" mentioned in this story. I'm familiar with "break, fix, restart" debugging from Lisp (which had a lot of cross-pollination with smalltalk)
  - igouy 4y ago
    afaik Smalltalk implementations usually provide step backwards but don't "run backwards". "The stack of (framed) execution contexts gives a history of the computation so far. You can select any frame, view instance values in the receiver, view the arguments and method variables at that point." So step backwards, modify a method, step backwards before that method send, and resume execution with the modified method. (Note: resume rather than restart, so the modified method has the preserved context unless we manually edit that context.)

nijave 4y ago

>can step through the code backward and rewind the program state to any point in history This seems impossible for anything that modifies external state. Say 1. Open database connection 2. Commit data 3. Close database connection How would you rewind right before #2 if you've already completed step #3? You'd need the socket/connection you already closed Unless that means something more like "keep a running record of program state over time"

fluoridation 4y ago
Yes, that's what it means. Ideally you'd record the state of memory and CPU after each instruction. In practice you can take snapshots at regular intervals and hook system functions to record their inputs and outputs. If a call has to be replayed the debugger intercepts it and gives the debuggee a recorded result.
- greglaw99 4y ago
  Exactly. Except there are sources of non-determinism other than syscalls. Namely asynchronous signals, thread ordering, shared memory and non-deterministic instructions. They can all be dealt with though.
deleted 4y ago
[deleted]
cmontella 4y ago
It can work but it depends on the system. One field in which it's very useful is game development. I'm working on a language that has time travel debugging as a feature, so you can rewind a game back to a previous state. I've found it useful when there's a momentary bug that would be hard to recreate. With time traveling, you pause, rewind, inspect state, fix the bug in situ, then resume from that point to check that the behavior is correct. Here's an example: http://docs.mech-lang.org/#/examples/bouncing-balls.mec http://docs.mech-lang.org/#/examples/bouncing-balls.mec If you want these kinds of features in other systems, they'll have to be architected to support them. For example, the external database will have to be rewound as well. If it doesn't support that feature, then cool language-level debugging features won't be as useful.

draegtun 4y ago

>> People pretends Smalltalk doesn't exist? And Factor and many implementations of Lisp too!

shadowofneptune 4y ago

Smalltalk images offered introspection, debugging of running processes, etc., but some of the later features listed seem quite impractical to add to the language. "Record the entire program execution," for instance. That's more or less the point the author makes on the next line: "Different tools support different features and have different limitations." The ideal debugger does not necessarily make for the most ideal programming environment, just as a plane made out of steel is great for structural stability but may not be a good plane.

HdS84 4y ago

Most of it can be done by the c# debugger, especially in the laid versions of visual studio.

jayd16 4y ago

Which of these can't visual studio or intellij do?

pjmlp 4y ago
hot code reload is very constrained in what can be changed. It is great that it exists, but it isn't Smalltalk where at any moment the debugger can come up, you can change the world and hit continue without any issues, with all live instances updated to the latest set of changes.
greglaw99 4y ago
IntelliJ can do time travel if you install the plugin: https://plugins.jetbrains.com/plugin/14767-time-travel-debug-for-java https://plugins.jetbrains.com/plugin/14767-time-travel-debug...