[Scilab-users] Clone a function, continued

[Scilab-users] Clone a function, continued

Thanks Samuel, the problem is that

save('macros/%axesData_i_h.bin', '%axesData_i_h')

will produce a .sod file with a .bin extension. Both formats
cannot be used indifferently for compiled macros of a library : in
the following code (that can be copy/pasted), a library is built,
the "fun1" function is saved in sod format, then the reference to
"fun1.bin" is replaced by "fun1.sod" in the lib file :

The MD5 hash is of the content of the .sci file, that here does
not exist. It is use by genlib to check whether the .sci must be
recompiled or not. You may try to set any md5 (or the cloned
one). As long as you don't recompile the lib with genlib -- just
loading it with load() or lib() --, this should work.

My 2 cents..

Samuel

Le 28/02/2018 à 14:52, Stéphane Mottelet a écrit :

Hello,

With the new library system, it is no longer possible to clone a
function in a library. This feature is still documented in the
help page of "lib" but is not working anymore since saving a
user-defined scilab function uses the sod/hdf5 format. Maybe one
can ask why such a feature is needed ? Sometimes it can be
usefull to have a function which is callable by different names
but actually does the same thing. The different calling names
can come from the adaptation for different types of data, which
can sometimes lead to the same treatment, hence to the same
function. Instead of writing two functions with the same source
code but a different calling name, cloning the original one was
an interesting feature.

I admit that the way it worked under scilab<6.x was not clean
at all *but* officially documented in the "lib" help page. For
example, imagine that a library has just been built (e.g. the
plotlib...)

genlib('plotlib','macros')

I need to add to this library %axesData_i_h which is a clone of
generic_i_h (in overloadinglib), which can be done in
scilab<6.x by:

Re: Clone a function, continued

Le 28/02/2018 à 16:30, Stéphane
Mottelet a écrit :

Thanks Samuel, the problem is that

save('macros/%axesData_i_h.bin', '%axesData_i_h')

will produce a .sod file with a .bin extension. Both formats
cannot be used indifferently for compiled macros of a library :
in the following code (that can be copy/pasted), a library is
built, the "fun1" function is saved in sod format, then the
reference to "fun1.bin" is replaced by "fun1.sod" in the lib
file :

Re: Clone a function, continued

will produce a .sod file with a .bin extension. Both formats
cannot be used indifferently for compiled macros of a library :
in the following code (that can be copy/pasted), a library is
built, the "fun1" function is saved in sod format, then the
reference to "fun1.bin" is replaced by "fun1.sod" in the lib
file :

Re: Clone a function, continued

Le 28/02/2018 à 18:48, Samuel Gougeon a
écrit :

Le 28/02/2018 à 16:30, Stéphane
Mottelet a écrit :

Thanks Samuel, the problem is that

save('macros/%axesData_i_h.bin', '%axesData_i_h')

will produce a .sod file with a .bin extension. Both formats
cannot be used indifferently for compiled macros of a library
: in the following code (that can be copy/pasted), a library
is built, the "fun1" function is saved in sod format, then the
reference to "fun1.bin" is replaced by "fun1.sod" in the lib
file :