From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8841 invoked by alias); 28 May 2008 07:23:22 -0000 Received: (qmail 8828 invoked by uid 22791); 28 May 2008 07:23:21 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 28 May 2008 07:22:53 +0000 Received: (qmail 14532 invoked from network); 28 May 2008 07:22:50 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 May 2008 07:22:50 -0000 From: Vladimir Prus To: Nick Roberts , gdb-patches@sources.redhat.com Subject: Re: [PATCH:MI] Return a subset of a variable object's children Date: Wed, 28 May 2008 19:15:00 -0000 User-Agent: KMail/1.9.9 References: <18452.24568.655617.907458@kahikatea.snap.net.nz> <18457.46138.681282.588777@kahikatea.snap.net.nz> <18469.3657.466721.123119@kahikatea.snap.net.nz> In-Reply-To: <18469.3657.466721.123119@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805281122.52651.vladimir@codesourcery.com> 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-05/txt/msg00729.txt.bz2 On Saturday 10 May 2008 06:54:01 you wrote: > > > > 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. > > > > > > I disagree, and I haven't yet seen a practical "handicap". We're not going > > > back to hand-written data structures for MI implementation. > > > > Well it's a shame that convenience should dictate the type of structures that > > are used because I can get this patch to work with an old Gdb using linked > > lists. > > As you've made your decision, the patch below isn't a RFA or RFC but a record > for the archives to ensure it's not lost like other patches that I've left > lying around. I feel sure that one day the issue will arise again, probably > when Eclipse finds a requirement for it. > > It's against current Gdb and uses the old linked lists. This means that the > size of the data structure is only proportional to the number of children > created and not the total number of possible children. Unlike the previous > patch, children are listed in sequence for both creation and update. Also > children can be deleted. Searching for a location to insert a child in the > list is linear (as before) but I anticipate that a front end would only ever > create a small number at any one time and delete children (that are not > visible) if the number became too great. In any case the search could be made > binary (O(log N)), if necessary. > > Oh, yes, and it's a unified diff! I think that the current data structures surely allow to implement the behaviour that is useful for frontends. I raise some questions about the original version of your patch in http://article.gmane.org/gmane.comp.gdb.patches/40676 which you did not respond to. Did you miss that email? Do you plan to have the original version of your patch adjusted and checked in? For the record, the usecases that I think will benefit from this new functionality are outlined in: http://article.gmane.org/gmane.comp.gdb.patches/40726 Thanks, Volodya