[Scilab-users] ipcv vs scicv

[P M]

Please enlighten me....on my PC the current situation is like this:

Scilab 6.1.0

Loading order 1:
- scicv
- IPCV
--> in console: help imread

--> img = imread(filename[,flag])            // hence the imread function
from scicv is found / used (?)

-------
Loading order 2:

- IPCV
- scicv
--> in console: help imread

--> im = imread(filename)
--> im = imread(url)                         // hence the imread function
from IPCV is found / used (?)

Does this not describe what Chin Luh has mentioned?


The behaviour described above would be different, when there is:
scicv.imread
IPCV.imread

...which is indeed python-like.

Thanks for your patience.

Philipp






Am Sa., 5. Dez. 2020 um 01:56 Uhr schrieb Chin Luh Tan <tanchinluh at gmail.com
>:

> Hi Samuel,
>
> Thanks for your details explanations and examples, they are really
> helpful. Yes you're right, the functions loaded are base on what you have
> describe, not depending on the order the modules being loaded. Thanks for
> pointing this out.
>
> Regards,
> Chin Luh
>
> On Sat, 5 Dec 2020 at 02:37, Samuel Gougeon <sgougeon at free.fr> wrote:
>
>> Hello Chin Luh,
>>
>> Le 04/12/2020 à 01:57, Chin Luh Tan a écrit :
>>
>> Hi all,
>>
>> Stephane, Thanks for the quick  examples to illustrate this.
>>
>> Claus, as shown by Stephane, this could be now by ourselves now from our
>> own modules. Stephane has illustrated a quick demo on this, while the one I
>> was testing with is the copy of toolbox skeleton inside the Scilab contrib,
>> modified to 2 modules, installed with atoms and let it load at start,
>> results are the same.
>>
>> There are 2 potential issues which we should take notes:
>> 1. The module which is loaded last, will have the "dominant" in the base
>> function.
>>
>> Are you sure about this? This was the rule with Scilab 5, but the removal
>> of the variables stack changed it within Scilab 6. I noticed with Scilab
>> 6.0 that the libraries are scanned for the required function only after
>> sorting their names in anti-alphabetical order.
>> So if both alib.myfunc() and zlib.myfunc() exist, myfunc() will call
>> zlib.myfunc(), whatever is the loading order of alib and zlib.
>>
>> On this respect, neither the
>> https://help.scilab.org/docs/6.1.0/en_US/library.html page is
>> up-to-date, not other pages dealing with libraries, like the genlib().
>> Here is the test:
>>
>> File = TMPDIR+"\test\";mkdir(File+"alib");mkdir(File+"zlib");
>> code = [ "function test()" ; "    disp(""test from alib"")" ; "endfunction"];mputl(code, File+"alib\test.sci");genlib("alib", File+"alib");
>> code = [ "function test()" ; "    disp(""test from zlib"")" ; "endfunction"];mputl(code, File+"zlib\test.sci");genlib("zlib", File+"zlib");
>> clear alib zlibload(File+"zlib\lib")load(File+"alib\lib")
>> test()
>> --> test()
>>   "test from zlib"
>>
>> for e.g.: the example that Stephane showed, we could call "lib1.foo" and
>> "lib2.foo", and calling just "foo" will be the same as  "lib2.foo".
>> 2. Only macros function could be called this way, if a module has a
>> scilab gateway that called direct from Scilab, (such as scicv), you could
>> not call scicvlib.imread as the imread is directly expose from the C lib to
>> Scilab.
>>
>> This is true only if the homonymous function is called without specifying
>> its library. Otherwise, the name resolution works:
>>
>> File = TMPDIR+"\test\";mkdir(File+"alib");code = [ "function cos(a)" ; "    disp(""cos() from alib"")" ; "endfunction"];mputl(code, File+"alib\cos.sci");genlib("alib", File+"alib");clear alibload(File+"alib\lib")
>> cos(1)alib.cos(1)
>>
>>
>> --> cos(1)
>>  ans  =
>>    0.5403023
>>
>> --> alib.cos(1)
>>   "cos() from alib"
>>
>> Best regards
>> Samuel
>>
>> _______________________________________________
>> users mailing list
>> users at lists.scilab.org
>> http://lists.scilab.org/mailman/listinfo/users
>>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20201207/7f5c4921/attachment.htm>