MI error msgs and localization

MI error msgs and localization

[Bjarke Viksoe]

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.

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Â…

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.

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.

Regards bjarke
BVRDE - http://bvrde.sourceforge.net/

MI error msgs and localization

[Nick Roberts]

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

RE: MI error msgs and localization

[Bjarke Viksoe]

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

Re: MI error msgs and localization

[Eli Zaretskii]

> From: "Bjarke Viksoe" <bviksoe@hotmail.com>
> 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.

Re: MI error msgs and localization

[Daniel Jacobowitz]

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

RE: MI error msgs and localization

[Nick Roberts]

 > >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 would guess that most of time GDB is used from the command line where there
is simply no front-end, dumb or otherwise.

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

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.

Nick

RE: MI error msgs and localization

[Bjarke Viksoe]

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

Re: MI error msgs and localization

[Eli Zaretskii]

> From: "Bjarke Viksoe" <bviksoe@hotmail.com>
> Bcc:
> Date: Tue, 14 Feb 2006 18:40:24 +0100
> 
> 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?

I think this makes a lot of sense.  But Someone(tm) will have to go
over all the messages and add the `type' thingy to each one.

RE: MI error msgs and localization

[Nick Roberts]

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

Perhaps we are not communicating but you seemed to be suggesting that the
front-end should do any localisation.  I was just saying that GDB has to
do it because it is often run from the command line.

Also you didn't respond to Eli's suggestion to arrange for your front end to
push LC_MESSAGES=C into the environment when it runs GDB.

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

Quite apart from localisation, at some stage it might also make sense to
someone, to change the message to "Unsupported option".  I don't think you can
rely on these messages to be cast in stone.

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

We've already got ^error as a result field so it doesn't make any sense to me,
 and if "Unrecognized option" comes from the console stream then I think that
 can still change.  The problem seems to be that of handling CLI error output
 in MI.  I see that the standard GNU error function provides for an error
 number which is less likely to change:

 -- Function: void error (int STATUS, int ERRNUM, const char *FORMAT,
          ...)

I wonder if GDB's error function could have one for MI e.g

&"Unrecognized option\n"
^error,msg="Unrecognized option",code="35"

or even

&"Unrecognized option\n"
^error,code="35"

 instead of just:

&"Unrecognized option\n"
^error,msg="Unrecognized option"

Nick


Nick

Re: MI error msgs and localization

[Daniel Jacobowitz]

On Wed, Feb 15, 2006 at 09:58:23AM +1300, Nick Roberts wrote:
>  > 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?
> 
> We've already got ^error as a result field so it doesn't make any sense to me,
>  and if "Unrecognized option" comes from the console stream then I think that
>  can still change.  The problem seems to be that of handling CLI error output
>  in MI.  I see that the standard GNU error function provides for an error
>  number which is less likely to change:
> 
>  -- Function: void error (int STATUS, int ERRNUM, const char *FORMAT,
>           ...)
> 
> I wonder if GDB's error function could have one for MI e.g
> 
> &"Unrecognized option\n"
> ^error,msg="Unrecognized option",code="35"
> 
> or even
> 
> &"Unrecognized option\n"
> ^error,code="35"
> 
>  instead of just:
> 
> &"Unrecognized option\n"
> ^error,msg="Unrecognized option"

GCC developers spent a lot of time talking about this.  I think the
trick to doing this right is actually to do it the way Bjarke
suggested: msg= as a free-form, explanatory text, and type= (or code=,
or something else) as a documented identifier.  But using numbers for
the identifiers is not necessarily a good idea, because keeping track
of them is error-prone.  I'd suggest that
type="init-option-unrecognized" was a lot more memorable than
"code=35".

We have to be careful what error messages get identifiers, though.
Please don't anybody go through the source indiscriminately adding
them.  Many errors will still be subject to change even if you tack
permanent identifiers on them.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI error msgs and localization

[Nick Roberts]

 > GCC developers spent a lot of time talking about this.  I think the
 > trick to doing this right is actually to do it the way Bjarke
 > suggested: msg= as a free-form, explanatory text, and type= (or code=,
 > or something else) as a documented identifier.  But using numbers for
 > the identifiers is not necessarily a good idea, because keeping track
 > of them is error-prone.  I'd suggest that
 > type="init-option-unrecognized" was a lot more memorable than
 > "code=35".

You wouldn't have to remember them, thay're for use by the front-end, not the
user.  In any case the console log stream gets printed alongside, which should
be self-explanatory.  How would you arrange for the type message to be
printed?  Would you give error a second string argument?  It has over 1200
calls.

 > We have to be careful what error messages get identifiers, though.
 > Please don't anybody go through the source indiscriminately adding
 > them.  Many errors will still be subject to change even if you tack
 > permanent identifiers on them.

All calls to error could be given a dummy argument (0, if numbers are used),
and replaced with a real one only in thoses cases when a need arises.

Nick

Re: MI error msgs and localization

[Daniel Jacobowitz]

On Wed, Feb 15, 2006 at 12:25:16PM +1300, Nick Roberts wrote:
>  > GCC developers spent a lot of time talking about this.  I think the
>  > trick to doing this right is actually to do it the way Bjarke
>  > suggested: msg= as a free-form, explanatory text, and type= (or code=,
>  > or something else) as a documented identifier.  But using numbers for
>  > the identifiers is not necessarily a good idea, because keeping track
>  > of them is error-prone.  I'd suggest that
>  > type="init-option-unrecognized" was a lot more memorable than
>  > "code=35".
> 
> You wouldn't have to remember them, thay're for use by the front-end, not the
> user.  In any case the console log stream gets printed alongside, which should
> be self-explanatory.  How would you arrange for the type message to be
> printed?  Would you give error a second string argument?  It has over 1200
> calls.
> 
>  > We have to be careful what error messages get identifiers, though.
>  > Please don't anybody go through the source indiscriminately adding
>  > them.  Many errors will still be subject to change even if you tack
>  > permanent identifiers on them.
> 
> All calls to error could be given a dummy argument (0, if numbers are used),
> and replaced with a real one only in thoses cases when a need arises.

You've answered your own question.  The calls which need to be changed
could be changed to call something other than error() itself.  I'm not
sure why you object to a second string argument and don't object to
adding a number to all of those call sites.

The user wouldn't have to remember them, of course - but _I_ would, as
a GDB developer.  Keeping track of all the used numbers in the GDB
source code, et cetera.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI error msgs and localization

[Nick Roberts]

 > > You wouldn't have to remember them, thay're for use by the front-end, not
 > > the user.  In any case the console log stream gets printed alongside,
 > > which should be self-explanatory.  How would you arrange for the type
 > > message to be printed?  Would you give error a second string argument?
 > > It has over 1200 calls.
 > > 
 > >  > We have to be careful what error messages get identifiers, though.
 > >  > Please don't anybody go through the source indiscriminately adding
 > >  > them.  Many errors will still be subject to change even if you tack
 > >  > permanent identifiers on them.
 > > 
 > > All calls to error could be given a dummy argument (0, if numbers are
 > > used), and replaced with a real one only in thoses cases when a need
 > > arises.
 > 
 > You've answered your own question.  The calls which need to be changed
 > could be changed to call something other than error() itself.

That's not quite what I said but it's a better idea as fewer changes need be
made.  Better still might be to use a global variable, perhaps
mi_error_message in mi-main.c could be used.  How about something like the
patch below (in mi_execute_command) to be used like this:

  mi_error_message = xstrprintf ("no-debugging-symbols");
  error(_("No debugging symbols found");

to give:

  &"No debugging symbols found\n"
  ^error,msg="no-debugging-symbols"

I've not used the previous example ("Unrecognized option"), as it comes from
getopt_long_only and not error (however, I think all of Bjarke's other
examples were from error).

WDYT?

Nick


*** mi-main.c	30 Jan 2006 09:17:56 +1300	1.83
--- mi-main.c	15 Feb 2006 14:31:38 +1300	
***************
*** 1171,1177 ****
  	     somewhere.  */
  	  fputs_unfiltered (command->token, raw_stdout);
  	  fputs_unfiltered ("^error,msg=\"", raw_stdout);
! 	  fputstr_unfiltered (result.message, '"', raw_stdout);
  	  fputs_unfiltered ("\"\n", raw_stdout);
  	  mi_out_rewind (uiout);
  	}
--- 1171,1183 ----
  	     somewhere.  */
  	  fputs_unfiltered (command->token, raw_stdout);
  	  fputs_unfiltered ("^error,msg=\"", raw_stdout);
! 	  if (mi_error_message)
! 	    {
! 	      fputstr_unfiltered (mi_error_message, '"', raw_stdout);
! 	      xfree (mi_error_message);
! 	    }
! 	  else
! 	    fputstr_unfiltered (result.message, '"', raw_stdout);
  	  fputs_unfiltered ("\"\n", raw_stdout);
  	  mi_out_rewind (uiout);
  	}

Re: MI error msgs and localization

[Daniel Jacobowitz]

On Wed, Feb 15, 2006 at 02:46:53PM +1300, Nick Roberts wrote:
> That's not quite what I said but it's a better idea as fewer changes need be
> made.  Better still might be to use a global variable, perhaps
> mi_error_message in mi-main.c could be used.  How about something like the
> patch below (in mi_execute_command) to be used like this:
> 
>   mi_error_message = xstrprintf ("no-debugging-symbols");
>   error(_("No debugging symbols found");
> 
> to give:
> 
>   &"No debugging symbols found\n"
>   ^error,msg="no-debugging-symbols"

Please don't.  If you need to pass two arguments to error, make a
two-argument version :-)

Passing arguments by globals is bad news.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI error msgs and localization

[Nick Roberts]

 > Please don't.  If you need to pass two arguments to error, make a
 > two-argument version :-)
 > 
 > Passing arguments by globals is bad news.

Well that's what is already done in mi-main.c, although admittedly the other
mi files use error.  More importantly, how do you propagate two messages
back up the stack when gdb_exception only allows one?

(top-gdb) ptype e
type = struct gdb_exception {
    enum return_reason reason;
    enum errors error;
    const char *message;
}

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI error msgs and localization

[Daniel Jacobowitz]

On Wed, Feb 15, 2006 at 05:47:30PM +1300, Nick Roberts wrote:
>  > Please don't.  If you need to pass two arguments to error, make a
>  > two-argument version :-)
>  > 
>  > Passing arguments by globals is bad news.
> 
> Well that's what is already done in mi-main.c, although admittedly the other
> mi files use error.  More importantly, how do you propagate two messages
> back up the stack when gdb_exception only allows one?
> 
> (top-gdb) ptype e
> type = struct gdb_exception {
>     enum return_reason reason;
>     enum errors error;
>     const char *message;
> }

By adding to that struct?

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI error msgs and localization

[Nick Roberts]

 > >                 ...More importantly, how do you propagate two messages
 > > back up the stack when gdb_exception only allows one?
 > > 
 > > (top-gdb) ptype e
 > > type = struct gdb_exception {
 > >     enum return_reason reason;
 > >     enum errors error;
 > >     const char *message;
 > > }
 > 
 > By adding to that struct?
 > 
 > -- 
 > Daniel Jacobowitz
 > CodeSourcery

Oh, that easy.  I don't know why, but I thought changing such a fundamental
data structure would be unwelcome.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI error msgs and localization

[Daniel Jacobowitz]

On Thu, Feb 16, 2006 at 10:02:26AM +1300, Nick Roberts wrote:
> Oh, that easy.  I don't know why, but I thought changing such a fundamental
> data structure would be unwelcome.

Not at all - that's the nice thing about internal interfaces; very
little in GDB knows what's in a gdb_exception.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI error msgs and localization

[Bob Rossi]

On Tue, Feb 14, 2006 at 04:05:05PM -0500, Daniel Jacobowitz wrote:
> On Wed, Feb 15, 2006 at 09:58:23AM +1300, Nick Roberts wrote:
> >  > 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?
> > 
> > We've already got ^error as a result field so it doesn't make any sense to me,
> >  and if "Unrecognized option" comes from the console stream then I think that
> >  can still change.  The problem seems to be that of handling CLI error output
> >  in MI.  I see that the standard GNU error function provides for an error
> >  number which is less likely to change:
> > 
> >  -- Function: void error (int STATUS, int ERRNUM, const char *FORMAT,
> >           ...)
> > 
> > I wonder if GDB's error function could have one for MI e.g
> > 
> > &"Unrecognized option\n"
> > ^error,msg="Unrecognized option",code="35"
> > 
> > or even
> > 
> > &"Unrecognized option\n"
> > ^error,code="35"
> > 
> >  instead of just:
> > 
> > &"Unrecognized option\n"
> > ^error,msg="Unrecognized option"
> 
> GCC developers spent a lot of time talking about this.  I think the
> trick to doing this right is actually to do it the way Bjarke
> suggested: msg= as a free-form, explanatory text, and type= (or code=,
> or something else) as a documented identifier.  But using numbers for
> the identifiers is not necessarily a good idea, because keeping track
> of them is error-prone.  I'd suggest that
> type="init-option-unrecognized" was a lot more memorable than
> "code=35".

I could not agree more here. I think every single error message has to
have a corresponding reason that the FE can understand. For instance, if
the FE is parsing the error message currently generated, it should be
prepared that the message can change at any given time. Any parsing of
the error message is a bad idea. It's as bad as parsing the CLI output.

The only way that MI should pass an error status back to the FE is
through a type="init-option-unrecognized". Each of these error responses
should be documented just like the asynchronous response reasons.

This is the only way to go, IMO.

Bob Rossi