From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10895 invoked by alias); 15 Aug 2011 12:36:49 -0000 Received: (qmail 10508 invoked by uid 22791); 15 Aug 2011 12:36:46 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.nokia.com (HELO mgw-da02.nokia.com) (147.243.128.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Aug 2011 12:36:32 +0000 Received: from gar.localnet (bettdhcp167113.europe.nokia.com [172.25.167.113]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7FCaUk1003788 for ; Mon, 15 Aug 2011 15:36:31 +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 12: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> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201108151436.50248.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/msg00041.txt.bz2 On Monday 15 August 2011 00:18:30 ext Daniel Jacobowitz wrote: > On Sun, Aug 14, 2011 at 12:10 PM, Andrew Oakley > wrote: > > I've got a patch to allow the Python pretty printer children iterators > > to return more pretty printers so they can create "phony groups" a bit > > like this: >=20 > Yay! That would be really nice to have indeed.=20 > > As far as I can tell I need to create "fake" varobj structures with no > > underlying value or type (because I don't have one). This appears to > > already happen and is tested for with CPLUS_FAKE_CHILD, but I'm not > > quite sure what that is for. Does this seem like a reasonable thing to > > do (after searching around for CPLUS_FAKE_CHILD)? >=20 > 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. >=20 > > My other worry is varobj invalidation and update. Am I correct in > > thinking that updates can only happen from a "root" varobj? If 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... I am not sure how partial updates on MI varobjs with phony levels=20 would work at all.=20 Imagine a data structure containing a char m[1000000][10], and a=20 "phony level pretty printer" that displays all the m[i] with m[i][0] =3D=3D= 'A'. Suppose initially that would be the items m[1] and m[10000], so we=20 get a display like=20 m -- m[1] "A...." m[1000] "A...." Now the user steps over m[5000][0] =3D 'A'. Assuming there is no dummy varobj for every _potential_ child, what mechanism would trigger the=20 varobj's update to produce the display m -- m[1] "A...." m[5000] "A...." m[10000] "A...."=20=20=20=20=20 eventually? [While the example might look contrived, it is a situation that naturally arises when using "phony levels", in various ways.] The only working "solution" for this kind of problem I am aware of is to=20 "manually" force a full re-evaluation of all top level items, i.e. not to rely on varobj's update mechanism at all. > > Am I correct in assuming you would want MI to work before accepting > > patches? >=20 > Even if it's not a requirement, I strongly encourage it. =46rom a gdb/python (and previously varobj...;-)) user's point of view it would be nice if caring for MI's varobj machinery (I really only mean=20 the varobjs, not MI in general) would not impact progress on the "pure" python side much. Andre'