From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5933 invoked by alias); 30 Apr 2008 06:25:03 -0000 Received: (qmail 5878 invoked by uid 22791); 30 Apr 2008 06:25:01 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Apr 2008 06:24:42 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Jr5k2-0006FH-Ku for gdb-patches@sources.redhat.com; Wed, 30 Apr 2008 06:24:34 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Apr 2008 06:24:34 +0000 Received: from vladimir by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Apr 2008 06:24:34 +0000 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: RE: [PATCH:MI] Return a subset of a variable object's children Date: Wed, 30 Apr 2008 09:20:00 -0000 Message-ID: References: <18452.24568.655617.907458@kahikatea.snap.net.nz> <18455.41299.899430.615138@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.5 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/msg00684.txt.bz2 Nick Roberts wrote: > > > 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? > > > 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 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? Even if technically possible, is this a desirable thing? 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. > > 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. > > > 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 - Volodya