From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7542 invoked by alias); 29 Apr 2008 22:30:32 -0000 Received: (qmail 7490 invoked by uid 22791); 29 Apr 2008 22:30:16 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Apr 2008 22:29:48 +0000 Received: from kahikatea.snap.net.nz (125.60.255.123.dynamic.snap.net.nz [123.255.60.125]) by viper.snap.net.nz (Postfix) with ESMTP id 6A9183DA31C; Wed, 30 Apr 2008 10:29:45 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id C3C548FC6D; Wed, 30 Apr 2008 10:29:43 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18455.41299.899430.615138@kahikatea.snap.net.nz> Date: Wed, 30 Apr 2008 07:02:00 -0000 To: "Marc Khouzam" Cc: Subject: RE: [PATCH:MI] Return a subset of a variable object's children In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA042910A5@ecamlmw720.eamcs.ericsson.se> References: <18452.24568.655617.907458@kahikatea.snap.net.nz> <6D19CA8D71C89C43A057926FE0D4ADAA042910A5@ecamlmw720.eamcs.ericsson.se> X-Mailer: VM 7.19 under Emacs 22.2.50.2 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00680.txt.bz2 > > 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 > > > > * 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