[Scilab-users] Scilab and hdf5 format (small survey)

[Scilab-users] Scilab and hdf5 format (small survey)

Hi All

I'm playing with hdf5 format into Scilab (I'm currently in an early stage that consists in understanding what the structures are); the goal is to deal with huge amount of data coming from Finite Element Analyses, and to perform additional calculations.

I'm wondering if there are a lot of people working with Hdf5 file into Scilab? in what fields?

(behind this, a goal among others is to get feedbacks from them on advantages and disadvantages).

[Scilab-users] clone a function in a library

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:

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 in a library

Another way would be to clone the source file with a hard link with your OS.
It is possible with Linux. It should be possible with powershell under
Windows.
With MacOS, i don't know. Likely possible as well. Could you confirm?
Then, try genlib() and see if it considers such a link..
In Linux, it should : all inodes are equal
In Windows: I will try, when updating the lib() and genlib() pages

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:
>
> %axesData_i_h=generic_i_h;
> save('macros/%axesData_i_h.bin',%axesData_i_h)
> mputl([mgetl('macros/names');'%axesData_i_h'],'macros/names')
>
> I said above "not clean at all", because the binary file "macros/lib"
> (which is created by the genlib call) does not need to be updated, as
> a subsequent
>
> plotlib=lib("macros")
>
> loads all functions, including %axesData_i_h
>
>
> Doing things like this is not possible any more. It was was also to
> add persistent variables in libraries, with the same mechanism.
>
> By the way, under scilab 6.0.1, the "macros/lib" is now an XML file
> with a clear syntax, e.g.
>
> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> <scilablib name="plotliblib">
> <macro name="%c_i_pltlibH" file="%c_i_pltlibH.bin"
> md5="d0966468b335a69681a29d84c99feb5c"/>
> <macro name="%figureDa_i_h" file="%figureDa_i_h.bin"
> md5="a1ebda57a1607b28095def2e415e2ec1"/>
> ...
> </scilablib>
>
> It does not seem to be documented either.
>
> S.
>
>

Re: clone a function in a library

Le 28/02/2018 à 15:17, Samuel Gougeon a écrit :
> Another way would be to clone the source file with a hard link with
> your OS.
> It is possible with Linux. It should be possible with powershell under
> Windows.
> With MacOS, i don't know. Likely possible as well. Could you confirm?
> Then, try genlib() and see if it considers such a link..
> In Linux, it should : all inodes are equal
> In Windows: I will try, when updating the lib() and genlib() pages

But it should be portable. I don't think that hard links are so..
As long as the library is not recompiled by the user, it should work.
Otherwise, hard links should be set in the module builder, before
building the library, and according to the OS...