Re: Python and structured output from breakpoint_ops

[Tom Tromey <tromey at redhat dot com>]

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.

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.

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.

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.

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.

Tom