From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2006 invoked by alias); 26 Jan 2006 07:01:57 -0000 Received: (qmail 1968 invoked by uid 22791); 26 Jan 2006 07:01:56 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 26 Jan 2006 07:01:54 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1F218e-0006mu-HU for gdb@sources.redhat.com; Thu, 26 Jan 2006 08:01:48 +0100 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Jan 2006 08:01:48 +0100 Received: from ghost by zigzag.lvk.cs.msu.su with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Jan 2006 08:01:48 +0100 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: MI -break-info command issues Date: Thu, 26 Jan 2006 12:09:00 -0000 Message-ID: References: <20060124144449.GE28357@brasko.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.8.2 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/msg00259.txt.bz2 Eli Zaretskii wrote: >> The extra information doesn't pertain to breakpoint itself, it's gdb >> opinion on formatting and is hardly usefull for machine interface. IMO, >> of course. > > This output is produced by the UI-independent output functions. So > judging its usefulness from the point of view of a GUI is taking a too > narrow view. The advantage of ui_out routines is that .... I'm actually talking about MI *protocol*. I think that usefulness of that should be judged from the point of view of its intended clients -- that are frontends, which nowdays means GUI. If MI is protocol specifically designed for some task, then it should not include some fields just because TUI needs those fields. > whoever writes > the code defines the layout once, and then each UI gleans whatever it > needs from the results. The programmer who wrote the code does not > need to bother which UI needs what information. Yes, that means some > of the info will be redundant or useless for certain types of UI, but > that's by design, and I think the advantages of a single interface far > outweigh the small annoyances of having to read and discard unused > parts of the output. Why can't MI layer weed out unnecessary information? - Volodya