Difference between revisions of "EiffelDebugger"
(→Please add your suggestions below) |
(→Crazy Brainstorms) |
||
Line 63: | Line 63: | ||
== Crazy Brainstorms == | == 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. | + | * 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. |
= Current known limitations = | = Current known limitations = |
Revision as of 04:34, 18 July 2007
This page is about the Eiffel debugging facilities integrated inside Eiffel Studio
Contents
Overview
Work in progress
Current
- Building this wiki page, with list of suggested features.
Done
- Improve the role of estudio/ec(ewb)/debugger/application
Now estudio is only an ec launcher ec contains the classic eiffel debugger (ewb) and when needed launch the eiffel debugger daemon ecdbgd The eiffel classic debugger daemon ecdbgd launches and control the debuggee application There is no more need for ebench lib and other linking particularities. Now thr workbench ec is able to debug and to be debugged at the same time. This helps a lot improving the classic eiffel debugger. Don't forget, you can (now) always start the graphical EiffelStudio using ec -gui estudio is doing more or less this, it just hide the text console, provide a splash screen and allow various customization, but it is just an easy launcher for EiffelStudio ec -gui
- Provide a way to pass environmental variables values to the debuggee
Suggestions
Here is a list of features we could think of, or suggested by Eiffel Studio users. There is no order for now.
- 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
- 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
- Add tooltip on editor to show value of "pointed" variable
- Being able to abort an expression evaluation
On dotnet there is a timeout, if the expression is taking too long, but for now nothing similar on classic
- having named group of breakpoints, this could enable use to Enable/Disable groups of breakpoints
- auto save Breakpoints more often
Currently, the breakpoints are saved after : end of debugging session, end of compilation, end of Eiffel Studio session
- 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)
To be able to display XML data as XML, and so on
- When an assertion fails need option to ignore it and continue
- merge call stack tool with threads tool using a tree_enabled grid
Please add your suggestions below
(this way it is easier for persons working on the debugger to notice new suggestions) ... Add your suggestions here ...
- Allow old syntax in the watch tool or put all old evaluations in the Object tool. This way, if we have a postcondition that goes "index = old index + 1" and it gets violated, it's possible to see the old value of index to better understand the cause of the assertion violation.
- Allow step-by-step execution of the invariants evaluation.
- Object viewer for HASH_TABLE.
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.