-var-show-attributes response syntax

-var-show-attributes response syntax

[Vladimir Prus]

Hello!

Here's the docs for -var-show-attributes MI command:

       Synopsis 
            -var-show-attributes name

          List attributes of the specified variable object name: 
             status=attr [ ( ,attr )* ]
             where attr is { { editable | noneditable } | TBD }.

What is the reason for using "non" instead of "attribute_name=attribute_value" 
syntax? The above assumes all attributes are boolean, which is not very 
extensible.

How about changing the above to "editable=0/1"? This sounds like breaking 
backward compatibility, but probably is not, because "editable" is broken 
itself:

     -var-create C * 1+1
     ^done,name="C",numchild="0",type="long"
     (gdb)
     -var-show-attributes C
     ^done,attr="editable"
     (gdb)

Thoughts?

- Volodya

Re: -var-show-attributes response syntax

[Nick Roberts]

Vladimir Prus writes:
 > 
 > Hello!
 > 
 > Here's the docs for -var-show-attributes MI command:
 > 
 >        Synopsis 
 >             -var-show-attributes name
 > 
 >           List attributes of the specified variable object name: 
 >              status=attr [ ( ,attr )* ]
 >              where attr is { { editable | noneditable } | TBD }.
 > 
 > What is the reason for using "non" instead of "attribute_name=attribute_value" 
 > syntax? The above assumes all attributes are boolean, which is not very 
 > extensible.

I think the above means output may be something like:

^done,attr={"editable","yellow","big"}

(Perhaps { a | b } should be documented in "Notation and Terminology".)

Currently it appears that attr="noneditable" for constant types and
attr="editable" otherwise.  I don't know what other attributes the authors
had in mind (long?, volatile?, local?, static?).

 > How about changing the above to "editable=0/1"? 

I see no advantage in restricting the output but I've not used this command.
How do you want to use it?

 >                                                 This sounds like breaking 
 > backward compatibility, but probably is not, because "editable" is broken 
 > itself:
 > 
 >      -var-create C * 1+1
 >      ^done,name="C",numchild="0",type="long"
 >      (gdb)
 >      -var-show-attributes C
 >      ^done,attr="editable"
 >      (gdb)

Why do you think this is broken?

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

Re: -var-show-attributes response syntax

[Vladimir Prus]

Nick Roberts wrote:

> Vladimir Prus writes:
>  > 
>  > Hello!
>  > 
>  > Here's the docs for -var-show-attributes MI command:
>  > 
>  >        Synopsis
>  >             -var-show-attributes name
>  > 
>  >           List attributes of the specified variable object name:
>  >              status=attr [ ( ,attr )* ]
>  >              where attr is { { editable | noneditable } | TBD }.
>  > 
>  > What is the reason for using "non" instead of
>  > "attribute_name=attribute_value" syntax? The above assumes all
>  > attributes are boolean, which is not very extensible.
> 
> I think the above means output may be something like:
> 
> ^done,attr={"editable","yellow","big"}

Yes, and this is exactly what I'm objecting too. 

> (Perhaps { a | b } should be documented in "Notation and Terminology".)
> 
> Currently it appears that attr="noneditable" for constant types and
> attr="editable" otherwise.  I don't know what other attributes the authors
> had in mind (long?, volatile?, local?, static?).
> 
>  > How about changing the above to "editable=0/1"?
> 
> I see no advantage in restricting the output but I've not used this
> command. How do you want to use it?

I want to add a new attribute there, actually, and I'd prefer to use more
regular name=value syntax.

>  >                                                 This sounds like
>  >                                                 breaking
>  > backward compatibility, but probably is not, because "editable" is
>  > broken itself:
>  > 
>  >      -var-create C * 1+1
>  >      ^done,name="C",numchild="0",type="long"
>  >      (gdb)
>  >      -var-show-attributes C
>  >      ^done,attr="editable"
>  >      (gdb)
> 
> Why do you think this is broken?

Because you can't assign the value to "1+1" -- it's not lvalue. And trying
to do so will result in error from gdb.

- Volodya

Re: -var-show-attributes response syntax

[Nick Roberts]

 > > I see no advantage in restricting the output but I've not used this
 > > command. How do you want to use it?
 > 
 > I want to add a new attribute there, actually, and I'd prefer to use more
 > regular name=value syntax.

That's still a bit vague.

You say:

   How about changing the above to "editable=0/1"?

Are you suggesting

  ^done,attr="editable=0",  ^done,attr="editable=1"

or

  ^done,editable="0",  ^done,editable="1"

Either case still requires the front end to do some string
manipulation/comparison.  Can you state precisely how you would change the
format and precisely what the benefit would be?

 > >  >                                                 This sounds like
 > >  >                                                 breaking
 > >  > backward compatibility, but probably is not, because "editable" is
 > >  > broken itself:
 > >  > 
 > >  >      -var-create C * 1+1
 > >  >      ^done,name="C",numchild="0",type="long"
 > >  >      (gdb)
 > >  >      -var-show-attributes C
 > >  >      ^done,attr="editable"
 > >  >      (gdb)
 > > 
 > > Why do you think this is broken?
 > 
 > Because you can't assign the value to "1+1" -- it's not lvalue. And trying
 > to do so will result in error from gdb.

I see, I missed that.  In fact it my example was also wrong too, constants
in C appear to be editable.  Noneditables appear to be arrays, structures,
unions etc.  However I think this a separate issue to changing the syntax.




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

Re: -var-show-attributes response syntax

[Vladimir Prus]

On Friday 10 November 2006 23:43, Nick Roberts wrote:
>  > > I see no advantage in restricting the output but I've not used this
>  > > command. How do you want to use it?
>  >
>  > I want to add a new attribute there, actually, and I'd prefer to use
>  > more regular name=value syntax.
>
> That's still a bit vague.
>
> You say:
>
>    How about changing the above to "editable=0/1"?
>
> Are you suggesting
>
>   ^done,attr="editable=0",  ^done,attr="editable=1"
>
> or
>
>   ^done,editable="0",  ^done,editable="1"

The latter.

> Either case still requires the front end to do some string
> manipulation/comparison. 

I don't follow -- every syntax requires some string manipulation. In 
fact, "name=value" syntax is used in many other places so frontend already 
knows how to parse it.

> Can you state precisely how you would change the 
> format and precisely what the benefit would be?

The benefit is consistency with other MI response.

>  > >  >                                                 This sounds like
>  > >  >                                                 breaking
>  > >  > backward compatibility, but probably is not, because "editable" is
>  > >  > broken itself:
>  > >  >
>  > >  >      -var-create C * 1+1
>  > >  >      ^done,name="C",numchild="0",type="long"
>  > >  >      (gdb)
>  > >  >      -var-show-attributes C
>  > >  >      ^done,attr="editable"
>  > >  >      (gdb)
>  > >
>  > > Why do you think this is broken?
>  >
>  > Because you can't assign the value to "1+1" -- it's not lvalue. And
>  > trying to do so will result in error from gdb.
>
> I see, I missed that.  In fact it my example was also wrong too, constants
> in C appear to be editable.  Noneditables appear to be arrays, structures,
> unions etc.  However I think this a separate issue to changing the syntax.

I meant to say that this command does not seem to have useful semantic, so 
backward compatibility is not that important with it.

- Volodya

Re: -var-show-attributes response syntax

[Nick Roberts]

 > > Are you suggesting
 > >
 > >   ^done,attr="editable=0",  ^done,attr="editable=1"
 > >
 > > or
 > >
 > >   ^done,editable="0",  ^done,editable="1"
 > 
 > The latter.
 > 
 > > Either case still requires the front end to do some string
 > > manipulation/comparison. 
 > 
 > I don't follow -- every syntax requires some string manipulation. In 
 > fact, "name=value" syntax is used in many other places so frontend already 
 > knows how to parse it.
 > 
 > > Can you state precisely how you would change the 
 > > format and precisely what the benefit would be?
 > 
 > The benefit is consistency with other MI response.

I'm still not clear as you've not said what new attribute(s) you want to
introduce.  Perhaps, as an alternative, they could be added to the output of
-var-info-expression.  I think the best thing to do is submit a patch.

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

Re: -var-show-attributes response syntax

[Andreas Schwab]

Nick Roberts <nickrob@snap.net.nz> writes:

> Vladimir Prus writes:
>  > 
>  > Hello!
>  > 
>  > Here's the docs for -var-show-attributes MI command:
>  > 
>  >        Synopsis 
>  >             -var-show-attributes name
>  > 
>  >           List attributes of the specified variable object name: 
>  >              status=attr [ ( ,attr )* ]
>  >              where attr is { { editable | noneditable } | TBD }.
>  > 
>  > What is the reason for using "non" instead of "attribute_name=attribute_value" 
>  > syntax? The above assumes all attributes are boolean, which is not very 
>  > extensible.
>
> I think the above means output may be something like:
>
> ^done,attr={"editable","yellow","big"}

In which case I think status is a typo and should actually have been attr,
like this:

      attr=ATTR [ ( ,ATTR )* ]

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: -var-show-attributes response syntax

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sat, 11 Nov 2006 05:29:57 +1300
> Cc: gdb@sources.redhat.com
> 
> (Perhaps { a | b } should be documented in "Notation and Terminology".)

It already is, AFAICS.

Re: -var-show-attributes response syntax

[Nick Roberts]

 > > (Perhaps { a | b } should be documented in "Notation and Terminology".)
 > 
 > It already is, AFAICS.

What's to say {} aren't literal?  (Which, of course, they are in the output
syntax.)

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

Re: -var-show-attributes response syntax

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sat, 11 Nov 2006 10:50:07 +1300
> Cc: gdb@sources.redhat.com
> 
>  > > (Perhaps { a | b } should be documented in "Notation and Terminology".)
>  > 
>  > It already is, AFAICS.
> 
> What's to say {} aren't literal?  (Which, of course, they are in the output
> syntax.)

Sorry, I no longer understand the problem you were talking about.
AFAICS, the `{}' are literal (and so don't need to be discussed),
while `|' is _not_ a literal character and is already documented in
"Notation and Terminology".  What am I missing?

Re: -var-show-attributes response syntax

[Nick Roberts]

 > Sorry, I no longer understand the problem you were talking about.
 > AFAICS, the `{}' are literal (and so don't need to be discussed),
 > while `|' is _not_ a literal character and is already documented in
 > "Notation and Terminology".  What am I missing?

From "GDB/MI Variable Objects" in the manual:

      lang=LANG-SPEC,exp=EXPRESSION

  where LANG-SPEC is `{"C" | "C++" | "Java"}'.

means e.g lang="C" not lang={"C"}

      status=ATTR [ ( ,ATTR )* ]

  where ATTR is `{ { editable | noneditable } | TBD }'.

means e.g attr="editable" not attr={{"editable"}}

As Andreas says, status=ATTR should be attr=ATTR.  Also editable | noneditable
should presumably be strings:

  where ATTR is `{ { "editable" | "noneditable" } | TBD }'.

Having said that I always find it hard to use one syntax to describe another
in an unambiguous way and it's not that hard to find out what is meant by
invoking GDB with MI.


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

Re: -var-show-attributes response syntax

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sat, 11 Nov 2006 12:29:50 +1300
> Cc: gdb@sources.redhat.com
> 
> >From "GDB/MI Variable Objects" in the manual:
> 
>       lang=LANG-SPEC,exp=EXPRESSION
> 
>   where LANG-SPEC is `{"C" | "C++" | "Java"}'.
> 
> means e.g lang="C" not lang={"C"}

Then I think the braces `{}' should be simply removed from the
description in the manual.

Re: -var-show-attributes response syntax

[Nick Roberts]

 > >       lang=LANG-SPEC,exp=EXPRESSION
 > > 
 > >   where LANG-SPEC is `{"C" | "C++" | "Java"}'.
 > > 
 > > means e.g lang="C" not lang={"C"}
 > 
 > Then I think the braces `{}' should be simply removed from the
 > description in the manual.

Yes that would work here but not in other places:

      -var-create {NAME | "-"}
         {FRAME-ADDR | "*"} EXPRESSION


      -var-update [PRINT-VALUES] {NAME | "*"}

where the braces make the extent of the alternatives unambiguous.

I think the section is intelligible even if not formally correct.  Since MI
is  likely to change I suggest we improve it later. 

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