This is the mail archive of the mailing list for the Archer 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] update has_more generation

On Tuesday 08 September 2009 Tom Tromey wrote:

> >>>>> "Volodya" == Vladimir Prus <> writes:
> Volodya> I think CLI has some limit on the number of elements
> Volodya> printed. Can we reuse that?
> My recollection is, not readily.
> The CLI approach is complicated by the existence of set print repeats.
> You can't just fetch "show print elements" characters and get the same
> result.  The printer API requires us to fetch what we need of the string
> up front; we can't lazily read more.

I realize that printer API does not support incremental fetch. MI does not
support incremental fetch of immediate value of varobj either. It seems
clear we won't get either of those for 7.0. However, it seems better to
limit string at arbitrary reasonably large number than allow GDB/frontend
to crash at random.

> We could "fix" the API by having to_string return a special lazy string
> object, then moving laziness into the C code.
> What does MI currently do for strings in C code?  Does it respect "set
> print elements"?

Yes, it does:

	set print elements 10
	&"set print elements 10\n"
	-var-create v * s
	^done,name="v",numchild="1",value="0x80484c0 \"fooaaaaaaa\"...",type="char *"

- Volodya

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