Re: Python API - nested pretty printers MI implications

["André Pönitz" <andre.poenitz@nokia.com>]

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.

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?

Andre'