This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]