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

[Vladimir Prus <vladimir@codesourcery.com>]

Marc Khouzam wrote:

>> If a variable is deleted from variables tree (because you left the scope
>> where that variable is defined), then you should delete variable object.
>> There's no reliable way to detect that exactly same variable is in scope
>> again and must be shown, so no reuse is possible.
> 
> We chose a more passive approach.  The frontend relies entirely on GDB to
> know if a varObj has gone out-of-scope.  Since GDB reports this
> only if the varObj is given the var-update command, we don't get to know
> it very often, because we only use the var-update command for varObj we want
> to know the value of.
> I believe an example is in order :-)
> 
> Say you have local variable bar in method foo().
> We create a varObj for bar.  Once we return from foo(), there is no longer
> a local variable bar, so we don't send a -var-update for it, which in turn
> means we don't realize that it is out-of-scope and we don't delete it.
> 
> What this implies in the end is that we only delete a varObj if our cache
> is full.  The only exception to this rule is when the expression of a
> variable object is re-used which will trigger a var-update, which will
> show that the old varObj is out-of-scope (so we create a new one.)
> (if after returning from foo(), there is another local variable bar)

That does not sound like an ideal approach, because given that GDB knows 
for sure which variable objects are in scope, and which are not, you are
using some heuristics to to guess that, and it will never be 100% ideal.
Having said that, while GDB knows everything, MI interfaces are somewhat
lacking as far as local variables are concerned. I plan to design command(s)
that allow to easily and reliably track local variables, and will post those.

>> > > There are natural scalability bounds in the UI -- if there are no
>> > > arrays involved, and you try to show 1000 items (backed by 1000 variable objects),
>> > > the UI is already useless. GDB is not the problem here.
>> > 
>> > Right, but for us the 1000 varObj are not meant to all be displayed at once
>> > but are a caching system.
>> 
>> I'm still not sure what you mean -- you mean that a variable object is not shown
>> in any widget, but only is stored in the cache? What is the key of the cache?
> 
> Ah yes, the key of the cache.  That gave me a big headache :-)
> It is a object containing: the expression for the varObj, the thread it is part of,
> and the frame level.
> If the same expression (variable name) is used in the same thread at the same frame
> level, then we first think it is the same varObj and we use -var-update; we then
> get an out-of-scope and we delete the old varObj and create a new one.

I see. I hope this approach won't be necessary soon (though only if you're willing
to conditionalize the logic in gdb version).

- Volodya