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

[Vladimir Prus <vladimir at codesourcery dot com>]

On Wednesday 30 April 2008 18:12:10 Marc Khouzam 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.
> > > In Qt, item data is requested only when item is drawn. I think SWT's Tree
> > > can be configured the same way. However, I don't think I saw any way, in
> > > either, to detect than an item is no longer visible. Marc, can you tell if
> > > SWT allows that?
> > 
> > In Emacs I would just find the first and last line numbers and work out
> > which elements were displayed from that.  
> 
> I'm not sure what SWT allows...
> In DSF-GDB, we have a LeastRecentlyUsed queue which allows us to know which
> varObj is the oldest (which implies it is not visible), and we can deleted
> once we have reached our limit of 1000 varObjs.

What is the practical measured advantage of that?

> I still think that GDB should avoid having the requirement of 'deleting
> old varObjs' toward the frontend.  

There's no concept of 'old varobjs' in MI protocol. You should delete variable
objects as soon as whatever GUI thing you have no longer need to display the
date the varobj corresponds to.

> It would be nicer if GDB would keep 
> its efficiency, not matter what the frontend did in this case.

Let's clarify what varobjs are for, in my opinion. They are primarily for 
implementing the 'variables' widget -- that shows local variables of a
function, expressions that user wishes to be always visible, and some auxillary
values. 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.

Speaking about arrays, I also don't understand which use cases are been considered.
I can think about those:

1. "Oops". User, without much though, opens an item in variable tree. The
item happens to be array of 10000 elements. We don't want UI to block until those
elements are fetched -- we want to show a few (say 10) and allow the user to get
some more in case he really wanted to see something.

2. "Subset". Probably, there's some local subset of array elements that the user
wants to look at. I think in that case, we should have a way to create only children
in the range that user is interested in. And I think Nick's patch is just fine.

3. "Data analysis". User actually wants to make some sense of all 10000 element.
Maybe, well, draw a chart. Or just look at the data. The data is integer, or some
other atomic type. Then, either some specialized widget, or merely the memory view,
is quite adequate.

What I don't see as a valid use case is one where:

1. The size of array is too large to keep all varobj always created.
2. User would like to just scroll though all the array items, without
clear intentions.

Am I missing something, and this use case is actually valid?

- Volodya