This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [PATCH:MI] Return a subset of a variable object's children
> > > > step size (stride) other than one.
> > >
> > > I'm not sure what the stride would be used for. Maybe something like
> > > printing all even indexes of an array for example? In any case, it is
> > > a pretty simple addition, and no one is forced to use it, so I'm only
> > > asking to understand better.
> >
> > Yes, I think its just another way to sample a large array. ISTR dbx allows
> > printing array slices in this way.
>
> And is this behaviour particularly useful?
It depends on your point of view. In scientific computing (my background),
arrays are often used and sampling allows the data to be viewed at a lower
resolution for an overall picture of a value set.
>...
> > 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.
> Even if technically possible, is this a desirable thing?
I'm just floating ideas, I've not worked out the details.
> I think the the
> primary goal of incremental fetch is that if you happen to have std::vector
> with 200 children, then display of it won't fill your entire screen with
> children of a single variable. With incremental fetch, you can look at the
> children only if you're really interested. On the other hand, I don't think
> keeping 200 varobjs in GDB is too expensive. And if we talk about 10000
> children, then well, I don't think standard variable display widget is gonna
> be very good. Even if you delete varobjs that are not visible, it's too hard
> to find anything interesting among 10000 elements.
Again in scientific computing, arrays often have many more than 10000 elements.
In image processing arrays are two dimensional 512x512 with over 250,0000
elements. The user would have to identify the region of interest for the
display widget, e.g. [110:120][220:230] for a 10x10 square centred at
(115,225).
> > > I was thinking that we could keep order of children as they are defined
> > > (current behaviour) but not fill them all, until requested.
> > > We could create the full Vector of children as is done now by
> > >
> > > while (VEC_length (varobj_p, var->children) < var->num_children)
> > > VEC_safe_push (varobj_p, var->children, NULL);
> >
> > I guess this would remove the need for a second loop but it seems wasteful
> > on memory. Previously children variable objects were stored as a linked
> > list and, as I have said before, I do think this is more suitable as
> > objects can then be inserted and removed at any point in the sequence of
> > children.
>
> Please feel free to implement generic list datastructure in C, or rewrite
> gdb in C++. So far, using vector proved to be big convenience.
Clearly I'm not going to do either but we could simply go back to using the
linked list structures that were already in varobj.c. It's a question of
whether the convenience outweighs the handicap of having to work with vectors
all the time or not. IMHO it doesn't.
> > > but only actually create the children that have been requested by the
> > > user. I'm not sure how much efficiency there is by allocating the
> > > memory before hand? Also, is there no way to grow the vector by more
> > > than a single point at a time?
> >
> > Like resize with STL vectors? I'm not aware of one.
>
> VEC_safe_grow
OK, I didn't know about that. Why not use it instead of VEC_safe_push in the
construct above?
--
Nick http://www.inet.net.nz/~nickrob