| Summary: | [variables] Add a smart or auto variables view in the debugger | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Ed Burnette <ed.burnette> |
| Component: | Debug | Assignee: | JDT-Debug-Inbox <jdt-debug-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | christian.koestlin, frank.musolf |
| Version: | 2.1 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Ed Burnette
Note: there is no support in JDI to retrieve "next" variables. We can only see what is currently allocated. I am not sure how this is different than what we have already. The variables view will display "this", children of which are member variables. All locals and arguements are also displayed (up to the point of execution). It goes to the source (or the ADT) to get the variables. Here's the difference
between the auto and variables view. Let's say that you are debugging a class
method like this:
1: void aMethod(int nItems, Object[] aItems)
2: {
3: int total;
4: total = nItems * 2;
5: nItems = total;
6: _items = nItems;
7: anotherMethod(aItems[0], aItems[1]);
8: }
And the class variables were something like this:
class aClass
{
int _items;
double _ratio;
String _name;
...
}
You step to line 4. The variables view might show these variables:
+ this
nItems = 1
+ aItems
total = <undefined>
In order to see the member variables you'd have to expand 'this'. Also if the
class had a lot of member variables then you would likely be seeing a lot of
stuff you don't care about right now.
The auto view might show these variables when stopped at line 4:
total = <undefined>
nItems = 1
The exact heuristic to decide which variables to show is up for debate, and
maybe "total" wouldn't be displayed if it's not allocated yet. But the basic
idea is that it shows you the variables you are likely to want to see when
debugging this particular statement. If you single step to line 5 then the
auto view would change to:
total = 2 <highlighted to indicate a change>
nItems = 1
_items = 0
Then if you step to line 6 the auto view would change to:
total = 2 <no longer highlighted>
nItems = 2 <highlighted>
_items = 0
+ aItems
The heuristic (just for illustration) might be something like:
start with a null list
for each line in (previous, current, next) do
tokenize the source code for line
for each potential variable in (tokenized list) do
add variable to list if it's not already there
done
done
for each potential variable in list do
try to add variable to view
if that fails (i.e., it's not really a variable), ignore it.
done
I know that the user can manually inspect whatever variables and expressions
they want but it's just that, manual. A good auto view would do what they want
80% of the time without any manual intervention.
Marking as later, for post 2.1 consideration. *** Bug 55344 has been marked as a duplicate of this bug. *** *** Bug 73525 has been marked as a duplicate of this bug. *** As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you. |