From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32394 invoked by alias); 15 Sep 2009 15:37:42 -0000 Received: (qmail 32385 invoked by uid 22791); 15 Sep 2009 15:37:41 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Sep 2009 15:37:37 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8FFbPMq017398; Tue, 15 Sep 2009 11:37:25 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n8FFbOTt018222; Tue, 15 Sep 2009 11:37:24 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n8FFbM6T003951; Tue, 15 Sep 2009 11:37:23 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 4F8F6378175; Tue, 15 Sep 2009 09:37:22 -0600 (MDT) From: Tom Tromey To: nickrob@snap.net.nz (Nick Roberts) Cc: gdb-patches@sourceware.org Subject: Re: Patch: implement new dynamic varobj spec References: <19113.58116.381538.294631@totara.tehura.co.nz> <19114.58228.563201.654364@totara.tehura.co.nz> <19118.51646.285931.86868@totara.tehura.co.nz> Reply-To: Tom Tromey Date: Tue, 15 Sep 2009 15:37:00 -0000 In-Reply-To: <19118.51646.285931.86868@totara.tehura.co.nz> (Nick Roberts's message of "Tue, 15 Sep 2009 10:54:54 +1200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2009-09/txt/msg00480.txt.bz2 >>>>> "Nick" == Nick Roberts writes: Nick> I don't know if others are already using these features but it Nick> would seem sensible to me for frontends to _drive_ MI and not for Nick> it to be the other way around. Yeah; the first very round of code was really done in isolation but since then, Vladimir has been trying things out in his GUI, and we've had another user doing the same. Nick> 1) The displayhint field output from -var-create as well/or Nick> instead of from -var-list-children. That would be useful for Nick> determining whether an element should be expandable or not. Types Nick> map, list -- yes, type string -- no. With normal variable objects Nick> I just use num_children but this isn't sufficient for dynamic Nick> ones. I can add displayhint to the -var-create output quite easily. It seems like a good idea; I will implement it soon. With a dynamic varobj you can tell if it has children by examining the has_more attribute. Nick> 2) If is_map is true, rather than: [...] Nick> I would prefer GDB to output: Nick> var1.0 = "map_element" Nick> var1.0.key = key0 Nick> var1.0.value = value0 Nick> That way the values could be displayed as a tree: I considered this back at the start. The problem with doing this is that the key need not be a scalar. It could be a struct or some other complicated varobj with children. Also, the current approach has a benefit because it is simple and uniform: we can add more display hints without modifying the C code. Tom