From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12611 invoked by alias); 10 Mar 2011 09:07:31 -0000 Received: (qmail 12599 invoked by uid 22791); 10 Mar 2011 09:07:29 -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; Thu, 10 Mar 2011 09:07:23 +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 p2A97Djr012836; Thu, 10 Mar 2011 11:07:14 +0200 From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= To: ext Andrew Oakley Subject: Re: Python API - pretty printing complex types Date: Thu, 10 Mar 2011 09:07:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.32-21-generic; KDE/4.4.5; i686; ; ) Cc: Joachim Protze , "gdb@sourceware.org" References: <20110309004619.7256b052@ado-gentoo> <201103090954.49355.andre.poenitz@nokia.com> <20110309193051.6c757cf5@ado-gentoo> In-Reply-To: <20110309193051.6c757cf5@ado-gentoo> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201103101007.21382.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/msg00066.txt.bz2 On Wednesday 09 March 2011 20:30:51 ext Andrew Oakley wrote: > n Wed, 09 Mar 2011 09:07:09 +0100 > Joachim Protze wrote: >=20 > > My first approach makes use of the undocumented (online-doc)=20 > > array-method of gdb.Type, that i put in a handy function -- the > > straight forward way. >=20 > OK, I was looking for that but couldn't find a way to do it. I see > this is now documented which is nice. It still doesn't handle more > complex cases though. >=20 > On Wed, 9 Mar 2011 09:54:49 +0100 > Andr=E9 P=F6nitz wrote: >=20 > > On Wednesday 09 March 2011 01:46:19 ext Andrew Oakley wrote: > > > [...] If API improvements are needed to do this I can have a go at=20 > > > writing the code (the current src/gdb/python code seems fairly=20 > > > easy to understand). > >=20 > > My 2 ct: The most dearly missing feature in the "official" pretty > > printer API is the possibility to create multi-level displays with > > "phony groups" and a flexible way to steer the "expansion state" of > > such groups. >=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 I'd say it's a frontend's job to maintain the expansion state and communicate that to gdb when asking for "expanded data". > I think it would be nice to be able to return pretty printers from the > children iterator of another pretty printer. This would allow "phony > groups" to be created - simply return another pretty printer for the > group and it will get printed in the usual fashion.=20=20 That's perhaps an possibility. Right now I feed a few parameters like expansion state and individual formating requests to a fat script that creates the full visible hierarchy in one go. That "naturally" solves the=20 "phony group" issue, as each dumper can create as many level as it wishes, and allows for the omission of repeated data (like type of child nodes in a std::vector etc). > I'm not sure what the best way to go about this is. The problem is > finding out if the value returned should be handled as a pretty printer > or if it was something else. I don't code much in python so I don't > really know what the usual API conventions are. These are the options > I've thought of: >=20 > 1. Use a different display_hint if pretty printers will be returned. > This is awkward if some of the children are simple types and some are > more complicated. I'm not sure how it would interact with GDB/MI. > 2. Create a new base class that pretty printers inherit from. This > doesn't really feel like "the python way" - duck typing seems to be > common.=20=20 [I haven't done any python before using python with gdb, but duck=20 typing certainly feels natural here] > 3. Assume that objects that are not gdb.Value instances are pretty > printers. This prevents any further extensions from working in the > same way. >=20 > 4. Assume that objects with a to_string member are pretty printers. > This is the only required member of pretty printers and seems more in > line with other python libraries. We probably want to check for this > after checking if the object was a gdb.Value, both for performance > reasons and to ensure no existing code has an nasty surprises. >=20 > I think option 4 is the best choice here and I'm happy to write a patch > to do this if there is some agreement that it is a reasonable decision > (and therefore might actually get committed).=20=20 It certainly looks like a step into the right direction. The missing "phony levels" effectively prevented me from using the "official" pretty printing approach in the past.=20 It would be perfect if the pretty-printers-can-return-pretty-printers=20 approach would also allow to (easily) feed the pretty printers with=20 per-value individual data. I found this pretty useful for "patchwork" applications, that cannot easily use global settings for everything. [In some cases you would like to do things like "display char * as Latin1, but in some cases it's UTF-8, sometimes it's a \0-separated and \0\0-terminated 'list' of strings, and sometimes really only a pointer to a single char". Or you have some numerical data in an array that you'd like to run through xplot as "pretty printer", but you don't want to=20 invoke that on every value of type std::vector. Things like that.] Andre'