This is the mail archive of the
mailing list for the GDB project.
Re: [mi] -stack-list-arguments --simple-values
- From: Vladimir Prus <vladimir at codesourcery dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Sat, 25 Jul 2009 10:15:58 +0400
- Subject: Re: [mi] -stack-list-arguments --simple-values
- References: <firstname.lastname@example.org> <email@example.com>
Tom Tromey wrote:
>>>>>> "Nick" == Nick Roberts <firstname.lastname@example.org> writes:
> Replying to an old-ish note.
> 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
> 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?
> I ask because this does seem to come up over and over. Not only are
> there MI formatting bugs, there are things like the recently discussed
> "info shared" output problem -- a command that has no MI equivalent, no
> use of ui_out, and which, presumably, existing MI consumers handle by
> parsing the CLI output.
> I have been thinking about this case for a few days and I really don't
> have any good solution. I also think that MI versioning seems to work
> at too coarse a granularity. For pretty-printing we're adding an
> explicit "enable" command to work around this problem -- but it seems
> odd to have an MI session start off with 100 -enable-foo commands. And,
> this case doesn't account for the mess that it would leave behind if we,
> e.g., applied it to the "info shared" case.
I presume one approach is to declare MI3 "volatile" and subject to breaking
change on short notice, so that I can evolve and stabilize freely, and
only then be freezed.