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

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

I just thought of something that I think we've both misunderstood about 
(well, at least I did) "Lifetime of Objects References" section in the 
DAP specification.

To quote the section:

"To simplify the management of object references in debug adapters, 
their lifetime is limited to the current suspended state.
Once execution resumes, object references become invalid and DAP clients 
must not use them.
When execution is paused again, object references no longer refer to the 
same objects.
This means that a debug adapter can easily use sequentially assigned 
integers for different objects and reset the counter to 1 when execution 
resumes."

This doesn't mean that *we* can't cache variables (or variable 
references) on the GDB side. Because *we* are not the client (in this 
scenario, we would be the "server",
seeing as how the DAP is designed to be like a stateless protocol kind 
of like http) we can do whatever we want in our DAP-interpreter. It's 
only the *client* that can't rely
on a variablesReference to mean the same thing between suspended states. 
This opens up for the possibility of, when building the stack metadata, 
such as locals, args,
frames, perhaps the user visited older frames and retrieved the scopes 
etc - this could be cached until next suspension and if it's invalid at 
that point, throw it away, if not,
serve it all up again.

The question is, is the added complexity of caching variables (like I 
did for my DA) worth it, if the Pretty Printer API is smart enough and 
performant enough? Probably not, it's probably not likely at all that 
it's worth it.
And by "smart enough" and "performant enough" I specifically mean a 
pretty printer API, where sub-regions, sub-ranges of variables can be 
fetched quickly, which this patch provides.