[Scilab-Dev] [warning()] Extending management mode for a specific message
Samuel Gougeon
sgougeon at free.fr
Fri Apr 8 01:11:18 CEST 2016
Hello (again),
Thanks Clément for putting the discussion in the even more public domain :)
If i may 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:
* up to now, it was only possible to display a message set as
warning() input parameter.
* warning("stop") tends to make a (specific) warning to stop
instead of only displaying a message.
Currently, the only difference with error() is that an error()
can't be turned off.
* 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*:
1. *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
2. *setting calls*: these are calls that defines how warning() must
behave or provide infos about current settings:
1. presently: warning("on"), warning("off"), warning("query")
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
o ["do", instructions] are to be defined in the code where the
warning must occur. It replace or "complements" the message ;
o 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] )*
o 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.
o "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")
o otherwise, the text is still considered as the message to be
displayed.
o "tag": specific string (attribute), expecting tagName in next argin
* *as settings*, anywhere:
o 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")
o 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
o 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.
* => need to modify genlib(). The new xml format of the "lib" file
could have a new xml tag.
* => need to modify load() (and/or its duplicate lib()) : to read
warning tags from the library and merge them in the overall list.
* => 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.
Hope to soon read other contributions, comments, and corrections.
Regards
Samuel
Le 07/04/2016 10:01, Clément David a écrit :
> Hello Scilab devs, hello all,
>
> If you track the codereview, you may have notice that I made some warning() modification [1] to
> centralize warning message management. The idea is to allow a specific message management instead of
> globally shut off the warnings.
>
> Samuel reacted rapidly and I totally agree that it might need to be discussed. Let's copy the first
> remarks there and continue the discussion.
>
>> The "stop" flag has been introduced in quite "urging" circumstances, without (public) discussion.
>> Yet, it has a meaning completely different
>> than for other flags, since it introduces the fact that we can specify a
>> "do on warning" action. This is a useful feature, but imo it should be
>> extended. It would be much more powerful and used if it was a hook for
>> any action (pause, whereami, disp("additional info"), etc).
> It might be a major behavior modification but I am also in favor of such a change, especially I was
> initially a bit confused about the 'stop' mode that does not map any existing Scilab behavior. The
> mode management below might be available either globally or for a specific warning. To ease
> implementation, I suggest to have :
>
> 1. "on" : enable a warning
> 2. "off" : disable it
> 3. "error" : throw an error (previously named "stop")
> 4. "pause" : pause scilab on warning, might be useful to quickly manage them
> 5. "execstr" : might execstr an extra argument as Samuel suggested. This might superseed "error"
> or "pause" but is harder to use as it will require an extra argument.
>
>> In the same idea, some other languages (i have PHP in mind) have a series
>> of warning levels (notices, warning, etc). Managing things in the such a
>> way in Scilab would be nice.
> Yep I am fully aware of such a feature in the Java world [2]. With such concepts everything is an
> error with an associated level and depending on the display (or logged) level the user might see an
> error, a warning or just an information. On that point we might also migrate existing functions to
> manage mode arguments similarly to warning().
>
> AFAIK in Scilab, the following functions might behave similarly :
>
> error()
> warning()
> // may be disp() or print() but the usage might differ
>
> and to manage other (less critical) levels, I only suggest to have logger fonctionnalities in an
> external toolbox at this time.
>
>
>> Finally, -- may be it is mainly about the documentation -- warning() has
>> 1) syntaxes used to trigger already existing actions (standard display,
>> stop), etc, to write in the code ; and
>> 2) syntaxes that control how Scilab must behave when it meets a warning
>> These are two clearly distinct sub-sets of instructions. In the help, they
>> are not clearly separated, and i get quite confused when reading it.
>> It was not so disturbing when only "on" "off" was available. But it is
>> no longer the case.
> Yep I tried to separate the two concepts : display and special modes ; but with the introduction to
> specific message targets the initial display feature is lost in the mass. I will update the help to
> manage that.
>
>
> [1]: https://codereview.scilab.org/#/c/18041
> [2]: https://docs.oracle.com/javase/8/docs/api/java/util/logging/Logger.html
>
> Thanks for your remarks and request on this topic,
>
> --
> Clément
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20160408/6b198bbd/attachment.htm>
More information about the dev
mailing list