Re: Python API - nested pretty printers MI implications

[Pedro Alves <pedro@codesourcery.com>]

On Monday 15 August 2011 15:33:45, André Pönitz wrote:
> On Monday 15 August 2011 15:25:48 ext Pedro Alves wrote:
> > On Monday 15 August 2011 13:36:50, André Pönitz wrote:
> > 
> > > I am not sure how partial updates on MI varobjs with phony levels 
> > > would work at all. 
> > > 
> > > Imagine a data structure containing a  char m[1000000][10], and a 
> > > "phony level pretty printer" that displays all the m[i] with m[i][0] == 'A'.
> > > Suppose initially that would be the items m[1] and m[10000], so we 
> > > get a display like 
> > > 
> > >    m --
> > >       m[1]  "A...."
> > >       m[1000]   "A...."
> > > 
> > > Now the user steps over m[5000][0] = 'A'. Assuming there is no dummy
> > > varobj for every _potential_ child, what mechanism would trigger the 
> > > varobj's update to produce the display
> > > 
> > >    m --
> > >       m[1]  "A...."
> > >       m[5000]   "A...."
> > >       m[10000]   "A...."     
> > > 
> > > eventually?
> > 
> > AFAIK, frontends do:
> > 
> > -var-update 2 *
> > 
> > and that should yield (but doesn't):
> > 
> > ^done,changelist=[{name="var1.m",value="",in_scope="true",type_changed="false",new_num_children="1",has_more="0",new_children=[{name="var1.m.5000",exp="5000",numchild="1",value="A....",type="foo"}]}]
> > (gdb)
> > 
> > Note new_num_children.  This should trigger the frontend re-fetching
> > the children of var1.m.
> > 
> > I think the issue here is that dynamic varobj's code doesn't
> > handle new children appearing before existing ones.  I got a 
> > patch to address that though, needed for supporting varobj's
> > that hide "<unavailable>" children.
> 
> Just to confirm I understood correctly: Assuming everything would work as 
> planned, a good strategy for frontends is to call '-var-update ... *'. Then
> gdb would walk the whole varobj hierarchy, running pretty printers as 
> appropriate, and produce a "diff" against the last reported state which is
> output as a changelist, announcing potential new children to the FE, 
> which in turn could ask for that in another roundtrip.

Yes.  I believe things could be extended to avoid extra roundtrips.

> If so, isn't this very similar to the "fat script" approach, where a python 
> command (fed with a list of "names" of the expanded items) does all
> the tree walking by itself? That would put everything into "user space",
> let the pretty printers output additional data that's not of "general"
> (i.e. for all FEs) interest, and would make implementation of pretty 
> printers with multiple phony levels straightforward?

Probably.  But doesn't that mean library writters would get to write
pretty printers for each FE out there?

-- 
Pedro Alves