[Scilab-Dev] [warning()] Extending management mode for a specific message

Samuel Gougeon sgougeon at free.fr
Fri Apr 8 13:43:18 CEST 2016


Hello Clément,

Le 08/04/2016 11:13, Clément David a écrit :
> Hello Samuel and good in depth analysis,
>
> To summarize :
>
> Le vendredi 08 avril 2016 à 01:11 +0200, Samuel Gougeon a écrit :
>> 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.
> Yep exactly, initially I thought about that "tag" or "simplified message" but discarded it due to
> the complexity of such a feature and the approaching Scilab 6 release. My need was just to hide the
> []+"" warning temporarly on some user code to check the tests.


So, if you keep the feature, and keep it as is, imo it should not be 
officially documented

>> The ["do", instructions] feature does not need such a table. It could already be a great
>> improvement,
>> with warning() overloading.
> Yep I will try to add that instead of the "stop" feature. The complexity is the same and it will be
> easier to manage.
>
> About the naming, I prefer a "execstr" instead of "do" but it might also be possible to simply pass
> a function that will be called on warning (similarly to uicontrol's callback). What do you prefer ?

Not using "execstr" would keep the warning message mandatory -- possibly 
empty "": Why not, ok
(but then "" would still display the "WARNING:" header, while we could 
wish to remove it to fully
customize the display.).
Then, it shall become possible to provide any series of instructions, 
not only the name of a callback function.

Future evolutions and adding argins should not be blocked/made hard due 
to hard argin list analysis.

About the warning level=notices level: i wondered about this recent post 
on users@ about removing
the verbosity of the external modules loading procedure, as an example. 
(by the way, a "modulesload"
common tag would be nice :))

Regards
Samuel




More information about the dev mailing list