Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Jim Ingham <jingham at apple dot com>]

Andrew,

On Tuesday, October 1, 2002, at 03:10  PM, Andrew Cagney wrote:

> > I am a little confused here.  One of the design points for the MI is 
> > the ability to add information to the commands without requiring a 
> > change in the clients (unless, of course, they wanted to use the new 
> > information).  That should mean that we have set up a situation where 
> > we can change the mi in substantial ways without having to demand 
> > that clients rewrite their code to use MI.  Shouldn't that mean that 
> > we can go a long way without having to make incompatible changes?  
> > And so, imposing the burden on ourselves of not jerking clients 
> > around all the time would not be such a big deal, and perhaps worth 
> > the inconvenience it would cause the MI developers?
> Yes, that's the theory.  There are always problems though:
>
> - for some commands, their output is simply bogus.  See gdb/672
> > > - var-update syntax is:
>   ^done,changelist={name="var3",in_scope="true",type_changed="false",
>      name="var2",in_scope="true",type_changed="false"}
> Notice how a single tuple contains several "name" fields :-(  JeffJ's 
> currently comming up with a patch that will preserve the current 
> behavior.
This was putatively bogus, but very easy to parse.  It didn't even 
annoy Rab, when he was first doing this...

> - some parts of the interface were technically flawed.
> The breakpoint event stuff that KeithS changed (but not in a backward 
> compatible way :-().  Not fixing this, further entrenches a flawed 
> model :-(  The only error in that change was not preserving the old 
> output when mi1 :-(
BTW, I haven't seen the actual change Keith is planning here.  Will he 
be sticking the command sequence cookie in the async result?  His 
example didn't show the cookies.

Seems to me that reporting command results as an async notification 
means that we are breaking the tie between the command and its results. 
 It was very nice that I could issue a bunch of commands at some point 
in the GUI code, then at another place gather up the results, and match 
them to the initial commands by using the sequence ID's.

In the new way of doing things, we have to parse more carefully, and 
assume that the =breakpoint-create that we just got was the one that 
came from the -break-insert in the output just above it.  It makes the 
client stream parser have to be more stateful that in the mi0 version, 
which doesn't seem to me all that good an idea.  If the async event has 
the cookie in it, this will be a little better, though it still means I 
have a two-step accumulation phase for each command (wait for the async 
result with the right cookie, then the done with the right cookie...)



> Fixing either of these involves significant change to MI's output, but 
> it, I think, is for the better.
>
> > As a client of the MI, this means that in a year or so I have to 
> > expect to rewrite code that works just fine, because you have deleted 
> > the support for it from gdb; or carry the burden of maintaining mi1 
> > as patches to the gdb sources.  And longer term, I can expect to do 
> > this again next year, unless things "stabilize" before then, which 
> > they may or may not do.  This doesn't sound appetizing to me.
> > The MI is a public interface to gdb - and the only really useful one 
> > we offer to external clients who are not Human beings right now.  It 
> > has been around in gdb, and we have been using it contentedly, for a 
> > couple of years now.  A retroactively stated policy of instability in 
> > this interface (including the vanishing of useful variants at odd 
> > intervals) seems very unfair to those who have been using it right 
> > along, as well as being one which can only slow its uptake in >> general.
> What we're seeing here is the fallout that results from a number of 
> players creating localized GDBs.  GDB developers have started looking 
> at the underlying problems that Apple and others encountered, and are 
> trying to fix them.  Regretably, per above, this is going to need some 
> short term change.
Just because K&R C kind of sucked, however, doesn't mean that most 
compiler vendors got to drop support for it...

Alternatively, I don't know why the planning model for the changes 
seems to be - we will change a bit, declare a version, change a bit 
more, declare another incompatible version and drop the first version, 
rinse and repeat...  In the face of the fact that you most 
unfortunately have users already, I think you should decide to work out 
the changes for whatever time it takes for you to come up with a 
version you are happy with, then stick with that for a product 
lifecycle-type-timescale, not a patch release timescale.  That way 
people who plan to use this stuff can actually plan their use of it...

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