1. SEP: Warning Level

2. Abstract

There are 3 distinct topics:

1. become able to identify each warning() with an id, and then become able to switch it "on" or "off" in a specific targeted way.
2. become able to define which action a triggered warning must do:
   1. up to now, it was only possible to display a message set as warning() input parameter.
   2. warning("stop") tends to make a (specific) warning to stop instead of only displaying a message.
   3. Currently, the only difference with error() is that an error() can't be turned off.
   4. we could rather think about a more general "do_on_trigger" action, "stop" being a too specific case that should not be defined as is.

3. Manage graded warning levels instead of a binary "on"|"off" coupled to a set of specific functions "warning()", "error()", ...: notice (mainly information messages) < warning (beware) < error

Moreover, there are 2 distinct types of calls:

• event calls: these are warning(..) instructions written in the code, where the warning must occur. Presently:

  • warning(message) : disp(message), and goes on
  • error(message): disp(message), and stops

• setting calls: these are calls that defines how warning() must behave or provide infos about current settings:

  • presently: warning("on"), warning("off"), warning("query")

3. Requirements

As you, I think that leveling warning() / error() is a task quite independent from both other topics. But we could anticipate the evolution. I do not think that it should be rejected in an external toolbox, because it's a "central common device" for flow-control. But it could be done later. Would it be complicated to implement it, without respect to existing warning() and error() in all existing codes?

What about the proposal https://codereview.scilab.org/#/c/18041/3 ? IMO,

• "stop" should really not be introduced. A more general syntax ["do", instructions] should be introduced instead
• "stop" or any ["do", instructions] should not be mixed with "on" and "off" flags, because
  • ["do", instructions] are to be defined in the code where the warning must occur. It replace or "complements" the message ; whereas "on" or "off" are setting instructions, anywhere (else) in the code
• "warningName" is actually the warning's id/tag. But in the page, we don't see any syntax where this tag is defined. From the page, should we understand that the (translated) warning message IS the tag ?? If so, i think that the tag must rather be independent from the message, and shall be invariant, whatever is the session language. Actually, calls on events are defined by developers, while settings are done by users. The identification must be common to both sides, so as simple as possible. Nothing is proposed to query ALL existing tags names and their statuses.

So, which prototypes could we dream about?

• in the code,on event: warning([level,] { "my message" | ["do", Scilab_instructions ] } [,"tag", tagName] )

  • level : 0, 1, 2: it would be straightforward to support this by opening warning() to overloading for argin#1 not a string. We could have:
    • 0: notices
    • 1: alerts
    • 2: errors
    • No need to do that in an external module
    • No back-compatibility issues: errors() would remain in place -- may be undocumented in Scilab 6.x? --, and former errors() calls progressively converted:

      error(message) => warning(2, message)

If <level> is provided,

• the next argin can't be "on" or "off" the next argin could be "query", to query the status of all warning at a given level. But this feature would not be at all a priority.
• "do": like a property, would expect the next argin to be a string defining actions to perform (Scilab instruction(s)). So :
  • warning("stop") would rather be something like warning("do","whereami(); error();..")
  • warning("pause") would rather be warning("do","pause")
  • warning("do", "disp(""My message"")") would be an equivalent of warning("My message")
• otherwise, the text is still considered as the message to be displayed.
• "tag": specific string (attribute), expecting tagName in next argin

• as settings, anywhere:
  • warning("query"): The overall status for all untagged warnings of level==1 (as now)
  • warning(level, "query"): The overall status for all untagged warnings of the given level.
  • warning( "query","tags"): List existing tags (of all levels), their statuses, and their levels.
  • warning(level, "query","tags"): List existing tags of given level, and their statuses: = filtered output from warning("query","tags")
  • warning("on"): turn on all tagged or untagged warnings, whatever is their levels
  • warning("on", "tagged"): turn on all tagged warnings, whatever is their levels
  • warning("on", "untagged"): turn on all untagged warnings, whatever is their levels
  • warning("on", "tag", tagName): turn on the given warning
  • warning("off",...) same things

BUT: to implement that, a look-up table of warnings shall be set and stored somewhere. This looks similar to the gettext() philosophy: AFAIU, all warning tags shall be harvested when compiling the code.

So: a library of macros shall have a new component (in the lib file) = list of warnings tags (and levels) defined in its public and privates functions.

1. need to modify genlib(). The new xml format of the "lib" file could have a new xml tag.
2. need to modify load() (and/or its duplicate lib()) : to read warning tags from the library and merge them in the overall list.
3. need to modify execstr() and deff()...

This is a lot of work...

Now, i may understand from your proposal that you don't want to go on this way. You might want to define the look-up table of tagNames only from the setting point of view. If so, i am sorry, but i think it is better to not implement this "tag" feature, because it would be hardly usable.

The ["do", instructions] feature does not need such a table. It could already be a great improvement, with warning() overloading.

By the way: despite the announcement, the localization of functions with gettext()==_() in external modules has never worked: http://bugzilla.scilab.org/13796

Is it because such a "harvest+registering" procedure is actually not yet implemented for gettext() out of Scilab? This opening had not been discussed, and if finally still unavailable.

Then, this "warning() discussion" could be the opportunity to implement both (at least for functions. For built-in, how to do?)

There were my lengthy thoughts, likely wrong on some aspects.

4. Related topics

4.1. Bugzilla links

The following bugs have been entered on bugzilla to track similar or related problems / wishlist

• http://bugzilla.scilab.org/13796

4.2. Mailling list threads

from http://mailinglists.scilab.org/warning-Extending-management-mode-for-a-specific-message-td4033934.html

4.3. Other software

5. Examples

---

CategorySep