<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hello (again),<br>
<br>
Thanks Clément for putting the discussion in the even more public
domain :)<br>
<br>
If i may abstract, <b>there are 3 distinct topics</b>:<br>
<ol>
<li>become able to identify each warning() with an id, and then
become able to switch it "on" or "off" in a specific targeted
way.<br>
<br>
</li>
<li>become able to define which action a triggered warning must
do:</li>
<ul>
<li>up to now, it was only possible to display a message set
as warning() input parameter.</li>
<li>warning("stop") tends to make a (specific) warning to stop
instead of only displaying a message.<br>
Currently, the only difference with error() is that an
error() can't be turned off. <br>
</li>
<li>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.<br>
<br>
</li>
</ul>
<li>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<br>
</li>
</ol>
<p>Moreover, <b>there are 2 distinct types of calls</b>:<br>
</p>
<ol>
<li><b>event calls</b>: these are warning(..) instructions
written in the code, where the warning must occur. Presently:
<br>
</li>
<ul>
<li>warning(message) : disp(message), and goes on</li>
<li>error(message): disp(message), and stops<br>
<br>
</li>
</ul>
<li><b>setting calls</b>: these are calls that defines how
warning() must behave or provide infos about current settings:</li>
<ol>
<li>presently: warning("on"), warning("off"), warning("query")<br>
<br>
</li>
</ol>
</ol>
<p>As you, i think that leveling warning()/error() is a task quite
independent from both other topics.<br>
But we could anticipate the evolution. I do not think that it
should be rejected in an external toolbox,<br>
because it's a "central common device" for flow-control. But it
could be done later. <br>
Would it be complicated to implement it, without respect to
existing warning() and error() in all existing codes?<br>
</p>
<p>What about the proposal
<a class="moz-txt-link-freetext" href="https://codereview.scilab.org/#/c/18041/3">https://codereview.scilab.org/#/c/18041/3</a> ?<br>
IMO,<br>
</p>
<ul>
<li>"stop" should really not be introduced. A more general
syntax ["do", instructions] should be introduced instead<br>
<br>
</li>
<li>"stop" or any ["do", instructions] should not be mixed
with "on" and "off" flags, because <br>
</li>
<ul>
<li> ["do", instructions] are to be defined in the code
where the warning must occur. It replace or "complements"
the message ;</li>
<li>whereas "on" or "off" are setting instructions, anywhere
(else) in the code<br>
<br>
</li>
</ul>
<li>"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??<br>
If so, i think that the tag must rather be independent from
the message, and shall be invariant, whatever is the session
language.<br>
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.<br>
<br>
</li>
<li>Nothing is proposed to query ALL existing tags names and
their statuses. <br>
</li>
</ul>
<p>So, which prototypes could we dream about? :)<br>
</p>
<ul>
<li><b>in the code,on event: warning([level,] { </b><b> "my
message" | </b><b>["do", Scilab_instructions ] } [,"tag",
tagName] )</b></li>
<ul>
<li>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:<br>
</li>
<ul>
<li>0: notices</li>
<li>1: alerts<br>
</li>
<li>2: errors<br>
<br>
</li>
<li>No need to do that in an external module</li>
<li>No back-compatibility issues: errors() would remain in
place -- may be undocumented in Scilab 6.x? --, and former
errors() calls progressively converted:<br>
error(message) => warning(2, message)<br>
<br>
If <level> is provided, <br>
</li>
</ul>
<ul>
<li>the next argin can't be "on" or "off"</li>
<li>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.<br>
<br>
</li>
</ul>
<li>"do": like a property, would expect the next argin to be a
string defining actions to perform (Scilab instruction(s)).
So</li>
<ul>
<li>warning("stop") would rather be something like
warning("do","whereami(); error();..")</li>
<li>warning("pause") would rather be warning("do","pause")</li>
<li>warning("do", "disp(""My message"")") would be an
equivalent of warning("My message")<br>
<br>
</li>
</ul>
<li>otherwise, the text is still considered as the message to
be displayed.<br>
<br>
</li>
<li>"tag": specific string (attribute), expecting tagName in
next argin<br>
<br>
</li>
</ul>
<li><b>as settings</b>, anywhere:</li>
<ul>
<li>warning("query"): The overall status for all untagged
warnings of level==1 (as now)<br>
warning(level, "query"): The overall status for all untagged
warnings of the given level. <br>
warning( "query","tags"): List existing tags (of
all levels), their statuses, and their levels.<br>
warning(level, "query","tags"): List existing tags of given
level, and their statuses: = filtered output from
warning("query","tags")<br>
<br>
</li>
<li>warning("on"): turn on all tagged or untagged warnings,
whatever is their levels <br>
warning("on", "tagged"): turn on all tagged warnings,
whatever is their levels<br>
warning("on", "untagged"): turn on all untagged warnings,
whatever is their levels<br>
warning("on", "tag", tagName): turn on the given warning<br>
<br>
</li>
<li>warning("off",...) same things <br>
</li>
</ul>
</ul>
<p><b>BUT</b>: to implement that, a look-up table of warnings
shall be set and stored somewhere. <br>
This looks similar to the gettext() philosophy: AFAIU, all
warning tags shall be harvested when compiling the code.<br>
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.<br>
</p>
<ul>
<li>=> need to modify genlib(). The new xml format of the
"lib" file could have a new xml tag.</li>
<li>=> need to modify load() (and/or its duplicate lib()) :
to read warning tags from the library and merge them in the
overall list.</li>
<li>=> need to modify execstr() and deff()...<br>
</li>
</ul>
<p>This is a lot of work...<br>
Now, i may understand from your proposal that you don't want to
go on this way. <br>
You might want to define the look-up table of tagNames only from
the setting point of view.<br>
If so, i am sorry, but i think it is better to not implement
this "tag" feature, because it would be hardly usable.<br>
</p>
<p>The ["do", instructions] feature does not need such a table. It
could already be a great improvement, <br>
with warning() overloading.<br>
</p>
<p>By the way: despite the announcement, the localization of
functions with gettext()==_() in external modules has never
worked: <br>
<a class="moz-txt-link-freetext" href="http://bugzilla.scilab.org/13796">http://bugzilla.scilab.org/13796</a><br>
Is it because such a "harvest+registering" procedure is actually
not yet implemented for gettext() out of Scilab?<br>
This opening had not been discussed, and if finally still
unavailable.<br>
</p>
<p>Then, this "warning() discussion" could be the opportunity to
implement both (at least for functions. For built-in, how to
do?)<br>
</p>
<p>There were my lengthy thoughts, likely wrong on some aspects.<br>
</p>
<p>Hope to soon read other contributions, comments, and
corrections.<br>
</p>
<p>Regards<br>
Samuel<br>
</p>
Le 07/04/2016 10:01, Clément David a écrit :<br>
</div>
<blockquote
cite="mid:1460016072.19415.2.camel@scilab-enterprises.com"
type="cite">
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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]: <a class="moz-txt-link-freetext" href="https://codereview.scilab.org/#/c/18041">https://codereview.scilab.org/#/c/18041</a>
[2]: <a class="moz-txt-link-freetext" href="https://docs.oracle.com/javase/8/docs/api/java/util/logging/Logger.html">https://docs.oracle.com/javase/8/docs/api/java/util/logging/Logger.html</a>
Thanks for your remarks and request on this topic,
--
Clément
_______________________________________________
dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dev@lists.scilab.org">dev@lists.scilab.org</a>
<a class="moz-txt-link-freetext" href="http://lists.scilab.org/mailman/listinfo/dev">http://lists.scilab.org/mailman/listinfo/dev</a>
</pre>
</blockquote>
<br>
</body>
</html>