From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21264 invoked by alias); 9 Mar 2011 19:28:18 -0000 Received: (qmail 21254 invoked by uid 22791); 9 Mar 2011 19:28:17 -0000 X-SWARE-Spam-Status: No, hits=-0.7 required=5.0 tests=AWL,BAYES_00,TVD_RCVD_IP X-Spam-Check-By: sourceware.org Received: from 186.162.232.72.static.reverse.ltdomains.com (HELO ado.is-a-geek.net) (72.232.162.186) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Mar 2011 19:28:09 +0000 Received: from moore.slainvet.net ([81.2.98.79] helo=ado-gentoo) by ado.is-a-geek.net with esmtpa (Exim 4.72) (envelope-from ) id 1PxPwP-0006ZS-Ma; Wed, 09 Mar 2011 20:25:06 +0000 Date: Wed, 09 Mar 2011 19:28:00 -0000 From: Andrew Oakley To: =?ISO-8859-1?Q?Andr=E9_P=F6nitz?= , Joachim Protze Cc: gdb@sourceware.org Subject: Re: Python API - pretty printing complex types Message-ID: <20110309193051.6c757cf5@ado-gentoo> In-Reply-To: <201103090954.49355.andre.poenitz@nokia.com> References: <20110309004619.7256b052@ado-gentoo> <201103090954.49355.andre.poenitz@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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-03/txt/msg00062.txt.bz2 n Wed, 09 Mar 2011 09:07:09 +0100 Joachim Protze wrote: > 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. 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. On Wed, 9 Mar 2011 09:54:49 +0100 Andr=E9 P=F6nitz wrote: > 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. 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 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 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: 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 3. Assume that objects that are not gdb.Value instances are pretty printers. This prevents any further extensions from working in the same way. 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. 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 --=20 Andrew Oakley