[Scilab-users] Resolving libraries <= (no subject)
Samuel Gougeon
sgougeon at free.fr
Fri Jul 31 14:13:12 CEST 2015
Hello Guylaine,
Le 31/07/2015 11:46, Collewet Guylaine a écrit :
>
> Hello,
>
> I want to use together two atoms modules that have some functions with
> the same names.
>
> Is there a way to indicate the name of the module I want to use when I
> call one function ?
>
If both functions -- say fun() -- are functions written in Scilab
language -- i mean none of them is a built-in function --,
then in dictinct ATOMS modules they should belong to two distinct
libraries, say atoms1_lib and atoms2_lib.
As far as i remember, the default foo() that will be called by foo() is
the one belonging to the library
that has been the most recently loaded. Anyway, to force using a
instanciation rather than the other, you
can use either atoms1_lib.foo() or atoms2_lib.foo() syntax. This forces
Scilab to use the specified library.
In case of conflict between a built-in and a function (aka "macro") : if
you define a macro with the name of
a previously loaded built-in, the macro crushes the built-in. I do not
know whether it is possible to still call
the built-in as is. But you can clone it before overwritting its first
name -- say atoms1_foo = foo (*), and then
use atoms1_foo() when required -- before crushing it with the
forthcoming foo(). Humm,
"you can" do that in an absolute way ; but if both ATOMS modules are
autoloaded, you cannot introduce
such a cloning instruction in the autoloading stack.
In such a case, you may cancel autoloading for both modules, and add
loading and cloning instructions in
the your personal startup file.
HTH
Samuel
(*) this way of doing becomes the only one possible in Scilab 6, because
newfun() and funptr() are being
removed from SCilab 6. But i met some cases for which this kind of
cloning failed, while it was OK when
cloning with newfun("atoms1_foo", funptr("foo")). I did not clearly
caught from where and when it occurred
-- may be when foo is used recursively.. --, but after some
investigations i found that (still in scilab 5.5.2):
// after
-->funptr("disp")
ans =
33004.
-->d = disp
d =
-->funptr("d")
ans =
0.
-->clear d
-->newfun("d", funptr("disp"))
-->funptr("d")
ans =
33004.
It is somewhat reported there: http://bugzilla.scilab.org/12965
About effects of cloning built-in:=, see also
http://bugzilla.scilab.org/8281
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20150731/cf7633d9/attachment.htm>
More information about the users
mailing list