The only mechanism that Delve offers for time travel is the checkpoint and restart commands. This means that you can't travel to a time in recorded history unless you've already been to that time by other means and checkpointed it. This is particularly inconvenient for debugging a LiveRecorder recording, because the interesting parts of the recording are usually at the end, but this is unreachable except by replaying the whole recording.
Possible solutions:
- Add a custom command or commands for time travel (compare
ugo in UDB).
- Extend the
restart command so that if the argument can be interpreted as a time in recorded history (or a special case like start or end) then travel to that time instead of interpreting the argument as a checkpoint number. A downside of this is that checkpoints are numbered and so are bbcounts, so that some arguments will be ambiguous.
The only mechanism that Delve offers for time travel is the
checkpointandrestartcommands. This means that you can't travel to a time in recorded history unless you've already been to that time by other means and checkpointed it. This is particularly inconvenient for debugging a LiveRecorder recording, because the interesting parts of the recording are usually at the end, but this is unreachable except by replaying the whole recording.Possible solutions:
ugoin UDB).restartcommand so that if the argument can be interpreted as a time in recorded history (or a special case likestartorend) then travel to that time instead of interpreting the argument as a checkpoint number. A downside of this is that checkpoints are numbered and so are bbcounts, so that some arguments will be ambiguous.