From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9208 invoked by alias); 27 Jan 2006 15:51:37 -0000 Received: (qmail 9198 invoked by uid 22791); 27 Jan 2006 15:51:36 -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, 27 Jan 2006 15:51:35 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F2Vsq-0007lw-WA; Fri, 27 Jan 2006 10:51:33 -0500 Date: Fri, 27 Jan 2006 16:01:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org, gdb@sources.redhat.com Subject: Re: MI -break-info command issues Message-ID: <20060127155132.GA8843@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org, gdb@sources.redhat.com References: <200601271115.22939.ghost@cs.msu.su> <20060127151220.GA978@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00298.txt.bz2 On Fri, Jan 27, 2006 at 06:47:47PM +0300, Vladimir Prus wrote: > > On Fri, Jan 27, 2006 at 05:59:56PM +0300, Vladimir Prus wrote: > >> If "minimal" protocol is explicitly not a goal of MI, or changing MI is > >> prohibited, just say so and I'll stop asking why there are unnecessary > >> fields. > > > > _Extending_ MI is fine; it was designed to be extensible. _Removing_ > > fields from MI is not fine, because you don't know if some other > > frontend relies on the data that you find superfluous. > > > > Folks have said this at least twice in this thread already. If you > > disagree, could you say why? > > Because with those fields, you get new issues: > > 1. They are not documented in sufficient detail. > 2. Looking at 'mi-read-memory.exp', those fields don't appear to be tested > -- it's only checked that the values of the fields are in hex. > 3. Everybody using MI should decide if those fields are useful for him, or > not. I don't buy it. If you don't know for sure what they do, and you don't need them, just ignore them - MI is designed to make unknown fields easy to ignore. > The problem with existing frontends can probably be solved by posting a > prominent message to mailing list whenever MI output is going to change. Or > using versioning. This has been discussed before plenty of times. We will make incompatible changes to MI from time to time; but IMO that doesn't justify making _unnecessary_ incompatible changes. Like Bob, I wouldn't have added the fields. But since they are present, I see no reason to remove them. -- Daniel Jacobowitz CodeSourcery From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9519 invoked by alias); 27 Jan 2006 15:51:38 -0000 Received: (qmail 9209 invoked by uid 22791); 27 Jan 2006 15:51: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, 27 Jan 2006 15:51:35 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F2Vsq-0007lw-WA; Fri, 27 Jan 2006 10:51:33 -0500 Date: Fri, 27 Jan 2006 16:11:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org, gdb@sources.redhat.com Subject: Re: MI -break-info command issues Message-ID: <20060127155132.GA8843@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org, gdb@sources.redhat.com References: <200601271115.22939.ghost@cs.msu.su> <20060127151220.GA978@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00299.txt.bz2 Message-ID: <20060127161100.PNbHKUC3UEnPPTs5Deh48DDTOEjlBZUdYDZajdMtkvA@z> On Fri, Jan 27, 2006 at 06:47:47PM +0300, Vladimir Prus wrote: > > On Fri, Jan 27, 2006 at 05:59:56PM +0300, Vladimir Prus wrote: > >> If "minimal" protocol is explicitly not a goal of MI, or changing MI is > >> prohibited, just say so and I'll stop asking why there are unnecessary > >> fields. > > > > _Extending_ MI is fine; it was designed to be extensible. _Removing_ > > fields from MI is not fine, because you don't know if some other > > frontend relies on the data that you find superfluous. > > > > Folks have said this at least twice in this thread already. If you > > disagree, could you say why? > > Because with those fields, you get new issues: > > 1. They are not documented in sufficient detail. > 2. Looking at 'mi-read-memory.exp', those fields don't appear to be tested > -- it's only checked that the values of the fields are in hex. > 3. Everybody using MI should decide if those fields are useful for him, or > not. I don't buy it. If you don't know for sure what they do, and you don't need them, just ignore them - MI is designed to make unknown fields easy to ignore. > The problem with existing frontends can probably be solved by posting a > prominent message to mailing list whenever MI output is going to change. Or > using versioning. This has been discussed before plenty of times. We will make incompatible changes to MI from time to time; but IMO that doesn't justify making _unnecessary_ incompatible changes. Like Bob, I wouldn't have added the fields. But since they are present, I see no reason to remove them. -- Daniel Jacobowitz CodeSourcery