Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Matt Rice <ratmice@gmail.com>
To: Tom Tromey <tom@tromey.com>
Cc: Simon Marchi <simon.marchi@polymtl.ca>,
		"gdb-patches@sourceware.org" <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 19:20:00 -0000	[thread overview]
Message-ID: <CACTLOFq8iN9FafMdBEs7ih6Q7JuOYRobXzhZfyyTCDgC5+iFBA@mail.gmail.com> (raw)
In-Reply-To: <87zia3afdt.fsf@bapiya>

On Sat, Sep 9, 2017 at 11:36 AM, Tom Tromey <tom@tromey.com> wrote:
>>>>>> "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.

At some point I had it encoding into python literals, with MI output
being converted into something parsable by the python literal_eval function[1]

JSON is really not very different, the only thing which kind of sucked
about it was dealing with
the places a range of values, or a slice is sent, these needed the
range to then be marshalled and unmarshalled
into tuples of numbers then back into ranges, this is more of an
annoyance than anything catastrophic,
but it means you have to evaluate the literals, then evaluate the
objects returned by that first pass...
using some little snippet of code specific to the data being sent.

https://docs.python.org/2/library/ast.html#ast.literal_eval

I don't know JSON well, but i don't see its format having a notion of
slices either
neither do I remember where specifically this came up in mi,
but if both having and eating cake were on the table JSON + primitive
syntax for range/slices would
be nice.

> 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


  reply	other threads:[~2017-09-09 19:20 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 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 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 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
2017-09-09 19:20       ` Matt Rice [this message]
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: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: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 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 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=CACTLOFq8iN9FafMdBEs7ih6Q7JuOYRobXzhZfyyTCDgC5+iFBA@mail.gmail.com \
    --to=ratmice@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simon.marchi@polymtl.ca \
    --cc=tom@tromey.com \
    /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