From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21650 invoked by alias); 11 Jan 2008 23:38:28 -0000 Received: (qmail 21642 invoked by uid 22791); 11 Jan 2008 23:38:27 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 11 Jan 2008 23:38:00 +0000 Received: from kahikatea.snap.net.nz (157.60.255.123.dynamic.snap.net.nz [123.255.60.157]) by viper.snap.net.nz (Postfix) with ESMTP id 5ECBA3D9F60; Sat, 12 Jan 2008 12:37:56 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 875FB8FC6D; Sat, 12 Jan 2008 12:37:50 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18311.64973.546980.107837@kahikatea.snap.net.nz> Date: Fri, 11 Jan 2008 23:38:00 -0000 To: Daniel Jacobowitz Cc: Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: [BUG:MI] -break-list doesn't list multiple breakpoints In-Reply-To: <20080111225452.GA26085@caradoc.them.org> References: <18310.38708.144719.374963@kahikatea.snap.net.nz> <18311.57557.312425.107700@kahikatea.snap.net.nz> <20080111225452.GA26085@caradoc.them.org> X-Mailer: VM 7.19 under Emacs 23.0.50.27 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00299.txt.bz2 > > I'm not sure of the logic of committing an incomplete patch, but in any > > case I think this needs to be fixed before the next release. > > I disagree. If someone needs this functionality in MI, they are > invited to contribute it. Unless I'm completely mistaken, what > happened previously in MI was even worse. Multiple breakpoints are new, so nothing happened in MI previously did it? The format of CLI output for pending breakpoints has currently changed and in that context Vladimir said: ...And probably the only way to change the situation is to decide that MI is the future, and actively discourage use of CLI for anything, to the degree of immediately refusing any request mentioning CLI in relation to any frontend. Refusing requests mentioning CLI and not providing functionality in MI seems to leave the frontend developer between a rock and a hard place. -- Nick http://www.inet.net.nz/~nickrob