From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13558 invoked by alias); 13 Feb 2006 19:56:36 -0000 Received: (qmail 13549 invoked by uid 22791); 13 Feb 2006 19:56:35 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 13 Feb 2006 19:56:34 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-18-48.inter.net.il [80.230.18.48]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id DOG31167 (AUTH halo1); Mon, 13 Feb 2006 21:56:27 +0200 (IST) Date: Mon, 13 Feb 2006 19:56:00 -0000 Message-Id: From: Eli Zaretskii To: "Bjarke Viksoe" CC: gdb@sourceware.org In-reply-to: (bviksoe@hotmail.com) Subject: Re: MI error msgs and localization Reply-to: Eli Zaretskii References: 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/msg00124.txt.bz2 > From: "Bjarke Viksoe" > Bcc: > Date: Mon, 13 Feb 2006 19:37:10 +0100 > > 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. If you _never_ display _any_ MI message verbatim, you can always arrange for your front end to push LC_MESSAGES=C into the environment when it runs GDB. Will this satisfy you? I don't think GDB can in general trust that every front end does such a thorough job of translating every message, so simply leaving the MI messages untranslated is not a good idea at this time. Perhaps we could come up with a smarter solution, one that would allow to identify the messages in English _and_ display them in the local language. Nick suggested one idea; perhaps there are others. I'd encourage you and everyone else to suggest ideas, but I don't think a simplistic ``don't translate any MI messages'' approach is acceptable. > >Patches are welcome for any further MI commands that you would like to see > >implemented. > > > >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. The number of MI questions > are steadily increasing in this maillist. I believe that the MI interface > will be the dominant way of using GDB in the future since more people will > realise that there finally is a not-so-arcane way to interface with it and > thus integration into the various editor tools becomes wide-spread. So it's > sad to see the same basic functions with "N/A" in the documentation still. So what would you like us to do? We are just a bunch of volunteers maintaining GDB on our free time (well, at least most of us are). Without new blood coming on board, how would things ever change for the better? In any case, thanks for your comments.