Hacker News Reader

Comment by igouy | Hacker News Reader

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.ht...

View on HN

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.

> 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.

Hence "ideally"

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.

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.

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)

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.)

Reply on news.ycombinator.com