From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19488 invoked by alias); 15 Aug 2011 15:36:32 -0000 Received: (qmail 19354 invoked by uid 22791); 15 Aug 2011 15:36:31 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.nokia.com (HELO mgw-da01.nokia.com) (147.243.128.24) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Aug 2011 15:36:12 +0000 Received: from gar.localnet (bettdhcp167113.europe.nokia.com [172.25.167.113]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7FFaAXi031772 for ; Mon, 15 Aug 2011 18:36:11 +0300 From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= To: "gdb@sourceware.org" Subject: Re: Python API - nested pretty printers MI implications Date: Mon, 15 Aug 2011 15:36:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.32-21-generic; KDE/4.4.5; i686; ; ) References: <20110814171023.19db4f49@ado-gentoo> <201108151633.46029.andre.poenitz@nokia.com> <201108151548.55558.pedro@codesourcery.com> In-Reply-To: <201108151548.55558.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108151736.30905.andre.poenitz@nokia.com> X-Nokia-AV: Clean X-IsSubscribed: yes 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 X-SW-Source: 2011-08/txt/msg00052.txt.bz2 On Monday 15 August 2011 16:48:55 ext Pedro Alves wrote: > > [...] > > Just to confirm I understood correctly: Assuming everything would work as > > planned, a good strategy for frontends is to call '-var-update ... *'. Then > > gdb would walk the whole varobj hierarchy, running pretty printers as > > appropriate, and produce a "diff" against the last reported state which is > > output as a changelist, announcing potential new children to the FE, > > which in turn could ask for that in another roundtrip. > > Yes. I believe things could be extended to avoid extra roundtrips. > > > If so, isn't this very similar to the "fat script" approach, where a python > > command (fed with a list of "names" of the expanded items) does all > > the tree walking by itself? That would put everything into "user space", > > let the pretty printers output additional data that's not of "general" > > (i.e. for all FEs) interest, and would make implementation of pretty > > printers with multiple phony levels straightforward? > > Probably. But doesn't that mean library writters would get to write > pretty printers for each FE out there? If the library writer wants to "support" every fancy feature of every FE, then, perhaps, yes. However, without that flexibility we are in "one size fits all" mode, where gdb hardcodes which kind of data is deemed useful for every FE, and the FE has to jump through hoops (like extra roundtrips to retrieve "missing" information, or ignore unneeded data) to get hold of what it (the FE) actually wants to display. [That's not just anticipation, I had that kind of situations in the past when a varobj based "full display" of a QObject based class resulted in 50 or more roundtrips, basically rendering the whole approach non-viable] Anyway, in practice I would expect most implementors of "library pretty printers" to just provide the "usual" data (i.e. most likely what the current varobjs display looks like), and the FE to override a handful of them with an FE-specific "enriched" version - if at all. A schism on an individual pretty printer level is certainly much easier to handle (especially if the maintainance burden for "fancy stuff" is solely on the individual FE side) than a schism on the fundamental "varobj vs fat script" level. Andre'