Hi, On Sat, 27 Oct 2018 at 01:50, Steven D'Aprano wrote:

[...]

...

So I was wondering if it would be possible to keep that context around if you are in the debugger and rewind the execution point to before the statement was triggered.

I think what you are looking for is a reverse debugger[1] also known as a time-travel debugger.

I think it's a bit different. A reverse debugger is here to debug complex conditions in a (static) program. What Ed is looking for is a way to catch easy failures, fix the obviously faulty line, and continue running the program. Of course I can't help but mention to Ed that this is precisely the kind of easy failures that are found by *testing* your code, particularly if that's code that only runs after hours of other code has executed. *Never* trust yourself to write correct code if you don't know that it is correct after waiting for hours. But assuming that you really, really are allergic to tests, then what you're looking for reminds me of long-ago Python experiments with resumable exceptions and patching code at runtime. Both topics are abandoned now. Resumable exceptions was a cool hack of the interpreter that nobody really found a use for (AFAIR); patching code at runtime comes with a pile of messes---it only works in the simple cases, but there is no general solution for that. A bientôt, Armin.

I have another idea on this. What about the idea of starting the program, and then a few minutes later, starting the same program a second time. If the first program errors, you could examine the second one which is a little bit behind. Before starting the second one, perhaps you could even make a copy of the second one and pause it for a few minutes before restarting, in case the second one also errors out, and so on. This would be more useful only in the case of deterministic errors. --Chris On Mon, Oct 29, 2018 at 11:59 AM Chris Jerdonek wrote:

A simpler feature that could possibly help him (assuming there isn't any external state to deal with) would be the ability to save everything at a certain point in time, and then resume it later. He could rig things up to save the state e.g. after every hour: 1 hour, 2 hours, etc. Then if an error occurs after 2.5 hours, he could at least start resuming after 2 hours. This could be viewed as a cheap form of a reverse debugger, because a reverse debugger has to save the state at every point in time, not just at a few select points.

--Chris

On Mon, Oct 29, 2018 at 9:51 AM Armin Rigo wrote:

...

Hi,

On Sat, 27 Oct 2018 at 01:50, Steven D'Aprano wrote:

...

[...]

...

So I was wondering if it would be possible to keep that context around if you are in the debugger and rewind the execution point to before the statement was triggered.

I think what you are looking for is a reverse debugger[1] also known as a time-travel debugger.

I think it's a bit different. A reverse debugger is here to debug complex conditions in a (static) program. What Ed is looking for is a way to catch easy failures, fix the obviously faulty line, and continue running the program.

Of course I can't help but mention to Ed that this is precisely the kind of easy failures that are found by *testing* your code, particularly if that's code that only runs after hours of other code has executed. *Never* trust yourself to write correct code if you don't know that it is correct after waiting for hours.

But assuming that you really, really are allergic to tests, then what you're looking for reminds me of long-ago Python experiments with resumable exceptions and patching code at runtime. Both topics are abandoned now. Resumable exceptions was a cool hack of the interpreter that nobody really found a use for (AFAIR); patching code at runtime comes with a pile of messes---it only works in the simple cases, but there is no general solution for that.

A bientôt,

Armin. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/chris.jerdonek%40gmail.co...

On Tue, Oct 30, 2018 at 11:10 AM Nathaniel Smith wrote:

I also wonder if it would be useful to give pdb the ability to break when an exception is *raised*, rather than when it's caught?

This is veering into python-ideas territory (or even python-list), but the first big concern that comes to my mind is that there are a LOT of places where exceptions are raised, and many of those exceptions end up being used for perfectly-normal flow control. So this would potentially add even more overhead to the raising of exceptions - basically, you have to retain state as if you're suspending a generator. But it'd be an extremely cool concept. Exceptions already snapshot all their locals, and this would just expand on that a bit. ChrisA

When I have a bug that only happens after hours of run time, I try to find a much shorter test case that reproduces it. -- Greg