From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7335 invoked by alias); 15 Aug 2011 14:33:46 -0000 Received: (qmail 7326 invoked by uid 22791); 15 Aug 2011 14:33:44 -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 14:33:30 +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 p7FEXQux005519; Mon, 15 Aug 2011 17:33:26 +0300 From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= To: ext Pedro Alves Subject: Re: Python API - nested pretty printers MI implications Date: Mon, 15 Aug 2011 14:33:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.32-21-generic; KDE/4.4.5; i686; ; ) Cc: "gdb@sourceware.org" References: <20110814171023.19db4f49@ado-gentoo> <201108151436.50248.andre.poenitz@nokia.com> <201108151425.48364.pedro@codesourcery.com> In-Reply-To: <201108151425.48364.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201108151633.46029.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/msg00047.txt.bz2 On Monday 15 August 2011 15:25:48 ext Pedro Alves wrote: > On Monday 15 August 2011 13:36:50, Andr=E9 P=F6nitz wrote: >=20 > > I am not sure how partial updates on MI varobjs with phony levels=20 > > would work at all.=20 > >=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 > >=20 > > m -- > > m[1] "A...." > > m[1000] "A...." > >=20 > > 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 > >=20 > > m -- > > m[1] "A...." > > m[5000] "A...." > > m[10000] "A...."=20=20=20=20=20 > >=20 > > eventually? >=20 > AFAIK, frontends do: >=20 > -var-update 2 * >=20 > and that should yield (but doesn't): >=20 > ^done,changelist=3D[{name=3D"var1.m",value=3D"",in_scope=3D"true",type_ch= anged=3D"false",new_num_children=3D"1",has_more=3D"0",new_children=3D[{name= =3D"var1.m.5000",exp=3D"5000",numchild=3D"1",value=3D"A....",type=3D"foo"}]= }] > (gdb) >=20 > Note new_num_children. This should trigger the frontend re-fetching > the children of var1.m. >=20 > I think the issue here is that dynamic varobj's code doesn't > handle new children appearing before existing ones. I got a=20 > patch to address that though, needed for supporting varobj's > that hide "" children. Just to confirm I understood correctly: Assuming everything would work as=20 planned, a good strategy for frontends is to call '-var-update ... *'. Then gdb would walk the whole varobj hierarchy, running pretty printers as=20 appropriate, and produce a "diff" against the last reported state which is output as a changelist, announcing potential new children to the FE,=20 which in turn could ask for that in another roundtrip. If so, isn't this very similar to the "fat script" approach, where a python= =20 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=20 printers with multiple phony levels straightforward? Andre'