Re: [platform-debug-dev] Design of "changed variable" support

[Darin_Wright@xxxxxxx]

I agree that presentation of "changed variables" needs debug model specific support. This will allow models that support a finer grained change resolution to report those changes (in the most efficient way possible).

The debug team has a counter proposal for implementing this support:

(1) We provide model specific support by having variables answer if they have changed since a specific time. Thus, the method added to IVariable would be:

public boolean hasChanged(long time)

This method will return true if the variable value has changed since the specified time (which is in the format of longs returned by System.currentTimeMillis()). We feel that the method #hasChanged() without specifying when/what the change is relative to, is insufficient. Since there could be multiple clients asking the same variable about changes, it seems time is the most flexible unit of measure. (For example, two views could be displaying the same variable). Most variables can have a simple implementation to support this - they just have to keep track of the last time its value changed.

(2) We will no longer use the disabled icon. We propose that the variables view and _expression_ view render changed items in red text. It is difficult for a model presentation to track variable changes, as the presentation is no view specific, and would have to maintain a cache of which variables it rendered when in order to display proper icons (and without adding special API to a model presentation to handle this).

We believe this addresses all of the points and bugs below. The only problem we see is that the solution is dependent on the underlying system's time resolution. That is, if a variable can be queried twice for a change, and it does change in a faster amount of time than the smallest  time unit on a platform, we will not detect the change. However, we believe this should not be an issue when stepping in the debugger.

Please let us know if this does or does not address your concerns and issues.

Thanks,

Darin

boxall@xxxxxxxxxx Sent by: platform-debug-dev-admin@xxxxxxxxxxx 03/20/2002 01:01 PM Please respond to platform-debug-dev

To:        platform-debug-dev@xxxxxxxxxxx         cc:                 Subject:        [platform-debug-dev] Design of "changed variable" support

I am converting from our own implementation of "changed variable" support
to make use of the core debug support and have run into some problems.

Before I get into the details I understand that by having core do the
implementation, all plugins can benefit from this support.
I would like debug plugins have the option of how to implement this
support.

Here are my reasons:

1) The current implementation relies on a comparison between the current
and previous values to decide if it has changed.

> We have debug engines that can determine that a variable has changed even
when it has been updated with the same value.

> I would like to see a new method on the IVariable interface:
IVariable.hasChanged()  that would be called when the plugin implements
their own support.

2) The use of a "disabled" icon to indicate that a variable has not changed
conflicts with the concept of disabling the monitoring of a variable.  Our
plugin allows a user to enable/disable the monitoring of a variable in the
same way you can enable/disable a breakpoint.

> I suggest using an icon decorator (a small delta symbol) that would
overlay the plugin supplied icon for that variable.
-or-
> Allow us to have muliple icons.   Our model presentation returns
different icons based on the "changed" state.

3) Current support doesn't show the top node of complex variables with
children, as changed if anyone of the children has changed.   This is
especially so if the children are not currently visible.

> Clearly the UI can't be expected to know the state of all the children.
Only the engine would know that some leaf node changed.  To the user it
would be valuable to know without expanding the whole variable tree that
something had changed in it.

> Another problem is that expanding a variable should show the node that
changed, something that the UI change implementation wouldn't be able to
detect.

4) We have other views that also show "changed" state and need to make them
consistent.   Having control ourselves would allow us to do that.
Otherwise we would have to make it look the same as the "Variables" view.

5) This could be memory hungry if the contents of the variables are very
large.

The following I believe are bugs and if you say so I will open them as
such.

Bug 1)   Clicking on one stack frame and then another loses the "changed"
state.    If I haven't moved the program the state should be remembered
even when I change stackframes.

Bug 2) Changed only works if I step.   It doesn't appear to work if I run
to a breakpoint even if it is in the same stackframe, which is a valid
operation.


Bottom line:   As nice as it is to have a common default implementation of
the "changed variable" support I think there are enough problems to either
put the responsiblity back on the IVariable to determine if it has changed.
(IVariable.hasChanged()) or allow a plugin to disable the internal method
and implement their own.




Alan Boxall - IBM Distributed Debugger
D1/121/8200/MKM
internet id : boxall@xxxxxxxxxx
Notes: Alan Boxall/Toronto/IBM @ IBMCA
Phn:(905)413-4117   T.L. 969-4117
Fax:(905)413-4850   T.L. 969-4850

_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev