EiffelDebugger - Revision history

Jfiat at 13:29, 28 May 2008

2008-05-28T13:29:06Z

Jfiat: /* Projects */

2008-05-26T09:06:27Z

‎Projects

Jfiat: /* Work in progress */

2008-05-26T09:04:23Z

‎Work in progress

Jfiat: /* Suggestions */

2007-11-12T16:26:34Z

‎Suggestions

Clemahieu: /* Crazy Brainstorms */

2007-07-19T15:44:19Z

‎Crazy Brainstorms

Jasonw: /* Crazy Brainstorms */

2007-07-19T11:54:47Z

‎Crazy Brainstorms

Jasonw: /* Crazy Brainstorms */

2007-07-19T11:23:38Z

‎Crazy Brainstorms

Jasonw: /* Crazy Brainstorms */

2007-07-19T11:23:18Z

‎Crazy Brainstorms

Jasonw: /* Crazy Brainstorms */

2007-07-18T13:43:39Z

‎Crazy Brainstorms

Jasonw: /* Crazy Brainstorms */

2007-07-18T13:38:28Z

‎Crazy Brainstorms

@@ Line 8: / Line 8: @@
 = Work in progress =
 == Documentation ==
-* [[InsideEiffelDebugger]]
+* [[Inside the Eiffel Debugger]]
 * [[ExecutionRecordAndReplay|Execution recording and Replay mechanism]]

@@ Line 7: / Line 7: @@
 = Work in progress =
-== Projects ==
+== Documentation ==
 * [[ExecutionRecordAndReplay|Execution recording and Replay mechanism]]
 == Current ==
 * Building this wiki page, with list of suggested features.

@@ Line 7: / Line 7: @@
 = Work in progress =
 == Current ==
 * Building this wiki page, with list of suggested features.

@@ Line 31: / Line 31: @@
 There is no order for now.
-* being able to set/modify an env variable for an execution, aka "Edit and continue" feature
+* '''DONE''' - being able to set/modify an env variable for an execution, aka "Edit and continue" feature
 * Being able to Attach/Detach Eiffel process
-* being able to evaluate a method
+* '''DONE''' - being able to evaluate a method
 * Add functionalities on Breakpoint
 ** tracepoint: output message when a stop point is reached
 ** changepoint: stop when a value changed
 * include direct variable values in exception trace
-* Add an "auto values" panel (similar to watches point, but using the current feature/line to show "near" variables values
+* '''DONE''' - Add an "auto values" panel (similar to watches point, but using the current feature/line to show "near" variables values
 * Add tooltip on editor to show value of "pointed" variable
 * Being able to abort an expression evaluation
@@ Line 47: / Line 47: @@
 * Ctrl-C on STRING object tool's tree should copy the whole string
   For now, it copy the value displayed in the debugger's grid
-* Improve the expanded display, to be more like Debug Viewer (like VS2005)
+* '''DONE''' - Improve the expanded display, to be more like Debug Viewer (like VS2005)
   To be able to display XML data as XML, and so on
 * When an assertion fails need option to ignore it and continue

@@ Line 64: / Line 64: @@
 == Crazy Brainstorms ==
 * A way to mark already executed lines with a different background, so when you are debugging a large feature (a typical example is a feature with nested if-then-else), you'll know the execution context (i.e., which branches were executed). For loops, we can use 2 different background colors, one for the current iteration, the other for former iterations. To implement this, we need to have some sort of callbacks every time when we meet the starting slot of a branch, such as if, else, inspect. From this along with the current execution point, we can infer which lines were actually executed. We only need to keep the information of the slots that are in current call stack. A way to achieve this is by generating invisible breakpoints, i.e., breakpoints that not visible to programmers, they are just used to record information. All the marked lines together provides a dynamic slicing of the running program. But this (I mean, only record branch start slots) is just for optimization. It lacks of generality. Because if we have callbacks for every slot, we can provide a event-based programmable debugger interface.
 = Current known limitations =

@@ Line 63: / Line 63: @@
 == Crazy Brainstorms ==
-* A way to mark already executed lines with a different background, so when you are debugging a large feature (a typical example is a feature with nested if-then-else), you'll know the execution context (i.e., which branches were executed). For loops, we can use 2 different background colors, one for the current iteration, the other for former iterations. To implement this, we need to have some sort of callbacks every time when we meet the starting slot of a branch, such as if, else, inspect. From this along with the current execution point, we can infer which lines were actually executed. We only need to keep the information of the slots that are in current call stack. '''All the marked lines together provides a dynamic slicing of the running program.''' But this (I mean, only record branch start slots) is just for optimization. It lacks of generality. Because if we have callbacks for every slot, we can provide a event-based programmable debugger interface.
+* A way to mark already executed lines with a different background, so when you are debugging a large feature (a typical example is a feature with nested if-then-else), you'll know the execution context (i.e., which branches were executed). For loops, we can use 2 different background colors, one for the current iteration, the other for former iterations. To implement this, we need to have some sort of callbacks every time when we meet the starting slot of a branch, such as if, else, inspect. From this along with the current execution point, we can infer which lines were actually executed. We only need to keep the information of the slots that are in current call stack. All the marked lines together provides a dynamic slicing of the running program. But this (I mean, only record branch start slots) is just for optimization. It lacks of generality. Because if we have callbacks for every slot, we can provide a event-based programmable debugger interface.
 = Current known limitations =