From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20590 invoked by alias); 17 Aug 2011 18:31:16 -0000 Received: (qmail 20579 invoked by uid 22791); 17 Aug 2011 18:31:14 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from adoakley.name (HELO ado.is-a-geek.net) (46.4.104.242) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 17 Aug 2011 18:30:49 +0000 Received: from ado-gentoo.moore.slainvet.net ([2001:8b0:393:0:223:54ff:fe39:b789] helo=ado-gentoo) by ado.is-a-geek.net with esmtpa (Exim 4.76) (envelope-from ) id 1Qtkqv-0007Tq-FT; Wed, 17 Aug 2011 18:28:33 +0000 Date: Wed, 17 Aug 2011 18:31:00 -0000 From: Andrew Oakley To: Pedro Alves Cc: gdb@sourceware.org Subject: Re: Python API - nested pretty printers MI implications Message-ID: <20110817193102.17406aff@ado-gentoo> In-Reply-To: <201108171349.10546.pedro@codesourcery.com> References: <20110814171023.19db4f49@ado-gentoo> <201108151530.08237.pedro@codesourcery.com> <20110816231151.6cd06011@ado-gentoo> <201108171349.10546.pedro@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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/msg00074.txt.bz2 On Wed, 17 Aug 2011 13:49:10 +0100 Pedro Alves wrote: > On Tuesday 16 August 2011 23:11:51, Andrew Oakley wrote: > > > > On Mon, 15 Aug 2011 15:30:08 +0100 > > Pedro Alves wrote: > > > On Monday 15 August 2011 15:06:10, Andrew Oakley wrote: > > > > I assume the idea is to create a gdb.Value (with some data it > > > > doesn't really matter what) and then detect that it is that > > > > particular gdb.Value when the pretty printers list is searched? > > > > Perhaps you could do something like this: > > > > > > > > def fake_value_printer(val): > > > > if hasattr(val, "prettyprinter"): > > > > return val.prettyprinter > > > > else: > > > > return None > > > > > > > > gdb.pretty_printers.insert(0, fake_value_printer) > > > > > > > > Then you could just return any old gdb.Value and as long as it > > > > had a prettyprinter attribute then that would be called instead > > > > of the "normal" version. > > > > > > > > Is this what you were thinking of? > > > > > > I was actually thinking more like: > > > > > > gdb.pretty_printers.insert(0, fake_value_printer) > > > > > > def fake_value_printer(val): > > > isinstance(o, MyFakeValue) > > > return FakeValuePrinter(val, or whatever args > > > needed) else: > > > return None > > > > > > instead of duck typing, but yes, that sounds similar. > > > > > > > That's quite a nice trick but I'm not sure its a good long-term > > > > solution. It relies on the same python gdb.Value being passed > > > > back to the pretty printer selection function > > > > > > I don't understand. > > > > Imagine for a minute that a "struct value" didn't have a reference > > to a gdb.Value. Instead a gdb.Value is created every time we want > > to pass a value to python. The result of this is that the > > pretty-printer could return one gdb.Value and the pretty printer > > selection function would get a completely different gdb.Value that > > represented the same thing (breaking any code that worked like the > > examples above). > > I understand now, thanks. Actually, it looks like that is already > happening, as when gdb always takes a copy of the struct value > under the gdb.Value internally, and then wraps it in a _new_ gdb.Value > before passing it to the python pretty printer lookup functions (in > the pretty_printers array). :-( IMO this is a bug, and the internal > conversions should be short-circuited to garantee the same gdb.Value > is passed ... > > (I remembered , > which ended up in gdb.Value being extendable, but I see that Tom had > identified the internal copy problem at the time too.) > > > Given that GDB is quite happy giving you different gdb.Value objects > > for exactly the same thing it doesn't seem unreasonable to expect > > it to happen with pretty printers too (and the documentation > > doesn't say that it can't happen). Now I have this information would it be better to attempt to fix the internal copy "problem" rather than continuing with the current changes that try to allow a pretty printer to be returned directly? Obviously documentation should be updated to indicate that you can rely on this behaviour (once any problems have been fixed) but a lot of scary things might go away. > > > There'd be no NULL values this way. Wasn't that the problem? > > > > Kind of. Unfortunately this could well confuse front ends. They > > see something that looks like a real value, it even has a type they > > can "helpfully" display. That's not good because this isn't a real > > value so we shouldn't make the FE (and by extension varobj) think > > that it is. > > Not sure that's a real problem. We could maybe just make it type > void. If I was wanting to write my own FE I would certainly want to know. On the other hand I have no intention of doing that so I guess it depends on what others think. Perhaps we could simply have a convention that fake values have a "void" type (assuming that can be done) so the FE can detect them if it wants to but it shouldn't break anything. I think should satisfy everybody. -- Andrew Oakley