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

[Nick Roberts]

 > > 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.

 > > 2008-04-27  Nick Roberts  <nickrob@snap.net.nz>
 > > 
 > >       * mi/mi-cmd-var.c (mi_cmd_var_list_children): Add options to select
 > >       a subset of children.
 > > 
 > >       * varobj.h (varobj_list_children): Declare new parameters.
 > > 
 > >       * varobj.c (struct varobj): New member current_children.
 > >       (varobj_list_children): Create any new varobjs for children
 > >       specified by mi_cmd_var_list_children.
 > >       (create_child): Add parameter real_index.  Use it.
 > > 
 > 
 > 
 > I have a concern about the ordering of children.  I think not having a
 > constant ordering for the children could prove a problem.  For example, I
 > think the algorithm proposed will fail if a child varObj is deleted by the
 > user.  I believe deleting a varObj inserts NULL in its current position,
 > however, the algo always inserts at the end, so it will miss the available
 > deleted entry.

You're probably right about ordering, and deletion does cause a segmentation
fault.

 > Also, the double loop may prove to be slow for large number of children.

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 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.

 > 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.

 > We can even improve on that by doing the following: instead of allocating
 > the vector for all children, we can allocate the vector for the children up
 > to start+number*stride.

The variables start, number and stride might be selectable by the user but I'm
thinking that "number" used by Gdb will be controlled by how many elements are
visible on the screen.  What happens with your approach when new elements
become visible and new children need to be created?

 > I believe this will give a constant ordering (same as current) and avoid the
 > costly double loop, since we can simply check for NULL to know if a child is
 > there or not.  And the delete will work as is.
 > 
 > You can also probably use the vector size instead of the new
 > current_children.

Thanks for the feedback.

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