From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5436 invoked by alias); 1 Oct 2002 17:34:00 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 5428 invoked from network); 1 Oct 2002 17:33:57 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by sources.redhat.com with SMTP; 1 Oct 2002 17:33:57 -0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g91HXlE14291 for ; Tue, 1 Oct 2002 10:33:47 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 1 Oct 2002 10:33:39 -0700 Received: from inghji.apple.com (inghji.apple.com [17.201.22.240]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id g91HXkb10191; Tue, 1 Oct 2002 10:33:46 -0700 (PDT) Date: Tue, 01 Oct 2002 10:34:00 -0000 Subject: Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: gdb-patches@sources.redhat.com To: Andrew Cagney From: Jim Ingham In-Reply-To: <3D99CD6A.6050405@redhat.com> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00008.txt.bz2 Andrew, On Tuesday, October 1, 2002, at 09:29 AM, Andrew Cagney wrote: >> Hi, all... >> The changes from mi0 to mi1 were pretty trivial. So clients (in my >> case Project Builder) can fairly easily accommodate the removal of >> the mi0 interpreter. I am not suggesting that we reinstate that. >> However, the mi2 is shaping up to be a pretty big change (among other >> things, command results are differently reported in toto, as well as >> some command results changing format.) Converting PB from mi1 to mi2 >> is going to be a lot of work. And because of its nature, there is >> no a priori way to tell what all the clients are - and not all the >> clients will closely read the gdb-patches mailing list... > > mi2 is bug fixes on mi1. However, at the same time it is gaining some > of the missing functionality. Its just that more bugs and more > missing functionality are being worked on. To put it simply, about > time! Well, mi1 was a moving target, so "bug fixes on mi1" is a little hard to quantify. But the change that Keith proposed - which started off the bump to mi2 discussion - was to move command result reporting for things like -break-insert from the ^done to the gdb event. This has a big effect on how a client uses the mi. > > cf the patch to pr gdb/672 where the output was straight bogus (it > contained the equivalent of {name="foo", name="bar", name="baz"}. > JeffJ has been asked to preserve the old (broken) behavior. I should > note it was very tempting to not make this request since the old > behavior was broken and should have been bug-reported and fixed long > long ago. > >> Because of this, I am a little nervous at the easy way we are talking >> about deleting older versions of the mi. I think it is our >> responsibility to careful, and only release versions of the mi that >> we want to support, not the clients of the mi's responsibility to >> change their code every time we decide we are tired of supporting the >> test cases from one of the other versions we have previously >> promulgated... The mi loses much of its appeal if it means you are >> going to have to occasionally rework parts of your client that >> already work just fine, or suffer permanent fork-hood for your gdb. > > I was ment to delete mi0 something like a year ago. I'm running a > little late on that one :-) > >> I agree with Daniel that we should hold off on declaring a real mi2 >> till we have something we are willing to support long term. And for >> the mi to be useful, I think we need to stick to only putting out >> named versions that we are willing to support. > > Part of the nature of GDB is that it is constantly evolving. MI is > going to be (like it or not) part of that evolution. Each new GDB > release will see enhancements and bug fixes and MI uses will need to > be accomodating to that. This is only partly true. We are actually pretty conservative about changing command output. We haven't broken annotate for a while, IIRC. The mi is more like the command output, and I think we should have the same level of conservatism about this. > > In return for this accomodation GDB are trying to preserve a given MI > interface for at least two release cycles. Part of is the very strong > emphasis on testcases and documentation. If you feel that things are > lacking in this area then, perhaphs something to contribute to, is the > documentation and testing infrastructure for MI (did the apple > droppings contain any new tests?). No, we haven't worked on this. It is something we know we need to do, but for now we have been using Project Builder as our mi tester (it exercises a fair bit of the functionality, and catches most of the things we break). > > Over time, the MI interface should also stablize. > I agree. I am just arguing that we should mark stable points and then think hard before we delete them. Otherwise while it is waiting to stabilize, folks will be reasonably a little chary about using it... Jim -- Jim Ingham jingham@apple.com Developer Tools - gdb Apple Computer