[Scilab-Dev] warning("stop") or warning("trace") ?

[Eric Dubois]

Hello Samuel

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.

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.

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.

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...

Éric.

2016-03-09 17:23 GMT+01:00 Samuel Gougeon <sgougeon at free.fr>:

> Hi,
>
> Le 09/03/2016 01:18, Samuel Gougeon a écrit :
>
>
>    - warning("stop"): 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.
>    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?
>
>
> An other solution could be to implement and use a new *warning("trace") *mode,
> instead of the rough warning("stop"). warning("trace") would display a
> warning + the where() or whereami() trace locating where the warning
> occurs, *without stopping the execution of the script*.
> This has been proposed while CodeReviewing the implementation of
> warning("stop"), but has not been retained. Don't know why.
>
> If the intention of warning("stop") (instead of "only warning("trace")) is
> to urge and compel users to update their codes, then the oldEmptyBehaviour
> flag should not be proposed in the other hand.
>
> BR
> Samuel
>
>
> _______________________________________________
> 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/20160309/cce8520e/attachment.htm>