Re: Python API - nested pretty printers MI implications

[Andrew Oakley <andrew at ado dot is-a-geek dot net>]

On 15/08/11 13:57, Pedro Alves wrote:
> On Sunday 14 August 2011 17:10:23, Andrew Oakley wrote:
>>         def children(self):
>>                 yield ("normal variable", "some value")
>>                 yield ("phony group 1", inner_pretty_printer(...))
>>                 yield ("phony group 2", inner_pretty_printer(...))
>>
>> This seems to work well but I'm not quite sure how to handle the for MI.
>>
>> As far as I can tell I need to create "fake" varobj structures with no
>> underlying value or type (because I don't have one). 
> 
> I'm not very familiar with the pretty printing stuff, but,
> doesn't something like this work nowadays?

[snip]

> That is, create a specialized Value class and install the pretty
> printer for that _value_.

This didn't come up when I asked about this previously.

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?

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 and probably causes exactly the
same problems for the MI.

Back to my initial question I guess for MI this is also creating a
"dummy" varobj with some type and value chosen by the python script.  Do
you know if this works in practice with MI frontends?

-- 
Andrew Oakley