Re: Question about printing info to UI (MI -vs- non-MI)

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> Just for reference, the output in the CLI case is:
Joel>     Catchpoint 1, CONSTRAINT_ERROR at [std frame info snipped]
Joel> The part that generates the info used to produce the GDB/MI *stopped
Joel> notification is nice and compact.  But the rest of the code makes me
Joel> wonder whether I might be able to simplify it. For instance, the first
Joel> thing I do is:

Joel> |  ui_out_text (uiout, (b->disposition == disp_del
Joel> |                       ? "\nTemporary catchpoint "
Joel> |                       : "\nCatchpoint "));

Joel> But this text doesn't get used in the case of GDB/MI.

Yeah.  The MI out_text implementation just discards the string.
Sometimes I find this irksome but the expense is not really very big.

Joel> Immediately following it, I do the same as in print_it_catch_exception,
Joel> which is to emit an "int" field, BUT only if we're not in MI mode
Joel> (we want that field to be in a special order, I understand).

I believe MI clients are not supposed to depend on the field order.

Joel> Does it make a difference to anyone that this info is emitted as
Joel> an int, and labeled "bkptno"?

I think it it nice to try to make the type be something sensible, for
API clarity and for future-proofness.  I think it generally doesn't
matter, except a few specific TUI cases.

The name does matter.  MI uses it to label the field it emits.
Field names are part of the MI API.

Joel> I used to think that there was only the CLI vs GDB/MI, but I'm just
Joel> realizing that there might be some solid reasons doing things this
Joel> way.  For instance, what about the TUI?

Yeah.  The TUI mostly inherits from the CLI ui-out implementation, but
applies a few tweaks.

We've considered exposing all this stuff to Python, so that we could
provide Python wrappers for all MI commands, and get Python objects back
in response.  It isn't clear we really need this, so nobody has worked
on it yet.

Joel> Depending on the answers to these questions, it might be better
Joel> for me to write the code:
Joel>     if (ui_out_is_mi_like_p (uiout))
Joel>       {
Joel>         [generate the MI data]
Joel>       }
Joel>     else
Joel>      {
Joel>         ui_out_text (uiout, "Catchpoint ");
Joel>         ui_out_field_int (uiout, "bkptno", b->number);
Joel>         [etc]

I think it is generally preferable to unify the two code paths, and to
use ui_out_is_mi_like_p as sparingly as possible.

You can simplify your code a little bit, but the two situations here are
different enough that if you wanted to make it an exception to the above
general rule, I think it would be ok.

FWIW, one major problem with ui-out as currently written is that it
interferes with i18n.  A fix to this (which I have not thought about
deeply) would probably also go a long way towards letting us remove uses
of ui_out_is_mi_like_p.

Tom