From stephane.mottelet at utc.fr Tue Apr 3 17:09:35 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 3 Apr 2018 17:09:35 +0200 Subject: [Scilab-Dev] Patch/CR policy when new files are added Message-ID: <3f2df24f-336f-a4a6-80a5-c10865302a43@utc.fr> Hello devs, I would like to know what is the policy when *new* source files (C,C++ or Java) are added when fixing a bug or adding a feature. A explained in https://wiki.scilab.org/Scilab%20Module%20Architecture when new source files are added in a module, Makefile.am has to mention these files but Makefile.in can only be regenerated by running autoreconf at the main SCI folder. So, should I add the resulting Makefile.in in my commit ? S. -- 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 From Clement.David at esi-group.com Tue Apr 3 17:45:19 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Tue, 3 Apr 2018 15:45:19 +0000 Subject: [Scilab-Dev] Patch/CR policy when new files are added In-Reply-To: <3f2df24f-336f-a4a6-80a5-c10865302a43@utc.fr> References: <3f2df24f-336f-a4a6-80a5-c10865302a43@utc.fr> Message-ID: <1522770318.23602.16.camel@esi-group.com> Hello St?phane, Yes you should also commit the Makefile.in ; it should be provided within the source tree to ease Scilab macros and help pages development as these does not require autotools / vcproj manipulation. Side note: some projects use a `./bootstrap` or ./autogen.sh` (mainly Gnome ones) to generate them using the machine local autotools ; we currently stick to Automake guidelines [1]. [1]: https://www.gnu.org/software/automake/manual/automake.html#CVS Thanks, -- Cl?ment Le mardi 03 avril 2018 ? 17:09 +0200, St?phane Mottelet a ?crit : > Hello devs, > > I would like to know what is the policy when *new* source files (C,C++ > or Java) are added when fixing a bug or adding a feature. A explained in > > https://wiki.scilab.org/Scilab%20Module%20Architecture > > when new source files are added in a module, Makefile.am has to mention > these files but Makefile.in can only be regenerated by running > autoreconf at the main SCI folder. > > So, should I add the resulting Makefile.in in my commit ? > > S. > > From Clement.David at esi-group.com Wed Apr 4 08:57:53 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Wed, 4 Apr 2018 06:57:53 +0000 Subject: [Scilab-Dev] [Scilab-users] Flatpak package In-Reply-To: References: Message-ID: <1522825072.23602.24.camel@esi-group.com> Hello Martin, Good idea ! I also have a first template of a Flatpak manifest with strong inspiration from the Octave one [1] as dependencies are very similar. The bash script used to compile our thirdparties [2] could also be a great source of inspiration. For Eigen, the included files are prefixed like in `#include "Eigen/Eigen"`; you should probably pass `--with-eigen-include=/app/include/` to make it work. [1]: https://github.com/flathub/org.octave.Octave [2]: https://github.com/scilab/scilab-prerequirements/blob/master/build-dependencies.sh Regards, -- Cl?ment Le mardi 03 avril 2018 ? 21:37 +0200, Martin Marmsoler a ?crit : > Hello, > > I'm trying to create a flatpak package of scilab. I try to compile scilab, but I have a different > folder where the Eigen files are stored. Because of this i get the following error: > > checking if Eigen is version 3.3.2 or later... configure: error: Version 3.3.2 of Eigen expected > (at least) > > I tried to add the path with the with-eigen-include argument, but it does not work: > "./scilab/configure --prefix=/app --with-eigen-include=/app/include/Eigen", > > is there anybody who know how I can add the path to the eigen .h files? > > Here you can find the flatpak manifest. When it is finish I will put it on github and create a > pullrequest > https://www.dropbox.com/sh/ezxzm748xs4a4jj/AAATpX_LACHp81hDUdEIz6y4a?dl=0 > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users From gernot.eric at wanadoo.fr Fri Apr 6 14:47:36 2018 From: gernot.eric at wanadoo.fr (ericgernot) Date: Fri, 6 Apr 2018 05:47:36 -0700 (MST) Subject: [Scilab-Dev] New xcos blocks executing scilab primitive functions Message-ID: <1523018856774-0.post@n3.nabble.com> Hi, I am new to scilab, and I am not a developper, but I fear I may become one because of Scilab :-; I am on windows 7 /64, and installed some recent versions. I created a physic model (chemical process with compositions, streams, etc.) from a script and used xcos to solve it, only using Sci_func blocks calling my functions (so that it is easily portable to other scilab versions). It works as desired, so now I want to speed it up. After all the possible improvements from vectorization, I decided to convert 30% of my scifunc into superblocks, giving a 30% speedup boost to the model. I could have written these in c/c++ also, but I suspect it would have taken longer (for me) My remaining scifunc blocks are using some scilab gateways such as fsolve, diag, etc, thus the conversion is not as straighforward. I tried to convert it in c using the scilab 2 c toolbox, this is great for all operations exept scilab gateways. I had a look at how to create a new block, how the c-block work, and finally how existing blocks are coded in c++. If I understand well, the possibilities are 1. copy the c++ primitive function code in a c-block, it will not work because it is not c, and because I don't know which libraries should be included. By the way, where can I put them so that the compiler finds them ? 2. use scilab API from a xcos c-block and send jobs. Will it really skip the interpreter ? 3. create a new block as a user (from within scilab). But you can't use c++ can you ? So I have to write or find c equivalent of scilab primitives, this is a pity ! 4. create a new block source code, and compile a new version of scilab with the new block. I suppose that the same problem exists: converting to c scilab primitives ? So this raised a few questions: - In the block source code, why not call scilab built in functions in c/c++ (not the gateway), only passing them the block arguments / parameters, instead of pasting the code there. That would ease the creation of new blocks isn't it ? - can users call these built in functions in their custom blocks (e.g. c-block) ? (I mean without invoking the parser etc., without linking already linked libraries, etc.) I suppose that many users ran through these problems. Thank you very mucn Regards, Eric -- Sent from: http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944.html From stephane.mottelet at utc.fr Fri Apr 6 16:40:58 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 6 Apr 2018 16:40:58 +0200 Subject: [Scilab-Dev] Adding new properties to graphic objects Message-ID: <771dfd8a-d24f-b16d-690f-65317cce4625@utc.fr> Hello, I just want to give my impressions about the tedious task of adding a new property to a graphic object, e.g. here a "SnapToTicks" property to the Slider, directly mapped to the SnapToTicks property of the Java widget: besides two makefile and the modification to the documentation I had to create two and modify? *11* C,C++ and Java sources files (see the CR @ https://codereview.scilab.org/#/c/19937/): scilab/modules/graphic_objects/src/scripts/propertiesMap.properties scilab/modules/graphic_objects/src/java/org/scilab/modules/graphic_objects/uicontrol/Uicontrol.java scilab/modules/graphic_objects/src/java/org/scilab/modules/graphic_objects/xmlloader/XMLDomLoader.java ??? ??? scilab/modules/graphics/macros/%h_p.sci scilab/modules/graphics/src/c/getHandleProperty/GetHashTable.c scilab/modules/graphics/src/c/getHandleProperty/SetHashTable.c ??? ??? scilab/modules/gui/includes/GetUicontrol.h ??? ??? scilab/modules/gui/includes/SetUicontrol.h ??? ??? scilab/modules/gui/sci_gateway/c/sci_uicontrol.c ??????? scilab/modules/gui/src/cpp/GetUicontrolSnapToTicks.cpp (NEW) ??????? scilab/modules/gui/src/cpp/SetUicontrolSnapToTicks.cpp (NEW) scilab/modules/gui/src/java/org/scilab/modules/gui/bridge/slider/SwingScilabSlider.java ??? ??? scilab/modules/hdf5/src/cpp/handle_properties.hxx Frankly, don't you find that it sucks ? Many properties could be added at the Scilab level (by using macros) if we had an overloading mechanism e.g when the user types something like h.newprop=stuff. Don't you find that such a mechanism could be useful ? S. -- 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 From stephane.mottelet at utc.fr Fri Apr 6 19:24:07 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 6 Apr 2018 19:24:07 +0200 Subject: [Scilab-Dev] example of c++ interface with new scilab api Message-ID: Hello, Where can I found a *self contained* working example (with ilib_build call) of a Scilab interface using the *new* c++ api, i.e. types::Function::ReturnValue sci_foo(types::typed_list &in, int _piRetCount, types::typed_list &out) ? All the examples given in the documentation are C interfaces, not C++. For example I would like to be able to clone the code of modules/integer/sci_gateway/cpp/sci_inttype.cpp (because of its nice and lready written switch/case on all scalar types) and build the interface then link from Scilab. Thanks in advance S. -- 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 From Clement.David at esi-group.com Mon Apr 9 09:37:27 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Mon, 9 Apr 2018 07:37:27 +0000 Subject: [Scilab-Dev] New xcos blocks executing scilab primitive functions In-Reply-To: <1523018856774-0.post@n3.nabble.com> References: <1523018856774-0.post@n3.nabble.com> Message-ID: <1523259445.3266.40.camel@esi-group.com> Hi Eric and welcome :) Nice to have some power users (and maybe futur developers) using big Xcos models, Xcos in 6.0.x have some issues only visible on big diagrams and we currently do not spend too much time benchmarking it. About the scifunc vs Superbloc vs C++ implementation speedup, the clear winner there would be C/C++ if (and only if) there is no event management (either discrete or zero-crossing) to perform. Zero crossing detection is hard to implement even for small sub-systems and discrete events are only easy for synchronous subsystem. Superblocs are straightforward to implement and manage very complex events / continuous states intrication in a clean manner however they can be confusing to maintains (for exemple if you want to preserve the same behavior across different blocks). Scifunc are in- between to me in term of implementation however very poor in term of performance (and not optimized at all). You could use the scicos_block4 API (the default one) in C or C++ ; if you take a look at our source code there is only a few in C++ but they can be easily converted to. About the libraries, I did not get it, do you want to link to different libraries ? The xcos_toolbox_skeleton and ilib_for_build() flags are working well. To call Scilab script within the sciblk2 [1] and sciblk4 [2] blocks we are indeed using the Scilab C++ API, the performance overhead is quiet clear as we are currently allocating Scilab types::Double or a types::MList through createblklist() for each output on each simulation step. This does an extra allocation (for the Scilab datatype) and a copy (for the data copy to scilab) whereas in C/C++ the data are passed by reference to the shared buffers. We clearly have to do better there ; maybe by allocating only once (at Initialization time) or passing types:: views to the shared buffers. There is a test case within xcos_toolbox_skeleton which switch the implementation of a NOOP block (that compute nothing) between Scilab and C depending on a parameter in Scilab. [1]: http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/sciblk2.cpp#n57 [2]: http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/sciblk4.cpp#n217 As a conclusion, yes you can call C++ functions from blocks and Scilab blocks issues comes from a slow implementation of C->Scilab calls not from the Scilab code interpretation. NB: yes this a known problem and some users already reports that but no one is currently working on that. Thanks, -- Cl?ment Le vendredi 06 avril 2018 ? 05:47 -0700, ericgernot a ?crit : > Hi, > > I am new to scilab, and I am not a developper, but I fear I may become one > because of Scilab :-; > I am on windows 7 /64, and installed some recent versions. > > I created a physic model (chemical process with compositions, streams, etc.) > from a script and used xcos to solve it, only using Sci_func blocks calling > my functions (so that it is easily portable to other scilab versions). It > works as desired, so now I want to speed it up. > > After all the possible improvements from vectorization, I decided to convert > 30% of my scifunc into superblocks, giving a 30% speedup boost to the model. > I could have written these in c/c++ also, but I suspect it would have taken > longer (for me) > > My remaining scifunc blocks are using some scilab gateways such as fsolve, > diag, etc, thus the conversion is not as straighforward. > > I tried to convert it in c using the scilab 2 c toolbox, this is great for > all operations exept scilab gateways. > > I had a look at how to create a new block, how the c-block work, and finally > how existing blocks are coded in c++. > > If I understand well, the possibilities are > 1. copy the c++ primitive function code in a c-block, it will not work > because it is not c, and because I don't know which libraries should be > included. By the way, where can I put them so that the compiler finds them ? > 2. use scilab API from a xcos c-block and send jobs. Will it really skip the > interpreter ? > 3. create a new block as a user (from within scilab). But you can't use c++ > can you ? So I have to write or find c equivalent of scilab primitives, this > is a pity ! > 4. create a new block source code, and compile a new version of scilab with > the new block. I suppose that the same problem exists: converting to c > scilab primitives ? > > So this raised a few questions: > - In the block source code, why not call scilab built in functions in c/c++ > (not the gateway), only passing them the block arguments / parameters, > instead of pasting the code there. That would ease the creation of new > blocks isn't it ? > - can users call these built in functions in their custom blocks (e.g. > c-block) ? (I mean without invoking the parser etc., without linking already > linked libraries, etc.) > > I suppose that many users ran through these problems. > Thank you very mucn > Regards, > Eric > > > > > -- > Sent from: http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944.html > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From Clement.David at esi-group.com Mon Apr 9 10:33:35 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Mon, 9 Apr 2018 08:33:35 +0000 Subject: [Scilab-Dev] example of c++ interface with new scilab api In-Reply-To: References: Message-ID: <1523262814.3266.52.camel@esi-group.com> Hello St?phane, I asked myself the same question some times ago and Antoine told me that the toolbox_skeleton contains such an example [1]. For a reduced example, the "cppsci" flags is passed directly to ilib_for_link / ilib_build table names, building cpp_find from the toolbox_skeleton is : ``` ilib_build("foo_scilab6", ["sci_cpp_find" "cppsci"], fullfile(SCI, "contrib", "toolbox_skeleton", "sci_gateway", "cpp", "sci_cpp_find.cxx"), []) ``` [1]: http://cgit.scilab.org/scilab/tree/scilab/contrib/toolbox_skeleton/sci_gateway/cpp/builder_gateway_cpp.sce Thanks, -- Cl?ment Le vendredi 06 avril 2018 ? 19:24 +0200, St?phane Mottelet a ?crit : > Hello, > > Where can I found a *self contained* working example (with ilib_build > call) of a Scilab interface using the *new* c++ api, i.e. > > types::Function::ReturnValue sci_foo(types::typed_list &in, int > _piRetCount, types::typed_list &out) > > ? All the examples given in the documentation are C interfaces, not C++. > > For example I would like to be able to clone the code of > modules/integer/sci_gateway/cpp/sci_inttype.cpp (because of its nice and > lready written switch/case on all scalar types) and build the interface > then link from Scilab. > > Thanks in advance > > S. > From stephane.mottelet at utc.fr Mon Apr 9 10:35:38 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Mon, 9 Apr 2018 10:35:38 +0200 Subject: [Scilab-Dev] example of c++ interface with new scilab api In-Reply-To: <1523262814.3266.52.camel@esi-group.com> References: <1523262814.3266.52.camel@esi-group.com> Message-ID: Thanks ! Le 09/04/2018 ? 10:33, Cl?ment David a ?crit?: > Hello St?phane, > > I asked myself the same question some times ago and Antoine told me that the toolbox_skeleton > contains such an example [1]. For a reduced example, the "cppsci" flags is passed directly to > ilib_for_link / ilib_build table names, building cpp_find from the toolbox_skeleton is : > > ``` > ilib_build("foo_scilab6", ["sci_cpp_find" "cppsci"], fullfile(SCI, "contrib", "toolbox_skeleton", > "sci_gateway", "cpp", "sci_cpp_find.cxx"), []) > ``` > > [1]: > http://cgit.scilab.org/scilab/tree/scilab/contrib/toolbox_skeleton/sci_gateway/cpp/builder_gateway_cpp.sce > Thanks, > > -- > Cl?ment > > Le vendredi 06 avril 2018 ? 19:24 +0200, St?phane Mottelet a ?crit : >> Hello, >> >> Where can I found a *self contained* working example (with ilib_build >> call) of a Scilab interface using the *new* c++ api, i.e. >> >> types::Function::ReturnValue sci_foo(types::typed_list &in, int >> _piRetCount, types::typed_list &out) >> >> ? All the examples given in the documentation are C interfaces, not C++. >> >> For example I would like to be able to clone the code of >> modules/integer/sci_gateway/cpp/sci_inttype.cpp (because of its nice and >> lready written switch/case on all scalar types) and build the interface >> then link from Scilab. >> >> Thanks in advance >> >> S. >> > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -- 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 From Clement.David at esi-group.com Mon Apr 9 10:49:36 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Mon, 9 Apr 2018 08:49:36 +0000 Subject: [Scilab-Dev] Adding new properties to graphic objects In-Reply-To: <771dfd8a-d24f-b16d-690f-65317cce4625@utc.fr> References: <771dfd8a-d24f-b16d-690f-65317cce4625@utc.fr> Message-ID: <1523263775.3266.65.camel@esi-group.com> Hello St?phane, Yes it is really tedious. Scilab uicontrols / graphics is using a mixture of C++ gateways (1 file) with C++ stored properties (1 getter and 1 setter) and Java through an MVC (1 file) that could be stored as XML (1 file) and as hdf5 (1 file) and could be printed into Scilab (1 file) etc... So currently there is one file per functionality as we started with a known set of properties and an increasing set of functionality. We could also have implemented the MVC with 1 file per property and a fixed set of functionality. Doing so today will require a major refactoring effort ! Thanks, -- Cl?ment Le vendredi 06 avril 2018 ? 16:40 +0200, St?phane Mottelet a ?crit : > Hello, > > I just want to give my impressions about the tedious task of adding a > new property to a graphic object, e.g. here a "SnapToTicks" property to > the Slider, directly mapped to the SnapToTicks property of the Java > widget: besides two makefile and the modification to the documentation I > had to create two and modify *11* C,C++ and Java sources files (see the > CR @ https://codereview.scilab.org/#/c/19937/): > > scilab/modules/graphic_objects/src/scripts/propertiesMap.properties > scilab/modules/graphic_objects/src/java/org/scilab/modules/graphic_objects/uicontrol/Uicontrol.jav > a > > scilab/modules/graphic_objects/src/java/org/scilab/modules/graphic_objects/xmlloader/XMLDomLoader. > java > > scilab/modules/graphics/macros/%h_p.sci > scilab/modules/graphics/src/c/getHandleProperty/GetHashTable.c > scilab/modules/graphics/src/c/getHandleProperty/SetHashTable.c > scilab/modules/gui/includes/GetUicontrol.h > scilab/modules/gui/includes/SetUicontrol.h > scilab/modules/gui/sci_gateway/c/sci_uicontrol.c > scilab/modules/gui/src/cpp/GetUicontrolSnapToTicks.cpp (NEW) > scilab/modules/gui/src/cpp/SetUicontrolSnapToTicks.cpp (NEW) > scilab/modules/gui/src/java/org/scilab/modules/gui/bridge/slider/SwingScilabSlider.java > scilab/modules/hdf5/src/cpp/handle_properties.hxx > > Frankly, don't you find that it sucks ? > > Many properties could be added at the Scilab level (by using macros) if > we had an overloading mechanism e.g when the user types something like > h.newprop=stuff. Don't you find that such a mechanism could be useful ? > > S. > > From gernot.eric at wanadoo.fr Mon Apr 9 12:33:57 2018 From: gernot.eric at wanadoo.fr (Eric GERNOT) Date: Mon, 9 Apr 2018 12:33:57 +0200 (CEST) Subject: [Scilab-Dev] New xcos blocks executing scilab primitive functions In-Reply-To: <1523259445.3266.40.camel@esi-group.com> References: <1523018856774-0.post@n3.nabble.com> <1523259445.3266.40.camel@esi-group.com> Message-ID: <1783656253.8967.1523270037574.JavaMail.www@wwinf1p23> Hello Clement, ? Thank you for this very clear answer. How does Scilab Gateways work? When we tap enter after entering the command line on the prompt, let's say to call a primitive, does the gateway also need the API ? Or is there a more direct way to do so ? ? Regarding my questions on the libraries. Well, let's say I am a simple user of scilab, with no code development tools installed. Editing a c-block, seeing the #include math.h line was a bit scary, because I thought "this will require that I have put the math.h file at the good place on my computer". So I insert nothing in the code, click "ok" and the compilation is succesful.? Now after running Scilab 2 c toolbox on my custom code, a number of subdirectories with multiple files were created in my custom directory. I suppose if I want this scilab 2 c created code running in the c-block, I have to put these files where the block can access them at compilation time. Same if I created the code on my own. That is why I asked where the c-block compiler looks to find the files, or how do we configure this, as users. ? Best regards, Eric ? ? ? ? > Message du 09/04/18 09:37 > De : "Cl?ment David" > A : "dev at lists.scilab.org" > Copie ? : > Objet : Re: [Scilab-Dev] New xcos blocks executing scilab primitive functions > > Hi Eric and welcome :) > > Nice to have some power users (and maybe futur developers) using big Xcos models, Xcos in 6.0.x have > some issues only visible on big diagrams and we currently do not spend too much time benchmarking > it. > > About the scifunc vs Superbloc vs C++ implementation speedup, the clear winner there would be C/C++ > if (and only if) there is no event management (either discrete or zero-crossing) to perform. Zero > crossing detection is hard to implement even for small sub-systems and discrete events are only easy > for synchronous subsystem. Superblocs are straightforward to implement and manage very complex > events / continuous states intrication in a clean manner however they can be confusing to maintains > (for exemple if you want to preserve the same behavior across different blocks). Scifunc are in- > between to me in term of implementation however very poor in term of performance (and not optimized > at all). > > You could use the scicos_block4 API (the default one) in C or C++ ; if you take a look at our source > code there is only a few in C++ but they can be easily converted to. About the libraries, I did not > get it, do you want to link to different libraries ? The xcos_toolbox_skeleton and ilib_for_build() > flags are working well. > > To call Scilab script within the sciblk2 [1] and sciblk4 [2] blocks we are indeed using the Scilab > C++ API, the performance overhead is quiet clear as we are currently allocating Scilab types::Double > or a types::MList through createblklist() for each output on each simulation step. This does an > extra allocation (for the Scilab datatype) and a copy (for the data copy to scilab) whereas in C/C++ > the data are passed by reference to the shared buffers. We clearly have to do better there ; maybe > by allocating only once (at Initialization time) or passing types:: views to the shared buffers. > There is a test case within xcos_toolbox_skeleton which switch the implementation of a NOOP block > (that compute nothing) between Scilab and C depending on a parameter in Scilab. > > [1]: http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/sciblk2.cpp#n57 > [2]: http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/sciblk4.cpp#n217 > > As a conclusion, yes you can call C++ functions from blocks and Scilab blocks issues comes from a > slow implementation of C->Scilab calls not from the Scilab code interpretation. > > NB: yes this a known problem and some users already reports that but no one is currently working on > that. > > Thanks, > > -- > Cl?ment > > Le vendredi 06 avril 2018 ? 05:47 -0700, ericgernot a ?crit : > > Hi, > > > > I am new to scilab, and I am not a developper, but I fear I may become one > > because of Scilab :-; > > I am on windows 7 /64, and installed some recent versions. > > > > I created a physic model (chemical process with compositions, streams, etc.) > > from a script and used xcos to solve it, only using Sci_func blocks calling > > my functions (so that it is easily portable to other scilab versions). It > > works as desired, so now I want to speed it up. > > > > After all the possible improvements from vectorization, I decided to convert > > 30% of my scifunc into superblocks, giving a 30% speedup boost to the model. > > I could have written these in c/c++ also, but I suspect it would have taken > > longer (for me) > > > > My remaining scifunc blocks are using some scilab gateways such as fsolve, > > diag, etc, thus the conversion is not as straighforward. > > > > I tried to convert it in c using the scilab 2 c toolbox, this is great for > > all operations exept scilab gateways. > > > > I had a look at how to create a new block, how the c-block work, and finally > > how existing blocks are coded in c++. > > > > If I understand well, the possibilities are > > 1. copy the c++ primitive function code in a c-block, it will not work > > because it is not c, and because I don't know which libraries should be > > included. By the way, where can I put them so that the compiler finds them ? > > 2. use scilab API from a xcos c-block and send jobs. Will it really skip the > > interpreter ? > > 3. create a new block as a user (from within scilab). But you can't use c++ > > can you ? So I have to write or find c equivalent of scilab primitives, this > > is a pity ! > > 4. create a new block source code, and compile a new version of scilab with > > the new block. I suppose that the same problem exists: converting to c > > scilab primitives ? > > > > So this raised a few questions: > > - In the block source code, why not call scilab built in functions in c/c++ > > (not the gateway), only passing them the block arguments / parameters, > > instead of pasting the code there. That would ease the creation of new > > blocks isn't it ? > > - can users call these built in functions in their custom blocks (e.g. > > c-block) ? (I mean without invoking the parser etc., without linking already > > linked libraries, etc.) > > > > I suppose that many users ran through these problems. > > Thank you very mucn > > Regards, > > Eric > > > > > > > > > > -- > > Sent from: http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944.html > > _______________________________________________ > > dev mailing list > > dev at lists.scilab.org > > http://lists.scilab.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev at lists.scilab.org http://lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From Clement.David at esi-group.com Mon Apr 9 15:27:22 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Mon, 9 Apr 2018 13:27:22 +0000 Subject: [Scilab-Dev] New xcos blocks executing scilab primitive functions In-Reply-To: <1783656253.8967.1523270037574.JavaMail.www@wwinf1p23> References: <1523018856774-0.post@n3.nabble.com> <1523259445.3266.40.camel@esi-group.com> <1783656253.8967.1523270037574.JavaMail.www@wwinf1p23> Message-ID: <1523280440.3266.79.camel@esi-group.com> Hello Eric, As described in some guides [1][2], the interpreter will call a gateway passing values using the C++ / C object-oriented / C stack-oriented APIs depending how you declared it. On the gateway you are free to do whatever you want with the data. [1]: https://wiki.scilab.org/howto/Create%20a%20toolbox#Gateway [2]: https://wiki.scilab.org/Developers However for Xcos, the story is a bit different as the blocks will be called by a simulator (ODE / IDA solver) not an interpreter ; the API is different and called scicos_block4 ; using a C-block you have to describe the interface and write some code using the data passed as arguments. Note: Scilab2C is a toolbox which might (or might not) follow Scilab coding conventions. -- Cl?ment Le lundi 09 avril 2018 ? 12:33 +0200, Eric GERNOT a ?crit : > Hello Clement, > > Thank you for this very clear answer. > How does Scilab Gateways work? When we tap enter after entering the command line on the prompt, > let's say to call a primitive, does the gateway also need the API ? > Or is there a more direct way to do so ? > > Regarding my questions on the libraries. > Well, let's say I am a simple user of scilab, with no code development tools installed. > Editing a c-block, seeing the #include math.h line was a bit scary, because I thought "this will > require that I have put the math.h file at the good place on my computer". > So I insert nothing in the code, click "ok" and the compilation is succesful. > Now after running Scilab 2 c toolbox on my custom code, a number of subdirectories with multiple > files were created in my custom directory. I suppose if I want this scilab 2 c created code > running in the c-block, I have to put these files where the block can access them at compilation > time. > Same if I created the code on my own. That is why I asked where the c-block compiler looks to find > the files, or how do we configure this, as users. > > Best regards, > Eric > > > > > > > Message du 09/04/18 09:37 > > > De : "Cl?ment David" > > > A : "dev at lists.scilab.org" > > > Copie ? : > > > Objet : Re: [Scilab-Dev] New xcos blocks executing scilab primitive functions > > > > > > Hi Eric and welcome :) > > > > > > Nice to have some power users (and maybe futur developers) using big Xcos models, Xcos in > > 6.0.x have > > > some issues only visible on big diagrams and we currently do not spend too much time > > benchmarking > > > it. > > > > > > About the scifunc vs Superbloc vs C++ implementation speedup, the clear winner there would be > > C/C++ > > > if (and only if) there is no event management (either discrete or zero-crossing) to perform. > > Zero > > > crossing detection is hard to implement even for small sub-systems and discrete events are > > only easy > > > for synchronous subsystem. Superblocs are straightforward to implement and manage very complex > > > events / continuous states intrication in a clean manner however they can be confusing to > > maintains > > > (for exemple if you want to preserve the same behavior across different blocks). Scifunc are > > in- > > > between to me in term of implementation however very poor in term of performance (and not > > optimized > > > at all). > > > > > > You could use the scicos_block4 API (the default one) in C or C++ ; if you take a look at our > > source > > > code there is only a few in C++ but they can be easily converted to. About the libraries, I > > did not > > > get it, do you want to link to different libraries ? The xcos_toolbox_skeleton and > > ilib_for_build() > > > flags are working well. > > > > > > To call Scilab script within the sciblk2 [1] and sciblk4 [2] blocks we are indeed using the > > Scilab > > > C++ API, the performance overhead is quiet clear as we are currently allocating Scilab > > types::Double > > > or a types::MList through createblklist() for each output on each simulation step. This does > > an > > > extra allocation (for the Scilab datatype) and a copy (for the data copy to scilab) whereas in > > C/C++ > > > the data are passed by reference to the shared buffers. We clearly have to do better there ; > > maybe > > > by allocating only once (at Initialization time) or passing types:: views to the shared > > buffers. > > > There is a test case within xcos_toolbox_skeleton which switch the implementation of a NOOP > > block > > > (that compute nothing) between Scilab and C depending on a parameter in Scilab. > > > > > > [1]: http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/sciblk2.cpp#n57 > > > [2]: http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/sciblk4.cpp#n217 > > > > > > As a conclusion, yes you can call C++ functions from blocks and Scilab blocks issues comes > > from a > > > slow implementation of C->Scilab calls not from the Scilab code interpretation. > > > > > > NB: yes this a known problem and some users already reports that but no one is currently > > working on > > > that. > > > > > > Thanks, > > > > > > -- > > > Cl?ment > > > > > > Le vendredi 06 avril 2018 ? 05:47 -0700, ericgernot a ?crit : > > > > Hi, > > > > > > > > I am new to scilab, and I am not a developper, but I fear I may become one > > > > because of Scilab :-; > > > > I am on windows 7 /64, and installed some recent versions. > > > > > > > > I created a physic model (chemical process with compositions, streams, etc.) > > > > from a script and used xcos to solve it, only using Sci_func blocks calling > > > > my functions (so that it is easily portable to other scilab versions). It > > > > works as desired, so now I want to speed it up. > > > > > > > > After all the possible improvements from vectorization, I decided to convert > > > > 30% of my scifunc into superblocks, giving a 30% speedup boost to the model. > > > > I could have written these in c/c++ also, but I suspect it would have taken > > > > longer (for me) > > > > > > > > My remaining scifunc blocks are using some scilab gateways such as fsolve, > > > > diag, etc, thus the conversion is not as straighforward. > > > > > > > > I tried to convert it in c using the scilab 2 c toolbox, this is great for > > > > all operations exept scilab gateways. > > > > > > > > I had a look at how to create a new block, how the c-block work, and finally > > > > how existing blocks are coded in c++. > > > > > > > > If I understand well, the possibilities are > > > > 1. copy the c++ primitive function code in a c-block, it will not work > > > > because it is not c, and because I don't know which libraries should be > > > > included. By the way, where can I put them so that the compiler finds them ? > > > > 2. use scilab API from a xcos c-block and send jobs. Will it really skip the > > > > interpreter ? > > > > 3. create a new block as a user (from within scilab). But you can't use c++ > > > > can you ? So I have to write or find c equivalent of scilab primitives, this > > > > is a pity ! > > > > 4. create a new block source code, and compile a new version of scilab with > > > > the new block. I suppose that the same problem exists: converting to c > > > > scilab primitives ? > > > > > > > > So this raised a few questions: > > > > - In the block source code, why not call scilab built in functions in c/c++ > > > > (not the gateway), only passing them the block arguments / parameters, > > > > instead of pasting the code there. That would ease the creation of new > > > > blocks isn't it ? > > > > - can users call these built in functions in their custom blocks (e.g. > > > > c-block) ? (I mean without invoking the parser etc., without linking already > > > > linked libraries, etc.) > > > > > > > > I suppose that many users ran through these problems. > > > > Thank you very mucn > > > > Regards, > > > > Eric > > > > > > > > > > > > > > > > > > > > -- > > > > Sent from: http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944. > > html > > > > _______________________________________________ > > > > dev mailing list > > > > dev at lists.scilab.org > > > > http://lists.scilab.org/mailman/listinfo/dev _______________________________________________ > > dev mailing list dev at lists.scilab.org http://lists.scilab.org/mailman/listinfo/dev > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From stephane.mottelet at utc.fr Mon Apr 9 15:45:37 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Mon, 9 Apr 2018 15:45:37 +0200 Subject: [Scilab-Dev] usage of push_back/front and pop_back/front in scilab API Message-ID: Hello, I have a newbie question about the usage of lists in the new scilab API. When e.g. you have to construct a list of vectors constructed from a vector double* YData which is updated and to be stored after each update in a list names pDblYOutList. By writing pDblYOutList.push_back(pdYData); at each update, since the address of YData does not change, at the end every term of the list will contain the same vector (ode bug :-(). I have some ideas to fix that but how does one proceed *properly* in the coding style of Scilab API ? S. -- 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 From stephane.mottelet at utc.fr Mon Apr 9 16:07:55 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Mon, 9 Apr 2018 16:07:55 +0200 Subject: [Scilab-Dev] usage of push_back/front and pop_back/front in scilab API In-Reply-To: References: Message-ID: <2d4f042d-15f9-fa60-3c0e-e833bf8f65b0@utc.fr> Le 09/04/2018 ? 15:45, St?phane Mottelet a ?crit?: > Hello, > > I have a newbie question about the usage of lists in the new scilab > API. When e.g. you have to construct a list of vectors constructed > from a vector > > double* YData > > which is updated and to be stored after each update in a list names > pDblYOutList. By writing > > pDblYOutList.push_back(pdYData); > > at each update, since the address of YData does not change, at the end > every term of the list will contain the same vector (ode bug :-(). I > have some ideas to fix that but how does one proceed *properly* in the > coding style of Scilab API ? > > S. > > > Supposing that pDblY0 exists, with? the required size, and pDblYOut is a types::Double*, does the following do the trick: ??????????? pDblYOut = new types::Double(pDblY0->getRows(), 1); ??????????? pDblYOut->set(pdYData); ??????????? pDblYOutList.push_back(pDblYOut->get()); Thanks for hints, comments.. S. -- 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 From Clement.David at esi-group.com Tue Apr 10 08:31:49 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Tue, 10 Apr 2018 06:31:49 +0000 Subject: [Scilab-Dev] usage of push_back/front and pop_back/front in scilab API In-Reply-To: <2d4f042d-15f9-fa60-3c0e-e833bf8f65b0@utc.fr> References: <2d4f042d-15f9-fa60-3c0e-e833bf8f65b0@utc.fr> Message-ID: <1523341907.3266.90.camel@esi-group.com> Le lundi 09 avril 2018 ? 16:07 +0200, St?phane Mottelet a ?crit : > Le 09/04/2018 ? 15:45, St?phane Mottelet a ?crit : > > Hello, > > > > I have a newbie question about the usage of lists in the new scilab > > API. When e.g. you have to construct a list of vectors constructed > > from a vector > > > > double* YData > > > > which is updated and to be stored after each update in a list names > > pDblYOutList. By writing > > > > pDblYOutList.push_back(pdYData); > > > > at each update, since the address of YData does not change, at the end > > every term of the list will contain the same vector (ode bug :-(). I > > have some ideas to fix that but how does one proceed *properly* in the > > coding style of Scilab API ? > > > > S. > > > > > > > > Supposing that pDblY0 exists, with the required size, and pDblYOut is a > types::Double*, does the following do the trick: > > pDblYOut = new types::Double(pDblY0->getRows(), 1); > pDblYOut->set(pdYData); > pDblYOutList.push_back(pDblYOut->get()); > > Thanks for hints, comments.. > > S. Hello St?phane, As `double* pdYData` is updated you have to copy the data to preserve the history ; you could either use Scilab API to store types::Double or plain C++ to store double* : auto pDblYOut = new types::Double(pDblY0->getRows(), 1); pDblYOut->set(pdYData); // will copy pdYData pDblYOutList->getData()->push_back(pDblYOut); // to preserve a pointer to the Scilab datatype with // types::List* pDblYOutList OR auto temp = new double[pDblY0->getRows()]; memcpy(temp, pdYData, pDblY0->getRows()*sizeof(double)); pDblYOutList.push_back(temp); // using std::vector pDblYOutList However (especially in ode() case) not that allocating on each loop step can be really slow ; having all the buffers pre-allocated at first will slightly improve loop caching. Regards, -- Cl?ment From gernot.eric at wanadoo.fr Tue Apr 10 10:31:06 2018 From: gernot.eric at wanadoo.fr (Eric GERNOT) Date: Tue, 10 Apr 2018 10:31:06 +0200 (CEST) Subject: [Scilab-Dev] New xcos blocks executing scilab primitive functions In-Reply-To: <1523280440.3266.79.camel@esi-group.com> References: <1523018856774-0.post@n3.nabble.com> <1523259445.3266.40.camel@esi-group.com> <1783656253.8967.1523270037574.JavaMail.www@wwinf1p23> <1523280440.3266.79.camel@esi-group.com> Message-ID: <853412734.3643.1523349066501.JavaMail.www@wwinf1j17> Cl?ment, ? Would it be different if we had to create a X_cos block executing a single Scilab expression (block output = RHS (block input, t, state derivative)) ? ? I noted that the actual Scifunc Block is very powerful and educational thus to me it should not be changed. ? Also I started suspecting that, although Scifunc blocks alone are slow compared to c or already provided blocks, they may not always be the bottleneck in the context of a specific calculation. I have to compare a few things and look at how many times each block is called by each solver. ? Regards, ? Eric ? ? ? > Message du 09/04/18 15:27 > De : "Cl?ment David" > A : "dev at lists.scilab.org" > Copie ? : > Objet : Re: [Scilab-Dev] New xcos blocks executing scilab primitive functions > > Hello Eric, > > As described in some guides [1][2], the interpreter will call a gateway passing values using the C++ > / C object-oriented / C stack-oriented APIs depending how you declared it. On the gateway you are > free to do whatever you want with the data. > > [1]: https://wiki.scilab.org/howto/Create%20a%20toolbox#Gateway > [2]: https://wiki.scilab.org/Developers > > However for Xcos, the story is a bit different as the blocks will be called by a simulator (ODE / > IDA solver) not an interpreter ; the API is different and called scicos_block4 ; using a C-block you > have to describe the interface and write some code using the data passed as arguments. > > Note: Scilab2C is a toolbox which might (or might not) follow Scilab coding conventions. > > -- > Cl?ment > > > Le lundi 09 avril 2018 ? 12:33 +0200, Eric GERNOT a ?crit : > > Hello Clement, > > > > Thank you for this very clear answer. > > How does Scilab Gateways work? When we tap enter after entering the command line on the prompt, > > let's say to call a primitive, does the gateway also need the API ? > > Or is there a more direct way to do so ? > > > > Regarding my questions on the libraries. > > Well, let's say I am a simple user of scilab, with no code development tools installed. > > Editing a c-block, seeing the #include math.h line was a bit scary, because I thought "this will > > require that I have put the math.h file at the good place on my computer". > > So I insert nothing in the code, click "ok" and the compilation is succesful. > > Now after running Scilab 2 c toolbox on my custom code, a number of subdirectories with multiple > > files were created in my custom directory. I suppose if I want this scilab 2 c created code > > running in the c-block, I have to put these files where the block can access them at compilation > > time. > > Same if I created the code on my own. That is why I asked where the c-block compiler looks to find > > the files, or how do we configure this, as users. > > > > Best regards, > > Eric > > > > > > > > > > > > Message du 09/04/18 09:37 > > > > De : "Cl?ment David" > > > > A : "dev at lists.scilab.org" > > > > Copie ? : > > > > Objet : Re: [Scilab-Dev] New xcos blocks executing scilab primitive functions > > > > > > > > Hi Eric and welcome :) > > > > > > > > Nice to have some power users (and maybe futur developers) using big Xcos models, Xcos in > > > 6.0.x have > > > > some issues only visible on big diagrams and we currently do not spend too much time > > > benchmarking > > > > it. > > > > > > > > About the scifunc vs Superbloc vs C++ implementation speedup, the clear winner there would be > > > C/C++ > > > > if (and only if) there is no event management (either discrete or zero-crossing) to perform. > > > Zero > > > > crossing detection is hard to implement even for small sub-systems and discrete events are > > > only easy > > > > for synchronous subsystem. Superblocs are straightforward to implement and manage very complex > > > > events / continuous states intrication in a clean manner however they can be confusing to > > > maintains > > > > (for exemple if you want to preserve the same behavior across different blocks). Scifunc are > > > in- > > > > between to me in term of implementation however very poor in term of performance (and not > > > optimized > > > > at all). > > > > > > > > You could use the scicos_block4 API (the default one) in C or C++ ; if you take a look at our > > > source > > > > code there is only a few in C++ but they can be easily converted to. About the libraries, I > > > did not > > > > get it, do you want to link to different libraries ? The xcos_toolbox_skeleton and > > > ilib_for_build() > > > > flags are working well. > > > > > > > > To call Scilab script within the sciblk2 [1] and sciblk4 [2] blocks we are indeed using the > > > Scilab > > > > C++ API, the performance overhead is quiet clear as we are currently allocating Scilab > > > types::Double > > > > or a types::MList through createblklist() for each output on each simulation step. This does > > > an > > > > extra allocation (for the Scilab datatype) and a copy (for the data copy to scilab) whereas in > > > C/C++ > > > > the data are passed by reference to the shared buffers. We clearly have to do better there ; > > > maybe > > > > by allocating only once (at Initialization time) or passing types:: views to the shared > > > buffers. > > > > There is a test case within xcos_toolbox_skeleton which switch the implementation of a NOOP > > > block > > > > (that compute nothing) between Scilab and C depending on a parameter in Scilab. > > > > > > > > [1]: http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/sciblk2.cpp#n57 > > > > [2]: http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/sciblk4.cpp#n217 > > > > > > > > As a conclusion, yes you can call C++ functions from blocks and Scilab blocks issues comes > > > from a > > > > slow implementation of C->Scilab calls not from the Scilab code interpretation. > > > > > > > > NB: yes this a known problem and some users already reports that but no one is currently > > > working on > > > > that. > > > > > > > > Thanks, > > > > > > > > -- > > > > Cl?ment > > > > > > > > Le vendredi 06 avril 2018 ? 05:47 -0700, ericgernot a ?crit : > > > > > Hi, > > > > > > > > > > I am new to scilab, and I am not a developper, but I fear I may become one > > > > > because of Scilab :-; > > > > > I am on windows 7 /64, and installed some recent versions. > > > > > > > > > > I created a physic model (chemical process with compositions, streams, etc.) > > > > > from a script and used xcos to solve it, only using Sci_func blocks calling > > > > > my functions (so that it is easily portable to other scilab versions). It > > > > > works as desired, so now I want to speed it up. > > > > > > > > > > After all the possible improvements from vectorization, I decided to convert > > > > > 30% of my scifunc into superblocks, giving a 30% speedup boost to the model. > > > > > I could have written these in c/c++ also, but I suspect it would have taken > > > > > longer (for me) > > > > > > > > > > My remaining scifunc blocks are using some scilab gateways such as fsolve, > > > > > diag, etc, thus the conversion is not as straighforward. > > > > > > > > > > I tried to convert it in c using the scilab 2 c toolbox, this is great for > > > > > all operations exept scilab gateways. > > > > > > > > > > I had a look at how to create a new block, how the c-block work, and finally > > > > > how existing blocks are coded in c++. > > > > > > > > > > If I understand well, the possibilities are > > > > > 1. copy the c++ primitive function code in a c-block, it will not work > > > > > because it is not c, and because I don't know which libraries should be > > > > > included. By the way, where can I put them so that the compiler finds them ? > > > > > 2. use scilab API from a xcos c-block and send jobs. Will it really skip the > > > > > interpreter ? > > > > > 3. create a new block as a user (from within scilab). But you can't use c++ > > > > > can you ? So I have to write or find c equivalent of scilab primitives, this > > > > > is a pity ! > > > > > 4. create a new block source code, and compile a new version of scilab with > > > > > the new block. I suppose that the same problem exists: converting to c > > > > > scilab primitives ? > > > > > > > > > > So this raised a few questions: > > > > > - In the block source code, why not call scilab built in functions in c/c++ > > > > > (not the gateway), only passing them the block arguments / parameters, > > > > > instead of pasting the code there. That would ease the creation of new > > > > > blocks isn't it ? > > > > > - can users call these built in functions in their custom blocks (e.g. > > > > > c-block) ? (I mean without invoking the parser etc., without linking already > > > > > linked libraries, etc.) > > > > > > > > > > I suppose that many users ran through these problems. > > > > > Thank you very mucn > > > > > Regards, > > > > > Eric > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Sent from: http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944. > > > html > > > > > _______________________________________________ > > > > > dev mailing list > > > > > dev at lists.scilab.org > > > > > http://lists.scilab.org/mailman/listinfo/dev _______________________________________________ > > > dev mailing list dev at lists.scilab.org http://lists.scilab.org/mailman/listinfo/dev > > > > _______________________________________________ > > dev mailing list > > dev at lists.scilab.org > > http://lists.scilab.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev at lists.scilab.org http://lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From gusmellbem at student.gu.se Tue Apr 10 13:53:28 2018 From: gusmellbem at student.gu.se (Emanuel Mellblom) Date: Tue, 10 Apr 2018 13:53:28 +0200 Subject: [Scilab-Dev] Thesis Survey - Personality and Burnout in Software Developers Message-ID: <584B2342-DC0C-42B9-99DD-768728B7EAAF@student.gu.se> Thesis Survey - Personality and Burnout in Software Developers Hello, We are two university students conducting a thesis research project which investigates the correlation between a software developer?s personality traits and their susceptibility to workplace burnout. If you are currently employed as a software developer, we invite you to participate by taking a survey measuring your personality and burnout to help us gain a better understanding of the subject. The survey should take no more than 5-10 minutes to complete. A link to the survey may be found below. https://goo.gl/forms/cOmsqJlAmVUaW3zq1 Your survey response will be anonymous and strictly confidential, and all data collected will be reported only in aggregate. If you would like to receive a copy of the results, you may reply to this email and they will be forwarded to you once the findings have been published. With thanks, Emanuel Mellblom gusmellbem at student.gu.se University of Gothenburg, Sweden Isar Arason gusarais at student.gu.se University of Gothenburg, Sweden -------------- next part -------------- An HTML attachment was scrubbed... URL: From gernot.eric at wanadoo.fr Wed Apr 11 14:40:11 2018 From: gernot.eric at wanadoo.fr (Eric GERNOT) Date: Wed, 11 Apr 2018 14:40:11 +0200 (CEST) Subject: [Scilab-Dev] New xcos blocks executing scilab primitive functions In-Reply-To: <853412734.3643.1523349066501.JavaMail.www@wwinf1j17> References: <1523018856774-0.post@n3.nabble.com> <1523259445.3266.40.camel@esi-group.com> <1783656253.8967.1523270037574.JavaMail.www@wwinf1p23> <1523280440.3266.79.camel@esi-group.com> <853412734.3643.1523349066501.JavaMail.www@wwinf1j17> Message-ID: <1623064640.9989.1523450411261.JavaMail.www@wwinf1m19> Here are a few comparisons with 3 scifunc_block (the clock has a period of 1s): 1) computation of two 100 x 100 matrix and attribution of the second 100 x 100 matrix to the output port 2) computation of two scalar and attribution of one to the output port 3) computation of two 100 x 100 matrix, and attribution of a scalar to the output port. ? (I prefer tic/toc vs timer because it is directly related to the actuel time the user waits). ? For comparison, I also tested the following scripts in scilab, that do the same as 1) and 2). The recorded times are +/- 1)? 1.5 s (xcos) and 0.7 s (scilab) 2)? 0.3 s (xcos) and 0.02 s (scilab) 3)? 1.5 s (xcos) ? As you can see, whether the large data are transfered to the output port or not does not dramatically change the computation time, and it resemble the script computation time (may be specific to this case though). Does it mean that also Scilab reallocate memory through createblklist() at each new script instruction ?(that was what I thought) Or is it because scifunc_block store the results of each instruction ? ? I don't see why Scilab is faster with the scalar. ? ? tic() for i = [1:1:10000] a=ones(100,100)*3 b=ones(100,100)*3 end disp(toc()) tic() for i = [1:1:10000] a=1*3 b=1*3 end disp(toc()) ? ? > Message du 10/04/18 10:31 > De : "Eric GERNOT" > A : "List dedicated to the development of Scilab" > Copie ? : > Objet : Re: [Scilab-Dev] New xcos blocks executing scilab primitive functions > > > Cl?ment, > ? > > Would it be different if we had to create a X_cos block executing a single Scilab expression (block output = RHS (block input, t, state derivative)) ? ? I noted that the actual Scifunc Block is very powerful and educational thus to me it should not be changed. ? Also I started suspecting that, although Scifunc blocks alone are slow compared to c or already provided blocks, they may not always be the bottleneck in the context of a specific calculation. I have to compare a few things and look at how many times each block is called by each solver. ? > Regards, ? Eric > ? > ? > ? > Message du 09/04/18 15:27 > De : "Cl?ment David" > A : "dev at lists.scilab.org" > Copie ? : > Objet : Re: [Scilab-Dev] New xcos blocks executing scilab primitive functions > > Hello Eric, > > As described in some guides [1][2], the interpreter will call a gateway passing values using the C++ > / C object-oriented / C stack-oriented APIs depending how you declared it. On the gateway you are > free to do whatever you want with the data. > > [1]: https://wiki.scilab.org/howto/Create%20a%20toolbox#Gateway > [2]: https://wiki.scilab.org/Developers > > However for Xcos, the story is a bit different as the blocks will be called by a simulator (ODE / > IDA solver) not an interpreter ; the API is different and called scicos_block4 ; using a C-block you > have to describe the interface and write some code using the data passed as arguments. > > Note: Scilab2C is a toolbox which might (or might not) follow Scilab coding conventions. > > -- > Cl?ment > > > Le lundi 09 avril 2018 ? 12:33 +0200, Eric GERNOT a ?crit : > > Hello Clement, > > > > Thank you for this very clear answer. > > How does Scilab Gateways work? When we tap enter after entering the command line on the prompt, > > let's say to call a primitive, does the gateway also need the API ? > > Or is there a more direct way to do so ? > > > > Regarding my questions on the libraries. > > Well, let's say I am a simple user of scilab, with no code development tools installed. > > Editing a c-block, seeing the #include math.h line was a bit scary, because I thought "this will > > require that I have put the math.h file at the good place on my computer". > > So I insert nothing in the code, click "ok" and the compilation is succesful. > > Now after running Scilab 2 c toolbox on my custom code, a number of subdirectories with multiple > > files were created in my custom directory. I suppose if I want this scilab 2 c created code > > running in the c-block, I have to put these files where the block can access them at compilation > > time. > > Same if I created the code on my own. That is why I asked where the c-block compiler looks to find > > the files, or how do we configure this, as users. > > > > Best regards, > > Eric > > > > > > > > > > > > Message du 09/04/18 09:37 > > > > De : "Cl?ment David" > > > > A : "dev at lists.scilab.org" > > > > Copie ? : > > > > Objet : Re: [Scilab-Dev] New xcos blocks executing scilab primitive functions > > > > > > > > Hi Eric and welcome :) > > > > > > > > Nice to have some power users (and maybe futur developers) using big Xcos models, Xcos in > > > 6.0.x have > > > > some issues only visible on big diagrams and we currently do not spend too much time > > > benchmarking > > > > it. > > > > > > > > About the scifunc vs Superbloc vs C++ implementation speedup, the clear winner there would be > > > C/C++ > > > > if (and only if) there is no event management (either discrete or zero-crossing) to perform. > > > Zero > > > > crossing detection is hard to implement even for small sub-systems and discrete events are > > > only easy > > > > for synchronous subsystem. Superblocs are straightforward to implement and manage very complex > > > > events / continuous states intrication in a clean manner however they can be confusing to > > > maintains > > > > (for exemple if you want to preserve the same behavior across different blocks). Scifunc are > > > in- > > > > between to me in term of implementation however very poor in term of performance (and not > > > optimized > > > > at all). > > > > > > > > You could use the scicos_block4 API (the default one) in C or C++ ; if you take a look at our > > > source > > > > code there is only a few in C++ but they can be easily converted to. About the libraries, I > > > did not > > > > get it, do you want to link to different libraries ? The xcos_toolbox_skeleton and > > > ilib_for_build() > > > > flags are working well. > > > > > > > > To call Scilab script within the sciblk2 [1] and sciblk4 [2] blocks we are indeed using the > > > Scilab > > > > C++ API, the performance overhead is quiet clear as we are currently allocating Scilab > > > types::Double > > > > or a types::MList through createblklist() for each output on each simulation step. This does > > > an > > > > extra allocation (for the Scilab datatype) and a copy (for the data copy to scilab) whereas in > > > C/C++ > > > > the data are passed by reference to the shared buffers. We clearly have to do better there ; > > > maybe > > > > by allocating only once (at Initialization time) or passing types:: views to the shared > > > buffers. > > > > There is a test case within xcos_toolbox_skeleton which switch the implementation of a NOOP > > > block > > > > (that compute nothing) between Scilab and C depending on a parameter in Scilab. > > > > > > > > [1]: http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/sciblk2.cpp#n57 > > > > [2]: http://cgit.scilab.org/scilab/tree/scilab/modules/scicos/src/cpp/sciblk4.cpp#n217 > > > > > > > > As a conclusion, yes you can call C++ functions from blocks and Scilab blocks issues comes > > > from a > > > > slow implementation of C->Scilab calls not from the Scilab code interpretation. > > > > > > > > NB: yes this a known problem and some users already reports that but no one is currently > > > working on > > > > that. > > > > > > > > Thanks, > > > > > > > > -- > > > > Cl?ment > > > > > > > > Le vendredi 06 avril 2018 ? 05:47 -0700, ericgernot a ?crit : > > > > > Hi, > > > > > > > > > > I am new to scilab, and I am not a developper, but I fear I may become one > > > > > because of Scilab :-; > > > > > I am on windows 7 /64, and installed some recent versions. > > > > > > > > > > I created a physic model (chemical process with compositions, streams, etc.) > > > > > from a script and used xcos to solve it, only using Sci_func blocks calling > > > > > my functions (so that it is easily portable to other scilab versions). It > > > > > works as desired, so now I want to speed it up. > > > > > > > > > > After all the possible improvements from vectorization, I decided to convert > > > > > 30% of my scifunc into superblocks, giving a 30% speedup boost to the model. > > > > > I could have written these in c/c++ also, but I suspect it would have taken > > > > > longer (for me) > > > > > > > > > > My remaining scifunc blocks are using some scilab gateways such as fsolve, > > > > > diag, etc, thus the conversion is not as straighforward. > > > > > > > > > > I tried to convert it in c using the scilab 2 c toolbox, this is great for > > > > > all operations exept scilab gateways. > > > > > > > > > > I had a look at how to create a new block, how the c-block work, and finally > > > > > how existing blocks are coded in c++. > > > > > > > > > > If I understand well, the possibilities are > > > > > 1. copy the c++ primitive function code in a c-block, it will not work > > > > > because it is not c, and because I don't know which libraries should be > > > > > included. By the way, where can I put them so that the compiler finds them ? > > > > > 2. use scilab API from a xcos c-block and send jobs. Will it really skip the > > > > > interpreter ? > > > > > 3. create a new block as a user (from within scilab). But you can't use c++ > > > > > can you ? So I have to write or find c equivalent of scilab primitives, this > > > > > is a pity ! > > > > > 4. create a new block source code, and compile a new version of scilab with > > > > > the new block. I suppose that the same problem exists: converting to c > > > > > scilab primitives ? > > > > > > > > > > So this raised a few questions: > > > > > - In the block source code, why not call scilab built in functions in c/c++ > > > > > (not the gateway), only passing them the block arguments / parameters, > > > > > instead of pasting the code there. That would ease the creation of new > > > > > blocks isn't it ? > > > > > - can users call these built in functions in their custom blocks (e.g. > > > > > c-block) ? (I mean without invoking the parser etc., without linking already > > > > > linked libraries, etc.) > > > > > > > > > > I suppose that many users ran through these problems. > > > > > Thank you very mucn > > > > > Regards, > > > > > Eric > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Sent from: http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944. > > > html > > > > > _______________________________________________ > > > > > dev mailing list > > > > > dev at lists.scilab.org > > > > > http://lists.scilab.org/mailman/listinfo/dev _______________________________________________ > > > dev mailing list dev at lists.scilab.org http://lists.scilab.org/mailman/listinfo/dev > > > > _______________________________________________ > > dev mailing list > > dev at lists.scilab.org > > http://lists.scilab.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev at lists.scilab.org http://lists.scilab.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev at lists.scilab.org http://lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Wed Apr 11 15:36:49 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Wed, 11 Apr 2018 15:36:49 +0200 Subject: [Scilab-Dev] Question about partial fix of bug #15523 Message-ID: Hello devs, As I said in http://bugzilla.scilab.org/show_bug.cgi?id=15523#c4, there is a an easy fix to repair mode %ODEOPTIONS(1)=2 for the "rkf" solver. In fact, lines 189-90 of this file if(itask.eq.1) then iflag=1 if(itask.eq.2) then iflag=-1 appear as completely *dumb* as fortran compilers (at least gfortran on OSX) silently ignore the code following a "then" on the same line. The following program : ?????? program dumb_program ????????? flag=0 ????????? if (flag.eq.0) then flag=1/flag ????????? print *,flag ?????? end program dumb_program gives the output ?? 0.00000000 Even by using -Wall no warning is produced at compilation. Anyway, there are only two allowed forms: -short form: if (flag.eq.0) flag=1/flag -long form: if (flag.eq.0) then ??? flag=1/flag endif And the fixed program works as expected ?????? program dumb_program ????????? flag=0 ????????? if (flag.eq.0) flag=1/flag ????????? print *,flag ?????? end program dumb_program as the output is ???????? Infinity Hence, my question is: can I create a small patch for "rkf" solver, commited to 6.0 branch, and keep the improvements to 'rk' solver for master ? S. -- 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 From stephane.mottelet at utc.fr Wed Apr 11 15:40:43 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Wed, 11 Apr 2018 15:40:43 +0200 Subject: [Scilab-Dev] Question about partial fix of bug #15523 In-Reply-To: References: Message-ID: I forgot to give the path to the source file: scilab/modules/differential_equations/src/fortran/rkf45.f Le 11/04/2018 ? 15:36, St?phane Mottelet a ?crit?: > Hello devs, > > As I said in http://bugzilla.scilab.org/show_bug.cgi?id=15523#c4, > there is a an easy fix to repair mode %ODEOPTIONS(1)=2 for the "rkf" > solver. In fact, lines 189-90 of this file > > if(itask.eq.1) then iflag=1 > if(itask.eq.2) then iflag=-1 > > appear as completely *dumb* as fortran compilers (at least gfortran on > OSX) silently ignore the code following a "then" on the same line. The > following program : > > ?????? program dumb_program > ????????? flag=0 > ????????? if (flag.eq.0) then flag=1/flag > ????????? print *,flag > ?????? end program dumb_program > > gives the output > > ?? 0.00000000 > > Even by using -Wall no warning is produced at compilation. Anyway, > there are only two allowed forms: > > -short form: > > if (flag.eq.0) flag=1/flag > > -long form: > > if (flag.eq.0) then > ??? flag=1/flag > endif > > And the fixed program works as expected > > ?????? program dumb_program > ????????? flag=0 > ????????? if (flag.eq.0) flag=1/flag > ????????? print *,flag > ?????? end program dumb_program > > as the output is > > ???????? Infinity > > Hence, my question is: can I create a small patch for "rkf" solver, > commited to 6.0 branch, and keep the improvements to 'rk' solver for > master ? > > S. > > -- 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 From Clement.David at esi-group.com Thu Apr 12 11:39:48 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Thu, 12 Apr 2018 09:39:48 +0000 Subject: [Scilab-Dev] Question about partial fix of bug #15523 In-Reply-To: References: Message-ID: <1523525987.11713.3.camel@esi-group.com> Hello St?phane, As this change can have an impact on existing code (even if the previous is incorrect) could please fix it in master ? Thanks, -- Cl?ment Le mercredi 11 avril 2018 ? 15:40 +0200, St?phane Mottelet a ?crit : > I forgot to give the path to the source file: > > scilab/modules/differential_equations/src/fortran/rkf45.f > > Le 11/04/2018 ? 15:36, St?phane Mottelet a ?crit : > > Hello devs, > > > > As I said in http://bugzilla.scilab.org/show_bug.cgi?id=15523#c4, > > there is a an easy fix to repair mode %ODEOPTIONS(1)=2 for the "rkf" > > solver. In fact, lines 189-90 of this file > > > > if(itask.eq.1) then iflag=1 > > if(itask.eq.2) then iflag=-1 > > > > appear as completely *dumb* as fortran compilers (at least gfortran on > > OSX) silently ignore the code following a "then" on the same line. The > > following program : > > > > program dumb_program > > flag=0 > > if (flag.eq.0) then flag=1/flag > > print *,flag > > end program dumb_program > > > > gives the output > > > > 0.00000000 > > > > Even by using -Wall no warning is produced at compilation. Anyway, > > there are only two allowed forms: > > > > -short form: > > > > if (flag.eq.0) flag=1/flag > > > > -long form: > > > > if (flag.eq.0) then > > flag=1/flag > > endif > > > > And the fixed program works as expected > > > > program dumb_program > > flag=0 > > if (flag.eq.0) flag=1/flag > > print *,flag > > end program dumb_program > > > > as the output is > > > > Infinity > > > > Hence, my question is: can I create a small patch for "rkf" solver, > > commited to 6.0 branch, and keep the improvements to 'rk' solver for > > master ? > > > > S. > > > > > > From stephane.mottelet at utc.fr Thu Apr 12 12:30:55 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Thu, 12 Apr 2018 12:30:55 +0200 Subject: [Scilab-Dev] Question about partial fix of bug #15523 In-Reply-To: <1523525987.11713.3.camel@esi-group.com> References: <1523525987.11713.3.camel@esi-group.com> Message-ID: I have another question: the fix for 'rk' and 'rkf' (http://bugzilla.scilab.org/15523) will be visible only if http://bugzilla.scilab.org/15527 is solved before. However, I have proposed the fix for bug 15527 in 6.0 as this bug really breaks ode. So please tell me if you want to -group fixes for bugs 15523, 1527 for master or -fix bug 15527 in 6.0, wait for weekly 6.0->master merge,? then fix bug 15523 on master In any case https://codereview.scilab.org/#/c/19946/ needs a review from the team. S. Le 12/04/2018 ? 11:39, Cl?ment David a ?crit?: > Hello St?phane, > > As this change can have an impact on existing code (even if the previous is incorrect) could please > fix it in master ? > > Thanks, > > -- > Cl?ment > > Le mercredi 11 avril 2018 ? 15:40 +0200, St?phane Mottelet a ?crit : >> I forgot to give the path to the source file: >> >> scilab/modules/differential_equations/src/fortran/rkf45.f >> >> Le 11/04/2018 ? 15:36, St?phane Mottelet a ?crit : >>> Hello devs, >>> >>> As I said in http://bugzilla.scilab.org/show_bug.cgi?id=15523#c4, >>> there is a an easy fix to repair mode %ODEOPTIONS(1)=2 for the "rkf" >>> solver. In fact, lines 189-90 of this file >>> >>> if(itask.eq.1) then iflag=1 >>> if(itask.eq.2) then iflag=-1 >>> >>> appear as completely *dumb* as fortran compilers (at least gfortran on >>> OSX) silently ignore the code following a "then" on the same line. The >>> following program : >>> >>> program dumb_program >>> flag=0 >>> if (flag.eq.0) then flag=1/flag >>> print *,flag >>> end program dumb_program >>> >>> gives the output >>> >>> 0.00000000 >>> >>> Even by using -Wall no warning is produced at compilation. Anyway, >>> there are only two allowed forms: >>> >>> -short form: >>> >>> if (flag.eq.0) flag=1/flag >>> >>> -long form: >>> >>> if (flag.eq.0) then >>> flag=1/flag >>> endif >>> >>> And the fixed program works as expected >>> >>> program dumb_program >>> flag=0 >>> if (flag.eq.0) flag=1/flag >>> print *,flag >>> end program dumb_program >>> >>> as the output is >>> >>> Infinity >>> >>> Hence, my question is: can I create a small patch for "rkf" solver, >>> commited to 6.0 branch, and keep the improvements to 'rk' solver for >>> master ? >>> >>> S. >>> >>> >> > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -- 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 From gernot.eric at wanadoo.fr Thu Apr 12 17:46:51 2018 From: gernot.eric at wanadoo.fr (Eric GERNOT) Date: Thu, 12 Apr 2018 17:46:51 +0200 (CEST) Subject: [Scilab-Dev] New xcos blocks executing scilab primitive functions Message-ID: <1199295227.18689.1523548011879.JavaMail.www@wwinf1p18> Hi Cl?ment, ? I hope you may help me spare some tests ! ? Regarding Scifunc blocks, in sciblk4, createblklist() uses vartosci(..) to reshape the inptr, yet it does only copy the adresses in a new table of pointers, not the actual data, isn't it? Do you thing this address copying is the time consumming operation ? ? I found 2 stranges things: 1) vartosci(..) creates a List with appends in a for loop, and the data is stored in a vector m_plData. That means each time the vector capacity is reached, it "reallocates it in order to grow in size when new elements are inserted, which implies allocating a new array and moving all elements to it". Is a memory allocation strategy defined somewhere in Scilab for TList, List and Typed_list. ? 2) createblklist(...) creates a TList whose values are also stored in a vector container m_plData, which is also dynamically allocated and may be recreated each time capacity is reached, by the append method. ? Thus, in sciblk4, could we call static types::InternalType* pIT = createblklist(...) and in.push_back(pIT) only when flag is on initialization, so that all Lists are created once and only updated at each iteration ? Would it help ? That would require to rewrite vartosci() and createblklist() with a iterator approach instead of append. ? Regards, Eric ? ? ? > Message du 09/04/18 09:37 > De : "Cl?ment David" > A : "dev at lists.scilab.org" > Copie ? : > Objet : Re: [Scilab-Dev] New xcos blocks executing scilab primitive functions > > To call Scilab script within the sciblk2 [1] and sciblk4 [2] blocks we are indeed using the Scilab > C++ API, the performance overhead is quiet clear as we are currently allocating Scilab types::Double > or a types::MList through createblklist() for each output on each simulation step. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Sat Apr 14 14:56:34 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 14 Apr 2018 14:56:34 +0200 Subject: [Scilab-Dev] Specific errors numbers: true removal becoming a unique flag, or ghosty ones? In-Reply-To: <3baf5d8e-e410-0f29-8d6d-34667790dc45@free.fr> References: <3baf5d8e-e410-0f29-8d6d-34667790dc45@free.fr> Message-ID: <17d5a280-81a5-e48b-6e7c-f0db4e10a300@free.fr> Allo? Le 01/02/2018 ? 16:12, Samuel Gougeon a ?crit : > Dear ESI-Scilab devs, > > Errors numbers are announced as removed in Scilab 6. Yet, some related > features are still active, for instance: > > --> error(123) > error: Wrong type for input argument #1: string expected. // OK > > --> error(123, "message") // Is this syntax intended to be kept? > message > > --> [t, n] = lasterror() > n = > 123. > > t = > message > > --> execstr("error(456, ""message"")", "errcatch") > ans = > 456. > > > It looks a bit hard to remove the 2nd lasterror() output, because this > would shift last ones (max 4 argouts), and so trigger > back-compatibility issues for nothing. > > But for lasterror() as for execstr(), the question is, noticeably to > be able to update the documentation in a relevant and reliable way: > Are specific errors numbers planned to still be possible --then, what > for? --, or will a unique 10000 error number be used as a filling > output for lasterror() and as a simple output flag for execstr()? > > There is also the case of the 999 error number heavily used in the > hard code. If 2 distinct error numbers are kept as "standard" flags, i > guess that the distinct meaning of each of them shall be explained.. > > Looking forward to reading you What i understand: * Contrarily to what has been announced: error numbers are not removed 6.0 CHANGES: Feature changes and additions o |error|: an error number in the input is deprecated. => This is wrong * In Scilab 6: o There is no longer any dedicated specific error numbers for some frequent error messages: numbers and messages are now independent. They are just 2 ways to tag an error. o As a consequence: error() can no longer be called only with a number. Indeed, an explicit message must now be provided, since now no message is ascribed to a number Is this right? Can we go with this description, or do you really want to deprecate numbers and actually remove them in 6.1 or later? Thanks Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Clement.David at esi-group.com Mon Apr 23 11:44:45 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Mon, 23 Apr 2018 09:44:45 +0000 Subject: [Scilab-Dev] New xcos blocks executing scilab primitive functions In-Reply-To: <1199295227.18689.1523548011879.JavaMail.www@wwinf1p18> References: <1199295227.18689.1523548011879.JavaMail.www@wwinf1p18> Message-ID: <1524476684.2277.47.camel@esi-group.com> Hello Eric, (answered inline) > Regarding Scifunc blocks, in sciblk4, createblklist() uses vartosci(..) to reshape the inptr, yet > it does only copy the adresses in a new table of pointers, not the actual data, isn't it? Do you > thing this address copying is the time consumming operation ? Yep exactly, allocating the ScilabList and ScilabDouble scalars for each inputs and on each time step is a big overhead comparing to passing pointers around as in the C interface. > I found 2 stranges things: > 1) vartosci(..) creates a List with appends in a for loop, and the data is stored in a vector > m_plData. That means each time the vector capacity is reached, it "reallocates it in order to grow > in size when new elements are inserted, which implies allocating a new array and moving all > elements to it". > Is a memory allocation strategy defined somewhere in Scilab for TList, List and Typed_list. That part should not be the issue as, after being cached, the TList will not be resized not reallocated. > 2) createblklist(...) creates a TList whose values are also stored in a vector container m_plData, > which is also dynamically allocated and may be recreated each time capacity is reached, by the > append method. > > Thus, in sciblk4, could we call static types::InternalType* pIT = createblklist(...) and > in.push_back(pIT) only when flag is on initialization, so that all Lists are created once and only > updated at each iteration ? Would it help ? That would require to rewrite vartosci() and > createblklist() with a iterator approach instead of append. Yep this will slightly increase the performance ; for example, the TList returned by createblklist() could be stored on the work opaque pointer at the "Initialization" and deleted at the "Ending" phase (before and after calling the Scilab function). And then before calling the function, cast the work pointer back to a TList, sync the incomes (inptr, z and x variables) call the function, sync the outcomes. Regards, -- Cl?ment > > Message du 09/04/18 09:37 > > De : "Cl?ment David" > > A : "dev at lists.scilab.org" > > Copie ? : > > Objet : Re: [Scilab-Dev] New xcos blocks executing scilab primitive functions > > > > > > To call Scilab script within the sciblk2 [1] and sciblk4 [2] blocks we are indeed using the > Scilab > > C++ API, the performance overhead is quiet clear as we are currently allocating Scilab > types::Double > > or a types::MList through createblklist() for each output on each simulation step. > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From sgougeon at free.fr Mon Apr 23 18:25:43 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Mon, 23 Apr 2018 18:25:43 +0200 Subject: [Scilab-Dev] 1 boolean = 4 bytes => 1 byte ? Message-ID: <0b3c5aec-d0ce-521b-4061-150e93ab57ff@free.fr> Hello, As reported @ http://bugzilla.scilab.org/12789 in 2013 (so 2 years before the first 6.0 alpha release), in Scilab 5 each boolean takes 4 bytes to be stored. It is 4 times more than an easy storage and handling with 1 byte per boolean, and 32 times more than a memory optimum with 8 booleans per byte. Since [names, memory]=who(..) is broken in Scilab 6, i did not check that this poor memory usage is still actual in 6.0. Assuming that it is the case, then, what would imply to change the storage -- say with 1 byte per boolean -- * in terms of implementation : would it be heavy to implement? * in terms of back-compatibility : would it have a big impact? Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: