Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: nickrob@snap.net.nz (Nick Roberts)
To: tromey@redhat.com
Cc: Vladimir Prus <vladimir@codesourcery.com>,
		gdb-patches@sources.redhat.com
Subject: Re: [mi] -stack-list-arguments --simple-values
Date: Sun, 26 Jul 2009 11:42:00 -0000	[thread overview]
Message-ID: <19051.44515.133597.439183@totara.tehura.co.nz> (raw)
In-Reply-To: <m3ws5xokop.fsf@fleche.redhat.com>

 > Nick> People often lament the poor syntax of MI but it really needs a
 > Nick> plan to replace it with something better.  However, such a plan
 > Nick> would really need a maintainer to lead it and doesn't really work
 > Nick> on a Write After Approval basis.
 > 
 > I think we can differentiate here between a plan and the patches
 > implementing the plan.
 >
 > In my view we could discuss the plan on the gdb list and reach some kind
 > of agreement.  This can be initiated by anybody.  If you want to start
 > it, I will try to help ensure that the discussion reaches some
 > conclusion.

Thanks for the offer but I have found it hard to convince maintainers to
make changes that they are not interested in.  For example, changing the
behaviour of "record stop" to not need confirmation when the server prefix
is used:

  http://sourceware.org/ml/gdb/2009-07/msg00153.html

I see this as an uncontroversial change that wouldn't affect other GDB
developers.  It probably wouldn't benefit them either but in Emacs development
the rule is just basically "do no harm".

With larger changes, e.g. using notifications for breakpoints, it can be
harder to reach a conclusion.

 > I think if there is general agreement about the direction then patch
 > review need not be a big problem.  I suppose my view is based on the
 > idea that the plan is probably where most of the contention lies, and
 > usually the implementation bits are straightforward.
 > 
 > Volodya> FWIW, both the above issue is universally believed to be not
 > Volodya> good, so patches to introduce MI3 version and switch select
 > Volodya> commands to "right" syntax appear to be fairly simple.
 > 
 > Nick> I quite like the idea of incrementally changing the output with
 > Nick> new commands because as soon as MI3 is released, you can be sure
 > Nick> people will find shortcomings with that.  You could say it is a
 > Nick> more agile approach.
 > 
 > What do you suggest?

Just that the output of some commands break the formal syntax rules, or
at least, parsing would be easier if:

 "[" RESULT ( "," RESULT )* "]"

wasn't admissible as in a LIST.  This could be circumvented, by adding new
commands ("embrace and extend") that provide a more consistent rather than
adding another MI level.

In Emacs, Dmitry Dzhus, has parsed the GDB/MI output as JSON objects and,
by way of an example, we might submit a patch for the new command
-stack-list-locals-and-args that was discussed earlier on the gdb mailing
list.

Of course, changes in asynchronous output probably would need a new MI level.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


      parent reply	other threads:[~2009-07-26  1:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-30  9:39 Vladimir Prus
2009-06-30 13:59 ` Daniel Jacobowitz
2009-07-01 13:13 ` Nick Roberts
2009-07-01 17:34   ` Vladimir Prus
2009-07-01 17:45     ` Niko Sams
2009-07-02  8:05       ` André Pönitz
2009-07-02  8:13         ` Niko Sams
2009-07-02  9:37         ` Nick Roberts
2009-07-02 10:30           ` Vladimir Prus
2009-07-03  8:33             ` Nick Roberts
2009-07-24 22:07               ` Tom Tromey
2009-07-25  7:21                 ` Vladimir Prus
2009-07-26 11:42                 ` Nick Roberts [this message]

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=19051.44515.133597.439183@totara.tehura.co.nz \
    --to=nickrob@snap.net.nz \
    --cc=gdb-patches@sources.redhat.com \
    --cc=tromey@redhat.com \
    --cc=vladimir@codesourcery.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