Difference between revisions of "ExecutionRecordAndReplay"
m |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
[[Category:EiffelDebugger]] | [[Category:EiffelDebugger]] | ||
| + | {{UnderConstruction}} | ||
| + | |||
| + | Quick notes about it, need to describe it better (later) | ||
= Execution Record and Replay mechanism = | = Execution Record and Replay mechanism = | ||
| + | *First check the documentation at http://docs.eiffel.com/book/eiffelstudio/execution-record-and-replay | ||
| + | *The basic idea, is to record the execution (i.e calls) and the various assignments (including of course object creation). | ||
| + | Then, when the user decides, he can replay (and restore the variables and attributes' values) according to the records ... | ||
| + | and then, you can use the EiffelStudio tools to browser, inspect values, and even evaluate expression on those values (be careful, that your expression evaluation won't be recorded ...). When you are done replaying the recorded execution, the "replayer" will revert changes, and should return the system in the same state it was before the user started the replay. | ||
| + | * Note that any external calls might introduce erroneous record. For instance if you have a file access, or a socket, or database ... anything which change outside the scope if the Eiffel code, it won't be recorded, and thus won't be replayed. | ||
| + | * And the "replayer" is not able to revert a once function to its "unevaluated" state. | ||
| + | |||
== Recording == | == Recording == | ||
| + | * The generated C code contains some calls such to RTDBG.*, those calls will trigger various events such as entering/exiting a feature, or local assignment, attribute assignment ... | ||
| + | * The implementation of the recording (and replay) is done in {RT_EXTENSION} (and other RT_DBG_* classes). Check RT_EXTENSION.notify (a_id: INTEGER; a_data: TUPLE). | ||
| + | * .. to be completed ... | ||
| + | |||
== Replay == | == Replay == | ||
| + | *The replay is controlled by EiffelStudio through the debugger (and expression evaluation .. i.e: remote call to control the debuggee) | ||
| + | * .. to be completed ... | ||
Latest revision as of 09:14, 29 June 2009
Not Ready for Review: This Page is Under Development!
Quick notes about it, need to describe it better (later)
Execution Record and Replay mechanism
- First check the documentation at http://docs.eiffel.com/book/eiffelstudio/execution-record-and-replay
- The basic idea, is to record the execution (i.e calls) and the various assignments (including of course object creation).
Then, when the user decides, he can replay (and restore the variables and attributes' values) according to the records ... and then, you can use the EiffelStudio tools to browser, inspect values, and even evaluate expression on those values (be careful, that your expression evaluation won't be recorded ...). When you are done replaying the recorded execution, the "replayer" will revert changes, and should return the system in the same state it was before the user started the replay.
- Note that any external calls might introduce erroneous record. For instance if you have a file access, or a socket, or database ... anything which change outside the scope if the Eiffel code, it won't be recorded, and thus won't be replayed.
- And the "replayer" is not able to revert a once function to its "unevaluated" state.
Recording
- The generated C code contains some calls such to RTDBG.*, those calls will trigger various events such as entering/exiting a feature, or local assignment, attribute assignment ...
- The implementation of the recording (and replay) is done in {RT_EXTENSION} (and other RT_DBG_* classes). Check RT_EXTENSION.notify (a_id: INTEGER; a_data: TUPLE).
- .. to be completed ...
Replay
- The replay is controlled by EiffelStudio through the debugger (and expression evaluation .. i.e: remote call to control the debuggee)
- .. to be completed ...
