<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Le 26/04/2021 à 14:15, Stéphane
Mottelet a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:26a6b036-7a07-430d-be95-fab451a2257f@utc.fr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<blockquote type="cite"
cite="mid:b85299ec-de54-4477-dfa2-c76157623207@free.fr">.../...<br>
<p>Such a wish was reported 10 years ago as <a
moz-do-not-send="true"
href="https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=6801">bug
6801</a>.<br>
<br>
To me, the only way to overcome any mprintf or disp made in
*.start files of external modules would be to become able to
redirect the standard output to null (or anywhere else as in a
file, as with diary, that forks the stream instead of
redirecting it).<br>
I don't think that %toolboxes aims to become public.
atomsGetInstalled() and atomsGetLoaded() (and others) would
likely be more suited to test the atoms status.</p>
For contribution,<br>
Samuel<br>
</blockquote>
<p>Yeah that's the idea. But better than redirection of the
standard output, all the stuff displayed in the .start file
should go in a Journal, to which display methods can be
associated. So instead of explicitely calling disp or mprinf,
etc. the .start script should just add some stuff + associated
verbosity level to the journal. What would be actually really
displayed will depend on the level of the used Journal. That's
the way the output is controlled in Ipopt, for example (but at
the C++ level).<br>
</p>
</blockquote>
<p>We can't prevent authors to actually add and use mprintf or/and
disp in their .start external file. They will be always free to
use such statements in the .start file template instanciated for
their actual toolbox.<br>
Now, if for instance a special syntax and parsing on .start
comments is proposed, it could be comprehensive enough to be
actually and exclusively used.<br>
But, likely, only static information would be possible in
comments. Formatted information like with printf placeholders
could not be provided.<br>
</p>
<p>By the way, i am not sure that the most compact display should be
the default mode. Out of the only module name, information
displayed when loading might be important.<br>
<br>
We tend to consider these displays as boring. But i am wondering
that this is because loading can be quite long... unrelated to the
display.<br>
When working afterward in the session, any displayed matrix or
handle gets most often immediately taller in the console than any
initial autoloading information (that occurs only once).<br>
So, to me, this is not really critical.<br>
<br>
</p>
</body>
</html>