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.jerdo...@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. > > --Chris > > On Mon, Oct 29, 2018 at 9:51 AM Armin Rigo <armin.r...@gmail.com> wrote: > >> Hi, >> >> On Sat, 27 Oct 2018 at 01:50, Steven D'Aprano <st...@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 >> >
_______________________________________________ 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/archive%40mail-archive.com
