<div dir="ltr">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.<div><br></div><div>--Chris</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 29, 2018 at 11:59 AM Chris Jerdonek <<a href="mailto:chris.jerdonek@gmail.com">chris.jerdonek@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>--Chris</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 29, 2018 at 9:51 AM Armin Rigo <<a href="mailto:armin.rigo@gmail.com" target="_blank">armin.rigo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
On Sat, 27 Oct 2018 at 01:50, Steven D'Aprano <<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>> wrote:<br>
> [...]<br>
> > So I was wondering if it would be possible to keep that context around<br>
> > if you are in the debugger and rewind the execution point to before<br>
> > the statement was triggered.<br>
><br>
> I think what you are looking for is a reverse debugger[1] also known as<br>
> a time-travel debugger.<br>
<br>
I think it's a bit different.  A reverse debugger is here to debug<br>
complex conditions in a (static) program.  What Ed is looking for is a<br>
way to catch easy failures, fix the obviously faulty line, and<br>
continue running the program.<br>
<br>
Of course I can't help but mention to Ed that this is precisely the<br>
kind of easy failures that are found by *testing* your code,<br>
particularly if that's code that only runs after hours of other code<br>
has executed.  *Never* trust yourself to write correct code if you<br>
don't know that it is correct after waiting for hours.<br>
<br>
But assuming that you really, really are allergic to tests, then what<br>
you're looking for reminds me of long-ago Python experiments with<br>
resumable exceptions and patching code at runtime.  Both topics are<br>
abandoned now.  Resumable exceptions was a cool hack of the<br>
interpreter that nobody really found a use for (AFAIR); patching code<br>
at runtime comes with a pile of messes---it only works in the simple<br>
cases, but there is no general solution for that.<br>
<br>
<br>
A bientôt,<br>
<br>
Armin.<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/chris.jerdonek%40gmail.com" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/chris.jerdonek%40gmail.com</a><br>
</blockquote></div>
</blockquote></div>