Re: Python and structured output from breakpoint_ops

[Phil Muldoon <pmuldoon at redhat dot com>]

Tom Tromey <tromey@redhat.com> writes:

> Phil> So in print_one's case, the parent does not call the child function
> Phil> until it has already populated all of the fields before address.  So
> Phil> there are only two fields left to fill: "address", and "what".  They
> Phil> have to be a long and a string.
> [...]
> Phil> Given that all one can return in the above context is
> Phil> essential a long and a string, I'm not sure what value we can add by
> Phil> letting the user return anything else? We would have to convert any list
> Phil> within the tuple to a string anyway.  I'd prefer users just do this
> Phil> themselves in Python.
>
> Phil> The same goes for print_stop_action.  This tells GDB what to print (via
> Phil> an enum) when the breakpoint stops.
>
> Phil> So again we are limited to a string and a constant.  I guess we could,
> Phil> if the user passed a list within a list, call ui_out_list there.  But to
> Phil> me, you will only ever want this output on one line (in fact, it may be
> Phil> a requirement, I am not to sure).
>
> I don't think it has to be.
>
> Phil> There seems to be more room to maneuver with print_mention, and
> Phil> print_one_detail.  They are currently implemented as pure strings.  But
> Phil> again, both I believe (and really, I want) to be implemented as a single
> Phil> string.  print_mention is called when a breakpoint is created.  Is there
> Phil> an example of what kind of structured output we could use here?
>
> I think I was hoping that we could unify some of the print methods.  It
> seems strange to have 4 different method to print more or less the same
> basic information.

Yeah I have no problem with that at all.  In fact, I totally agree there
should not be a one-to-one mapping of the internal -> external APIs.
They make sense to GDB internally, but not externally.

>
> This might mean constraining the output a little bit in order to provide
> a simpler API.  I think that would be good, but that is just my opinion;
> however, if it turned out to be too limiting we could always extend the
> options later.
>
> Even if all the methods can't be unified it seems that at least
> print_one and print_one_detail could be.

Right, so in this context "describe_breakpoint" could be the name
there.  Similarly, something like "describe_new_breakpoint" for mention.
>
> Phil> print_one_detail is an optional detail line below each entry for "info
> Phil> breakpoints".  This has to be limited to a single line, to remain
> Phil> constant with "info breakpoints" output.
>
> It seems like it could have multiple lines, just nothing does this
> yet.

My caution here is that we have three interfaces to describe breakpoints
too: CLI, Annotations, and MI (1 and 2?).  Even though annotations seems
barely used, emacs uses it.  Maybe this isn't an issue at all.

>
> This is a good example of where structured output is useful: right now
> the code has to know how to format the continuation lines (e.g., start
> with a tab) -- but it seems like it would be better not to bake this
> into Python scripts everywhere, in case we want to change the "info
> break" formatting in the future.  Some kind of structured result would
> let us do this.

I'm not sure what you mean?  There are two fields, What and Address, so
in that narrow context there will not be a continuation.  The old
print_one_detail, yeah, I can see that.  Also there seems to be just a
free-flow standard to where the detail line starts.  Some start at the
second column, some at the beginning (at least, when I last looked).  
>
> Phil> In fact, if you look at the mi command -break-list, it just maps
> Phil> to info break and captures that output.  Maybe that conversation
> Phil> is what Jan was talking about when there is an explicit mention
> Phil> that any field change has to be made by Vlad?
>
> I wouldn't worry about the field name thing in this discussion.  We're
> already talking about extensions to gdb from third parties, nothing in
> the core.
>
> However, another important thing is that the print_* methods work from
> both MI and the CLI.  Otherwise, -break-list is going to print garbage
> when someone installs one of these Python-created breakpoints.

Right, see above, including annotations.  As they stand right now, in my
branch, they do work for all three of the interfaces.  My thoughts are
how do we write this API (With structured output)?  Do we completely
disseminate the API from the GDB internals, and ask for our own kind of
custom output, then just slot in the various bits of detail into the
various fields?  What are these APIs? What kind of structured output?

Cheers,

Phil