Re: [PATCH v1] gdb/DAP Introduce new methods to to Pretty Printers

[Simon Farre <simon.farre.cx@gmail.com>]

Hi Tom, thanks for your input!
> The reason stems from a mistake we made early on when adding Python to
> gdb -- when adding pretty-printers, we weren't very careful about
> letting people know that we might add more methods to the printers.
>
> This means existing code is free to use any name on the printer objects,
> except the few we documented.  I'm not sure num_children or
> children_range are used anywhere -- but they might well be.
>
> Of course it's not very hard to fix this in printers.  However, it's bad
> to ship a new gdb that breaks people's setup.  We've tried pretty hard
> to avoid this.
We could go the c++ standard library route here and define silly (guard) 
names for everything we do, going forward.

So;
def __children_range, def __num_children.

If it's good for C++ standard library developers, it can be good for us 
as well ;).  Even though it's a tried and true approach
it's not one that I'm much fond of, but we could do that.
> These are exposed to Python as struct types, but we'd like to present
> them as array types over DAP -- which is what is done for the CLI (via
> special cases in the printing code) and also for MI (via varobj, though
> I haven't actually implemented this for Rust yet).
I don't understand this part, I wrote a the documentation example, that 
behaves like an dynamic array,
where pretty printer makes use of it's intimate knowledge of the length, 
because I specifically had languages
like Rust in mind (or any other type of dynamic data).

Or do you mean that it should automatically understand when
it's a built in type, in the language? That would be nice. But would 
that not introduce scope issues, like at what point do we stop?
Wouldn't we have to 1st class-implement every language that has a novel 
idea of representing (its own) standard data types? Or are for instance
Rust slices represented specifically as a special type in DWARF that we 
can recognize?

I think with the Python approach we leave more room for flexibility, 
than we do closing the PP stuff behind "MI-doors" as it were.
I also have a pet peeve against MI, so I *really* don't like that, just 
based on personal preference.

Besides, going the MI approach, excludes anyone who actually wants to 
write a (performant)
pretty printer for their own container, doesn't it? I don't think we can 
accept 100ms response times for trivial data,
when pretty printers are involved (and if libstdc++ pp is involved, it 
crashes and burns, making debugging using DAP impossible
as previously discussed).

Either way, having a "smart pretty printer" sounds good, for the use 
cases you've described, Ada strings,
Rust slices, etc - but my biggest question is how would we extend that 
to arbitrary client code?

Never mind about the caching-stuff I said, that can be left to any 
DA-implementers that wrap GDB's DAP,
if they choose to live on the wild side. I think closing the gaping 
performance hole is of much more importance.

Simon