[mi] -stack-list-arguments --simple-values

[mi] -stack-list-arguments --simple-values

[Vladimir Prus]

[-- Attachment #1: Type: Text/Plain, Size: 346 bytes --]


This patch makes -stack-list-arguments --simple-values work.
It looks like --simple-values (and friends) were accepted for
-stack-list-locals, but not for -stack-list-arguments. While
the utility of such human friendly spelling is unclear, for
a machine interface, it's even more confusing having 1/2
of relevant commands accept it.

- Volodya


[-- Attachment #2: stack_options.diff --]
[-- Type: text/x-patch, Size: 6079 bytes --]

Index: gdb/ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.10656
diff -u -p -r1.10656 ChangeLog
--- gdb/ChangeLog	30 Jun 2009 09:24:46 -0000	1.10656
+++ gdb/ChangeLog	30 Jun 2009 09:36:17 -0000
@@ -1,5 +1,10 @@
 2009-06-30  Vladimir Prus  <vladimir@codesourcery.com>
 
+	* mi/mi-cmd-stack.c (parse_print_values): New.
+	(mi_cmd_stack_list_locals, mi_cmd_stack_list_args): Use the above.
+
+2009-06-30  Vladimir Prus  <vladimir@codesourcery.com>
+
 	* varobj.c (varobj_get_type): Use type_to_string.
 
 2009-06-29  Pedro Alves  <pedro@codesourcery.com>
Index: gdb/mi/mi-cmd-stack.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmd-stack.c,v
retrieving revision 1.43
diff -u -p -r1.43 mi-cmd-stack.c
--- gdb/mi/mi-cmd-stack.c	3 Jan 2009 05:57:57 -0000	1.43
+++ gdb/mi/mi-cmd-stack.c	30 Jun 2009 09:36:17 -0000
@@ -116,6 +116,24 @@ mi_cmd_stack_info_depth (char *command, 
   ui_out_field_int (uiout, "depth", i);
 }
 
+static enum print_values
+parse_print_values (char *name)
+{
+   if (strcmp (name, "0") == 0
+       || strcmp (name, mi_no_values) == 0)
+     return PRINT_NO_VALUES;
+   else if (strcmp (name, "1") == 0
+	    || strcmp (name, mi_all_values) == 0)
+     return PRINT_ALL_VALUES;
+   else if (strcmp (name, "2") == 0
+	    || strcmp (name, mi_simple_values) == 0)
+     return PRINT_SIMPLE_VALUES;
+   else
+     error (_("Unknown value for PRINT_VALUES: must be: \
+0 or \"%s\", 1 or \"%s\", 2 or \"%s\""),
+	    mi_no_values, mi_all_values, mi_simple_values);
+}
+
 /* Print a list of the locals for the current frame. With argument of
    0, print only the names, with argument of 1 print also the
    values. */
@@ -130,20 +148,7 @@ mi_cmd_stack_list_locals (char *command,
 
    frame = get_selected_frame (NULL);
 
-   if (strcmp (argv[0], "0") == 0
-       || strcmp (argv[0], mi_no_values) == 0)
-     print_values = PRINT_NO_VALUES;
-   else if (strcmp (argv[0], "1") == 0
-	    || strcmp (argv[0], mi_all_values) == 0)
-     print_values = PRINT_ALL_VALUES;
-   else if (strcmp (argv[0], "2") == 0
-	    || strcmp (argv[0], mi_simple_values) == 0)
-     print_values = PRINT_SIMPLE_VALUES;
-   else
-     error (_("Unknown value for PRINT_VALUES: must be: \
-0 or \"%s\", 1 or \"%s\", 2 or \"%s\""),
-	    mi_no_values, mi_all_values, mi_simple_values);
-  list_args_or_locals (1, print_values, frame);
+   list_args_or_locals (1, parse_print_values (argv[0]), frame);
 }
 
 /* Print a list of the arguments for the current frame. With argument
@@ -157,6 +162,7 @@ mi_cmd_stack_list_args (char *command, c
   int i;
   struct frame_info *fi;
   struct cleanup *cleanup_stack_args;
+  enum print_values print_values;
 
   if (argc < 1 || argc > 3 || argc == 2)
     error (_("mi_cmd_stack_list_args: Usage: PRINT_VALUES [FRAME_LOW FRAME_HIGH]"));
@@ -174,6 +180,8 @@ mi_cmd_stack_list_args (char *command, c
       frame_high = -1;
     }
 
+  print_values = parse_print_values (argv[0]);
+
   /* Let's position fi on the frame at which to start the
      display. Could be the innermost frame if the whole stack needs
      displaying, or if frame_low is 0. */
@@ -196,7 +204,7 @@ mi_cmd_stack_list_args (char *command, c
       QUIT;
       cleanup_frame = make_cleanup_ui_out_tuple_begin_end (uiout, "frame");
       ui_out_field_int (uiout, "level", i);
-      list_args_or_locals (0, atoi (argv[0]), fi);
+      list_args_or_locals (0, print_values, fi);
       do_cleanups (cleanup_frame);
     }
 
Index: gdb/testsuite/ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/ChangeLog,v
retrieving revision 1.1902
diff -u -p -r1.1902 ChangeLog
--- gdb/testsuite/ChangeLog	29 Jun 2009 18:53:55 -0000	1.1902
+++ gdb/testsuite/ChangeLog	30 Jun 2009 09:36:18 -0000
@@ -1,3 +1,8 @@
+2009-06-30  Vladimir Prus  <vladimir@codesourcery.com>
+
+	* gdb.mi/mi-stack.exp: Testing symbolic options
+	to -stack-list-locals and -stack-list-arguments.
+
 2009-06-29  Jan Kratochvil  <jan.kratochvil@redhat.com>
 
 	* gdb.threads/current-lwp-dead.exp, gdb.threads/current-lwp-dead.c: New.
Index: gdb/testsuite/gdb.mi/mi-stack.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-stack.exp,v
retrieving revision 1.28
diff -u -p -r1.28 mi-stack.exp
--- gdb/testsuite/gdb.mi/mi-stack.exp	3 Jan 2009 05:58:06 -0000	1.28
+++ gdb/testsuite/gdb.mi/mi-stack.exp	30 Jun 2009 09:36:18 -0000
@@ -115,7 +115,7 @@ proc test_stack_args_listing {} {
 	    "232\\^done,stack-args=\\\[frame=\{level=\"1\",args=\\\[\{name=\"strarg\",value=\"$hex \\\\\"A string argument.\\\\\"\"\}\\\]\}\\\]" \
                 "stack args listing 1 1 1"
 
-    mi_gdb_test "233-stack-list-arguments 1 1 3" \
+    mi_gdb_test "233-stack-list-arguments --all-values 1 3" \
 	    "233\\^done,stack-args=\\\[frame=\{level=\"1\",args=\\\[\{name=\"strarg\",value=\"$hex \\\\\"A string argument.\\\\\"\"\}\\\]\},frame=\{level=\"2\",args=\\\[\{name=\"intarg\",value=\"2\"\},\{name=\"strarg\",value=\"$hex \\\\\"A string argument.\\\\\"\"\}\\\]\},frame=\{level=\"3\",args=\\\[\{name=\"intarg\",value=\"2\"\},\{name=\"strarg\",value=\"$hex \\\\\"A string argument.\\\\\"\"\},\{name=\"fltarg\",value=\"3.5\"\}\\\]\}\\\]" \
                 "stack args listing 1 1 3"
 
@@ -180,7 +180,7 @@ mi_execute_to "exec-next 4" "end-steppin
     "232\\^done,locals=\\\[\{name=\"A\",value=\"1\"\},\{name=\"B\",value=\"2\"\},\{name=\"C\",value=\"3\"\},\{name=\"D\",value=\"\\{0, 1, 2\\}\"\}\\\]" \
                 "stack locals listing of names and values"
 
-    mi_gdb_test "232-stack-list-locals 2" \
+    mi_gdb_test "232-stack-list-locals --simple-values" \
 	    "232\\^done,locals=\\\[\{name=\"A\",type=\"int\",value=\"1\"\},\{name=\"B\",type=\"int\",value=\"2\"\},\{name=\"C\",type=\"int\",value=\"3\"\},\{name=\"D\",type=\"int \\\[3\\\]\"\}\\\]" \
   "stack locals listing, simple types: names and values, complex type: names and types"
 

Re: [mi] -stack-list-arguments --simple-values

[Daniel Jacobowitz]

On Tue, Jun 30, 2009 at 01:39:30PM +0400, Vladimir Prus wrote:
> 
> This patch makes -stack-list-arguments --simple-values work.
> It looks like --simple-values (and friends) were accepted for
> -stack-list-locals, but not for -stack-list-arguments. While
> the utility of such human friendly spelling is unclear, for
> a machine interface, it's even more confusing having 1/2
> of relevant commands accept it.

Was this already in the manual?

-- 
Daniel Jacobowitz
CodeSourcery

[mi] -stack-list-arguments --simple-values

[Nick Roberts]

 > This patch makes -stack-list-arguments --simple-values work.
 > It looks like --simple-values (and friends) were accepted for
 > -stack-list-locals, but not for -stack-list-arguments. While
 > the utility of such human friendly spelling is unclear, for
 > a machine interface, it's even more confusing having 1/2
 > of relevant commands accept it.

It's not immediately clear from the manual that SHOW-VALUES from
-stack-list-arguments and PRINT-VALUES from -stack-list-locals are related.
-stack-list-arguments takes three arguments while -stack-list-locals only
takes -one.  I think it would be nice to have one command,
-stack-list-locals-and-args say, that lists both the locals and the arguments
of the current frame:


  The `-stack-list-locals-and-args' Command
  --------------------------------

  Synopsis
  ........

  -stack-list-locals-and-args PRINT-VALUES

     Display the local variable and argument names for the selected frame.
  If PRINT-VALUES is 0 or `--no-values', print only the names of the
  variables; if it is 1 or `--all-values', print also their values; and
  if it is 2 or `--simple-values', print the name, type and value for
  simple data types and the name and type for arrays, structures and
  unions.  In this last case, a frontend can immediately display the
  value of simple data types and create variable objects for other data
  types when the user wishes to explore their values in more detail.


GDB Command
...........

`info locals' and `info locals' in GDB.

Example
.......

     (gdb)
     -stack-list-locals-and-args 0
     ^done,vars={locals={name="A",name="B",name="C"},
                 args={name="arg1",name="arg2"}}
     (gdb)
     -stack-list-locals-and-args --all-values
     ^done,vars={locals={{name="A",value="1"},{name="B",value="2"},
       {name="C",value="{1, 2, 3}"}},args={{name="arg1",value="5"},
       {name="arg4",value="6.2"}}}
     (gdb)


using curly brackets which appears to be more in keeping with the
JSON concept of an object.

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

Re: [mi] -stack-list-arguments --simple-values

[Vladimir Prus]

On Wednesday 01 July 2009 Nick Roberts wrote:

>  > This patch makes -stack-list-arguments --simple-values work.
>  > It looks like --simple-values (and friends) were accepted for
>  > -stack-list-locals, but not for -stack-list-arguments. While
>  > the utility of such human friendly spelling is unclear, for
>  > a machine interface, it's even more confusing having 1/2
>  > of relevant commands accept it.
> 
> It's not immediately clear from the manual that SHOW-VALUES from
> -stack-list-arguments and PRINT-VALUES from -stack-list-locals are related.
> -stack-list-arguments takes three arguments while -stack-list-locals only
> takes -one.  I think it would be nice to have one command,
> -stack-list-locals-and-args say, that lists both the locals and the arguments
> of the current frame:

It would be nice indeed. However, I have not entirely designed how a frontend
should actually work with locals and arguments, so I did not do anything
like that -- just fixed obvious inconsistency between existing commands.

- Volodya

Re: [mi] -stack-list-arguments --simple-values

[Niko Sams]

On Wed, Jul 1, 2009 at 19:34, Vladimir Prus<vladimir@codesourcery.com> wrote:
> On Wednesday 01 July 2009 Nick Roberts wrote:
>
>>  > This patch makes -stack-list-arguments --simple-values work.
>>  > It looks like --simple-values (and friends) were accepted for
>>  > -stack-list-locals, but not for -stack-list-arguments. While
>>  > the utility of such human friendly spelling is unclear, for
>>  > a machine interface, it's even more confusing having 1/2
>>  > of relevant commands accept it.
>>
>> It's not immediately clear from the manual that SHOW-VALUES from
>> -stack-list-arguments and PRINT-VALUES from -stack-list-locals are related.
>> -stack-list-arguments takes three arguments while -stack-list-locals only
>> takes -one.  I think it would be nice to have one command,
>> -stack-list-locals-and-args say, that lists both the locals and the arguments
>> of the current frame:
>
> It would be nice indeed. However, I have not entirely designed how a frontend
> should actually work with locals and arguments, so I did not do anything
> like that -- just fixed obvious inconsistency between existing commands.
>
Isn't every arg a local? Why would an IDE want to display arguments
and locals differently?
In KDevelop I added the arguments to the locals.
-stack-list-locals-and-args would be perfect.

Niko

Re: [mi] -stack-list-arguments --simple-values

[André Pönitz]

On Wednesday 01 July 2009 19:44:53 Niko Sams wrote:
> > It would be nice indeed. However, I have not entirely designed how a frontend
> > should actually work with locals and arguments, so I did not do anything
> > like that -- just fixed obvious inconsistency between existing commands.
> >
> Isn't every arg a local? Why would an IDE want to display arguments
> and locals differently?
> In KDevelop I added the arguments to the locals.
> -stack-list-locals-and-args would be perfect.

[Qt Creator does the same btw] So for me, too, yes.

But in any case it would be nice to be as open as (easily) possible
to other approaches and not to force some design decision on a
frontend. In case of  -stack-list-locals-and-args  that would be 
possible by e.g. adding a  kind="arg" / kind="local" flag or such.

On a related note, can't we have the contents of a 
'-stack-list-locals-and-args' in the *stopped  message?

_That_ would save a roundtrip, -stack-list-locals-and-args would
probably not save time at all, at best remove twenty lines of
frontend code...

Andre'

Re: [mi] -stack-list-arguments --simple-values

[Niko Sams]

On Thu, Jul 2, 2009 at 10:05, André Pönitz<andre.poenitz@nokia.com> wrote:
> On Wednesday 01 July 2009 19:44:53 Niko Sams wrote:
>> > It would be nice indeed. However, I have not entirely designed how a frontend
>> > should actually work with locals and arguments, so I did not do anything
>> > like that -- just fixed obvious inconsistency between existing commands.
>> >
>> Isn't every arg a local? Why would an IDE want to display arguments
>> and locals differently?
>> In KDevelop I added the arguments to the locals.
>> -stack-list-locals-and-args would be perfect.
>
> [Qt Creator does the same btw] So for me, too, yes.
>
> But in any case it would be nice to be as open as (easily) possible
> to other approaches and not to force some design decision on a
> frontend. In case of  -stack-list-locals-and-args  that would be
> possible by e.g. adding a  kind="arg" / kind="local" flag or such.
>
> On a related note, can't we have the contents of a
> '-stack-list-locals-and-args' in the *stopped  message?
If the user doesn't have a variable view shown there is no need to
update locals.
So this needs to be optional.

Niko

Re: [mi] -stack-list-arguments --simple-values

[Nick Roberts]

 > > Isn't every arg a local? Why would an IDE want to display arguments
 > > and locals differently?
 > > In KDevelop I added the arguments to the locals.
 > > -stack-list-locals-and-args would be perfect.
 > 
 > [Qt Creator does the same btw] So for me, too, yes.
 > 
 > But in any case it would be nice to be as open as (easily) possible
 > to other approaches and not to force some design decision on a
 > frontend. In case of  -stack-list-locals-and-args  that would be 
 > possible by e.g. adding a  kind="arg" / kind="local" flag or such.
 > 
 > On a related note, can't we have the contents of a 
 > '-stack-list-locals-and-args' in the *stopped  message?
 > 
 > _That_ would save a roundtrip, -stack-list-locals-and-args would
 > probably not save time at all, at best remove twenty lines of
 > frontend code...

If "added the arguments to the locals" means combining the output of
-stack-list-arguments with -stack-list-locals then presumably
-stack-list-locals-and-args would save one round trip time.  I don't think the
extra would be very expensive though.

Another, possibly bigger, benefit of introducing such new commands is that the
syntax could be more formally defined and they could gradually replace old
ones.

Currently the output syntax is:

`TUPLE ==>'
     ` "{}" | "{" RESULT ( "," RESULT )* "}" '

`LIST ==>'
     ` "[]" | "[" VALUE ( "," VALUE )* "]" | "[" RESULT ( "," RESULT )*
     "]" '

and it would be nice to have:


`TUPLE ==>'
     ` "{}" | "{" RESULT ( "," RESULT )* "}" '

`LIST ==>'
     ` "[]" | "[" VALUE ( "," VALUE )* "]" '


-stack-list-locals is one of the commands that has

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


One reason why, in Emacs, we don't fully parse MI output, but use regular
expression matching, is because of these inconsistencies.

People often lament the poor syntax of MI but it really needs a plan to
replace it with something better.  However, such a plan would really need a
maintainer to lead it and doesn't really work on a Write After Approval basis.

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

Re: [mi] -stack-list-arguments --simple-values

[Vladimir Prus]

Nick Roberts wrote:

>  > > Isn't every arg a local? Why would an IDE want to display arguments
>  > > and locals differently?
>  > > In KDevelop I added the arguments to the locals.
>  > > -stack-list-locals-and-args would be perfect.
>  > 
>  > [Qt Creator does the same btw] So for me, too, yes.
>  > 
>  > But in any case it would be nice to be as open as (easily) possible
>  > to other approaches and not to force some design decision on a
>  > frontend. In case of  -stack-list-locals-and-args  that would be
>  > possible by e.g. adding a  kind="arg" / kind="local" flag or such.
>  > 
>  > On a related note, can't we have the contents of a
>  > '-stack-list-locals-and-args' in the *stopped  message?
>  > 
>  > _That_ would save a roundtrip, -stack-list-locals-and-args would
>  > probably not save time at all, at best remove twenty lines of
>  > frontend code...
> 
> If "added the arguments to the locals" means combining the output of
> -stack-list-arguments with -stack-list-locals then presumably
> -stack-list-locals-and-args would save one round trip time.  I don't think the
> extra would be very expensive though.
> 
> Another, possibly bigger, benefit of introducing such new commands is that the
> syntax could be more formally defined and they could gradually replace old
> ones.
> 
> Currently the output syntax is:
> 
> `TUPLE ==>'
>      ` "{}" | "{" RESULT ( "," RESULT )* "}" '
> 
> `LIST ==>'
>      ` "[]" | "[" VALUE ( "," VALUE )* "]" | "[" RESULT ( "," RESULT )*
>      "]" '
> 
> and it would be nice to have:
> 
> 
> `TUPLE ==>'
>      ` "{}" | "{" RESULT ( "," RESULT )* "}" '
> 
> `LIST ==>'
>      ` "[]" | "[" VALUE ( "," VALUE )* "]" '
> 
> 
> -stack-list-locals is one of the commands that has
> 
> "[" RESULT ( "," RESULT )* "]"  output.
> 
> 
> One reason why, in Emacs, we don't fully parse MI output, but use regular
> expression matching, is because of these inconsistencies.

Can you clarify this? KDevelop does use a parser and convert MI into
a convenient internal representation, so it is clearly possible in C++.
I don't know much about Emacs internals -- is there some problem with
parsing methods available there?

 
> People often lament the poor syntax of MI but it really needs a plan to
> replace it with something better.  However, such a plan would really need a
> maintainer to lead it and doesn't really work on a Write After Approval basis.

FWIW, both the above issue is universally believed to be not good, so
patches to introduce MI3 version and switch select commands to "right"
syntax appear to be fairly simple.

- Volodya

 

Re: [mi] -stack-list-arguments --simple-values

[Nick Roberts]

 > > One reason why, in Emacs, we don't fully parse MI output, but use regular
 > > expression matching, is because of these inconsistencies.
 > 
 > Can you clarify this? KDevelop does use a parser and convert MI into
 > a convenient internal representation, so it is clearly possible in C++.
 > I don't know much about Emacs internals -- is there some problem with
 > parsing methods available there?

We're just starting to fully use MI in Emacs and formally parse (Dmitry) the
output but I would think it's possible parse anything in Emacs (Lisp) and it's
just a question of complexity.

 >  
 > > People often lament the poor syntax of MI but it really needs a plan to
 > > replace it with something better.  However, such a plan would really need a
 > > maintainer to lead it and doesn't really work on a Write After Approval basis.
 > 
 > FWIW, both the above issue is universally believed to be not good, so
 > patches to introduce MI3 version and switch select commands to "right"
 > syntax appear to be fairly simple.

I quite like the idea of incrementally changing the output with new commands
because as soon as MI3 is released, you can be sure people will find
shortcomings with that.  You could say it is a more agile approach.

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

Re: [mi] -stack-list-arguments --simple-values

[Tom Tromey]

>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> 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
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?

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.

Tom

Re: [mi] -stack-list-arguments --simple-values

[Vladimir Prus]

Tom Tromey wrote:

>>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> 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
> 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?
> 
> 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.

- Volodya

Re: [mi] -stack-list-arguments --simple-values

[Nick Roberts]

 > 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