(original) (raw)
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 <chris.jerdonek@gmail.com> 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.--ChrisOn Mon, Oct 29, 2018 at 9:51 AM Armin Rigo <armin.rigo@gmail.com> wrote:Hi,
On Sat, 27 Oct 2018 at 01:50, Steven D'Aprano <steve@pearwood.info> 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.com