From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17430 invoked by alias); 13 Feb 2006 20:01:54 -0000 Received: (qmail 17416 invoked by uid 22791); 13 Feb 2006 20:01:53 -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; Mon, 13 Feb 2006 20:01:48 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F8jtI-0000OI-KT; Mon, 13 Feb 2006 15:01:44 -0500 Date: Mon, 13 Feb 2006 20:01:00 -0000 From: Daniel Jacobowitz To: Bjarke Viksoe Cc: gdb@sourceware.org Subject: Re: MI error msgs and localization Message-ID: <20060213200144.GA1398@nevyn.them.org> Mail-Followup-To: Bjarke Viksoe , gdb@sourceware.org References: <17391.40721.926885.140030@kahikatea.snap.net.nz> 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-02/txt/msg00125.txt.bz2 Just to add to what others have said... On Mon, Feb 13, 2006 at 07:37:10PM +0100, Bjarke Viksoe wrote: > >These messages appear to be part of the CLI output intended for the user > >and > >not MI. It seems natural to translate them. > > I really don't agree at all. Very few output in MI mode is/should be > intended for users only. You have got get past the stage where you think of > the front-end as a "dumb automated shell" and into thinking "integrated > environment with user friendly error messages". Preferrably these messages > should have been streamed out as a MI result-records. > > I translate "No symbol table loaded..." into asking the user to switch to > debug-mode in my tool. "Unrecognized option" pop ups that the GDB version > is too old, reinstall needed. "Thread x has terminated" refreshed the > thread list etc etc etc. No user behind a front-end will understand "No > such process." or "No executable file specified" by itself when the cause > of this is some magic done by the controlling front-end. This is a clever thing to do. However, like most clever things, expect to have to do some legwork to keep it working. The error messages are deliberately not part of the documented interface. The documented interface we take pains to keep compatible; the undocumented bits are subject to change at any time. If there are particular messages that are valuable to front ends, then maybe they should get their own documentation and MI representation; don't count on the magic strings in ^error to remain unchanged. > >As stated in the manual, MI is still evolving. The best way to make it do > >the things you want is to participate in its development. > > > > Unfortunately I see this reply too often here. That's your invitation to help. There's plenty of ways to help without coding on GDB - the documentation, or simply participating when developers ask questions about how people are really using MI. But without more people interested in doing MI development, it WILL NOT improve. Many of us have got enough GDB issues we want to fix without volunteering to improve MI also; we need people who care about it. -- Daniel Jacobowitz CodeSourcery