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-boun...@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
_______________________________________________ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users