[Octave-bug-tracker] [bug #58296] Improve description of warning state

[Tasos Papastylianou]

Follow-up Comment #5, bug #58296 (project octave):

Dear Markus and Rik, thank you for taking the time to address this so
diligently. I appreciate your arguments, and stand corrected.

I hope this doesn't come across like I'm trying to justify my entry (which I
appreciate is annoying when it happens and all too common in such threads).
However, I might as well complete the picture with some more issues I've
spotted, perhaps you can shed some light there as well: best case scenario,
there's still some actual issues there, which can then become proper bug
reports; worst case scenario, you'll give me even further good explanations
why things are they way they are, and perhaps I can use this and contribute
towards improving documentation. I would be happy to do so, time permitting.


1) Rik, thank you for pointing out that matlab behaves the same. You are
absolutely right. I was thrown back when I tried my example, because matlab
gave me this output:


warning( 'query', 'BohemianRhapsody:this-is-the-real-life' )
% Error using warning
% Unknown setting or incorrect message identifier
%'BohemianRhapsody:this-is-the-real-life'.


However, after seeing your example, it turns out that, you are indeed correct
that matlab reports the state of unknown warning identifiers as 'status on'
The problem above was not one of an unknown identifier as I initially thought.
Rather, it simply turns out that octave allows dashes in the name, but matlab
does not.


2) There still seem to exist at least a couple of visible differences with
matlab, which are presumably bugs rather than intentional behaviour:

M: 'warning on' in matlab turns all warnings on.
O: 'warning on' in octave has no visible effect on currently off ids. They
stay off.

Whereas 'warning on all' does the same in both systems

M: 'warning' and 'warning query all' have the same effect in matlab (i.e.
resulting in a meaningful message)
O: 'warning' and 'warning query all' have different outputs in octave. The
first gives a meaningful message, but the latter gives a struct (which is
rather cryptic if it hasn't just been explained to you carefully by Markus and
Rik!).

Regarding that last point, the special nature of the 'all' identifier is not
obvious simply from the struct returned, unless one knows about it. A more
appropriate terminal message would be needed, like matlab does it. At the very
least, the nature of the 'all' struct should be explained in the
documentation, whereas currently the nature of the 'all' id is only mentioned
in passing. (as I said, I'd be happy to contribute if and when I find the time
and figure out how
to do it).


3) I do believe that it would be advantageous to throw a warning (yes I'm
aware of the irony) when one tries to set a warning id that does not
pre-exist. Just because matlab allows silently it does not mean it shouldn't
be there in octave. E.g. I can envisage a scenario where one sets
Octave:shadowed-functions instead of Octave:shadowed-function all too easily.


4) You are absolutely correct about the shadowing warning. Ironically I had a
different example in mind which was more elaborate, and in my attempt to
simplify I chose an entirely inappropriate example. Having said that, I have
just tested the example I did have in mind in matlab too, and this also fails
to throw a warning. In case there is interest, the example is as follows:

# In the linux terminal, do: 
mkdir a && echo "function myfun(); disp('a'); end" > ./a/myfun.m
mkdir b && echo "function myfun(); disp('b'); end" > ./b/myfun.m

# From matlab or octave, do:
addpath('a'); myfun
addpath('b'); myfun % no warning that myfun has been silently replaced

I would assume that warning of such conflicts having taken place (or indeed a
warning when a variable name is used that previously belonged to a function)
would be useful in octave, even if matlab doesn't warn about this either.

5) I assumed that Octave:built-in-variable-assignment referred to masking a
built in variable or function (much like Rik's sin = 5 example), but this does
not seem to be the case. What does this do then? It's not clear from the
documentation. (and, in any case, this type of conflict would also be useful
to flag with a warning).

Thanks again for your input, and sorry for the long ramble.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58296>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/