Hi Pierre,
Le 15/07/2015 09:37, [email protected] a écrit :
.../...
but this_is_a_very_very_long_function_name() is unknown.
.
You are right! When i did successfully the trial before posting to
answer you, i used
clear this_is_a_very_very_long_function_name
before using lib, because i compiled
this_is_a_very_very_long_function_name() by hand during previous tests.
So, to be sure that the function will be loaded by lib(..) instead of
coming from a former compilation, i did this "clear..."
BUT after tests of reproducibility before answering you here, i have
just found that "clear" is bugged, and just posted that:
http://bugzilla.scilab.org/13979
!
I am unable to reproduce in Scilab 5.5.2 the formerly posted successful
story. In all ways, indeed, as you were claiming it, it fails.
These tests have shown other bugs. For instance, lib() is not (yet?)
available in YaSp (2015-07-12 release)...,
and since getd() is bugged http://bugzilla.scilab.org/13890, it turns
hard to work with YaSp.
Besides, in the help page of "genlib", it is written that "Scilab
tacitly assumes that file foo.sci defines at least a function named
foo" which is not the case here.
.
That's also right. As you certainly also tested it, other tests confirm
that.
There are other "strange" constrains with libraries. For example,
genlib() needs a library name (first argin), but when loading a library
with lib(), the genlib library name (that looks to build the "lib" file)
looks to not be used. At least, the name of the library loaded by lib
looks to depend on the name of the lhs as test_lib = lib(libdir),
instead of on the genlib libname... It would not be unpleasant to
rationalize / simplify that with Scilab 6.
Best regards
Samuel
_______________________________________________
dev mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/dev
