From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5044 invoked by alias); 11 Mar 2011 11:25:54 -0000 Received: (qmail 4912 invoked by uid 22791); 11 Mar 2011 11:25:52 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_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; Fri, 11 Mar 2011 11:25:47 +0000 Received: from gar.localnet (berwst16747.europe.nokia.com [172.25.167.47]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2BBPStP012165; Fri, 11 Mar 2011 13:25:28 +0200 From: =?utf-8?q?Andr=C3=A9_P=C3=B6nitz?= To: ext Tom Tromey Subject: Re: Python API - pretty printing complex types Date: Fri, 11 Mar 2011 11:25:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.32-21-generic; KDE/4.4.5; i686; ; ) Cc: ext Andrew Oakley , Joachim Protze , "gdb@sourceware.org" References: <20110309004619.7256b052@ado-gentoo> <201103101007.21382.andre.poenitz@nokia.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201103111225.41524.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-03/txt/msg00086.txt.bz2 On Thursday 10 March 2011 22:25:20 ext Tom Tromey wrote: > >>>>> "Andr=C3=A9" =3D=3D Andr=C3=A9 P=C3=B6nitz writes: >=20 > >> I don't know about "expansion state" it feels like it is GDBs job to > >> manage that rather than the pretty printers themselves.=20 >=20 > Andr=C3=A9> I'd say it's a frontend's job to maintain the expansion state= and > Andr=C3=A9> communicate that to gdb when asking for "expanded data". >=20 > If I understand correctly, then I think the varobj stuff does this ok. > It is the front end's choice whether to fetch varobj children, and how > many to fetch. Front ends do have to do a little dance to make the > "windowing" work out right, but it isn't too bad. > > Also, the pretty-printer API was designed so that a printer can be > written to compute data lazily, to avoid over-fetching. There are still > some wrinkles here, I think strings still don't work completely > properly. I think there is still a PR open about this. >=20 > I know you aren't using varobj. We could probably expose more of the > pretty-printer stuff to pure Python if you'd find that helpful... > though I suspect just the existing gdb.default_visualizer is enough. I readily believe that varobj work ok for "normal C" cases, but after spend= ing quite some time on a varobj based general solution (still used on Mac btw) I came to the conclusion that either I do not understand the concept on a=20 very fundamental level, or the varobj approach can conceptually not work for "phony" data. I.e. data that is entirely artificial (like grouping of data= =20 members of some struct) or the result of inferior calls ("getter" style=20 functions). Unfortunately, that kind of data is a large (and the most interesting) part= of what I need to display. E.g. object properties that are formally only acces= sible=20 by getter functions, and even if most of them are backed by real data in so= me memory "somewhere", that does not have to be the case when the result is=20 constructed on-the-fly. How do I create a varobj representing such a result? What kind of mechanism makes -var-update do the "right thing", i.e. notifies me that that the result of an inferior call "changes", i.e. possibly would = need=20 to be re-computed as the context leading to its original computation? I really think this cannot work with the gdb's varobj architecture, and nei= ther with some incremental improvement on top of it. But as it is easy to prove = me wrong by pointing to any other gdb frontend successfully handling that use= =20 case that question should be answerable. > Andr=C3=A9> It would be perfect if the pretty-printers-can-return-pretty-= printers=20 > Andr=C3=A9> approach would also allow to (easily) feed the pretty printe= rs with=20 > Andr=C3=A9> per-value individual data. I found this pretty useful for "pa= tchwork" > Andr=C3=A9> applications, that cannot easily use global settings for ever= ything. > Andr=C3=A9> [In some cases you would like to do things like "display char= * as > Andr=C3=A9> Latin1, but in some cases it's UTF-8, sometimes it's a \0-sep= arated and > Andr=C3=A9> \0\0-terminated 'list' of strings, and sometimes really onl= y a pointer > Andr=C3=A9> to a single char". Or you have some numerical data in an arra= y that you'd > Andr=C3=A9> like to run through xplot as "pretty printer", but you don't = want to=20 > Andr=C3=A9> invoke that on every value of type std::vector. Thing= s like that.] >=20 > varobj lets you assign a printer to a specific varobj, but I'm not sure > if anything uses this, and it probably only makes sense if there is > prior coordination with the front end. That might work, pushing per-item configuration data from the frontend befo= re '-var-update' calls or such would be ok. I am not convinced, however, it would help. Changing the display might easily impact the child nodes (see above example of plain Latin1 vs \0-separated and \0\0-terminated list of=20 strings) and therefore the varobjs representing these nodes. I have a gut feeling that this will cause troubles. > Handling this via sub-pretty-printers for (e.g.) specific fields in > known structures seems reasonable. But I don't know a fully general way > to handle this, like if the user wants "print some_global_string" to > automatically know to use a different encoding. One could do some guesswork based on the actual string data. But according to user feedback it's sufficient to have a reasonable first approximation (like Latin1 or the system locale) and provide options to change encoding globally and per-item. And that's straightforward to do with the "fat scrip= t" approach. Andre'