Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Simon Marchi <simon.marchi@ericsson.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] doc: Add table of MI versions
Date: Tue, 15 Jan 2019 17:28:00 -0000	[thread overview]
Message-ID: <831s5despw.fsf@gnu.org> (raw)
In-Reply-To: <20190114203902.11490-1-simon.marchi@ericsson.com> (message from	Simon Marchi on Mon, 14 Jan 2019 20:39:16 +0000)

> From: Simon Marchi <simon.marchi@ericsson.com>
> CC: Simon Marchi <simon.marchi@ericsson.com>
> Date: Mon, 14 Jan 2019 20:39:16 +0000
> 
> This patch adds a table summarizing the history or MI versions:
> 
> - The version number
> - Which GDB version introduced it
> - Breaking changes compared to the previous version

Thanks.

> -Although @sc{gdb/mi} is still incomplete, it is currently being used
> -by a variety of front ends to @value{GDBN}.  This makes it difficult
> -to introduce new functionality without breaking existing usage.  This
> -section tries to minimize the problems by describing how the protocol
> -might change.
> +The MI interface is versioned, allowing it to evolve while avoiding breaking
> +existing front ends.

Some of the rationale you removed sounds like something good to have.
Explaining the rationale for a section is in general a Good Thing,
IMO.

>  If the changes are likely to break front ends, the MI version level
> -will be increased by one.  This will allow the front end to parse the
> -output according to the MI version.  Apart from mi0, new versions of
> -@value{GDBN} will not support old versions of MI and it will be the
> -responsibility of the front end to work with the new one.
> +will be increased by one.  Previous versions of MI remain available, allowing
> +front ends to keep using them until they are modified to use the latest MI
> +version.

Likewise here: the old text explained that miN version will generally
be incompatible with miN-1 version.  Your change removes that
important statement.  I'd prefer not to lose that part.

> -@c Starting with mi3, add a new command -mi-version that prints the MI
> -@c version?

Why did you remove the comment?  It seems like a valid idea, perhaps
worth implementing.

> +Since @code{--interpreter=mi} always points to the latest MI version, it is
> +recommended that front ends request a specific version of MI when launching
> +@value{GDBN} (e.g. @code{--interpreter=mi2}) to make sure to get an interpreter
                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
"to make sure they get and interpreter ..."

> +The @code{-environment-pwd}, @code{-environment-directory} and
> +@code{-environment-path} commands now returns values using the MI output
> +syntax, rather than CLI output.
                       ^^^^^^^^^^
"CLI output syntax", I presume.

> +@item
> +@code{-var-list-children}'s @code{children} result field is a now list, rather
                                                            ^^^^^^^^
A typo.


  reply	other threads:[~2019-01-15 17:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-14 20:39 Simon Marchi
2019-01-15 17:28 ` Eli Zaretskii [this message]
2019-01-15 18:27   ` Simon Marchi
2019-01-15 19:20     ` Eli Zaretskii
2019-01-15 20:37       ` Simon Marchi
2019-01-16 17:04         ` Eli Zaretskii
2019-01-16 17:21           ` Simon Marchi
2019-01-16 20:57             ` André Pönitz
2019-01-16 19:35           ` Simon Marchi

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=831s5despw.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=simon.marchi@ericsson.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