RE: MI error msgs and localization

Bjarke Viksoe
2006-02-13T18:37:15Z

> > 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.

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.

>
>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.

I would love to participate but I'm primarily a Windows developer and tries
to focus on UI in my spare time and ancient C programs/style just scares me.
I really appreciate the work that has been done, just hope that GDB team
will keep focus on making MI integration a primarily target so the tool is
not just accessible for geeky developers that fathoms 2-letter shortcut
commands, but also to mainstream developers using high-level development
tools.

Sorry, just a litte frustrated that MI doesn't seem to move forward. I do
really appreciate the work that has been done on GDB already.

regards, bjarke viksoe
GMail Drive - http://www.viksoe.dk/gmail/