<div dir="ltr">Hello Samuel<div><br></div><div>I think my concerns have not been fully understood: the problem is not-or not only- to allow users to adapt their code, for which the warning(s'top') or warning('trace') whatever is implemented is useful. </div><div><br></div><div>The problem is also that you will have many difficulties to detect all cases when your programs will be at risk of making an addition of an empty matrix and a non empty one and not crash but produce a wrong result. And the problem is -again- worse for toolboxes: you may expect the developper of a toolbox to be aware of the diffculties that this change of behaviour entail, but this is much less the case for users (such as some of the ones that use some of the capabilities of my toolbox not because they are written in Scilab, but because they find adapted to the problem they want to deal with), who won't necessary be aware of this risk.</div><div><br></div><div>I think that if such error happens and is discovered, it will do much harm to Scilab image. Beyond the problems it causes to me (already 5 full days of hard work to test and adapt my programs and I have only discovered the most obvious problems), I think this is a reason why the change should absolutely not be made.</div><div><br></div><div>Unfortunately, I have the impression that I won't be heard and I feal a little bit discouraged not to have any answer from Scilab team to much of these concerns. The fact that some toolboxes are no more packaged under Atoms is another source of concern, which make me wonder if Scilab entreprises is still paying attention to the community...</div><div><br></div><div>Éric.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-09 17:23 GMT+01:00 Samuel Gougeon <span dir="ltr"><<a href="mailto:sgougeon@free.fr" target="_blank">sgougeon@free.fr</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Hi,<br>
<br>
Le 09/03/2016 01:18, Samuel Gougeon a écrit :<br>
</div>
<blockquote type="cite">
<ul>
<li><tt>warning("stop")</tt>: i agree that, in order to update
all contents and to be sure that results are reliable and not
polluted by unpredictable "[]+-" side effects, this warning
mode will have to be always activated for a very long period,
may be up to Scilab 7. Then, the problem is that this stopping
mode does not resolve the cause: if an up-to-date package
intentionally uses warnings for anything else than []+, it
will be stopped as well. <br>
This warning mode should accept an additional parameter
identifying the type of event (or a series/vector of events)
for which stopping must occur. Shouln't it?</li>
</ul>
</blockquote>
<br>
An other solution could be to implement and use a new <b>warning("trace")
</b>mode, instead of the rough warning("stop").<tt> warning("trace")</tt>
would display a warning + the <tt>where()</tt> or <tt>whereami() </tt>trace
locating where the warning occurs, <i>without stopping the
execution of the script</i>.<br>
This has been proposed while CodeReviewing the implementation of <tt>warning("stop"),</tt>
but has not been retained. Don't know why.<br>
<br>
If the intention of <tt>warning("stop") </tt>(instead of "only <tt>warning("trace"))
</tt>is to urge and compel users to update their codes, then the <tt>oldEmptyBehaviour
flag should not be proposed in the other hand.<br>
<br>
BR<span class="HOEnZb"><font color="#888888"><br>
Samuel<br>
<br>
</font></span></tt>
</div>
<br>_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@lists.scilab.org">dev@lists.scilab.org</a><br>
<a href="http://lists.scilab.org/mailman/listinfo/dev" rel="noreferrer" target="_blank">http://lists.scilab.org/mailman/listinfo/dev</a><br>
<br></blockquote></div><br></div>