This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Python API - nested pretty printers MI implications
On Monday 15 August 2011 15:06:10, Andrew Oakley wrote:
> 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?
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.
> and probably causes exactly the same problems for the MI.
There'd be no NULL values this way. Wasn't that the problem?
> 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?
I'm not sure what you mean. You'd always need a "dummy" varobj
for each of the "fake values", wouldn't you? (I'm not sure you've
seen my reply to André though).
--
Pedro Alves