From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18843 invoked by alias); 24 Mar 2006 02:40:38 -0000 Received: (qmail 18831 invoked by uid 22791); 24 Mar 2006 02:40:37 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 24 Mar 2006 02:40:36 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FMcE6-0000l4-3i; Thu, 23 Mar 2006 21:40:34 -0500 Date: Fri, 24 Mar 2006 04:25:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: gdb-patches@sources.redhat.com Subject: Re: MI: type prefixes for values Message-ID: <20060324024034.GA2853@nevyn.them.org> Mail-Followup-To: Nick Roberts , gdb-patches@sources.redhat.com References: <17427.54333.236860.258115@kahikatea.snap.net.nz> <20060317193243.GB19068@nevyn.them.org> <17435.24954.801098.804532@kahikatea.snap.net.nz> <20060318013113.GA28374@nevyn.them.org> <17435.29362.640036.97752@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17435.29362.640036.97752@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00261.txt.bz2 On Sat, Mar 18, 2006 at 03:38:42PM +1300, Nick Roberts wrote: > > I don't think it makes a difference - it could confuse consumers of MI2 > > anyway - that's all I'm worried about. > > I think it means its generally less likely to make a difference. In Emacs, I > just take the value of the field amd insert it in the appropriate window at > the appropriate place. Thats why the type currently gets duplicated in the > locals window. Removing the type prefix just removes that duplication, I > don't have to make any changes to the lisp code in Emacs. Adding a field, > however, might break my parser if I'm not expecting it. > > However, perhaps you're thinking specifically of Eclipse. No, it was just the only one I had handy to test. I'm unsympathetic if adding a new field breaks your parser; MI is deliberately arranged so that consumers can ignore new fields that they don't understand. Anyway, I think I'm OK with this change, but I want to track down one more thing first. > > > Since there are likely to be many more changes to MI, I suggest that when > > > we start making changes for mi3 only, the default remains at mi2. This > > > will allow a period of development for mi3 during which changes can be > > > made more freely. It could then be made the default level after it has > > > stabilised. > > > > Yes, this is already how we document -i=mi to work. It's the last > > finalized version of the protocol. > > But there have been many changes to mi2, notably adding the fullname field > in several places, since it became the default level. I'm just suggesting > that we don't have mi4, mi5, mi6 etc because it gets too complicated. Adding the fullname field was considered (as I wrote above) as a backwards-compatible change. I don't intend on allowing incompatible changes to sneak into MI2 (well, hopefully...). MI3 will be ready when it's ready :-) -- Daniel Jacobowitz CodeSourcery