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

["André Pönitz" <apoenitz@trolltech.com>]

[Sorry Nick for the private reply... I am still fighting the Mail client ;-}]

On Wednesday 30 April 2008 11:25:05 you wrote:
>  > > > I was thinking that only a small number of children would ever exist
>  > > > simultaneously.  Scrolling might make that a larger number but maybe
>  > > > it could be arranged to delete children that go out of view.
>  > > 
>  > > I wonder if deleting children that are not visible is possible/desirable.
>  > 
>  > Well, I would still prefer a simple toggle that would allow me to switch off
>  > any automatic creation of children and one-shot 'expression evaluation'
>  > >  > and one-shot 'children listing'. 
> 
> Are you arguing against the general concept of variable objects?

Erm... yes. Could be seen as such.

Variable objects are really nice and useful for displaying C-like structure if you
want a 1:1 display in the frontend when all (or at least most of) the state you
need can be kept in the debugger.

However, anything beyond that gets ugly and as soon as one arrives at 
the point where one basically duplicates a lot of the internal backend 
state in the frontend one develops the desire not to need to care for
the backend state at all...

>  > I would expect this to be much simpler to implement on the gdb side and
>  > gives all the flexibility needed (as far as I am concerned) on the
>  > frontend side.
> 
> 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. 

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), _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.

Andre'

 

>