message ids for warnings and errors

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

message ids for warnings and errors

John W. Eaton-6
I've started to implement the

  warning (msgid, fmt, ...)
  error (msgid, fmt, ...)

feature.  This will allow us to also do things like

  warning off MATLAB:divideByZero

and (probably) eliminate all the warn_* built-in variables.  I would
rather not tag our warning and error messsages internally with
"MATLAB:", and I'm not a big fan of StudlyCaps so perhaps we would
have message IDs like "Octave:divide_by_zero" instead, with a lookup
table so that this is equivalent to MATLAB:divideByZero (unless we can
rely on a uniform translation like Octave -> MATLAB and _[a-z] ->
[A-Z]).  Does anyone know of a comprehensive list of IDs that Matlab
uses for warnings?

Thanks,

jwe

Reply | Threaded
Open this post in threaded view
|

Re: message ids for warnings and errors

Stéfan van der Walt
On Tue, Dec 06, 2005 at 03:18:50PM -0500, John W. Eaton wrote:

> I've started to implement the
>
>   warning (msgid, fmt, ...)
>   error (msgid, fmt, ...)
>
> feature.  This will allow us to also do things like
>
>   warning off MATLAB:divideByZero
>
> and (probably) eliminate all the warn_* built-in variables.  I would
> rather not tag our warning and error messsages internally with
> "MATLAB:", and I'm not a big fan of StudlyCaps so perhaps we would
> have message IDs like "Octave:divide_by_zero" instead, with a lookup
> table so that this is equivalent to MATLAB:divideByZero (unless we can
> rely on a uniform translation like Octave -> MATLAB and _[a-z] ->
> [A-Z]).  Does anyone know of a comprehensive list of IDs that Matlab
> uses for warnings?

I wonder how consistent they are in the usage of these strings. The
best description I could find is at

http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/ch12_er7.html#prog_message_identifiers

and it doesn't refer to a list of pre-defined identifiers.

My vote goes for the lookup-table, rather than the string translation.

Regards
St?fan

Reply | Threaded
Open this post in threaded view
|

Re: message ids for warnings and errors

Bill Denney
On Tue, 6 Dec 2005, Stefan van der Walt wrote:

> I wonder how consistent they are in the usage of these strings. The
> best description I could find is at
>
> http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/ch12_er7.html#prog_message_identifiers
>
> and it doesn't refer to a list of pre-defined identifiers.
>
> My vote goes for the lookup-table, rather than the string translation.

That looks like what I see as well.  These identifiers are written in by
the coders of the individual functions (you can add one yourself as part
of your warning).  I would say that the warning types should be added as
they are found, and I don't think that they are standard.

Bill

--
Warning label at MIT's Junior Lab:
"WARNING: Do not look into laser with remaining eye"
   -- /usr/bin/fortune

Reply | Threaded
Open this post in threaded view
|

Re: message ids for warnings and errors

Søren Hauberg
tir, 06 12 2005 kl. 17:21 -0500, skrev Bill Denney:

> On Tue, 6 Dec 2005, Stefan van der Walt wrote:
>
> > I wonder how consistent they are in the usage of these strings. The
> > best description I could find is at
> >
> > http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/ch12_er7.html#prog_message_identifiers
> >
> > and it doesn't refer to a list of pre-defined identifiers.
> >
> > My vote goes for the lookup-table, rather than the string translation.
>
> That looks like what I see as well.  These identifiers are written in by
> the coders of the individual functions (you can add one yourself as part
> of your warning).  I would say that the warning types should be added as
> they are found, and I don't think that they are standard.
Some can be found by typing

warning query all

in the matlab prompt. Although this will only give you the warnings with
preset defaults.

/S�ren

> Bill
>
> --
> Warning label at MIT's Junior Lab:
> "WARNING: Do not look into laser with remaining eye"
>    -- /usr/bin/fortune
How appropriate :-)



Reply | Threaded
Open this post in threaded view
|

Re: message ids for warnings and errors

John W. Eaton-6
On  6-Dec-2005, S?ren Hauberg wrote:

| Some can be found by typing
|
| warning query all
|
| in the matlab prompt. Although this will only give you the warnings with
| preset defaults.

Try

  warning query all
  warning on all
  warning query all

Do you get different lists for the first and second query?

jwe

Reply | Threaded
Open this post in threaded view
|

Re: message ids for warnings and errors

John W. Eaton-6
In reply to this post by Bill Denney
On  6-Dec-2005, Bill Denney wrote:

| On Tue, 6 Dec 2005, Stefan van der Walt wrote:
|
| > I wonder how consistent they are in the usage of these strings. The
| > best description I could find is at
| >
| > http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/ch12_er7.html#prog_message_identifiers
| >
| > and it doesn't refer to a list of pre-defined identifiers.
| >
| > My vote goes for the lookup-table, rather than the string translation.
|
| That looks like what I see as well.  These identifiers are written in by
| the coders of the individual functions (you can add one yourself as part
| of your warning).  I would say that the warning types should be added as
| they are found, and I don't think that they are standard.

Yes, I'm not proposing that we implement them all at once, even if we
could find a list.  I was more interested in seeing whether there was
a uniform naming scheme and about how many there are.

I suppose the first thing to do is eliminate all the warn_* built-in
variables in favor of controlling warnings with warning [on|off] ID.

Thanks,

jwe

Reply | Threaded
Open this post in threaded view
|

Re: message ids for warnings and errors

Søren Hauberg
In reply to this post by John W. Eaton-6
tir, 06 12 2005 kl. 17:37 -0500, skrev John W. Eaton:
> Try
>
>   warning query all
>   warning on all
>   warning query all
>
> Do you get different lists for the first and second query?
Matlab is to "smart":

>> warning query all
The default warning state is 'on'. Warnings not set to the default are

  State  Warning Identifier

    off  MATLAB:UsingLongNames
    off  MATLAB:intConvertNaN
    off  MATLAB:intConvertNonIntVal
    off  MATLAB:intConvertOverflow
    off  MATLAB:intMathOverflow
    off  MATLAB:max:mixedIntegerScalarDoubleInputs
    off  MATLAB:max:mixedSingleDoubleInputs
    off  MATLAB:min:mixedIntegerScalarDoubleInputs
    off  MATLAB:min:mixedSingleDoubleInputs
    off  MATLAB:mir_warning_unrecognized_pragma
    off  MATLAB:nonScalarConditional

>> warning on all
>> warning query all
The default warning state is 'on'. Warnings not set to the default are

  State  Warning Identifier

    off  MATLAB:UsingLongNames
    off  MATLAB:nonScalarConditional

>> warning off all
>> warning query all
All warnings have the state 'off'.

This is on matlab 7.0.0.19901 (R14) on the unix system at school.

/S�ren
>
> jwe

Reply | Threaded
Open this post in threaded view
|

Re: message ids for warnings and errors

Quentin Spencer
In reply to this post by John W. Eaton-6
John W. Eaton wrote:

>On  6-Dec-2005, S?ren Hauberg wrote:
>
>| Some can be found by typing
>|
>| warning query all
>|
>| in the matlab prompt. Although this will only give you the warnings with
>| preset defaults.
>
>Try
>
>  warning query all
>  warning on all
>  warning query all
>
>Do you get different lists for the first and second query?
>  
>


Yes, but unfortunately not what I think you were hoping for:

 >> warning query all
The default warning state is 'on'. Warnings not set to the default are

  State  Warning Identifier

    off  MATLAB:UsingLongNames
    off  MATLAB:intConvertNaN
    off  MATLAB:intConvertNonIntVal
    off  MATLAB:intConvertOverflow
    off  MATLAB:intMathOverflow
    off  MATLAB:max:mixedIntegerScalarDoubleInputs
    off  MATLAB:max:mixedSingleDoubleInputs
    off  MATLAB:min:mixedIntegerScalarDoubleInputs
    off  MATLAB:min:mixedSingleDoubleInputs
  error  MATLAB:mir_variable_with_script_name
    off  MATLAB:mir_warning_unrecognized_pragma
    off  MATLAB:nonScalarConditional

 >> warning on all
 >> warning query all
The default warning state is 'on'. Warnings not set to the default are

  State  Warning Identifier

    off  MATLAB:UsingLongNames
    off  MATLAB:nonScalarConditional


Reply | Threaded
Open this post in threaded view
|

Re: message ids for warnings and errors

John W. Eaton-6
In reply to this post by Søren Hauberg
On  6-Dec-2005, S?ren Hauberg wrote:

| Matlab is to "smart":

Yup.  I guess you are supposed to always save the previous warning
state if you want to return to it.  But is it nice or not that
"warning on all" leaves a few warnings disabled?

In any case, I've just checked in some changes to Octave's warning
function to allow message-ids.  You can also use

  warning error ID

to turn warnings into errors.  I think this is also compatible
behavior.

To distinguish message-ids from formats when two or more arguments are
passed to the warning function, we check the first argument to warning
to see if it contains "%".  If so, we assume it is a format, otherwise
it is a message-id.  It's a bit of a kluge, but I'm not sure there is
anything better to do.

No calls to warning actually use message-ids yet, but the next step
should be to eliminate the need for the warn_* built-in variables.
I'd appreciate any help with that.  It should be relatively easy.

Thanks,

jwe

Reply | Threaded
Open this post in threaded view
|

Re: message ids for warnings and errors

Stéfan van der Walt
In reply to this post by John W. Eaton-6
On Tue, Dec 06, 2005 at 05:39:49PM -0500, John W. Eaton wrote:

> On  6-Dec-2005, Bill Denney wrote:
>
> | On Tue, 6 Dec 2005, Stefan van der Walt wrote:
> |
> | > I wonder how consistent they are in the usage of these strings. The
> | > best description I could find is at
> | >
> | > http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/ch12_er7.html#prog_message_identifiers
> | >
> | > and it doesn't refer to a list of pre-defined identifiers.
> | >
> | > My vote goes for the lookup-table, rather than the string translation.
> |
> | That looks like what I see as well.  These identifiers are written in by
> | the coders of the individual functions (you can add one yourself as part
> | of your warning).  I would say that the warning types should be added as
> | they are found, and I don't think that they are standard.
>
> Yes, I'm not proposing that we implement them all at once, even if we
> could find a list.  I was more interested in seeing whether there was
> a uniform naming scheme and about how many there are.

It's just as well.  I found a list by grepping through the MATLAB
m-files (one that I obviously can't publish here) -- it contains more
than 2000 warnings.  These include very specific warnings like
MATLAB:cell2mat:NoInputs.

I don't see any way we can implement all these, given that we're not
allowed to look at the MATLAB source and the narrow scope they have.

St?fan

Reply | Threaded
Open this post in threaded view
|

Re: message ids for warnings and errors

John W. Eaton-6
On  7-Dec-2005, Stefan van der Walt wrote:

| It's just as well.  I found a list by grepping through the MATLAB
| m-files (one that I obviously can't publish here) -- it contains more
| than 2000 warnings.  These include very specific warnings like
| MATLAB:cell2mat:NoInputs.
|
| I don't see any way we can implement all these, given that we're not
| allowed to look at the MATLAB source and the narrow scope they have.

I don't think it is necessary for us to have them all.  It is never an
error to use "warning off msgid", so it shouldn't matter whether we
actually have a warning with the given msgid.  But it would be nice if
we do the right thing for the warnings that we know about, and that
are common to both Octave and Matlab (divide by zero, for example).
And in those cases, it would also be nice to recognize the message ids
that Matlab uses, provided that doing so is not a lot of trouble.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: message ids for warnings and errors

Paul Kienzle

On Dec 7, 2005, at 10:15 AM, John W. Eaton wrote:

> On  7-Dec-2005, Stefan van der Walt wrote:
>
> | It's just as well.  I found a list by grepping through the MATLAB
> | m-files (one that I obviously can't publish here) -- it contains more
> | than 2000 warnings.  These include very specific warnings like
> | MATLAB:cell2mat:NoInputs.
> |
> | I don't see any way we can implement all these, given that we're not
> | allowed to look at the MATLAB source and the narrow scope they have.
>
> I don't think it is necessary for us to have them all.  It is never an
> error to use "warning off msgid", so it shouldn't matter whether we
> actually have a warning with the given msgid.  But it would be nice if
> we do the right thing for the warnings that we know about, and that
> are common to both Octave and Matlab (divide by zero, for example).
> And in those cases, it would also be nice to recognize the message ids
> that Matlab uses, provided that doing so is not a lot of trouble.

It would be nice if the warning state were automatically
restored when the function completes, otherwise we are going
to end up with unwind protect cruft sprinkled everywhere again.
If users really want a name for a group of warning states,
then put them together in a script.

The usual place to turn off warnings for the user, the
.octaverc file, would never be unwound since octave never
goes above toplevel.

- Paul

Reply | Threaded
Open this post in threaded view
|

Re: message ids for warnings and errors

John W. Eaton-6
On  7-Dec-2005, Paul Kienzle wrote:

| It would be nice if the warning state were automatically
| restored when the function completes, otherwise we are going
| to end up with unwind protect cruft sprinkled everywhere again.

One of the reasons for adding the message-id thing was compatibility.
Having the state scoped would break compatibility.

In CVS Octave, we have 21 knobs for warning control:

  warn_assign_as_truth_value
  warn_function_name_clash
  warn_neg_dim_as_zero
  warn_separator_insert
  warn_variable_switch_label
  warn_associativity_change
  warn_future_time_stamp
  warn_num_to_str
  warn_single_quote_string
  warn_divide_by_zero
  warn_imag_to_real
  warn_precedence_change
  warn_str_to_num
  warn_empty_list_elements
  warn_matlab_incompatible
  warn_reload_forces_clear
  warn_string_concat
  warn_fortran_indexing
  warn_missing_semicolon
  warn_resize_on_range_error
  warn_undefined_return_values

and 12 of them are off by default.  So I guess we have a situation
similar to Matlab, where we will start with

  warning on all

plus the 12 exceptions.

Is it really a problem if the state is global?  Are there very many
(any) places now where we need unwind_protect to play with the warning
state?

jwe

Reply | Threaded
Open this post in threaded view
|

Re: message ids for warnings and errors

Paul Kienzle

On Dec 7, 2005, at 7:24 PM, John W. Eaton wrote:

> On  7-Dec-2005, Paul Kienzle wrote:
>
> | It would be nice if the warning state were automatically
> | restored when the function completes, otherwise we are going
> | to end up with unwind protect cruft sprinkled everywhere again.
>
> One of the reasons for adding the message-id thing was compatibility.
> Having the state scoped would break compatibility.
>
> In CVS Octave, we have 21 knobs for warning control:
>
>   warn_assign_as_truth_value
>   warn_function_name_clash
>   warn_neg_dim_as_zero
>   warn_separator_insert
>   warn_variable_switch_label
>   warn_associativity_change
>   warn_future_time_stamp
>   warn_num_to_str
>   warn_single_quote_string
>   warn_divide_by_zero
>   warn_imag_to_real
>   warn_precedence_change
>   warn_str_to_num
>   warn_empty_list_elements
>   warn_matlab_incompatible
>   warn_reload_forces_clear
>   warn_string_concat
>   warn_fortran_indexing
>   warn_missing_semicolon
>   warn_resize_on_range_error
>   warn_undefined_return_values
>
> and 12 of them are off by default.  So I guess we have a situation
> similar to Matlab, where we will start with
>
>   warning on all
>
> plus the 12 exceptions.
>
> Is it really a problem if the state is global?  Are there very many
> (any) places now where we need unwind_protect to play with the warning
> state?

~/cvs/octave/scripts$ grep -h "^ *warn_" */*.m */*/*.m | sed -e"s/^
*//;s/ *= */ = /" | sort | uniq

   warn_empty_list_elements = 0;
   warn_empty_list_elements = save_warn_empty_list_elements;
   warn_fortran_indexing = 0;
   warn_fortran_indexing = wfi;
   warn_str_to_num = 0;
   warn_str_to_num = tmp;

~/cvs/octave/scripts$ grep -l "^ *warn_" */*.m */*/*.m | wc
   16      16     357


Similarly, octave-forge has 27 instances, including

   warn_divide_by_zero = 0;
   warn_divide_by_zero = wdz;

Maybe warn could have another state 'expected' which
suppresses the warning in the local scope?  So rather
than:

    wfi = warning('query','octave:empty_list_elements');
    unwind_protect
      warning('off','octave:empty_list_elements');
      ...
    unwind_protect_cleanup
      warning(wfi,'octave:empty_list_elements');
    end_unwind_protect

you would use:

    warning('expected','octave:empty_list_elements');
    ...

- Paul

Reply | Threaded
Open this post in threaded view
|

Re: message ids for warnings and errors

Paul Kienzle
In reply to this post by John W. Eaton-6

On Dec 7, 2005, at 7:24 PM, John W. Eaton wrote:

> In CVS Octave, we have 21 knobs for warning control:
>
>   warn_assign_as_truth_value
>   warn_function_name_clash
>   warn_neg_dim_as_zero
>   warn_separator_insert
>   warn_variable_switch_label
>   warn_associativity_change
>   warn_future_time_stamp
>   warn_num_to_str
>   warn_single_quote_string
>   warn_divide_by_zero
>   warn_imag_to_real
>   warn_precedence_change
>   warn_str_to_num
>   warn_empty_list_elements
>   warn_matlab_incompatible
>   warn_reload_forces_clear
>   warn_string_concat
>   warn_fortran_indexing
>   warn_missing_semicolon
>   warn_resize_on_range_error
>   warn_undefined_return_values

Few of these names can be guessed from the text of the
warning, but the text of the warning is all that the
user sees.

We could allow something like:

    warning off 'empty list elements'

to suppress the warning message containing the string
'empty list elements'.  Unfortunately this won't work
so well with internationalization.

Any other suggestions?

- Paul

Reply | Threaded
Open this post in threaded view
|

Re: message ids for warnings and errors

John W. Eaton-6
In reply to this post by Paul Kienzle
On  7-Dec-2005, Paul Kienzle wrote:

| ~/cvs/octave/scripts$ grep -h "^ *warn_" */*.m */*/*.m | sed -e"s/^
| *//;s/ *= */ = /" | sort | uniq
|
|    warn_empty_list_elements = 0;
|    warn_empty_list_elements = save_warn_empty_list_elements;
|    warn_fortran_indexing = 0;
|    warn_fortran_indexing = wfi;
|    warn_str_to_num = 0;
|    warn_str_to_num = tmp;
|
| ~/cvs/octave/scripts$ grep -l "^ *warn_" */*.m */*/*.m | wc
|    16      16     357

Since these appear to set the variables to what are now default
values, I'd be in favor of simply removing them.

| Similarly, octave-forge has 27 instances, including
|
|    warn_divide_by_zero = 0;
|    warn_divide_by_zero = wdz;
|
| Maybe warn could have another state 'expected' which
| suppresses the warning in the local scope?

I think I'd rather avoid the extra complexity.  But maybe you see a
simple way to imlement it?

jwe

Reply | Threaded
Open this post in threaded view
|

Re: message ids for warnings and errors

John W. Eaton-6
In reply to this post by Paul Kienzle
On  7-Dec-2005, Paul Kienzle wrote:

| Few of these names can be guessed from the text of the
| warning, but the text of the warning is all that the
| user sees.
|
| We could allow something like:
|
|     warning off 'empty list elements'
|
| to suppress the warning message containing the string
| 'empty list elements'.  Unfortunately this won't work
| so well with internationalization.
|
| Any other suggestions?

In Matlab, "warning on verbose" results in warning printing an
additional message about how to disable warnings.  The message id for
the warning is displayed.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: message ids for warnings and errors

Paul Kienzle
In reply to this post by John W. Eaton-6

On Dec 7, 2005, at 8:41 PM, John W. Eaton wrote:

> | Similarly, octave-forge has 27 instances, including
> |
> |    warn_divide_by_zero = 0;
> |    warn_divide_by_zero = wdz;
> |
> | Maybe warn could have another state 'expected' which
> | suppresses the warning in the local scope?
>
> I think I'd rather avoid the extra complexity.  But maybe you see a
> simple way to imlement it?

The obvious way is to maintain a list of warning
names and states for the current function context
and run through this list when the function returns.
This does mean the majority of functions have to
pay for a feature they do not use, so not an ideal
solution.

A generalization of this is to support an
on_return("...") eval-like statement which
is called just before the function returns.
This is handy for implementing post-condition
checks for programming by contract, but not
otherwise very useful.

An ugly alternative is to hook into the symbol
table with a new octave type which is a subclass
of the structure type.  When a warning state is
set, add a field to the __expected_warning__
structure mapping warning name with the old state.
At the end of the function, when the current
symbol table is deleted and __expected_warning__
is freed, all warning states can be restored.

Either way, this seems like a low priority
issue.

- Paul

Reply | Threaded
Open this post in threaded view
|

Re: message ids for warnings and errors

Stéfan van der Walt
On Thu, Dec 08, 2005 at 11:38:09PM -0500, Paul Kienzle wrote:
> The obvious way is to maintain a list of warning
> names and states for the current function context
> and run through this list when the function returns.
> This does mean the majority of functions have to
> pay for a feature they do not use, so not an ideal
> solution.

Would it be worthwhile to implement hash-tables in liboctave?  That
way the performance hit needs to be minimal.

Stefan

Reply | Threaded
Open this post in threaded view
|

Re: message ids for warnings and errors

Paul Kienzle

On Dec 9, 2005, at 4:40 AM, Stefan van der Walt wrote:

> On Thu, Dec 08, 2005 at 11:38:09PM -0500, Paul Kienzle wrote:
>> The obvious way is to maintain a list of warning
>> names and states for the current function context
>> and run through this list when the function returns.
>> This does mean the majority of functions have to
>> pay for a feature they do not use, so not an ideal
>> solution.
>
> Would it be worthwhile to implement hash-tables in liboctave?  That
> way the performance hit needs to be minimal.

That isn't the issue.  The issue is that in
ov-usr-fn.cc(do_multi_index_op) you would need
to push and pop the set of suppressed warnings
on the unwind protect stack for every function
call even though most functions don't need it.

- Paul