Re: [Scilab-users] Unable to update ATOMS packages - Scilab 6.0.1

2018-10-18 Thread Pndsc 
Blank window - sometimes the buttons themselves arent displayed but will
spawn when the mouse cursor goes over them.

https://imgur.com/a/lxdokm1

>Maybe the fix I proposed you (the export MESA_GL_VERSION_OVERRIDE=3.0 ;
>) is not exactly what you need. Someone told me to try to limit the mesa
>gl version to use, but the optimal value might be different for you. You
>might try to experiment different values. 

It seems that this might have been a superfluous thing - the nightly build
scilab is the one that gives me a libgfortran error and refuses to start.
Conventional 6.0.1 starts fine but doesnt display any graphs. 




--
Sent from: 
http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] HDF5 save is super slow

2018-10-18 Thread Clément DAVID 
> > Why is the code for structs (lines 242--74)  commented out ? Is it 
> > broken or else ?
> If var2vec() / vec2var() could be extended to provide a universal way to 
> serialize / deserialize really any scilab variable, that would be really nice.
> Could we make a SEP or fill a bug as a wish ?

Yep I have no problem to allocate a SEP for that, vec2var / var2vec might be 
used elsewhere but the format need to be documented for all managed types. 
Handle, for example, will probably not be stored at first. A SEP might even be 
good to define the real need for that "a Scilab variable dump for cheap and 
fast access" and to clearly state that this encoding might change across OS, 
hardware or Scilab versions.

Are you interested in writing it ?  

Thanks,

--
Clément
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] HDF5 save is super slow

2018-10-18 Thread Stéphane Mottelet 

Le 18/10/2018 à 15:51, Clément DAVID a écrit :

Hello Stephane,

Probably commented out as we have no easy way to extract such data easily using 
only C constructs (from a Scicos block). It might be possible to uncomment and 
check the counterpart side (vec2var.cpp) to ensure it works correctly.

only single structs are supported, likely.

S.


Thanks,

--
Clément

-Original Message-
From: users  On Behalf Of Stéphane Mottelet
Sent: Thursday, October 18, 2018 3:01 PM
To: users@lists.scilab.org
Subject: Re: [Scilab-users] HDF5 save is super slow

Hello again,

Le 18/10/2018 à 14:56, Clément David a écrit :

Hi Antoine,

That one point, vec2var has been defined to pass some datatypes from Scilab "ast" (C++ 
side, data pointers, refcounted) to Scilab "scicos" (C, raw memory allocated once and 
passed around). Some data structures might not be handled correctly, I was even surprised that 
mlists worked correctly.

Scilab Struct (or Cell) are missing as they are more complex datatypes
to serialize. Handle are even harder (as you need to list the
properties somewhere). Feel free to take a look at the code [1],

[1]:
https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/cgit.
scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/var2vec.cpp?h=6.0
#n243

Why is the code for structs (lines 242--74)  commented out ? Is it broken or 
else ?


Cheers,
--
Clément

-Original Message-
From: antoine monmayrant 
Sent: Thursday, October 18, 2018 2:47 PM
To: Clément DAVID ; Users
mailing list for Scilab 
Cc: Clément David 
Subject: Re: [Scilab-users] HDF5 save is super slow



Le 18/10/2018 à 14:09, Clément DAVID a écrit :

Hello,

My 2cents, this is probably a poor man’s approach but Xcos offers vec2var / 
var2vec functions that encode in a double vector any Scilab datatypes passed as 
arguments. The encoding duplicates the data in memory so there might be some 
overhead.

Er, I tried var2vec, but it does not work with structures:
--> typeof(t)
    ans  =
    st

--> var2vec(t)
var2vec: Wrong type for input argument #1: Double, Integer, Boolean, String or 
List type.

Arghh... so var2vec does not work for any datatype right?

Antoine

On my machine, I have these timings using the attached script (Antoine’s one 
edited):
save list of syslins: 1.361704
save list of vec[]: 0.056788
save var2vec(list of syslins): 0.014411

Discarding hdf5 groups creation is a huge performance win but remove any way to 
create clean hdf5 (eg. to address subgroups directly).

Thanks,

--
Clément

From: users  On Behalf Of Arvid Rosén
Sent: Tuesday, October 16, 2018 1:01 PM
To: antoine.monmayr...@laas.fr; Users mailing list for Scilab

Subject: Re: [Scilab-users] HDF5 save is super slow

From: users
mailto:users-boun...@lists.scilab.org

on behalf of "amonm...@laas.fr"

mailto:amonm...@laas.fr>>
Reply-To:
"antoine.monmayr...@laas.fr"
mailto:antoine.monmayr...@laas.fr>>,
Users mailing list for Scilab
mailto:users@lists.scilab.org>>
Date: Tuesday, 16 October 2018 at 09:53
To: "users@lists.scilab.org"
mailto:users@lists.scilab.org>>
Subject: Re: [Scilab-users] HDF5 save is super slow

Couldn't you create your own atom package that restore this raw memory dump for 
scilab 6.0?
I understand why we moved away from this model, but it seems to be key for you.
There is always a trade-off between portability (and robustness) and raw 
speed...

Yeah, if that was possible, I would certainly do it. We already have a bunch of 
C/C++ binaries that we compile and link dynamically, but for that to be easy to 
implement, I guess the lists and structures need to be stored linearly in one 
consecutive chunk of memory. I don’t know if that is the case. Anyone? C++ 
integrations and gateways are very poorly documented at the moment.
Otherwise, I would need to do some recursive implementation, that handles a 
bunch of different object types. Sounds painful.

Cheers,
Arvid

___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists
.scilab.org/mailman/listinfo/users


--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable Département Génie 
des Procédés Industriels Sorbonne Universités - Université de Technologie de 
Compiègne CS 60319, 60203 Compiègne cedex Tel : +33(0)344234688 
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.utc.fr/~mottelet

___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
___
users mailing list
users@lists.scilab.org

Re: [Scilab-users] HDF5 save is super slow

2018-10-18 Thread Clément DAVID 
Hello Stephane,

Probably commented out as we have no easy way to extract such data easily using 
only C constructs (from a Scicos block). It might be possible to uncomment and 
check the counterpart side (vec2var.cpp) to ensure it works correctly.

Thanks,

--
Clément 

-Original Message-
From: users  On Behalf Of Stéphane Mottelet
Sent: Thursday, October 18, 2018 3:01 PM
To: users@lists.scilab.org
Subject: Re: [Scilab-users] HDF5 save is super slow

Hello again,

Le 18/10/2018 à 14:56, Clément David a écrit :
> Hi Antoine,
>
> That one point, vec2var has been defined to pass some datatypes from Scilab 
> "ast" (C++ side, data pointers, refcounted) to Scilab "scicos" (C, raw memory 
> allocated once and passed around). Some data structures might not be handled 
> correctly, I was even surprised that mlists worked correctly.
>
> Scilab Struct (or Cell) are missing as they are more complex datatypes 
> to serialize. Handle are even harder (as you need to list the 
> properties somewhere). Feel free to take a look at the code [1],
>
> [1]: 
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/cgit.
> scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/var2vec.cpp?h=6.0
> #n243
Why is the code for structs (lines 242--74)  commented out ? Is it broken or 
else ?

> Cheers,
> --
> Clément
>
> -Original Message-
> From: antoine monmayrant 
> Sent: Thursday, October 18, 2018 2:47 PM
> To: Clément DAVID ; Users 
> mailing list for Scilab 
> Cc: Clément David 
> Subject: Re: [Scilab-users] HDF5 save is super slow
>
>
>
> Le 18/10/2018 à 14:09, Clément DAVID a écrit :
>> Hello,
>>
>> My 2cents, this is probably a poor man’s approach but Xcos offers vec2var / 
>> var2vec functions that encode in a double vector any Scilab datatypes passed 
>> as arguments. The encoding duplicates the data in memory so there might be 
>> some overhead.
> Er, I tried var2vec, but it does not work with structures:
> --> typeof(t)
>    ans  =
>    st
>
> --> var2vec(t)
> var2vec: Wrong type for input argument #1: Double, Integer, Boolean, String 
> or List type.
>
> Arghh... so var2vec does not work for any datatype right?
>
> Antoine
>> On my machine, I have these timings using the attached script (Antoine’s one 
>> edited):
>> save list of syslins: 1.361704
>> save list of vec[]: 0.056788
>> save var2vec(list of syslins): 0.014411
>>
>> Discarding hdf5 groups creation is a huge performance win but remove any way 
>> to create clean hdf5 (eg. to address subgroups directly).
>>
>> Thanks,
>>
>> --
>> Clément
>>
>> From: users  On Behalf Of Arvid Rosén
>> Sent: Tuesday, October 16, 2018 1:01 PM
>> To: antoine.monmayr...@laas.fr; Users mailing list for Scilab 
>> 
>> Subject: Re: [Scilab-users] HDF5 save is super slow
>>
>> From: users
>> mailto:users-boun...@lists.scilab.org
>> >
>>> on behalf of "amonm...@laas.fr"
>> mailto:amonm...@laas.fr>>
>> Reply-To:
>> "antoine.monmayr...@laas.fr"
>> mailto:antoine.monmayr...@laas.fr>>, 
>> Users mailing list for Scilab 
>> mailto:users@lists.scilab.org>>
>> Date: Tuesday, 16 October 2018 at 09:53
>> To: "users@lists.scilab.org"
>> mailto:users@lists.scilab.org>>
>> Subject: Re: [Scilab-users] HDF5 save is super slow
>>
>> Couldn't you create your own atom package that restore this raw memory dump 
>> for scilab 6.0?
>> I understand why we moved away from this model, but it seems to be key for 
>> you.
>> There is always a trade-off between portability (and robustness) and raw 
>> speed...
>>
>> Yeah, if that was possible, I would certainly do it. We already have a bunch 
>> of C/C++ binaries that we compile and link dynamically, but for that to be 
>> easy to implement, I guess the lists and structures need to be stored 
>> linearly in one consecutive chunk of memory. I don’t know if that is the 
>> case. Anyone? C++ integrations and gateways are very poorly documented at 
>> the moment.
>> Otherwise, I would need to do some recursive implementation, that handles a 
>> bunch of different object types. Sounds painful.
>>
>> Cheers,
>> Arvid
> ___
> users mailing list
> users@lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists
> .scilab.org/mailman/listinfo/users


--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable Département Génie 
des Procédés Industriels Sorbonne Universités - Université de Technologie de 
Compiègne CS 60319, 60203 Compiègne cedex Tel : +33(0)344234688 
http://www.utc.fr/~mottelet

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] HDF5 save is super slow

2018-10-18 Thread Clément DAVID 
Hello Stephane,

TL ;DR ; HDF5 is a cross-platform, cross-language, portable file format used in 
almost all scientific software these days. Please use this sane default !

Writing a custom serialization scheme (like the one provided by vec2var / 
var2vec) might not be complicated to implement however the hard part is 
maintaining and describing a serialization format to be used in the long term.

Using Scilab 5, the “stack” save and load functions were almost trivial as they 
are directly mapped from memory to disk; the format used is “the stack” so it 
is known and used everywhere (even for custom string encoding). This vec2var 
serialization is only used internally (to pass block parameters around), does 
not respect any described format nor validate against any documentation and is 
not portable; in the long term, I won’t promise it to be stable. Implementing 
your own serialization scheme will probably lead your software into trouble. 
Really, it isn’t easy in the long term! The HDF5 format is described, its 
serialized data are browsable (through hdfview) and does not cope with 
low-level requirements.

To me, the issue is really a performance bug. We might find a way to fix it 
within Scilab rather than provide a workaround (with custom encodings). The 
hdf5 library is a bug one, maybe with a clever understanding of its internal 
serialization, we might find a better execution path for this use-case (without 
changing the file format).

Thanks,

--
Clément

From: users  On Behalf Of Stéphane Mottelet
Sent: Thursday, October 18, 2018 2:39 PM
To: users@lists.scilab.org
Subject: Re: [Scilab-users] HDF5 save is super slow

Hello Clément,

Le 18/10/2018 à 14:09, Clément DAVID a écrit :
Hello,

My 2cents, this is probably a poor man’s approach but Xcos offers vec2var / 
var2vec functions that encode in a double vector any Scilab datatypes passed as 
arguments. The encoding duplicates the data in memory so there might be some 
overhead.
Do you think it would be complicated to continuously write the serialized data 
on the disk ?

On my machine, I have these timings using the attached script (Antoine’s one 
edited):
save list of syslins: 1.361704
save list of vec[]: 0.056788
save var2vec(list of syslins): 0.014411

Discarding hdf5 groups creation is a huge performance win but remove any way to 
create clean hdf5 (eg. to address subgroups directly).

Thanks,

--
Clément

From: users 
 On 
Behalf Of Arvid Rosén
Sent: Tuesday, October 16, 2018 1:01 PM
To: antoine.monmayr...@laas.fr; Users 
mailing list for Scilab 
Subject: Re: [Scilab-users] HDF5 save is super slow

From: users 
mailto:users-boun...@lists.scilab.org>> on 
behalf of "amonm...@laas.fr" 
mailto:amonm...@laas.fr>>
Reply-To: "antoine.monmayr...@laas.fr" 
mailto:antoine.monmayr...@laas.fr>>, Users mailing 
list for Scilab mailto:users@lists.scilab.org>>
Date: Tuesday, 16 October 2018 at 09:53
To: "users@lists.scilab.org" 
mailto:users@lists.scilab.org>>
Subject: Re: [Scilab-users] HDF5 save is super slow

Couldn't you create your own atom package that restore this raw memory dump for 
scilab 6.0?
I understand why we moved away from this model, but it seems to be key for you.
There is always a trade-off between portability (and robustness) and raw 
speed...

Yeah, if that was possible, I would certainly do it. We already have a bunch of 
C/C++ binaries that we compile and link dynamically, but for that to be easy to 
implement, I guess the lists and structures need to be stored linearly in one 
consecutive chunk of memory. I don’t know if that is the case. Anyone? C++ 
integrations and gateways are very poorly documented at the moment.
Otherwise, I would need to do some recursive implementation, that handles a 
bunch of different object types. Sounds painful.

Cheers,
Arvid




___

users mailing list

users@lists.scilab.org

https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users



--

Stéphane Mottelet

Ingénieur de recherche

EA 4297 Transformations Intégrées de la Matière Renouvelable

Département Génie des Procédés Industriels

Sorbonne Universités - Université de Technologie de Compiègne

CS 60319, 60203 Compiègne cedex

Tel : +33(0)344234688

http://www.utc.fr/~mottelet
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] HDF5 save is super slow

2018-10-18 Thread amonmayr 

Le 18/10/2018 à 15:00, Stéphane Mottelet a écrit :

Hello again,

Le 18/10/2018 à 14:56, Clément David a écrit :

Hi Antoine,

That one point, vec2var has been defined to pass some datatypes from 
Scilab "ast" (C++ side, data pointers, refcounted) to Scilab "scicos" 
(C, raw memory allocated once and passed around). Some data 
structures might not be handled correctly, I was even surprised that 
mlists worked correctly.


Scilab Struct (or Cell) are missing as they are more complex 
datatypes to serialize. Handle are even harder (as you need to list 
the properties somewhere). Feel free to take a look at the code [1],


[1]: 
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/var2vec.cpp?h=6.0#n243
Why is the code for structs (lines 242--74)  commented out ? Is it 
broken or else ?
If var2vec() / vec2var() could be extended to provide a universal way to 
serialize / deserialize really any scilab variable, that would be really 
nice.

Could we make a SEP or fill a bug as a wish ?

Antoine



Cheers,
--
Clément

-Original Message-
From: antoine monmayrant 
Sent: Thursday, October 18, 2018 2:47 PM
To: Clément DAVID ; Users 
mailing list for Scilab 

Cc: Clément David 
Subject: Re: [Scilab-users] HDF5 save is super slow



Le 18/10/2018 à 14:09, Clément DAVID a écrit :

Hello,

My 2cents, this is probably a poor man’s approach but Xcos offers 
vec2var / var2vec functions that encode in a double vector any 
Scilab datatypes passed as arguments. The encoding duplicates the 
data in memory so there might be some overhead.

Er, I tried var2vec, but it does not work with structures:
--> typeof(t)
   ans  =
   st

--> var2vec(t)
var2vec: Wrong type for input argument #1: Double, Integer, Boolean, 
String or List type.


Arghh... so var2vec does not work for any datatype right?

Antoine
On my machine, I have these timings using the attached script 
(Antoine’s one edited):

save list of syslins: 1.361704
save list of vec[]: 0.056788
save var2vec(list of syslins): 0.014411

Discarding hdf5 groups creation is a huge performance win but remove 
any way to create clean hdf5 (eg. to address subgroups directly).


Thanks,

--
Clément

From: users  On Behalf Of Arvid Rosén
Sent: Tuesday, October 16, 2018 1:01 PM
To: antoine.monmayr...@laas.fr; Users mailing list for Scilab

Subject: Re: [Scilab-users] HDF5 save is super slow

From: users
mailto:users-boun...@lists.scilab.org>

on behalf of "amonm...@laas.fr"

mailto:amonm...@laas.fr>>
Reply-To:
"antoine.monmayr...@laas.fr"
mailto:antoine.monmayr...@laas.fr>>, Users
mailing list for Scilab
mailto:users@lists.scilab.org>>
Date: Tuesday, 16 October 2018 at 09:53
To: "users@lists.scilab.org"
mailto:users@lists.scilab.org>>
Subject: Re: [Scilab-users] HDF5 save is super slow

Couldn't you create your own atom package that restore this raw 
memory dump for scilab 6.0?
I understand why we moved away from this model, but it seems to be 
key for you.
There is always a trade-off between portability (and robustness) and 
raw speed...


Yeah, if that was possible, I would certainly do it. We already have 
a bunch of C/C++ binaries that we compile and link dynamically, but 
for that to be easy to implement, I guess the lists and structures 
need to be stored linearly in one consecutive chunk of memory. I 
don’t know if that is the case. Anyone? C++ integrations and 
gateways are very poorly documented at the moment.
Otherwise, I would need to do some recursive implementation, that 
handles a bunch of different object types. Sounds painful.


Cheers,
Arvid

___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users 






--
+++

 Antoine Monmayrant LAAS - CNRS
 7 avenue du Colonel Roche
 BP 54200
 31031 TOULOUSE Cedex 4
 FRANCE

 Tel:+33 5 61 33 64 59
 
 email : antoine.monmayr...@laas.fr

 permanent email : antoine.monmayr...@polytechnique.org

+++

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] HDF5 save is super slow

2018-10-18 Thread Stéphane Mottelet 

Hello again,

Le 18/10/2018 à 14:56, Clément David a écrit :

Hi Antoine,

That one point, vec2var has been defined to pass some datatypes from Scilab "ast" (C++ 
side, data pointers, refcounted) to Scilab "scicos" (C, raw memory allocated once and 
passed around). Some data structures might not be handled correctly, I was even surprised that 
mlists worked correctly.

Scilab Struct (or Cell) are missing as they are more complex datatypes to 
serialize. Handle are even harder (as you need to list the properties 
somewhere). Feel free to take a look at the code [1],

[1]: 
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/var2vec.cpp?h=6.0#n243
Why is the code for structs (lines 242--74)  commented out ? Is it 
broken or else ?



Cheers,
--
Clément

-Original Message-
From: antoine monmayrant 
Sent: Thursday, October 18, 2018 2:47 PM
To: Clément DAVID ; Users mailing list for 
Scilab 
Cc: Clément David 
Subject: Re: [Scilab-users] HDF5 save is super slow



Le 18/10/2018 à 14:09, Clément DAVID a écrit :

Hello,

My 2cents, this is probably a poor man’s approach but Xcos offers vec2var / 
var2vec functions that encode in a double vector any Scilab datatypes passed as 
arguments. The encoding duplicates the data in memory so there might be some 
overhead.

Er, I tried var2vec, but it does not work with structures:
--> typeof(t)
   ans  =
   st

--> var2vec(t)
var2vec: Wrong type for input argument #1: Double, Integer, Boolean, String or 
List type.

Arghh... so var2vec does not work for any datatype right?

Antoine

On my machine, I have these timings using the attached script (Antoine’s one 
edited):
save list of syslins: 1.361704
save list of vec[]: 0.056788
save var2vec(list of syslins): 0.014411

Discarding hdf5 groups creation is a huge performance win but remove any way to 
create clean hdf5 (eg. to address subgroups directly).

Thanks,

--
Clément

From: users  On Behalf Of Arvid Rosén
Sent: Tuesday, October 16, 2018 1:01 PM
To: antoine.monmayr...@laas.fr; Users mailing list for Scilab

Subject: Re: [Scilab-users] HDF5 save is super slow

From: users
mailto:users-boun...@lists.scilab.org>

on behalf of "amonm...@laas.fr"

mailto:amonm...@laas.fr>>
Reply-To:
"antoine.monmayr...@laas.fr"
mailto:antoine.monmayr...@laas.fr>>, Users
mailing list for Scilab
mailto:users@lists.scilab.org>>
Date: Tuesday, 16 October 2018 at 09:53
To: "users@lists.scilab.org"
mailto:users@lists.scilab.org>>
Subject: Re: [Scilab-users] HDF5 save is super slow

Couldn't you create your own atom package that restore this raw memory dump for 
scilab 6.0?
I understand why we moved away from this model, but it seems to be key for you.
There is always a trade-off between portability (and robustness) and raw 
speed...

Yeah, if that was possible, I would certainly do it. We already have a bunch of 
C/C++ binaries that we compile and link dynamically, but for that to be easy to 
implement, I guess the lists and structures need to be stored linearly in one 
consecutive chunk of memory. I don’t know if that is the case. Anyone? C++ 
integrations and gateways are very poorly documented at the moment.
Otherwise, I would need to do some recursive implementation, that handles a 
bunch of different object types. Sounds painful.

Cheers,
Arvid

___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users



--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] HDF5 save is super slow

2018-10-18 Thread Clément David 
Hi Antoine,

That one point, vec2var has been defined to pass some datatypes from Scilab 
"ast" (C++ side, data pointers, refcounted) to Scilab "scicos" (C, raw memory 
allocated once and passed around). Some data structures might not be handled 
correctly, I was even surprised that mlists worked correctly.

Scilab Struct (or Cell) are missing as they are more complex datatypes to 
serialize. Handle are even harder (as you need to list the properties 
somewhere). Feel free to take a look at the code [1],

[1]: 
http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/var2vec.cpp?h=6.0#n243

Cheers,
--
Clément

-Original Message-
From: antoine monmayrant  
Sent: Thursday, October 18, 2018 2:47 PM
To: Clément DAVID ; Users mailing list 
for Scilab 
Cc: Clément David 
Subject: Re: [Scilab-users] HDF5 save is super slow



Le 18/10/2018 à 14:09, Clément DAVID a écrit :
> Hello,
>
> My 2cents, this is probably a poor man’s approach but Xcos offers vec2var / 
> var2vec functions that encode in a double vector any Scilab datatypes passed 
> as arguments. The encoding duplicates the data in memory so there might be 
> some overhead.
Er, I tried var2vec, but it does not work with structures:
--> typeof(t)
  ans  =
  st

--> var2vec(t)
var2vec: Wrong type for input argument #1: Double, Integer, Boolean, String or 
List type.

Arghh... so var2vec does not work for any datatype right?

Antoine
>
> On my machine, I have these timings using the attached script (Antoine’s one 
> edited):
> save list of syslins: 1.361704
> save list of vec[]: 0.056788
> save var2vec(list of syslins): 0.014411
>
> Discarding hdf5 groups creation is a huge performance win but remove any way 
> to create clean hdf5 (eg. to address subgroups directly).
>
> Thanks,
>
> --
> Clément
>
> From: users  On Behalf Of Arvid Rosén
> Sent: Tuesday, October 16, 2018 1:01 PM
> To: antoine.monmayr...@laas.fr; Users mailing list for Scilab 
> 
> Subject: Re: [Scilab-users] HDF5 save is super slow
>
> From: users 
> mailto:users-boun...@lists.scilab.org>
> > on behalf of "amonm...@laas.fr" 
> mailto:amonm...@laas.fr>>
> Reply-To: 
> "antoine.monmayr...@laas.fr" 
> mailto:antoine.monmayr...@laas.fr>>, Users 
> mailing list for Scilab 
> mailto:users@lists.scilab.org>>
> Date: Tuesday, 16 October 2018 at 09:53
> To: "users@lists.scilab.org" 
> mailto:users@lists.scilab.org>>
> Subject: Re: [Scilab-users] HDF5 save is super slow
>
> Couldn't you create your own atom package that restore this raw memory dump 
> for scilab 6.0?
> I understand why we moved away from this model, but it seems to be key for 
> you.
> There is always a trade-off between portability (and robustness) and raw 
> speed...
>
> Yeah, if that was possible, I would certainly do it. We already have a bunch 
> of C/C++ binaries that we compile and link dynamically, but for that to be 
> easy to implement, I guess the lists and structures need to be stored 
> linearly in one consecutive chunk of memory. I don’t know if that is the 
> case. Anyone? C++ integrations and gateways are very poorly documented at the 
> moment.
> Otherwise, I would need to do some recursive implementation, that handles a 
> bunch of different object types. Sounds painful.
>
> Cheers,
> Arvid

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] HDF5 save is super slow

2018-10-18 Thread antoine monmayrant 



Le 18/10/2018 à 14:09, Clément DAVID a écrit :

Hello,

My 2cents, this is probably a poor man’s approach but Xcos offers vec2var / 
var2vec functions that encode in a double vector any Scilab datatypes passed as 
arguments. The encoding duplicates the data in memory so there might be some 
overhead.

Er, I tried var2vec, but it does not work with structures:
--> typeof(t)
 ans  =
 st

--> var2vec(t)
var2vec: Wrong type for input argument #1: Double, Integer, Boolean, 
String or List type.


Arghh... so var2vec does not work for any datatype right?

Antoine


On my machine, I have these timings using the attached script (Antoine’s one 
edited):
save list of syslins: 1.361704
save list of vec[]: 0.056788
save var2vec(list of syslins): 0.014411

Discarding hdf5 groups creation is a huge performance win but remove any way to 
create clean hdf5 (eg. to address subgroups directly).

Thanks,

--
Clément

From: users  On Behalf Of Arvid Rosén
Sent: Tuesday, October 16, 2018 1:01 PM
To: antoine.monmayr...@laas.fr; Users mailing list for Scilab 

Subject: Re: [Scilab-users] HDF5 save is super slow

From: users mailto:users-boun...@lists.scilab.org>> on behalf of 
"amonm...@laas.fr" mailto:amonm...@laas.fr>>
Reply-To: "antoine.monmayr...@laas.fr" 
mailto:antoine.monmayr...@laas.fr>>, Users mailing list for Scilab 
mailto:users@lists.scilab.org>>
Date: Tuesday, 16 October 2018 at 09:53
To: "users@lists.scilab.org" 
mailto:users@lists.scilab.org>>
Subject: Re: [Scilab-users] HDF5 save is super slow

Couldn't you create your own atom package that restore this raw memory dump for 
scilab 6.0?
I understand why we moved away from this model, but it seems to be key for you.
There is always a trade-off between portability (and robustness) and raw 
speed...

Yeah, if that was possible, I would certainly do it. We already have a bunch of 
C/C++ binaries that we compile and link dynamically, but for that to be easy to 
implement, I guess the lists and structures need to be stored linearly in one 
consecutive chunk of memory. I don’t know if that is the case. Anyone? C++ 
integrations and gateways are very poorly documented at the moment.
Otherwise, I would need to do some recursive implementation, that handles a 
bunch of different object types. Sounds painful.

Cheers,
Arvid


___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] HDF5 save is super slow

2018-10-18 Thread Stéphane Mottelet 

Hello Clément,

Le 18/10/2018 à 14:09, Clément DAVID a écrit :


Hello,

My 2cents, this is probably a poor man’s approach but Xcos offers 
vec2var / var2vec functions that encode in a double vector any Scilab 
datatypes passed as arguments. The encoding duplicates the data in 
memory so there might be some overhead.


Do you think it would be complicated to continuously write the 
serialized data on the disk ?


On my machine, I have these timings using the attached script 
(Antoine’s one edited):


save _list_ of _syslins_: 1.361704

save _list_ of vec[]: 0.056788

save var2vec(list of _syslins_): 0.014411

Discarding hdf5 groups creation is a huge performance win but remove 
_any way_ to create clean hdf5 (eg. to address subgroups directly).


Thanks,

--

Clément

*From:*users  *On Behalf Of *Arvid Rosén
*Sent:* Tuesday, October 16, _2018_ 1:01 PM
*To:* antoine.monmayr...@laas.fr; Users mailing list for Scilab 


*Subject:* Re: [Scilab-users] HDF5 save is super slow

*From: *users > on behalf of 
"amonm...@laas.fr " >
*Reply-To: *"antoine.monmayr...@laas.fr 
" >, Users mailing list for Scilab 
mailto:users@lists.scilab.org>>

*Date: *Tuesday, 16 October 2018 at 09:53
*To: *"users@lists.scilab.org " 
mailto:users@lists.scilab.org>>

*Subject: *Re: [Scilab-users] HDF5 save is super slow

Couldn't you create your own atom package that _restore_ this raw 
memory dump for _scilab_ 6.0?
I understand why we moved away from this model, but it seems to be key 
for you.
There is always a trade-off between portability (and robustness) and 
raw speed...


Yeah, if that was possible, I would certainly do it. We already have a 
bunch of C/C++ binaries that we compile and link dynamically, but for 
that to be easy to implement, I guess the lists and structures need to 
be stored linearly in one consecutive chunk of memory. I don’t know if 
that is the case. Anyone? C++ integrations and gateways are very 
poorly documented at the moment.


Otherwise, I would need to do some recursive implementation, that 
handles a bunch of different object types. Sounds painful.


Cheers,

Arvid



___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users



--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] HDF5 save is super slow

2018-10-18 Thread Clément DAVID 
Hello,

My 2cents, this is probably a poor man’s approach but Xcos offers vec2var / 
var2vec functions that encode in a double vector any Scilab datatypes passed as 
arguments. The encoding duplicates the data in memory so there might be some 
overhead.

On my machine, I have these timings using the attached script (Antoine’s one 
edited):
save list of syslins: 1.361704
save list of vec[]: 0.056788
save var2vec(list of syslins): 0.014411

Discarding hdf5 groups creation is a huge performance win but remove any way to 
create clean hdf5 (eg. to address subgroups directly).

Thanks,

--
Clément

From: users  On Behalf Of Arvid Rosén
Sent: Tuesday, October 16, 2018 1:01 PM
To: antoine.monmayr...@laas.fr; Users mailing list for Scilab 

Subject: Re: [Scilab-users] HDF5 save is super slow

From: users 
mailto:users-boun...@lists.scilab.org>> on 
behalf of "amonm...@laas.fr" 
mailto:amonm...@laas.fr>>
Reply-To: "antoine.monmayr...@laas.fr" 
mailto:antoine.monmayr...@laas.fr>>, Users mailing 
list for Scilab mailto:users@lists.scilab.org>>
Date: Tuesday, 16 October 2018 at 09:53
To: "users@lists.scilab.org" 
mailto:users@lists.scilab.org>>
Subject: Re: [Scilab-users] HDF5 save is super slow

Couldn't you create your own atom package that restore this raw memory dump for 
scilab 6.0?
I understand why we moved away from this model, but it seems to be key for you.
There is always a trade-off between portability (and robustness) and raw 
speed...

Yeah, if that was possible, I would certainly do it. We already have a bunch of 
C/C++ binaries that we compile and link dynamically, but for that to be easy to 
implement, I guess the lists and structures need to be stored linearly in one 
consecutive chunk of memory. I don’t know if that is the case. Anyone? C++ 
integrations and gateways are very poorly documented at the moment.
Otherwise, I would need to do some recursive implementation, that handles a 
bunch of different object types. Sounds painful.

Cheers,
Arvid


sample.sce
Description: sample.sce
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] How to Install SCILAB 5.5.2 on Ubuntu 18.04

2018-10-18 Thread Samuel Enibe 
I have installed SCILAB 6.0.1 on Ubuntu 18.04 but it is experiencing so
many problems. One of these is the inability to Install modules from ATOMS.

To circumvent this problem, I downloaded the binary version of 5.5.2 and
installed it using the instructions on SCILAB wiki. Unfortunately, the
installation does not work at all.

Is there another way of doing the installation of 5.5.2?

Thank you very much.

God bless you.

Samuel Enibe
University of Nigeria Nsukka
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] uicontrol TABLE

2018-10-18 Thread Izabela Wójcik-Grząba 

Hello,

Sorry for returning to the topic of editting uicontrol Table but I still
don't know how it works. When I change the data in a Help example (code
below) the resulting table t2 doesn't change.

// Start of code

params = [" " "Country" "Population [Mh]" "Temp.[°C]" ];
towns = ["Mexico" "Paris" "Tokyo" "Singapour"]';
country = ["Mexico" "France" "Japan" "Singapour"]';
pop  = string([22.41 11.77 33.41 4.24]');
temp = string([26 19 22 17]');
table = [params; [ towns country pop temp ]]

f = gcf();
clf
as = f.axes_size;  // [width height]
ut = uicontrol("style","table",..
   "string",table,..
   "position",[5 as(2)-100 300 87],.. // => @top left corner 
of

figure
   "tooltipstring","Data from majors towns")

// Modify by hand some values in the table. Then get them back from the 
ui:

t2=matrix(ut.string,size(table))

// End of code

I use a version from this site which should work:
http://www.scilab.org/fr/development/nightly_builds/master

Kind regards,
Iza
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] uicontrol TABLE

2018-10-18 Thread Izabela Wójcik-Grząba 

Hello,

Sorry for returning to the topic of editting uicontrol Table but I still
don't know how it works. When I change the data in a Help example (code
below) the resulting table t2 doesn't change.

// Start of code

params = [" " "Country" "Population [Mh]" "Temp.[°C]" ];
towns = ["Mexico" "Paris" "Tokyo" "Singapour"]';
country = ["Mexico" "France" "Japan" "Singapour"]';
pop  = string([22.41 11.77 33.41 4.24]');
temp = string([26 19 22 17]');
table = [params; [ towns country pop temp ]]

f = gcf();
clf
as = f.axes_size;  // [width height]
ut = uicontrol("style","table",..
   "string",table,..
   "position",[5 as(2)-100 300 87],.. // => @top left corner 
of

figure
   "tooltipstring","Data from majors towns")

// Modify by hand some values in the table. Then get them back from the 
ui:

t2=matrix(ut.string,size(table))

// End of code

I use a version from this site which should work:
http://www.scilab.org/fr/development/nightly_builds/master

Kind regards,
Iza
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] LIST ADMIN : Fwd: Non remis : Re: Unable to update ATOMS packages - Scilab 6.0.1

2018-10-18 Thread Clément DAVID 
Hello Antoine,

Thanks, unsub-ed on the mailing list admin interface.

--
Clément

From: users  On Behalf Of 
antoine.monmayrant+sci...@laas.fr
Sent: Wednesday, October 17, 2018 8:47 AM
To: International users mailing list for Scilab. 
Subject: [Scilab-users] LIST ADMIN : Fwd: Non remis : Re: Unable to update 
ATOMS packages - Scilab 6.0.1


Hello,

Is there any admin of users@lists.scilab.org 
over here?
Could you deregister this email adress: 
ngro...@rms-signal.com .
I get an error message whenever I post something to 
users@lists.scilab.org and it's really annoying.

Thank you in advance,

Antoine


 Message transféré 
Sujet :

Non remis : Re: [Scilab-users] Unable to update ATOMS packages - Scilab 6.0.1

Date :

Wed, 17 Oct 2018 08:42:08 +0200

De :

postmas...@rms-sysma.fr

Pour :

amonm...@laas.fr



Échec de la remise pour ces destinataires ou groupes :

ngro...@rms-signal.com
L'adresse de messagerie que vous avez entrée est introuvable. Vérifiez 
l'adresse de messagerie du destinataire et essayez de renvoyer le message. Si 
le problème persiste, contactez le support technique de votre organisation.






Informations de diagnostic pour les administrateurs :

Serveur de génération : SERVEUR2012.ts.local

ngro...@rms-signal.com
Remote Server returned '550 5.1.1 RESOLVER.ADR.RecipNotFound; not found'

En-têtes de message d'origine :

Received: from SERVEUR2012.ts.local (192.168.13.2) by SERVEUR2012.ts.local

 (192.168.13.2) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 17 Oct

 2018 08:42:08 +0200

Received: from SERVEUR2012 (127.0.0.1) by SERVEUR2012.ts.local (127.0.0.1)

 with Microsoft SMTP Server id 15.0.847.32 via Frontend Transport; Wed, 17 Oct

 2018 08:42:08 +0200

Received: From ns0.ovh.net by SERVEUR2012 with POPtm; mer. 17 oct. 2018

 08:42:02

X-POPTM-SENDTO: ngro...@rms-signal.com

X-POPTM-BOXID: 1

Return-Path: 


Delivered-To: ngro...@rms-signal.com

Received: from localhost (HELO queue) (127.0.0.1)by localhost with SMTP; 17

 Oct 2018 08:39:22 +0200

Received: from unknown (HELO output55.mail.ovh.net) (10.108.97.112)  by

 mail150.ha.ovh.net with AES256-GCM-SHA384 encrypted SMTP; 17 Oct 2018

 08:39:22 +0200

Received: from vr49.mail.ovh.net (unknown [10.101.8.49]) by 
out55.mail.ovh.net

 (Postfix) with ESMTP id 42ZjFk5Wynz4fd8P for 
; Wed,

 17 Oct 2018 06:39:22 + (UTC)

Received: from in37.mail.ovh.net (unknown [10.101.4.37]) by 
vr49.mail.ovh.net

 (Postfix) with ESMTP id 42ZjFk4nYfz1vHlv for 
; Wed,

 17 Oct 2018 06:39:22 + (UTC)

Received-SPF: None (mailfrom) identity=mailfrom; client-ip=109.7.104.50; 
helo=corvo.scilab.org; 
envelope-from=users-boun...@lists.scilab.org;
 receiver=

Authentication-Results: in37.mail.ovh.net; dkim=none; dkim-atps=neutral

Received: from corvo.scilab.org (50.104.7.109.rev.sfr.net [109.7.104.50]) by

 in37.mail.ovh.net (Postfix) with ESMTPS id 42ZjFk4VSXzsBk7  for

 ; Wed, 17 Oct 2018 
06:39:22 + (UTC)

Received: by corvo.scilab.org (Postfix, from userid 999) id 61495126044; 
Wed,

 17 Oct 2018 08:38:46 +0200 (CEST)

X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on corvo.inria.fr

X-Spam-Level:

X-Spam-Status: No, score=-4.2 required=6.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,

SPF_PASS autolearn=unavailable version=3.3.2

Received: from corvo.inria.fr (localhost [IPv6:::1]) by corvo.scilab.org

 (Postfix) with ESMTP id 9649D1205CB; Wed, 17 Oct 2018 08:38:37 +0200 (CEST)

Received: by corvo.scilab.org (Postfix, from userid 999) id 730E81205CB; Wed,

 17 Oct 2018 08:38:25 +0200 (CEST)

Received-SPF: pass (laas.fr: 140.93.0.15 is authorized to use

 'amonm...@laas.fr' in 'mfrom' identity (mechanism 
'a:mail.laas.fr' matched))

 receiver=corvo.scilab.org; identity=mailfrom; 
envelope-from="amonm...@laas.fr";

 helo=laas.laas.fr; client-ip=140.93.0.15

Received: from laas.laas.fr (laas.laas.fr [140.93.0.15]) by corvo.scilab.org

 (Postfix) with ESMTPS id D901C1204B6 for 
; Wed, 17

 Oct 2018 08:38:12 +0200 (CEST)

Received: from [IPv6:2001:660:6602:4:6600:6aff:fe8b:a548] (tournois.laas.fr

 [IPv6:2001:660:6602:4:6600:6aff:fe8b:a548]) by laas.laas.fr

 (8.16.0.21/8.15.2) with ESMTPS id w9H6cBXe056744 (version=TLSv1.2

 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for

 ; Wed, 17 Oct 2018 
08:38:11 +0200 (CEST)

To: 

References: