From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29152 invoked by alias); 16 Sep 2009 17:12:57 -0000 Received: (qmail 29144 invoked by uid 22791); 16 Sep 2009 17:12:56 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_36,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; Wed, 16 Sep 2009 17:12:50 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8GHCc7S012839; Wed, 16 Sep 2009 13:12:38 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n8GHCaEv029340; Wed, 16 Sep 2009 13:12:37 -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 n8GHCZvE023898; Wed, 16 Sep 2009 13:12:35 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id C3B6E378198; Wed, 16 Sep 2009 11:12:34 -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> <19120.5383.874148.235514@totara.tehura.co.nz> Reply-To: Tom Tromey Date: Wed, 16 Sep 2009 17:12:00 -0000 In-Reply-To: <19120.5383.874148.235514@totara.tehura.co.nz> (Nick Roberts's message of "Wed, 16 Sep 2009 10:28:23 +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/msg00521.txt.bz2 >>>>> "Nick" == Nick Roberts writes: Tom> With a dynamic varobj you can tell if it has children by examining the Tom> has_more attribute. Nick> The field has_more tells you if it _currently_ has children. If Nick> you create a variable object of a STL container immediately after Nick> declaring an empty container, e.g. after Ok, yeah, I see what you mean. Nick> map m; Nick> then has_more=0 yet the node for it would need to be expandable. I don't think I understand this, though. There would be nothing underneath the node. So, showing some expansion control would be weird, wouldn't it? Nick> AFAICS the only way the front end can discriminate is through the Nick> displayhint field. I would like the display hint to remain just a hint. In particular I think it is important for future backward compatibility that we don't require all front ends to know about all possible hints -- that is, it should always be ok for the front end to ignore a hint it doesn't understand. So, if we need a way to determine "might possibly have children", then let's add a new attribute. Nick> On that note, printers.py in libstdc++ doesn't have a displayhint Nick> function for StdListPrinter. I'll look into this. I'm not sure whether this was intentional or not. Nick> Also there appears to be something wrong with the python class Nick> StdVectorPrinter because if you create a variable object immediately after Nick> declaring it, e.g. after I'll look at this too, thanks. Tom