From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1840 invoked by alias); 8 Jan 2014 14:27:39 -0000 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 Received: (qmail 1825 invoked by uid 89); 8 Jan 2014 14:27:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.5 required=5.0 tests=AWL,BAYES_00,GARBLED_BODY autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 Jan 2014 14:27:37 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1W0u6X-0007GB-L3 from Yao_Qi@mentor.com ; Wed, 08 Jan 2014 06:27:33 -0800 Received: from SVR-ORW-FEM-02.mgc.mentorg.com ([147.34.96.206]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Jan 2014 06:27:33 -0800 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.2.247.3; Wed, 8 Jan 2014 06:27:32 -0800 Message-ID: <52CD5FF1.6050506@codesourcery.com> Date: Wed, 08 Jan 2014 14:27:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Keith Seitz CC: "gdb-patches@sourceware.org ml" Subject: Re: [RCF 00/11] Visit varobj available children only in MI References: <1385258996-26047-1-git-send-email-yao@codesourcery.com> <52CC45DD.3000407@redhat.com> In-Reply-To: <52CC45DD.3000407@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00208.txt.bz2 Thanks for the review, Keith. On 01/08/2014 02:22 AM, Keith Seitz wrote: > Why was this feature implemented this way? Specifically, if some varobj > children are not available from trace data, isn't the decision to filter > this information a function of the user interface? Wouldn't it have > sufficed to add a flag to the varobj designating the child as not > collected in the trace experiment or unavailable? > > I am definitely /not/ suggesting that this be re-implemented or > re-designed. I just want to understand why this was implemented this > way. Perhaps there is a significant speed advantage for large trace > experiments or some other technical/legitimate reason for this > implementation? We don't want frontends learn much new. If they already support pretty-print dynamic varobj, they should support available-children-only varobj. Frontends have only to pass option "--available-children-only" to some MI commands, and then frontends can handle the output as correctly as it handles pretty-printer's output. > > That aside, one other thing I'd like to ask about: the flag > "--available-children-only" rather strikes me like a property of the > varobj. Not altogether unlike the display format. Is there a reason a It (available-children-only) is a property of varobj, we add a new field available_children_only in struct varobj_dynamic for this purpose (in patch 07), at least, it is in the code. > flag was chosen to implement this over, say, a (new) command like > "-var-set-show-available-children-only" or requiring/allowing > --available-children-only to be specified on the root varobj creation > and "saved"/enforced for all subsequent commands on the varobj and its > children? Yeah, we can have a global setting to decide whether to honour available-children-only or not, and this global setting can be set by a new MI command. > > The only rationale I can think of is if a UI wanted to query gdb/mi for > varobjs with and without this option. Is that a common use case? Is I am not sure how common this use case is, but IMO, it is more flexible, compared with the approach using global setting. > there perhaps another use case which I have not considered? > > Finally, I didn't see any mention of documentation updates. This change > will require both a manual update and a NEWS entry, documenting the new > feature. It was intended and was mentioned in the cover letter of this series. There should be some changes during the review, which affect the doc and NEWS. > > I believe Joel has committed the MI "features" series; an update to this > might be desirable [perhaps Joel might be able to offer an opinion]. Right, we can add a new feature "mi-available-children-only" in the reply of -list-features. -- Yao (齐尧)