<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hello Samuel,<br>
1. It's intentional, when a function is private, it must stay
private.<br>
2. Need time to read threads and understand the problem.<br>
3.It is a bug ! Someone forgot to read documentation before coding !
( probably me ^^ )<br>
<br>
Antoine<br>
<p>Le 14/01/2019 à 23:58, Samuel Gougeon a écrit :<br>
</p>
<blockquote type="cite"
cite="mid:e23e1ce4-de9a-7b76-10e1-561a6f935016@free.fr">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<p>Hello devs,</p>
<p>After having done it for lib() (already in a somewhat awkward
way), i would like to update the documentation for libraries and
genlib() pages for Scilab 6, as fairly <a
href="http://bugzilla.scilab.org/show_bug.cgi?id=14098"
moz-do-not-send="true">requested there</a>.<br>
However, there is no indication whether observable changes are
intentional or should be considered as bugs.<br>
Now, documenting things make them official. Therefore, the
status of changes should be made clearer by their authors.<br>
</p>
<ol>
<li>In a .sci file, functions that are defined after the main
one are now private, no longer registered in the library.<br>
There were some discussions about this new feature, early
after the first Scilab 6.0.0-alpha and beta releases.<br>
I think that we can consider this point as a new great
official feature now.<br>
<br>
</li>
<li>genlib() no longer allows to build a library including some
symbols other than functions.<br>
This change could be a consequence of the first chaneg
presented here-above.<br>
A bugzilla report could be posted about this topic, that was
somewhat presented in <a
href="http://mailinglists.scilab.org/Scilab-users-Clone-a-function-continued-tp4037723p4037728.html"
moz-do-not-send="true">this thread</a>.<br>
This point is problematic for some toolboxes.<br>
IMO, the problem is that there is no workaround. <br>
One smart way to do the same maybe in an even smarter way
would be to be able to protect variables one by one.<br>
Then, doing so would be possible in the .start file of a
module. Indeed, this genlib feature was interesting mainly --
or even only ? -- as a workaround of the unability to protect
variables.<br>
Now, when will it be possible to protect variables on the fly
in the session with Scilab 6?...<br>
<br>
</li>
<li>genlib() is no longer able to exclude any *.sci files of the
current directory to not be compiled. This is <a
href="http://bugzilla.scilab.org/show_bug.cgi?id=15919"
moz-do-not-send="true">reported there</a>. To me, if this
change is intentional, it is debatable...<br>
<br>
</li>
</ol>
<p>Looking forward to reading you</p>
<p>Samuel<br>
<br>
PS: IMO it would be better to document as many Scilab 5 =>
Scilab 6.0 changes as possible <b>before</b> Scilab 6.1.0<br>
<br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dev@lists.scilab.org">dev@lists.scilab.org</a>
<a class="moz-txt-link-freetext" href="http://lists.scilab.org/mailman/listinfo/dev">http://lists.scilab.org/mailman/listinfo/dev</a>
</pre>
</blockquote>
</body>
</html>