From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21493 invoked by alias); 16 Aug 2011 22:12:06 -0000 Received: (qmail 21480 invoked by uid 22791); 16 Aug 2011 22:12:05 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from adoakley.name (HELO ado.is-a-geek.net) (46.4.104.242) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 16 Aug 2011 22:11:48 +0000 Received: from ado-gentoo.moore.slainvet.net ([2001:8b0:393:0:223:54ff:fe39:b789] helo=ado-gentoo) by ado.is-a-geek.net with esmtpa (Exim 4.76) (envelope-from ) id 1QtRpF-0006rw-NO; Tue, 16 Aug 2011 22:09:33 +0000 Date: Tue, 16 Aug 2011 22:12:00 -0000 From: Andrew Oakley To: =?UTF-8?B?QW5kcsOpIFDDtm5pdHo=?= Cc: "gdb@sourceware.org" , drow@false.org Subject: Re: Python API - nested pretty printers MI implications Message-ID: <20110816231147.514bd35e@ado-gentoo> In-Reply-To: <201108151736.30905.andre.poenitz@nokia.com> References: <20110814171023.19db4f49@ado-gentoo> <201108151633.46029.andre.poenitz@nokia.com> <201108151548.55558.pedro@codesourcery.com> <201108151736.30905.andre.poenitz@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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/msg00061.txt.bz2 On Mon, 15 Aug 2011 17:36:30 +0200 Andr=C3=A9 P=C3=B6nitz wrote: > > > 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? > >=20 > > Probably. But doesn't that mean library writters would get to write > > pretty printers for each FE out there? >=20 > If the library writer wants to "support" every fancy feature of every > FE, then, perhaps, yes. >=20 > 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. OK, so I guess the consensus here is that we should expose the tree produced by python scripts to MI, including any phony children.=20=20 On Sun, 14 Aug 2011 18:18:30 -0400 Daniel Jacobowitz wrote: > It does seem like a reasonable idea, but watch out for > CPLUS_FAKE_CHILD; it may not be a good model. It's used right now for > public/protected/private groups, and no one seems to want it there - > it might go away at some point. I still don't have a better idea for this, so it is probably what I'll have to go with. I'll rename it as it won't just be a C++ thing any more. If anybody has a way to avoid this then I'm like to hear about it, but I certainly think the varobj code needs some way to deal with fake objects that are untyped and have no underlying value.=20=20 On Sun, 14 Aug 2011 18:18:30 -0400 Daniel Jacobowitz wrote: > On Sun, Aug 14, 2011 at 12:10 PM, Andrew Oakley > wrote: > > My other worry is varobj invalidation and update. =C2=A0Am I correct in > > thinking that updates can only happen from a "root" varobj? =C2=A0If so > > it should be possible to reconstruct the "fake" varobj structures in > > varobj_update (I don't think it will be straightforward though). >=20 > My memory on this is a bit spotty. I think it may be possible to > update non-root varobjs, but it's the common case to update the root. > That might have been an out-of-tree patch though... Nobody else seems to indicate that this is possible and I can't find any way to do it. I think it's probably safe to assume you can't do this for now. If we want to be able to update non-root objects in the front end will probably have to know that the object is phony and therefore it can't update it directly (or it could try to update it and get some kind of error).=20=20 The general impression I have got is that MI is somewhat lacking in "advanced" features and people have just hacked away to get front ends to do what they want. On this basis it seems sensible to get this change in and do my best not to break any existing code. That way when somebody does decide to rework some of the MI code they will not overlook the idea of having phony objects (however they are implemented).=20=20 Unless anyone has any other suggestions or objections I guess I'll probably start work on this "soon". --=20 Andrew Oakley