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

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: [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: 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