Re: [python] another round of fixlets

[Vladimir Prus <vladimir at codesourcery dot com>]

On Thursday 20 August 2009 Tom Tromey wrote:

> I'm checking this in on the python branch.
> 
> This fixes a few more oddities pointed out by Vladimir, either in his
> note here earlier today, or in the thread on the gdb list.
> 
> In particular:
> 
> * We are better about computing the "numchild" result
> * We emit "{...}" as the value of a varobj that has children

I am sorry to be PITA, but something is still wrong. If I create
varobj from a vector that is presently empty, GDB does not notice
when things are pushed into it.

	(gdb) -var-create var0 @ v
	^done,name="var0",numchild="0",value="std::vector of length 0, capacity 0",type="std::vector<int, std::allocator<int> >",thread-id="1",has_more="0"
	(gdb) -exec-next 

This steps over push_back, but:

	(gdb) -var-update --all-values *
	^done,changelist=[]

If I create varobj from a non-empty vector then push_back is handled
fine, as well as pop_back.

Also, notice the string value for the varobj -- it's against "std::vector of length..." :-)
Initially, I was surprised -- I did not expect the string value for std::vector to 
differ depending on the number of children it has *now*. We probbly could use the 
presence of 'children' method in the pretty-printer, or some such, as the criteria?
But on the other hand, showing {...} as string value and no children at all might
be equally confusing... I am not sure what's best here.

> * We emit "has_more" for -var-create; this can be used to discover
>   whether the varobj has dynamic children

> Vladimir, I made up this last one to allow discoverability of dynamic
> children by the MI user.  Maybe it isn't the best way to go ... let me
> know what you think, we can certainly do something else here.

This worked fine for me -- thanks!

- Volodya