Implement an engine for debugging purposes

[swagner]

Developing complex algorithms is a quite difficult and error-prone task. Therefore a special engine for debugging algorithms would be very helpful. This engine should offer more insights into the operator graph and the scope tree during the execution of an algorithm.

[swagner]

Milestone 3.2 deleted

[epitzer]

Preliminary version of debug engine with stepping, execution stack view and current operator scope view (r4743)

[epitzer]

Correct reference hint path (r4744)

[epitzer]

Show and link operator parameters and variables (r4746)

[epitzer]

add license (r4747)

[epitzer]

Show expected parameter values and include type information in tool tip (r4753)

[epitzer]

navigate execution contexts show active scopes (r4759)

[epitzer]

Show parameters of active execution context in DebugEngine (r4765)

[epitzer]

Prevent stepping execution on empty execution stack (r4827)

[epitzer]

Refactoring and modularization of DebugEngine (r4871)

[epitzer]

Complete overhaul of DebugEngine (r4876)

[epitzer]

Many small improvements(r4903)

• suppress logging during execution
• add refresh button
• optionally skip over execution stack operators
• expand all tree views and scroll to top node
• show operator on click on atomic operation
• add build.cmd

[epitzer]

Add operator trace view (r4904)

[epitzer]

Several GUI improvements (r4909)

• add icons and tool tips
• add support for suspending the operator trace view
• faster skipping of stack-only operations
• remove log view and execution time view

[swagner]

mkommend, please review this first and return it to me for a second review afterwards. Thanks.

[epitzer]

Better display and highlighting of scopes (r4930)

[epitzer]

Add tool tip for current scope (r4931)

[mkommend]

Reviewing comments

• DebugEngine
  • Is it always possible to cast an IOperation to an IExecutionContext? Otherwise checks must be inserted.
  • IOperation.Operator could be null.
  • In my opition the ignoreNextBreakPoint flag should be removed as this adds additional complexity.

[mkommend]

Minor changes in DebugEngine with r4946.

[epitzer]

Simpler breakpoint handling, fix cloning, prevent stepping while running (r4947)

[mkommend]

review comments:

• set contents of detail views to null if the DebugEngine is running
• create seperate class for OperatorTrace
• permanently highlight execution contexts' scopes
• check if execution context has always the same parameters as the operator => remove paramters view

[epitzer]

• create own class for OperatorTrace
• remove unnecessary event handlers
• prevent flickering while stepping
• permanently highlight execution context's scope

(r4993)

[epitzer]

Move parent tracing to operator trace class (r4996)

[epitzer]

remove resources, add license headers, update plug-in dependencies (r4998)

[mkommend]

review comments:

• Is the CurrentOperator property really necessary? As far as I can see it only gets the value of CurrentOperation.Operator.
• There should also be events for changes of the ExecutionStack, the OperatorTrace and the Log, similar to CurrentOperationChanged event. Another possibility would be to declare the DebugEngine as sealed class.
• Is it possible to make the RegisterParenthood method private and to remove the call to it in DebugEngine line 283.
• OperatorTrace.Generate should be static and return a new OperatorTrace object.
• The Suspend- and ResumeUpdate methods in the OperatorTraceView and the ExecutionStackView are not needed anymore and should be removed.

[epitzer]

Replying to mkommend:

Is the CurrentOperator property really necessary? As far as I can see it only gets the value of CurrentOperation.Operator.

The currentOperator field is only set during the execution of an operator and is used to abort the operator.

There should also be events for changes of the ExecutionStack, the OperatorTrace and the Log, similar to CurrentOperationChanged event. Another possibility would be to declare the DebugEngine as sealed class.

The references to these objects can never change during the lifetime of a DebugEngine (except during cloning and serialization), the setters will been marked private.

Is it possible to make the RegisterParenthood method private and to remove the call to it in DebugEngine line 283.

Tracking parenthood is one of the two core functionalities provided by this class and cannot be removed.

OperatorTrace.Generate should be static and return a new OperatorTrace object.

The call to Generate uses the collected parenthood information stored inside the OperatorTrace to repopulate itself and can, therefore, not be made static.

The Suspend- and ResumeUpdate methods in the OperatorTraceView and the ExecutionStackView are not needed anymore and should be removed.

This will fixed in the next commit.

[epitzer]

private setters for ExecutionStack, OperatorTrace and Log, remove unneeded SuspendUpdate and ResumeUpdate methods (r5001)

[epitzer]

unseal views, rename OperatorTrace.Generate to Regenerate, and remove questionable virtual from property with private setter (r5002)

[epitzer]

replace parameter view with context menu to access variable values in execution context view (r5003)

[epitzer]

disable context menu "Show Value" if value is null or not an IContent (r5077)

[swagner]

Integrated DebugEngine into trunk in r5114.

epitzer please review the trunk integration and delete the DebugEngine branch, if everything is ok. Thanks.

[swagner]

Fixed project references in r5115.

[swagner]

The DebugEngine is really great. Many thanks to epitzer for implementing it.

Some review comments on the UI:

• Using a bold font for highlighting nodes in a tree view may lead to clipped node texts (see for example the "Global Scope" tree node). This probably is a windows forms bug. I recommend to avoid bold fonts. Instead only foreground or background colors should be used.
• The text of the context menu in the execution context tree view should be "Show Actual Value" and not "show actual value".
• When the user right clicks into the execution context tree view, the selected node should be changed. Otherwise the context menu is shown for the currently selected node and not for the clicked node.
• The margins of controls inside group boxes are not equal. Some of them are too small (for example in the execution stack group box, the execution context group box, etc.).
• The actual names of lookup parameters should be shown in the execution context tree view. I would recommend the format "<name>=<value>" for value parameters and "<name> (<actual name>)" for lookup parameters.
• When stepping through an algorithm, in each second step the operation group box contains no data. What is the purpose of this behavior?
• What is the purpose of the labels "Context", "Atomic" and "Collection"? It seems to me that these labels do not really provide much information. Maybe they can be removed?
• Saving an algorithm with a debug engine takes a long time. Is it possible to improve the persistence of debug engines?

[epitzer]

• fixed truncation of bold text in TreeView
• changed "show actual value" initial caps
• select node on right click
• fixed margins
• include actual name for parameters
• remove unnecessary labels

(r5116)

[epitzer]

(r5117)

• Disable detailed logging while not stepping for drastic reduction in log size
• Optionally disable operator trace for much faster execution and persistence (disabled by default)
• Initially enable stepping over stack operations

[epitzer]

Show empty operator trace when not enabled (r5121)

[epitzer]

Enable showing actual values for parameters in non-current execution contexts (r5122)

[epitzer]

Correctly select parent.tag instead of just parent when trying to show the actual value (r5124)

[epitzer]

(r5146)

• Show a different icon for breakpoints
• Show an icon for the active operation

[epitzer]

@swagner: Please review final changes and consider for release.

[epitzer]

deleted branch (r5167)

[epitzer]

Correctly show whether operator trace is enabled (r5174)

[swagner]

Great thanks. I reviewed the last changes and came across some additional comments:

• It seems that nested operation collections are not correctly shown in the execution stack. For example, have a look at the execution stack after the SubScopesProcessor following the selector in the GA & TSP sample is executed:

Shown execution stack:
+ - 2 Operations
| + - SubScopesProcessor
+ - 2 Operations
  + - EmptyOperator
  + - ChildrenCreator

Correct execution stack:
+ - 2 Operations
  + - 2 Operations
  | + - EmptyOperator
  | + - ChildrenCreator
  + - SubScopesProcessor

• It should be shown in the execution stack, if an operation collection is marked as parallel or not. I would recommend to simply change the tree node text to "x Parallel Operations" in that case.
• Maybe single steps should also be executed asynchronously. Some steps really take some time and the UI freezes for a noticeable time in that case.
• Please add spaces before and after equal signs and parentheses in the execution context view and the scope view (for example "Maximization = False" or "Quality (TSPTourLength) = ItemArray<DoubleValue>").
• Is the operator trace list view correctly disabled, if the operator trace is not enabled? I would expect that it to be grayed out in that case.
• null values of parameters should be visualized as "null" instead of displaying nothing.

[epitzer]

Properly show nesting in execution stack and remove unused suspension code and display "Parallel" for parallel operation collections (r5219)

[epitzer]

Better spacing for parameters and display of "null" for null values in parameter view (r5220)

[epitzer]

Disable list view control in operator trace if operator trace is itself disabled (r5221)

[epitzer]

Use a background worker to execute single steps to prevent the GUI locking up for long-running operations (r5222)

[epitzer]

@swagner: Thanks for the feedback! All issues raised in #comment:57 should be fixed now.

[swagner]

Perfect, thanks.