[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