Dave Angel wrote:
Scott David Daniels wrote:
Patrick Sabin wrote:
Horace Blegg schrieb:
You might consider using a VM with 'save-points'. You run the
program (in a debugger/ida/what have you) to a certain point
(logical point would be if/ifelse/else statements, etc) and save the
VM state. Once you've saved, you continue. If you find the path
you've taken isn't what you are after, you can reload a previous
save point and start over, trying a different path the next time.
That was my idea to implement it. I thought of taking snapshots of
the current state every time a "unredoable instruction", e.g random
number generation, is done.
Remember, storing into a location is destruction.
Go over a list of VM instructions and see how many of them are undoable.
Read his suggested approach more carefully. He's not "undoing"
anything. He's rolling back to the save-point, and then stepping
forward to the desired spot.
Right, I did misread "unredoable" as "undoable." However, I suspect a
surprising amount of stuff is "unredoable" -- iff the random number
generator counts as one of those things. The random number seeder is
unredoable with empty args, but running the generator once seeded is
predictable (by design). If you don't capture the random number state
as part of your "snapshot," _lots_ of C space storage will be in the
same class, and you are stuck finding the exceptional "safe to use"
cases, rather than the exceptional "unsafe to use." Similarly, system
calls about time or _any_ callback (when and where executed) create
snapshot points, and I suspect roll forwards will be relatively short.
In fact, in some sense the _lack_ of a callback is unredoable.
--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list
