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

Clément David clement.david at scilab-enterprises.com
Wed Apr 20 19:35:41 CEST 2016


Hi Samuel, hi all,

> > 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 :))

As we are near the release, we decided to postpone this change after Scilab 6.0.0. I will also try
to implement a nice tag (or keyword) management to ease warning management (both in scilab and
toolboxes).
 
And also I have to write a SEP on it ;).

--
Clément




More information about the dev mailing list