Re: Python API - nested pretty printers MI implications

[Andrew Oakley <andrew@ado.is-a-geek.net>]

On Wed, 17 Aug 2011 13:49:10 +0100
Pedro Alves <pedro@codesourcery.com> wrote:

> On Tuesday 16 August 2011 23:11:51, Andrew Oakley wrote:
> > 
> > On Mon, 15 Aug 2011 15:30:08 +0100
> > Pedro Alves <pedro@codesourcery.com> 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 <http://sourceware.org/ml/gdb/2010-09/msg00125.html>, 
> 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