From stephane.mottelet at utc.fr Fri May 4 11:00:24 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 4 May 2018 11:00:24 +0200 Subject: [Scilab-Dev] Critical regression Message-ID: Hello all, There is a critical regression in 6.0.1 w.r.t 5.5.2 for cacsd functions http://bugzilla.scilab.org/show_bug.cgi?id=15562 ss2tf, zpk, and maybe some others are broken. Any help to find where the problem resides is welcome ! 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 May 4 13:21:30 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 4 May 2018 13:21:30 +0200 Subject: [Scilab-Dev] Critical regression In-Reply-To: References: Message-ID: <000c99ec-047e-9c94-38e0-23a58c6bf163@utc.fr> Le 04/05/2018 ? 11:00, St?phane Mottelet a ?crit?: > Hello all, > > There is a critical regression in 6.0.1 w.r.t 5.5.2 for cacsd functions > > http://bugzilla.scilab.org/show_bug.cgi?id=15562 > > ss2tf, zpk, and maybe some others are broken. Any help to find where > the problem resides is welcome ! > > S. > > I cannot believe that such a trivial property (undergraduate math. level) has not been taken into account: the characteristic polynomial of a real matrix has real coefficients. I am very disappointed because this problem was easy to detect before the initial release of Scilab 6.0, since test_run cascd ss2tf fails. See the proposed fix @ https://codereview.scilab.org/#/c/20004/ -- 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 sgougeon at free.fr Fri May 4 16:12:02 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 4 May 2018 16:12:02 +0200 Subject: [Scilab-Dev] doc: inclusion Message-ID: <1371a0d7-6809-b06a-fe97-e27930b3fabe@free.fr> Dear devs and authors, When writting or improving some documentation pages, in many occasions it would be great to share some XML parts between several XML files. This would avoid very heavy synchronization issues: when a part is changed in a file, it must be changed in the same way in N other files.. This is a common and important concern, a very time-consuming one. The tag already allows to do it for Scilab pages. The Scilab documentation builder already supports it. This tag is being documented for Scilab. It is already used in only one page (other thousands..), to build the JKFLIPFLOP.xml one. This tag is not properly a docbook one. Its usage is well documented, for instance here: https://msdn.microsoft.com/en-us/library/aa302291.aspx#xinc_topic4 But the Scilab support of has a major issue: the *xpointer=".."* attribute that specifies the targeted tag in the source file, to be included in the destination file, looks to support only the "*element(/i/j/k..)*" syntax .: this means that the tag to be copied is the kth child of the jth child of the ith main tag in the source file. After many trials, i did not find any way how to actually use other much more handy, robust and reliable xpointer syntaxes using tags ids, like simply *xpointer="the_id_of_tag_to_be_imported"*. The /i/j/k addressing is very fragile: As soon as the architecture of the source file is changed -- for instance we insert a section, subsection, paragraph somewhere, and this shifts all indices of following children, and demands to update all /i/j/k references. This present limitation could be the reason why was not more used up to now. It is rather frustrating. In Scilab, the required *xmlns:xi="http://www.w3.org/2001/XInclude"* is dated of 2001. Scilab does not accept the later 2003 release as used in the aa302291.asp documentation page. In 2003, XInclude was still in development. So we may easily think that 2 years earlier in 2001, some xpointer features described in 2003 did not yet exist. To conclude : Would it be possible to make the Scilab documentation builder compliant with the /xmlns:xi="http://www.w3.org///*200*//*3*///XInclude"/ release? Thanks Samuel* * -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri May 4 17:30:20 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 4 May 2018 17:30:20 +0200 Subject: [Scilab-Dev] doc: inclusion In-Reply-To: <1371a0d7-6809-b06a-fe97-e27930b3fabe@free.fr> References: <1371a0d7-6809-b06a-fe97-e27930b3fabe@free.fr> Message-ID: <476b0d5c-8224-925f-83a7-c6de843c8d95@free.fr> Le 04/05/2018 ? 16:12, Samuel Gougeon a ?crit : > > Dear devs and authors, > > When writting or improving some documentation pages, in many occasions > it would be great to share some XML parts between several XML files. > This would avoid very heavy synchronization issues: when a part is > changed in a file, it must be changed in the same way in N other files.. > This is a common and important concern, a very time-consuming one. > > The tag already allows to do it for Scilab pages. The > Scilab documentation builder already supports it. > This tag is being documented for Scilab. It is already used in only > one page (other thousands..), to build the JKFLIPFLOP.xml one. > This tag is not properly a docbook one. Its usage is well documented, > for instance here: > https://msdn.microsoft.com/en-us/library/aa302291.aspx#xinc_topic4 > > But the Scilab support of has a major issue: the > *xpointer=".."* attribute that specifies the targeted tag in the > source file, to be included in the destination file, looks to support > only the "*element(/i/j/k..)*" syntax > .: > this means that the tag to be copied is the kth child of the jth child > of the ith main tag in the source file. > > After many trials, i did not find any way how to actually use other > much more handy, robust and reliable xpointer syntaxes using tags ids, > like simply *xpointer="the_id_of_tag_to_be_imported"*. The /i/j/k > addressing is very fragile: As soon as the architecture of the source > file is changed -- for instance we insert a section, subsection, > paragraph somewhere, and this shifts all indices of following > children, and demands to update all /i/j/k references. > This present limitation could be the reason why was not > more used up to now. > It is rather frustrating. > In Scilab, the required *xmlns:xi="http://www.w3.org/2001/XInclude"* > is dated of 2001. Scilab does not accept the later 2003 release as > used in the aa302291.asp documentation page. In 2003, XInclude was > still in development. So we may easily think that 2 years earlier in > 2001, some xpointer features described in 2003 did not yet exist. > > To conclude : Would it be possible to make the Scilab documentation > builder compliant with the > /xmlns:xi="http://www.w3.org///*200*//*3*///XInclude"/ release? > For information and tests, the template that i use for my own tests is attached: * unzip it * edit ~/help/en_US/get.xml and ~/help/en_US/get.xml with an external editor (Notepad++ is excellent for xml :) * In Scilab, run o --> consolebox on // on Windows o load and exec ~/builder.sce * See the error messages from the doc builder in the consolebox * --> host cls // to clear the consolebox * change the xpointer value in get.xml and/or the id of the examples in get_source.dbk, and rerun builder.sce etc Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xi_include.zip Type: application/x-zip-compressed Size: 18750 bytes Desc: not available URL: From stephane.mottelet at utc.fr Fri May 18 09:03:54 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 18 May 2018 09:03:54 +0200 Subject: [Scilab-Dev] Under Linux, make install fails to make a working standalone Scilab Message-ID: Hello, Under Linux, make install fails to make a working standalone Scilab (here with branch-6.0) I did: make clean ./configure --prefix=/home/mottelet/WORK make make install then, /home/mottelet/WORK/bin/scilab gives me: /home/mottelet/WORK/bin/scilab-bin: error while loading shared libraries: libssl.so.0.9.8: cannot open shared object file: No such file or directory When I saw that the WORK/lib/thirdparty/ folder was missing I made a clone of the thirdparty folder which is part of my git repo in WORK/lib/thirdparty but I still get the same error. What did I miss ? 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 Fri May 18 11:51:56 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Fri, 18 May 2018 09:51:56 +0000 Subject: [Scilab-Dev] Under Linux, make install fails to make a working standalone Scilab In-Reply-To: References: Message-ID: <1526637115.15377.14.camel@esi-group.com> Hello St?phane, This issue (or similar startup issues) comes from a version mismatch on dependencies between configure/build time and run time. You have to ship the same (or compatible) thirdparty within the install dir. By default, the launcher script (at run time) add the directories shipped with the scilab binary. After copying the thirdparty to the same location as in the binary, you should make scilab run. If not, the location you put them might not be good. If you want to debug these things, use : SCIVERBOSE=1 /home/mottelet/WORK/bin/scilab Thanks, -- Cl?ment Le vendredi 18 mai 2018 ? 09:03 +0200, St?phane Mottelet a ?crit : > Hello, > > Under Linux, make install fails to make a working standalone Scilab (here > with branch-6.0) > > I did: > > make clean > ./configure --prefix=/home/mottelet/WORK > make > make install > > then, /home/mottelet/WORK/bin/scilab gives me: > > /home/mottelet/WORK/bin/scilab-bin: error while loading shared libraries: > libssl.so.0.9.8: cannot open shared object file: No such file or directory > > When I saw that the WORK/lib/thirdparty/ folder was missing I made a clone > of the thirdparty folder which is part of my git repo in WORK/lib/thirdparty > > but I still get the same error. What did I miss ? > > S. > From stephane.mottelet at utc.fr Fri May 18 15:17:30 2018 From: stephane.mottelet at utc.fr (stephane.mottelet at utc.fr) Date: Fri, 18 May 2018 13:17:30 +0000 Subject: [Scilab-Dev] Under Linux, make install fails to make a working standalone Scilab In-Reply-To: <1526637115.15377.14.camel@esi-group.com> References: <1526637115.15377.14.camel@esi-group.com> Message-ID: <20180518131730.Horde.SY9_EanYob002Upk-dKPttx@webmail.utc.fr> Hello, Sorry, I thought that I had to use the same directory layout as in the official 6.0.1. Now that I have copied scilab/lib/thirdparty and scilab/thirdparty (.jar files) at the same location in the install folder, scilab seems to start but freezes : ~/WORK$ SCIVERBOSE=1 ./bin/scilab SCILABBIN : scilab-bin DISABLE_JAVA_DETECTION : 0 SCILAB_MODE : gui OS : Linux MODEL : x86_64 IS_SCILAB_BINARY : 0 Trying to find Java in /usr/java/jdk1.8.*/ Trying to find Java in /usr/lib/jvm/java-1.8.0-openjdk-amd64/ Java found in /usr/lib/jvm/java-8-openjdk-amd64 JAVA_HOME : /usr/lib/jvm/java-8-openjdk-amd64 SCI : /home/mottelet/WORK/share/scilab/ SCIBIN : /home/mottelet/WORK/bin/scilab-bin PATH : /home/mottelet/WORK/share/scilab/:/home/mottelet/WORK/share/scilab//bin:/home/mottelet/WORK/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin CLASSPATH : /home/mottelet/WORK/share/scilab//modules/core/jar/org.scilab.modules.core.jar EGL_DRIVER : egl_glx LD_LIBRARY_PATH : /home/mottelet/WORK/share/scilab//lib/thirdparty:/home/mottelet/WORK/share/scilab//bin:/home/mottelet/WORK/share/scilab//lib/scilab/:/home/mottelet/WORK/share/scilab//lib64/scilab/:.:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/native_threads/:/home/mottelet/WORK/share/scilab//lib/thirdparty/redist DOCBOOK : /home/mottelet/WORK/share/scilab//thirdparty/docbook (the script freezes at this point). In -nwni I have the following error : ~/WORK$ SCIVERBOSE=1 ./bin/scilab -nwni SCILABBIN : scilab-cli-bin DISABLE_JAVA_DETECTION : 1 SCILAB_MODE : nwni OS : Linux MODEL : x86_64 IS_SCILAB_BINARY : 0 SCI : /home/mottelet/WORK/share/scilab/ SCIBIN : /home/mottelet/WORK/bin/scilab-cli-bin PATH : /home/mottelet/WORK/share/scilab/:/home/mottelet/WORK/share/scilab//bin:/home/mottelet/WORK/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin CLASSPATH : EGL_DRIVER : LD_LIBRARY_PATH : /home/mottelet/WORK/share/scilab//lib/thirdparty:/home/mottelet/WORK/share/scilab//bin:/home/mottelet/WORK/share/scilab//lib/scilab/:/home/mottelet/WORK/share/scilab//lib64/scilab/:.:/home/mottelet/WORK/share/scilab//lib/thirdparty/redist DOCBOOK : /home/mottelet/WORK/share/scilab//thirdparty/docbook Scilab branch-6.0 (May 18 2018, 08:28:32) Une erreur a ?t? d?tect?e en chargeant /home/mottelet/WORK/share/scilab//modules/functions/.libs/libscifunctions.so : /home/mottelet/WORK/share/scilab//modules/functions/.libs/libscifunctions.so: cannot open shared object file: No such file or directory --> However, the scilab binary runs fine in all modes from the build folder. S. Quoting Cl?ment David : > Hello St?phane, > > This issue (or similar startup issues) comes from a version mismatch > on dependencies between > configure/build time and run time. You have to ship the same (or > compatible) thirdparty within the > install dir. By default, the launcher script (at run time) add the > directories shipped with the > scilab binary. > > After copying the thirdparty to the same location as in the binary, > you should make scilab run. If > not, the location you put them might not be good. If you want to > debug these things, use : > > SCIVERBOSE=1 /home/mottelet/WORK/bin/scilab > > Thanks, > > -- > Cl?ment > > Le vendredi 18 mai 2018 ? 09:03 +0200, St?phane Mottelet a ?crit : >> Hello, >> >> Under Linux, make install fails to make a working standalone Scilab (here >> with branch-6.0) >> >> I did: >> >> make clean >> ./configure --prefix=/home/mottelet/WORK >> make >> make install >> >> then, /home/mottelet/WORK/bin/scilab gives me: >> >> /home/mottelet/WORK/bin/scilab-bin: error while loading shared libraries: >> libssl.so.0.9.8: cannot open shared object file: No such file or directory >> >> When I saw that the WORK/lib/thirdparty/ folder was missing I made a clone >> of the thirdparty folder which is part of my git repo in WORK/lib/thirdparty >> >> but I still get the same error. What did I miss ? >> >> S. > > _______________________________________________ > dev mailing list > dev at lists.scilab.orghttps://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From Clement.David at esi-group.com Tue May 22 11:12:50 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Tue, 22 May 2018 09:12:50 +0000 Subject: [Scilab-Dev] 1 boolean = 4 bytes => 1 byte ? In-Reply-To: <0b3c5aec-d0ce-521b-4061-150e93ab57ff@free.fr> References: <0b3c5aec-d0ce-521b-4061-150e93ab57ff@free.fr> Message-ID: <1526980369.2237.20.camel@esi-group.com> Hello Samuel, After some diving into the ast/types source code and debugging session I got some information : --> disp(%t) // gdb resolved the value as a > where m_iSize = 1 // (the size of the inner m_pRealData) --> disp([%t %f %t %f]) // gdb resolved the value as a > where m_iSize = 4 // (the size of the inner m_pRealData) So in Scilab 6, there is 4 byte per boolean; to me a first thing to do before changing the current implementation is to let `who()` return both the memory used (including the Scilab header) and the memory used by the inner data storage. Note: as discussed in this ML, the overhead per for Scilab datatype (not inner value) is 208 byte per value, to me it is more important to reduce it first as it will impact all ArrayOf based datatype. Thanks, -- Cl?ment Le lundi 23 avril 2018 ? 18:25 +0200, Samuel Gougeon a ?crit : > 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 > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From Clement.David at esi-group.com Tue May 29 21:40:07 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Tue, 29 May 2018 19:40:07 +0000 Subject: [Scilab-Dev] doc: inclusion In-Reply-To: <476b0d5c-8224-925f-83a7-c6de843c8d95@free.fr> References: <1371a0d7-6809-b06a-fe97-e27930b3fabe@free.fr> <476b0d5c-8224-925f-83a7-c6de843c8d95@free.fr> Message-ID: Hello Samuel, After some trial and error as well as debug session to track the issue, it seems that the underlying xpointer implementation (Xerces from JRE) does not support the id syntax. To clarify none of the following works (from http://www.sagehill.net/docbookxsl/ModularDoc.html): Only the fragile (I fully agree with you): Initially I tried to push this usage to restructure the Xcos help pages while preserving the content and setup the JKFLIPFLOP.xml and associated JKFLIPFLOP_content.dbk with this idea. The path approach is acceptable in my case as the content will always be structured. If you wish to share content, another option is to import the whole dbk document using xinclude or to fallback to the ENTITY DTD declaration as in the master xml file. Thanks, -- Cl?ment Le vendredi 04 mai 2018 ? 17:30 +0200, Samuel Gougeon a ?crit : > Le 04/05/2018 ? 16:12, Samuel Gougeon a ?crit : > > Dear devs and authors, > > When writting or improving some documentation pages, in many occasions it would be great to > > share some XML parts between several XML files. This would avoid very heavy synchronization > > issues: when a part is changed in a file, it must be changed in the same way in N other files.. > > This is a common and important concern, a very time-consuming one. > > > > The tag already allows to do it for Scilab pages. The Scilab documentation > > builder already supports it. > > This tag is being documented for Scilab. It is already used in only one page (other > > thousands..), to build the one. > > This tag is not properly a docbook one. Its usage is well documented, for instance here: > > https://msdn.microsoft.com/en-us/library/aa302291.aspx#xinc_topic4 > > But the Scilab support of has a major issue: the xpointer=".." attribute that > > specifies the targeted tag in the source file, to be included in the destination file, looks to > > support only the "element(/i/j/k..)" syntax.: this means that the tag to be copied is the kth > > child of the jth child of the ith main tag in the source file. > > After many trials, i did not find any way how to actually use other much more handy, robust and > > reliable xpointer syntaxes using tags ids, like simply xpointer="the_id_of_tag_to_be_imported". > > The /i/j/k addressing is very fragile: As soon as the architecture of the source file is > > changed -- for instance we insert a section, subsection, paragraph somewhere, and this shifts > > all indices of following children, and demands to update all /i/j/k references. > > This present limitation could be the reason why was not more used up to now. > > It is rather frustrating. > > In Scilab, the required xmlns:xi="http://www.w3.org/2001/XInclude" is dated of 2001. Scilab does > > not accept the later 2003 release as used in the aa302291.asp documentation page. In 2003, > > XInclude was still in development. So we may easily think that 2 years earlier in 2001, some > > xpointer features described in 2003 did not yet exist. > > To conclude : Would it be possible to make the Scilab documentation builder compliant with the > > xmlns:xi="http://www.w3.org/2003/XInclude" release? > > For information and tests, the template that i use for my own tests is attached: > unzip it > edit ~/help/en_US/get.xml and ~/help/en_US/get.xml with an external editor (Notepad++ is > excellent for xml :) > In Scilab, run > --> consolebox on // on Windows > load and exec ~/builder.sce > See the error messages from the doc builder in the consolebox > --> host cls // to clear the consolebox > change the xpointer value in get.xml and/or the id of the examples in > get_source.dbk, and rerun builder.sce etc > Samuel > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From siddhartha.gairola18 at gmail.com Wed May 30 20:32:48 2018 From: siddhartha.gairola18 at gmail.com (Siddhartha Gairola) Date: Thu, 31 May 2018 00:02:48 +0530 Subject: [Scilab-Dev] Reg: Including thirdparty libraries in my source files. Message-ID: Dear Developers, If we are working on a Toolbox which uses the scilab_api and our source files include libraries like *libgl and Eigen* how do we make sure the compiler includes these headers too. I am using - "ilib_build() to compile the files" Same I am trying for the Mex_api in scilab and using "ilib_mex_build()" Headers included - "#include #include #include #include " But it gives the following error - *'''ilib_compile: An error occurred during the compilation:ambient_occlusion.c:1:34: fatal error: igl/matlab/MexStream.h: No such file or directory #include ^compilation terminated.make: *** [ambient_occlusion.lo] Error 1"""* The error is obviously due to *igl* not being linked. How do we specify this to resolve the dependency error? Would be grateful for any help in this direction. Regards, Siddhartha -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed May 30 21:18:54 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 30 May 2018 21:18:54 +0200 Subject: [Scilab-Dev] intppty() <= Re: BLAS use in Scilab In-Reply-To: <6d82edc6-3a68-f7e3-d5b1-755db10ebac9@utc.fr> References: <1518615338745-0.post@n3.nabble.com> <46fbee01-dbcf-104b-aa1f-d9c6d2bd32b1@utc.fr> <1518631624856-0.post@n3.nabble.com> <20180214181500.Horde.6noFgwETGwdsbK9FITULam6@webmail.utc.fr> <20180214200352.Horde.lsHYFRpjelt8p_GJ1NTzzuQ@webmail.utc.fr> <1518648613976-0.post@n3.nabble.com> <1518649368521-0.post@n3.nabble.com> <293ab011-7dba-c3a1-6b7c-b9815a339555@utc.fr> <3daebae7-eba4-a32c-5e1e-c403ece6f5fa@scilab-enterprises.com> <1553ecbc-2120-9236-3e8e-b32eb09811e4@utc.fr> <6d82edc6-3a68-f7e3-d5b1-755db10ebac9@utc.fr> Message-ID: <5535f904-ed22-4034-8de7-5b3c83d76da0@free.fr> Le 22/02/2018 ? 14:18, St?phane Mottelet a ?crit : > Really, nobody knows ? > > S. > > Le 20/02/2018 ? 11:57, St?phane Mottelet a ?crit : >> Hello, >> >> Continuing on this subject, Hello, I discovered that the new Scilab >> API allows to modify input parameters of a function (in-place >> assignment), e.g. I have modified the previous daxpy such that the >> expression >> >> daxpy(2,X,Y) >> >> has no output but formally does "Y+=2*X" if such an operator would >> exist in Scilab. In this case there is no matrix copy at all, hence >> no memory overhead. >> >> Was it possible to do this with the previous API ? On this topic: the strange builtin function intppty() has been continued in Scilab 6: https://help.scilab.org/docs/6.0.1/en_US/intppty.html Unfortunately, the page has no example. And some words look not up-to-date: /Warning: declaring that the interface with number////|fun|////can../. Actually, fun is no longer the numerical id of the gateway, but its literal name. What's hard to understand for me is that intppty() applies to all functions of a gateway, not one by one. By the way, the requirement to make a gateway or a builtin function "switchable" is unclear. When testing intppty() with an arbitrary gateway name that matches none of Scilab ones, it does not complain. Some benchmarks would be welcome to illustrate the actual action of this function. Best regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ScilabWarning.png Type: image/png Size: 603 bytes Desc: not available URL: From sgougeon at free.fr Thu May 31 12:06:07 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 31 May 2018 12:06:07 +0200 Subject: [Scilab-Dev] doc: inclusion In-Reply-To: References: <1371a0d7-6809-b06a-fe97-e27930b3fabe@free.fr> <476b0d5c-8224-925f-83a7-c6de843c8d95@free.fr> Message-ID: Hello Cl?ment, Le 29/05/2018 ? 21:40, Cl?ment David a ?crit : > Hello Samuel, > > After some trial and error as well as debug session to track the issue, it seems that the underlying > xpointer implementation (Xerces from JRE) does not support the id syntax. To clarify none of the > following works (from http://www.sagehill.net/docbookxsl/ModularDoc.html): > > > > > > Only the fragile (I fully agree with you): > > > > Initially I tried to push this usage to restructure the Xcos help pages while preserving the content > and setup the JKFLIPFLOP.xml and associated JKFLIPFLOP_content.dbk with this idea. The path approach > is acceptable in my case as the content will always be structured. > > If you wish to share content, another option is to import the whole dbk document using xinclude or > to fallback to the ENTITY DTD declaration as in the master xml file. Thanks for your input. If i well understand your answer, upgrading the Scilab support of to a 2003 release is either not relevant, or not applicable, or would not extend xpointer usages. It is rather disappointing, but ok, i am taking note of it. The workarounds that you indicate at the end are not clear to be. I must spend additional time to see what's possible, test things, and if it's actually worthwhile to go this way versus time to maintain/update such a documentation structure. Regards Samuel From sgougeon at free.fr Thu May 31 12:42:29 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 31 May 2018 12:42:29 +0200 Subject: [Scilab-Dev] 1 boolean = 4 bytes => 1 byte ? In-Reply-To: <1526980369.2237.20.camel@esi-group.com> References: <0b3c5aec-d0ce-521b-4061-150e93ab57ff@free.fr> <1526980369.2237.20.camel@esi-group.com> Message-ID: <8ec9ec2d-c08a-ba30-0b6d-303a06d298de@free.fr> Hello Cl?ment, Le 22/05/2018 ? 11:12, Cl?ment David a ?crit : > Hello Samuel, > > After some diving into the ast/types source code and debugging session I got some information : > > --> disp(%t) > // gdb resolved the value as a > where m_iSize = 1 > // (the size of the inner m_pRealData) > --> disp([%t %f %t %f]) > // gdb resolved the value as a > where m_iSize = 4 > // (the size of the inner m_pRealData) > > So in Scilab 6, there is 4 byte per boolean; to me a first thing to do before changing the current > implementation is to let `who()` return both the memory used (including the Scilab header) and the > memory used by the inner data storage. > > Note: as discussed in this ML, the overhead per for Scilab datatype (not inner value) is 208 byte > per value, to me it is more important to reduce it first as it will impact all ArrayOf based > datatype. So, i understand that it is hard, or even impossible, or useless, to assess the impact of a change in term of back-compatibility wrt existing datafiles. I understand also that the Scilab devs team has finally decided -- at least as a first step -- to retrieve the former who() behavior to get the memory, so including the Scilab header. To me, it would be anyway better to drop the "word" unit (set of 8 bytes) and to return the memory preferably /in bytes/. Beyond the recovery of [x,mem]=who(..), this would already be an improvement. As far as i understand it -- what's not sure --, i am not convinced by the last point, in terms of priority. The main concern of the initial report is the better usage of the memory, noticeably when doing operations on big arrays with big intermediate boolean arrays. Some operations may fail because of insufficient intermediate memory. Now, even if 1000 variables are simultaneously defined in the workspace -- this never happens, but let's assume it is so --, and that each one takes 208 bytes (really per value ?? i assume it is rather per container. Is it right?), then this uses 208 kbytes, what's nothing. Now, if a single boolean array is defined and used to process a whole 1000x1000x4 RGBA image, it uses alone 16 MB instead of 4MB, that's >>> 208 kbytes. Avoiding to waste these 12 MB was the main aim of my initial report. Please correct me if my calculations are wrong, with respect to this aim. Best regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Thu May 31 15:18:06 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Thu, 31 May 2018 15:18:06 +0200 Subject: [Scilab-Dev] Scilab and Jupyter Message-ID: Hello, Does somebody know if this work https://summerofcode.withgoogle.com/archive/2016/projects/6165785793789952/ led to subsequent developments into scilab ? E.g. does it have something in common with https://scilab.io/cloud/ ? 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