Re: Python and structured output from breakpoint_ops

[Pedro Alves <pedro@codesourcery.com>]

On Friday 07 October 2011 16:39:59, Tom Tromey wrote:

> 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.

I still think we should cleanup the breakpoint printing machinery before
exporting it to python.  These methods were not converted to
breakpoint_ops yet.  By only considering a single string, you're leaving
out breakpoints with multiple locations.  And those will become even more
important with Tom's linespec/multi-location rework.

> 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.

Yeah.  Random catchpoints are likely to want it.

> 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.

Yeah.  I'd like that direction.  It'd allow for more smarter column/cell
wrapping too.

> 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?

The thing is that the fields that are output aren't constrained at all
by the "address" / "what" columns you see in the CLI.  Look at all
the "ui_out_*" calls.  It seems quite reasonable to me to be able to
output random fields from python too, so you could implement new
breakpoint/catchpoints in python and forward whatever necessary info
to the frontend through MI.

-- 
Pedro Alves