From: Tom Tromey <tom@tromey.com>
To: Simon Marchi <simon.marchi@polymtl.ca>
Cc: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: Re: [RFA 1/7] Use ui_out_emit_table and ui_out_emit_list in print_thread_info_1
Date: Sat, 09 Sep 2017 18:36:00 -0000 [thread overview]
Message-ID: <87zia3afdt.fsf@bapiya> (raw)
In-Reply-To: <02d471158b96dd13bd7f998f8ec2a310@polymtl.ca> (Simon Marchi's message of "Sat, 09 Sep 2017 19:47:04 +0200")
>>>>> "Simon" == Simon Marchi <simon.marchi@polymtl.ca> writes:
Simon> I think overall this function is a bad example of how to share code
Simon> between CLI and MI. There are so many if (is_mi_like_p) that it's
Simon> essentially two functions in one. Apart from iterating on threads,
Simon> the MI and CLI outputs don't share much...
I think a long term goal should be to remove all those is_mi_like_p
checks. In some situations this might mean introducing "MI 4" and
fixing up the historical baggage; but that would also be a good thing,
as there are a few places where gdb has remained buggy for the sake of
not breaking existing MI readers.
What I'd really like is for MI to be defined as JSON (it is pretty close
already), but that's maybe a bit much to ask.
A related thought is that if more spots used ui-out (I'm thinking mainly
*-valprint, but maybe there are others), then colorization could be done
at the ui-out layer.
Tom
next prev parent reply other threads:[~2017-09-09 18:36 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-09 15:35 [RFA 0/7] more ui-out cleanup removal Tom Tromey
2017-09-09 15:35 ` [RFA 5/7] Use ui_out_emit_list in more places Tom Tromey
2017-09-09 18:43 ` Simon Marchi
2017-09-09 15:35 ` [RFA 1/7] Use ui_out_emit_table and ui_out_emit_list in print_thread_info_1 Tom Tromey
2017-09-09 17:47 ` Simon Marchi
2017-09-09 18:36 ` Tom Tromey [this message]
2017-09-09 19:20 ` Matt Rice
2017-09-09 15:35 ` [RFA 4/7] Use ui_out_emit_tuple in disasm.c Tom Tromey
2017-09-09 18:35 ` Simon Marchi
2017-10-12 15:37 ` Simon Marchi
2017-10-12 16:06 ` Simon Marchi
2017-10-12 16:11 ` Tom Tromey
2017-10-12 21:07 ` Tom Tromey
2017-10-13 16:13 ` Tom Tromey
2017-10-16 22:37 ` Simon Marchi
2017-10-16 22:59 ` Tom Tromey
2017-09-09 15:35 ` [RFA 3/7] Use ui_out_emit_tuple in more places Tom Tromey
2017-09-09 18:32 ` Simon Marchi
2017-09-09 19:32 ` Tom Tromey
2017-09-09 15:35 ` [RFA 6/7] Remove make_cleanup_ui_out_redirect_pop Tom Tromey
2017-09-09 18:49 ` Simon Marchi
2017-09-09 15:46 ` [RFA 7/7] Use ui_out_emit_list and ui_out_emit_tuple with gdb::optional Tom Tromey
2017-09-09 18:51 ` Simon Marchi
2017-09-09 15:46 ` [RFA 2/7] Remove make_cleanup_ui_out_table_begin_end Tom Tromey
2017-09-09 16:02 ` Tom Tromey
2017-09-09 18:22 ` Simon Marchi
2017-09-09 19:44 ` [RFA 0/7] more ui-out cleanup removal Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zia3afdt.fsf@bapiya \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@polymtl.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox