From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10027 invoked by alias); 22 Nov 2013 16:12:17 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 9999 invoked by uid 89); 22 Nov 2013 16:12:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_40,RDNS_NONE,SPF_HELO_PASS,SPF_PASS,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 22 Nov 2013 16:12:15 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rAMGC50s032176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Nov 2013 11:12:06 -0500 Received: from barimba (ovpn-113-124.phx2.redhat.com [10.3.113.124]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rAMGC3E1020640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 22 Nov 2013 11:12:04 -0500 From: Tom Tromey To: Yao Qi Cc: "gdb\@sourceware.org" Subject: Re: semantics of dynamic varobj References: <528F5839.4050100@codesourcery.com> Date: Fri, 22 Nov 2013 16:12:00 -0000 In-Reply-To: <528F5839.4050100@codesourcery.com> (Yao Qi's message of "Fri, 22 Nov 2013 21:12:25 +0800") Message-ID: <87eh68e7qk.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-11/txt/msg00087.txt.bz2 >>>>> "Yao" == Yao Qi writes: Yao> I ask these questions because I am adding a new kind of dynamic Yao> varobj, whose contents are provided by only available data. There are maybe two things that suggest that a dynamic varobj is not the way to go here. One is that these aren't truly dynamic. They are just ordinary varobjs where some child values are unavailable. It seems far simpler to me to just provide an "unavailable" marker. Second, dynamic varobjs have different semantics than ordinary ones, so they are only enabled when the client requests them. (And, clients may use the "python" feature to decide this, since that's the only signal right now that they exist.) So, would then (1) be at least conceptually tied to Python (you could add a new feature I suppose) and (2) have to decide what to do if the feature is not enabled... which goes back to the idea of just treating these as normal varobjs. Tom