Re: [5.1/mi] Enable MI interface

Re: [5.1/mi] Enable MI interface

[Jim Ingham]

Eli,

On Monday, March 5, 2001, at 12:42 PM, gdb-digest-
help@sources.redhat.com wrote:

>
> Bother.  Can you, or someone else, please describe in a few words what
> does "enable the MI interface" mean, in practical terms, for a port
> such as the DJGPP port?

Should mean not too much.  If the ui_out stuff works on your host 
platform, then you should pretty much get the MI for free.  It is 
another command set for gdb, and a particular ui_out that formats the 
output to these commands in a more deterministicly parseable way than 
raw gdb console output.

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer

Re: [5.1/mi] Enable MI interface

[Eli Zaretskii]

On Mon, 5 Mar 2001, Jim Ingham wrote:

> Should mean not too much.  If the ui_out stuff works on your host 
> platform, then you should pretty much get the MI for free.  It is 
> another command set for gdb, and a particular ui_out that formats the 
> output to these commands in a more deterministicly parseable way than 
> raw gdb console output.

IIRC MI is an interface between GDB and what/whoever is using GDB,
right?  If so, how, if at all, does it come into play in the normal
DJGPP usage where the user types command into GDB's CLI interface?
Does something convert these commands into MI before passing them to
GDB?

Or does the addition of MI simply mean that there's another command
language available to the user, which they can use as they see fit?
That is, unless the users actually type some MI commands, the MI code
will not spring into action at all?

Or am I missing the point entirely?

Re: [5.1/mi] Enable MI interface

[Andrew Cagney]

Eli Zaretskii wrote:
> 
> On Mon, 5 Mar 2001, Jim Ingham wrote:
> 
> > Should mean not too much.  If the ui_out stuff works on your host
> > platform, then you should pretty much get the MI for free.  It is
> > another command set for gdb, and a particular ui_out that formats the
> > output to these commands in a more deterministicly parseable way than
> > raw gdb console output.
> 
> IIRC MI is an interface between GDB and what/whoever is using GDB,
> right?  If so, how, if at all, does it come into play in the normal
> DJGPP usage where the user types command into GDB's CLI interface?
> Does something convert these commands into MI before passing them to
> GDB?

Yes.  One day, GDB will look like:

	CLI ->	libgdb  <- MI
	       core-gdb

at present it looks more like:

	corCe-gLdbI <- liMbgIb
	core-gdb+CLI <- libgdb+MI

However, it is still possible to build with/without out the MI.

> Or does the addition of MI simply mean that there's another command
> language available to the user, which they can use as they see fit?
> That is, unless the users actually type some MI commands, the MI code
> will not spring into action at all?

Unless the user enters:

	DOS>  gdb -i mi

MI will do nothing.

	Andrew

Re: [5.1/mi] SYNTAX CHANGE? - List ``[ ]'' vs ``{ }''

[Jim Ingham]

Andrew & Fernando,

Okay, here are Rab's comments about the proposed change to the MI 
interface (Rab Hagy (rhagy@apple.com) is the fellow responsible for the 
Project Builder side of debugging for Apple's IDE.):

> 1) The delimiters for a list should be different from those for a tuple.
> The output of MI is, basically, a property list. Property lists have 
> been around for a long time and they have different delimiters for 
> tuples and lists.
>
> The current situation, in which the same delimiters are used for both 
> lists and tuples, results in stream of MI output which is difficult to 
> inspect "by eye". The parser is a bit more complex than it needs to be 
> because it has to handle the overloading of '{'. As a result, the data 
> structures used to represent a VALUE is not a clean as they could be 
> either.
>
> And, I mean this in the nicest way possible, this oversight sticks out 
> like a sore thumb... when I wrote the special-cases in the parser to 
> deal with this obvious error in the grammar, I wondered if MI was 
> really up to snuff.
>
> 2) '[' and ']' are the correct delimiters
> Adding these characters to the grammar does not complicate the parsing 
> of MI output. These are the obvious characters to be used as the 
> delimiters for a list.
>
> 3) ``[bp="1",bp="2",bp="4"]'' is incorrect
> I don't think this example is allowed by the proposed grammar. It 
> should be one of:
> 	bps=["1", "2", "4"]
> 	[{bp="1"}, {bp="2"}, {bp="4"}]
>
> -rab

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer

Re: [5.1/mi] SYNTAX CHANGE? - List ``[ ]'' vs ``{ }''

[Fernando Nasser]

I rest my case :-)

Jim Ingham wrote:
> 
> Andrew & Fernando,
> 
> Okay, here are Rab's comments about the proposed change to the MI
> interface (Rab Hagy (rhagy@apple.com) is the fellow responsible for the
> Project Builder side of debugging for Apple's IDE.):
> 
> > 1) The delimiters for a list should be different from those for a tuple.
> > The output of MI is, basically, a property list. Property lists have
> > been around for a long time and they have different delimiters for
> > tuples and lists.
> >
> > The current situation, in which the same delimiters are used for both
> > lists and tuples, results in stream of MI output which is difficult to
> > inspect "by eye". The parser is a bit more complex than it needs to be
> > because it has to handle the overloading of '{'. As a result, the data
> > structures used to represent a VALUE is not a clean as they could be
> > either.
> >
> > And, I mean this in the nicest way possible, this oversight sticks out
> > like a sore thumb... when I wrote the special-cases in the parser to
> > deal with this obvious error in the grammar, I wondered if MI was
> > really up to snuff.
> >
> > 2) '[' and ']' are the correct delimiters
> > Adding these characters to the grammar does not complicate the parsing
> > of MI output. These are the obvious characters to be used as the
> > delimiters for a list.
> >
> > 3) ``[bp="1",bp="2",bp="4"]'' is incorrect
> > I don't think this example is allowed by the proposed grammar. It
> > should be one of:
> >       bps=["1", "2", "4"]
> >       [{bp="1"}, {bp="2"}, {bp="4"}]
> >
> > -rab
> 
> Jim
> --
> Jim Ingham                                   jingham@apple.com
> Developer Tools - gdb
> Apple Computer

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: gdb Digest 5 Mar 2001 20:42:12 -0000 Issue 473

[Jim Ingham]

Andrew,

Both Project Builder and Insight offer a traditional GDB console as well 
as the GUI interface to gdb.  In the case of Insight, the thought was 
that once the GUI provided ALL the access that you could need to gdb's 
functionality it would go away.  In the case of PB, we have pretty 
strong feedback from our users that they REALLY like having the console 
there...  So we will need to provide some way to run console commands, 
WHILE using the MI as the communications channel between gdb & PB.  And 
the use of query is at present a problem which we still need to solve.

So while I agree that the design of the MI itself, and of the libgdb 
interface by extension - should avoid this kind of callback, I at least 
need to think some more about how to support the CLI over MI mode for 
the near future.  Tcl had the notion of service modes in its 
interpreter, so that you could modally re-enter the event loop looking 
for a particular bit of information, but not handling other types.  This 
was needed, for instance, to do things like wait for Window creation in 
Tk before you went on to do something with the window...  Maybe we could 
use this sort of notion to post & wait on the input channel without 
losing the local execution context?

Jim

On Monday, March 5, 2001, at 12:42 PM, gdb-digest-
help@sources.redhat.com wrote:

>
> From conversations, I believe that the current thinking is that MI
> operations should be largely self contained - they should not involve
> things like call-backs.
>
> Comments?
>
> 	Andrew

--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer

Re: [5.1/mi] SYNTAX CHANGE? - List ``[ ]'' vs ``{ }''

[Jim Ingham]

Andrew,

We do use the MI for communication between Project Builder - Apple's IDE 
for Mac OS X - and gdb.  I sent this discussion off to the fellow who 
does actually USES the stuff we generate to see what he thinks.  I will 
try to get back on this as soon as may be.

Jim

> I'm very very open to feedback.  Given that MI currently involves a
> custom GDB, I suspect that no one is using it in a production
> environment (Apple?).
>

--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer

[5.1/mi] SYNTAX CHANGE? - List ``[ ]'' vs ``{ }''

[Andrew Cagney]

Hello,

The MI documentation currently contains:

GDB/MI Draft Changes to Output Syntax
=====================================

   One problem identified in the existing GDB/MI output syntax was the
difficulty in differentiating between a tuple such as:

     {number="1",type="breakpoint",disp="keep",enabled="y"}

   where each value has a unique label, and a list such as:

     {"1","2","4"}
     {bp="1",bp="2",bp="4"}

   where values are un-labeled or the label is duplicated.

[....]

`RESULT ==>'
     STRING "=" VALUE

`VALUE ==>'
     C-STRING `|' TUPPLE `|' LIST

`TUPPLE ==>'
     "{}" `|' "{" RESULT { "," RESULT } "}"

`LIST ==>'
     "`[]'" `|' "`['" VALUE { "," VALUE } "`]'"

--

Which would change the above examples to:

     ["1","2","4"]
     [bp="1",bp="2",bp="4"]

This should look familar if you've used erlang or maranda(?).

I'd like to propose that this change be adopted before MI is enabled
(before 5.1 is released).  The code change is trivial.

My concern is with people that might currently be using MI.  While the
opening section reads:

     Note that GDB/MI is still under construction, so some of the
  features described below are incomplete and subject to change.

I'm very very open to feedback.  Given that MI currently involves a
custom GDB, I suspect that no one is using it in a production
environment (Apple?).

--

Should my proposal to ``correctly fix'' the problem fail, I'll fix the
problem by deleting that section of the MI spec :-)

I might also add a note warning implementors of the ambigious syntax :-)

enjoy,
	Andrew

Re: [5.1/mi] SYNTAX CHANGE? - List ``[ ]'' vs ``{ }''

[Fernando Nasser]

Andrew,

I strongly object to the use of "[]".  This will add another special
character and make things more difficult.

The output like {"1","2","4"} can easily be considered as a list value
by the parser.  The parser will need to have some description of the
expected result, even if in a lose way so it should still be able to
identify that this is a list value and not a list of values.

The {bp="1",bp="2",bp="4"} result should not be generated.  As we
currently have to share the output producing code with the CLI, we end
up generating things like this.  But I guess we should fix the source of
such anachronisms instead of changing the output format because of it.

It may be better to leave the output as is for 5.1 and see what the
parser implementers say.  If they complain, we can discuss the best
alternative and patch both the branch and the trunk.  As you said, it is
a simple change to the mi-out code.

Fernando



Andrew Cagney wrote:
> 
> Hello,
> 
> The MI documentation currently contains:
> 
> GDB/MI Draft Changes to Output Syntax
> =====================================
> 
>    One problem identified in the existing GDB/MI output syntax was the
> difficulty in differentiating between a tuple such as:
> 
>      {number="1",type="breakpoint",disp="keep",enabled="y"}
> 
>    where each value has a unique label, and a list such as:
> 
>      {"1","2","4"}
>      {bp="1",bp="2",bp="4"}
> 
>    where values are un-labeled or the label is duplicated.
> 
> [....]
> 
> `RESULT ==>'
>      STRING "=" VALUE
> 
> `VALUE ==>'
>      C-STRING `|' TUPPLE `|' LIST
> 
> `TUPPLE ==>'
>      "{}" `|' "{" RESULT { "," RESULT } "}"
> 
> `LIST ==>'
>      "`[]'" `|' "`['" VALUE { "," VALUE } "`]'"
> 
> --
> 
> Which would change the above examples to:
> 
>      ["1","2","4"]
>      [bp="1",bp="2",bp="4"]
> 
> This should look familar if you've used erlang or maranda(?).
> 
> I'd like to propose that this change be adopted before MI is enabled
> (before 5.1 is released).  The code change is trivial.
> 
> My concern is with people that might currently be using MI.  While the
> opening section reads:
> 
>      Note that GDB/MI is still under construction, so some of the
>   features described below are incomplete and subject to change.
> 
> I'm very very open to feedback.  Given that MI currently involves a
> custom GDB, I suspect that no one is using it in a production
> environment (Apple?).
> 
> --
> 
> Should my proposal to ``correctly fix'' the problem fail, I'll fix the
> problem by deleting that section of the MI spec :-)
> 
> I might also add a note warning implementors of the ambigious syntax :-)
> 
> enjoy,
>         Andrew

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [5.1/mi] SYNTAX CHANGE? - List ``[ ]'' vs ``{ }''

[Andrew Cagney]

Fernando Nasser wrote:
> 
> Andrew,
> 
> I strongly object to the use of "[]".  This will add another special
> character and make things more difficult.

This is interesting :-)

From memory, the proposal came about because a person implementing a
parser found that they needed contextual information (expect a list of
breakpoints) when translating the MI output into an internal structure. 
The intention of the syntax change (differentiate between lists and
tupples) was to make things easier - the basic structure could be
reconstructed without the need for that context.

An existing parser would just tread ``[ ]'' like ``{ }''.  I don't see a
need for any other special characters.

> The output like {"1","2","4"} can easily be considered as a list value
> by the parser.  The parser will need to have some description of the
> expected result, even if in a lose way so it should still be able to
> identify that this is a list value and not a list of values.

My memory of the reasoning behind the change was to remove the need for
the parser to have this knowledge.

> The {bp="1",bp="2",bp="4"} result should not be generated.  As we
> currently have to share the output producing code with the CLI, we end
> up generating things like this.  But I guess we should fix the source of
> such anachronisms instead of changing the output format because of it.

Do you think that the syntax should be tightened so that the above isn't
allowed?

> It may be better to leave the output as is for 5.1 and see what the
> parser implementers say.  If they complain, we can discuss the best
> alternative and patch both the branch and the trunk.  As you said, it is
> a simple change to the mi-out code.

I'd really like this resolved before MI is permenantly enabled.  Once it
is enabled, things like the syntax will become impossible to change.

In the end I guess the question is, is the world be made up of just
lists and atoms or lists, tupples and atoms.  The answer probably
depends on which list like language you were taught :-)

	enjoy,
		Andrew