Hacker News new | ask | show | jobs
by aidenn0 1203 days 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.
3 comments
sebastianconcpt 1203 days 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.

link
aidenn0 1203 days 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)
link
leni536 1203 days 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.

link
aidenn0 1203 days ago
Hence "ideally"
link
roca 1202 days 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.

link
igouy 1202 days 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.)

link