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

[Matt Rice <ratmice@gmail.com>]

On Thu, Jul 20, 2023 at 9:47 AM Simon Farre <simon.farre.cx@gmail.com> wrote:
>
>
> > Matt> FWIW, there has been a bit of spit-balling within the rust community
> > Matt> about leveraging Debug trait implementations
> > Matt> within pretty printers, where what seemed to me like the obvious way
> > Matt> to leverage these was to compile Debug impls to wasm,
> > Matt> and write a python wrapper which calls into the wasm.  I haven't
> > Matt> thought or looked into it too much to have considered any hurdles of
> > Matt> this approach really, but it would be nice if languages with wasm
> > Matt> toolchains could define/compile pretty printers in their own language,
> > Matt> since often they already exist for the purpose of runtime logging...
> > Matt> Seemed worth bringing up if we're spit-balling here too.
> >
> > Ages ago I looked into this a little, the idea being to compile selected
> > functions to Python using the gdb API.  In the end though it seemed too
> > hard for the value it would deliver.
> >
> > Anyway, the wasm approach seems fine -- they solved all the toolchain
> > problems, which is nice.  The main issue is that, IIUC, debug traits
> > just emit a string representation -- but IMO the debugger really wants a
> > more key-value / array-like representation.
> >
> > This seems like something that could be implemented "on the side", like
> > the way that gdb-natvis exists.
> >
> > Tom
> Right, I would agree with Tom here. Having it just represented as a
> string is sort of the "problem" we're in and even though a lot of
> people  (maybe even a majority) still use CLI/TUI, I'm not particularly
> sure demanding new users going forward should be forced to accept such a
> user interface, instead of having it as a choice. A GUI and a CLI/TUI
> have to make substantially different design choices, because a CLI is
> always a REPL, so each individual operation can be somewhat costly,
> because it's going to feel sort of fast for the end user anyway, whereas
> a GUI can see large swathes of the program at every instant - making
> each and every one of those operations build up to a total cost pretty
> quickly.
>
> So, being able to query the types "directly", which means, sub objects,
> ranges etc is something that's valuable. GDB-CLI provides something like
> this with simple C-like types (the foo@10 expression). So, I think that
> excludes the #[derive(DebugWasm)] (ish) approach, unless it fulfills the
> requirements I've talked about here. I do like the idea that it would
> mean not having to write pp's for everything though.

Yeah the #[derive(Debug)] example was largely given as a pragmatic example,
In that there is no current trait which matches an pretty-printer like API.
Similarish traits would be Serialize/Deserialize, and
https://crates.io/crates/cc-traits crate for collections,
(not in std).  But nothing really that enumerates only over the stuff
you want to see.

It seemed okayish to me primarily for a proof of concept, since it
exists, is common and could reach
a lot of developers without much burden.

One thing your replies make me wonder about is the 'selecting pretty printers',
In the manual it specifies a search order in which these are
controlled (falling back to 'raw-text' somewhat implicitly).
I primarily use CLI, but in these debugger interfaces, would it be
worthwhile considering
giving pretty printers a 'sort'. So that we could register multiple
pretty-printers 'formatted-text', 'array-like',
'struct-like', 'map-like'.  This kind of selection mechanism with
priority based on the sort of pretty-printer would perhaps work
better for languages with trait/type-class like languages like rust
and haskell.  Since that tends to be how they implement
enumeration.  Part of what makes this difficult is the orphan rules,
stating you either need to specify the trait, or the type implementing
the trait.  So unless the type provider or trait provider implements a
`DebugWasm` trait it is hard to add it in a way the debugger could
leverage.
So adding/implementing enumeration-like mechanisms for pretty printing
to these types of languages really has quite a few open questions.
But in my mind `pretty-printer for objects that implement trait X
where trait X is specified by the pretty printer`.
whether it be `Debug`, `Collection<Item=T> where T: Debug`, or `Serialize`,

Additionally it would provide data for some form of a populated
drop-down selection box, where users could select the pretty-printer
That would seem to at least allow developers to leverage existing
traits while not limiting things to formatted-text.

However I could just be excessively complicating things here, but just
spitballing ways that we can leverage existing things like
formatted-text,
while eventually being able to grow into a struct/array/map-like
representation which I agree is desirable...
Anyhow, this is probably beyond long enough.

> Are there any lessons we can learn from LLDB here? How do they do it?

*shrug*, I don't have any experience with it.

> Then again, what's good about GDB/Python (and therefore the DAP interp)
> is that it allows for some customizability by the DA, so for instance, I
> would drive my DA to enforce the num_children/children_range approach,
> since the point of my DA was performance. So I think, no matter where we
> land, it's probably good if we could let the DA-implementer have room to
> make the tradeoffs it desires. It's also why I think it'd be good if the
> DAP interpreter isn't too reliant on MI because I believe MI was meant
> to solve a different problem (remote, vs a unified GUI & remote-protocol).
>
> Simon