Re: [PATCH:MI] Return a subset of a variable object's children

[Nick Roberts <nickrob@snap.net.nz>]

 > > Are you arguing against the general concept of variable objects?
 > 
 > Erm... yes. Could be seen as such.

With respect, I'm not sure that you know what you are talking about.  The
concept of variable objects predates MI and was take from Insight.  It hasn't
been developed overnight but over a long time by experienced Gdb developers,
i.e, not the likes of me.

 > > ...
 > > Presumably your one-shot 'children listing' requires all values to be
 > > printed each time.  Variable objects work by just printing the values
 > > which have changed.
 >  
 > I am fully aware of that. It has a very limited utility, though...
 > 
 > I basically have to fill, say, 20 lines in the typical 'Locals & Watchers'
 > view.
 > 
 > With a one-shot approach I can fire off 20 simple request, getting back
 > 20 simple results (say, a total of 1000 bytes of data) compare them with
 > the previous results myself, re-populate the view, mark changes etc.
 > No big deal as it happens at most once per user interaction. Easy and 
 > predictable. 

How do you know if an expression is still in scope?  How do you know that
an original variable is not currently shadowed by another with the same name?
How do you know how many elements are in an array, members in a structure?
These are some of the questions that variable objects address.

 > With the 'update notifications' I get an unpredictable amount of data
 > (there could be an array with a few thousand children after all, all
 > being changed, stalling my communication line for an unpredicatable
 > amount of time),

This is what we're currently discussing: ways to ensure that thousands of
variable objects aren't created when viewing arrays with thousands of elements.

 >                 _and_ the data I get is insufficient as it, for instance, 
 > does not tell me that a std::string has changed somewhere in the middle.
 > So I need to do a few 'one-shot evaluations' anyway to get the desired
 > results. All in all, less satisfactory.

And maybe the Python interface can address this.

-- 
Nick                                           http://www.inet.net.nz/~nickrob