Debug Expressions

["Darin Wright/WPG/OTI" <Darin_Wright@xxxxxxx>]

As more debuggers are developed for Eclipse, there will be a need for
generic "Expression" support. The following document provides a proposal
for dealing with this. Comments welcome.



Darin

Title: Debug Expressions

Debug Expressions

This document describes a proposal for generic “expressions” to be incorporated into the platform debug model and UI. This is intended to allow specific debug architectures to provide implementations of expressions to support features such as an inspector and/or watch list.

 

An _expression_ is a snippet of code that can be evaluated to produce a value. The context/binding required to evaluate an _expression_ varies by debug model/architecture/language, and by user intent. For example, a Java _expression_ requires a context in which to be compiled (a Java project), and a thread in which to be evaluated. Furthermore, an _expression_ may need to be evaluated at a specific location in a program (for example, at a breakpoint/line where certain variables referenced in the _expression_ are visible/allocated). A user may want to evaluate an _expression_ once to produce a value than can be “inspected” iteratively (i.e. like a VAJ inspector), or they may wish to evaluate an _expression_ iteratively producing new values each time (i.e. as in a watch list).

 

The following definition of expressions is proposed:

 

·        An _expression_ is a debug element with two attributes – an _expression_ (source code snippet, i.e. a java.lang.String), and a current value (i.e. an org.eclipse.debug.core.IValue). The binding of an _expression_ is implementation specific. That is, the time/location/context at which an _expression_ is evaluated is up to each implementation. Expressions are required to fire debug events to allow clients to know when an _expression_ has been created, when an _expression_ has expired, and when the value of an _expression_ has changed. An _expression_ does not need to be bound to a debug target or launch, and is allowed to return “null” when queried for its debug target or launch.

 

The debug UI would provide an “_expression_ View” (which would replace the current “Inspector View”):

 

·         The _expression_ view is similar to the variables view, which displays expressions and their values. Values may be complex data structures, as in the variables view, and have children that can be expanded and viewed. The view would contain a “details” area, as the variables view does, to show the details of a selected value.

·         A debug model presentation will be given the chance to render an “_expression_”, but the debug UI will also provide a default icon and label. This would allow specific implementations to provide special icons to distinguish between “watch items” and “inspected items”.

·         The _expression_ view listens for debug events to know when to update the view (i.e. as expressions are created, they are added to the view; as expressions are terminated, they are removed from the view; and as expressions are changed, their value is updated).

·        Standard remove/remove all actions will be available in a view. When an _expression_ is removed, it will be sent a message to be “disposed”, such that it can do any cleanup required. (Expressions can also remove themselves from the view by firing a terminate event – for example, an _expression_ that represents an object being inspected would terminate when its VM terminates).

·        The creation of an _expression_ is controlled by clients. There is no general way to enter/create an _expression_ – it is client defined. For example, a Java _expression_ is created by performing an “inspect” action in the java editor.

·        Expressions may be persisted across workbench invocations. For example, “watch items” are expressions that are evaluated each time a program suspends. Persistence is controlled by specific implementations. That is, if an _expression_ is to be persisted, the _expression_ should be re-created by its plug-in at startup and added to the _expression_ view.

·        The _expression_ view could be filtered by debug model (similar feature request exists for breakpoints view). Thus, when a debug target is selected, only those expressions that pertain to that debug model are displayed. (The filter is controlled by a toggle button in the toolbar – i.e. “show all expressions/show expressions associated with selected debug target”).

·        To support advanced _expression_ evaluation, the details area of the variables and _expression_ view should allow typing (currently, it is read-only). For example, this will allow the Java debugger to perform evaluations in the context of a selected item in the variables view/_expression_ view. The “read-only” property of the details area could be dynamic, and could be controlled by the IValueDetailListener inteface. For example, a flag could be added to the interface that tells listeners if the value is read-only. This could also provide support for a new method of “value changing” – i.e. entering a new value and pressing CTRL-S. Clients can contribute actions to the detail view pop-up menu using the standard workbench extensions. It would be nice if we could also alow the contribution of code assist and formatting (not sure how difficult this is). What we eventually want to have is a detail area that acts like a display view when viewing “Java details”. Perhaps we could allow a debug model presentation to supply its own “details area” widget/view. The debug UI would provide a simple default view (what we have currently).

 

 

 

Copyright © 2001 Object Technology International, Inc.