From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16179 invoked by alias); 10 Mar 2011 21:25:41 -0000 Received: (qmail 16168 invoked by uid 22791); 10 Mar 2011 21:25:40 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 10 Mar 2011 21:25:34 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p2ALPMpf000756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Mar 2011 16:25:22 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p2ALPLgh023717; Thu, 10 Mar 2011 16:25:21 -0500 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p2ALPK3g019880; Thu, 10 Mar 2011 16:25:21 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id 830A13797CD; Thu, 10 Mar 2011 14:25:20 -0700 (MST) From: Tom Tromey To: =?utf-8?B?QW5kcsOpIFDDtm5pdHo=?= Cc: ext Andrew Oakley , Joachim Protze , "gdb\@sourceware.org" Subject: Re: Python API - pretty printing complex types References: <20110309004619.7256b052@ado-gentoo> <201103090954.49355.andre.poenitz@nokia.com> <20110309193051.6c757cf5@ado-gentoo> <201103101007.21382.andre.poenitz@nokia.com> Date: Thu, 10 Mar 2011 21:25:00 -0000 In-Reply-To: <201103101007.21382.andre.poenitz@nokia.com> (=?utf-8?Q?=22An?= =?utf-8?Q?dr=C3=A9_P=C3=B6nitz=22's?= message of "Thu, 10 Mar 2011 10:07:21 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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/msg00083.txt.bz2 >>>>> "Andr=C3=A9" =3D=3D Andr=C3=A9 P=C3=B6nitz = writes: >> I don't know about "expansion state" it feels like it is GDBs job to >> manage that rather than the pretty printers themselves.=20 Andr=C3=A9> I'd say it's a frontend's job to maintain the expansion state a= nd Andr=C3=A9> communicate that to gdb when asking for "expanded data". 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. 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. Andr=C3=A9> It would be perfect if the pretty-printers-can-return-pretty-pr= inters=20 Andr=C3=A9> approach would also allow to (easily) feed the pretty printers= with=20 Andr=C3=A9> per-value individual data. I found this pretty useful for "patc= hwork" Andr=C3=A9> applications, that cannot easily use global settings for everyt= hing. 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-separ= ated and Andr=C3=A9> \0\0-terminated 'list' of strings, and sometimes really only = a pointer Andr=C3=A9> to a single char". Or you have some numerical data in an array = that you'd Andr=C3=A9> like to run through xplot as "pretty printer", but you don't wa= nt to=20 Andr=C3=A9> invoke that on every value of type std::vector. Things = like that.] 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. 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. Tom