From: Nick Roberts <nickrob@snap.net.nz>
To: "Bjarke Viksoe" <bviksoe@hotmail.com>
Cc: gdb@sourceware.org
Subject: MI error msgs and localization
Date: Sun, 12 Feb 2006 20:49:00 -0000 [thread overview]
Message-ID: <17391.40721.926885.140030@kahikatea.snap.net.nz> (raw)
In-Reply-To: <BAY111-F17900FCC72ED8D8FA0E121A0040@phx.gbl>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown, Size: 1895 bytes --]
> Hi, I've been using the MI interface for quite some time and noticed that
> preparation for localization has begun in GDB. Can I express some concern
> that compatibility with existing MI systems may suffer from this.
AFAIK, the only localisation proposed for MI output is for error messages.
> For instance, a cleanup must be done to make sure all errors are still
> reported through MI in English including the more exceptional ones
> (especially during startup). For instance, I am actively interpreting raw
> console-stream output for the following strings:
>
> No debugging symbols found
> Unable to attach to process
> No such process
> No symbol table is loaded
> No such file
> gdb: unrecognized option
> An internal GDB error was detected.
> Thread x has terminated.
> No executable file specified
> No executable specified, use
These messages appear to be part of the CLI output intended for the user and
not MI. It seems natural to translate them.
> For yet-unsupported commands in MI I resort to -interpreter-exec console
> xxx, but that leaves a problem where I have to at least handle messages
> such as
>
> ---Type <return>
>
>
to keep the non-interactive experience a joy.
You can do "-gdb-set height 0" to stop this.
Patches are welcome for any further MI commands that you would like to see
implemented.
> Please consider support for MI as an important feature in future versions of
> GDB as well. English MI error output should somehow be retained for Machine
> Interpreting (!!) perhaps with the additional inclusion of the localized
> display text.
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.
Nick http://www.inet.net.nz/~nickrob
next prev parent reply other threads:[~2006-02-12 20:49 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-12 14:54 Bjarke Viksoe
2006-02-12 20:49 ` Nick Roberts [this message]
2006-02-13 18:37 ` Bjarke Viksoe
2006-02-13 19:56 ` Eli Zaretskii
2006-02-13 20:01 ` Daniel Jacobowitz
2006-02-14 1:30 ` Nick Roberts
2006-02-14 17:40 ` Bjarke Viksoe
2006-02-14 19:42 ` Eli Zaretskii
2006-02-14 20:59 ` Nick Roberts
2006-02-14 21:05 ` Daniel Jacobowitz
2006-02-14 23:26 ` Nick Roberts
2006-02-14 23:32 ` Daniel Jacobowitz
2006-02-15 1:48 ` Nick Roberts
2006-02-15 3:05 ` Daniel Jacobowitz
2006-02-15 4:48 ` Nick Roberts
2006-02-15 13:37 ` Daniel Jacobowitz
2006-02-15 21:03 ` Nick Roberts
2006-02-15 21:17 ` Daniel Jacobowitz
2006-02-15 1:55 ` Bob Rossi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17391.40721.926885.140030@kahikatea.snap.net.nz \
--to=nickrob@snap.net.nz \
--cc=bviksoe@hotmail.com \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox