[Scilab-users] Resolving libraries <= (no subject)

[Collewet Guylaine]

Thank you for your answer

I am in the first case I guess (in fact the two librairies are one atoms
module and one home-made scilab contribution)

When I try to call atoms1_lib.foo()  I get the error message (sorry it is
in French on my computer) : L'extraction récursive n'est pas valide dans
ce contexte.

Guylaine



De : users [mailto:users-bounces at lists.scilab.org] De la part de Samuel
Gougeon
Envoyé : vendredi 31 juillet 2015 14:13
À : International users mailing list for Scilab.
Objet : Re: [Scilab-users] Resolving libraries <= (no subject)



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/167e8534/attachment.htm>