From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19349 invoked by alias); 14 Feb 2006 17:40:29 -0000 Received: (qmail 19292 invoked by uid 22791); 14 Feb 2006 17:40:28 -0000 X-Spam-Check-By: sourceware.org Received: from bay111-f5.bay111.hotmail.com (HELO hotmail.com) (64.4.17.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 14 Feb 2006 17:40:27 +0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 14 Feb 2006 09:40:24 -0800 Message-ID: Received: from 64.4.17.200 by by111fd.bay111.hotmail.msn.com with HTTP; Tue, 14 Feb 2006 17:40:24 GMT X-Sender: bviksoe@hotmail.com In-Reply-To: <17393.12925.270558.512941@kahikatea.snap.net.nz> From: "Bjarke Viksoe" To: gdb@sourceware.org Bcc: Subject: RE: MI error msgs and localization Date: Tue, 14 Feb 2006 17:40:00 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed 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/msg00138.txt.bz2 > > 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 would guess that most of time GDB is used from the command line where >there >is simply no front-end, dumb or otherwise. But we are talking about MI mode now and how that should be shaped? > >The error message "Unrecognized option" is not intended to provide >information >about the GDB version. If you want to use it for that purpose, thats your >choice, but you can hardly expect the GDB community to "support" that >feature. I don't get your point. A front-end can decide how it wants to interpret an error message as it pleases. I do it because this is the error I get when -i=mi is used on a version that does not support it at all. It makes sense in that context since I'm building the command line. I don't particular like to hard-code these strings. The list of messages I gave previously are all marked as console-stream-output. What I am saying is that localizing such error messages will hurt MI dependant tools since the messages are highly useful for the front-end. I'm not sure what purpose console-output really has in a Machine Interface as it tends to make sense only to humans - but I guess some systems are making use of them. What I'd really like is to see them also wrapped in result-records (sample; ignore syntax): ^failed,type="init-option-unrecognized",msg="Unrecognized option" Does that make any sense? My initial warning was that without "cleaning" the code and making sure *all* spurious messages are classified and wrapped in proper MI records, localizing may break some tools or see important features disappear because they were using the raw console output in lack of proper MI structure wrapping. regards, bjarke viksoe 80386.NET - http://www.viksoe.dk/code/asmil.htm