From communication at scilab-enterprises.com Mon Jun 1 15:23:26 2015 From: communication at scilab-enterprises.com (Scilab Communications) Date: Mon, 01 Jun 2015 15:23:26 +0200 Subject: [Scilab-Dev] ScilabTEC 2015 : Exchanges with passion Message-ID: <556C5CCE.7010804@scilab-enterprises.com> Dear Scilab Users, The 7th edition of the International Scilab Users Conference, hosted at Mozilla Space in Paris on May 21 & 22, has been a real success. ScilabTEC attendees have been able to enjoy two days of presentations about innovative applications using Scilab and of fruitful networking moments. We, the Scilab team, want to express our sincere thanks to the community, the speakers and all the attendees for coming together to network, exchange ideas, learn and also have fun with us! Presentations will be available shortly. Meanwhile, you can consult the photos of the event at https://plus.google.com/+scilab/posts/DaDTztgcZtb See you at ScilabTEC 2016! -- Communication Department, Scilab Enterprises 143bis rue Yves Le Coz - 78000 Versailles (France) http://www.scilab-enterprises.com - http://www.scilab.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From priyankahiranandani at gmail.com Mon Jun 1 10:52:07 2015 From: priyankahiranandani at gmail.com (priyanka hiranandani) Date: Mon, 1 Jun 2015 04:52:07 -0400 Subject: [Scilab-Dev] dev@lists.scilab.org Message-ID: I am working on implementing Image Processing Toolbox in Scilab. For that I am implementing Opencv functions in Scilab through C++ using functions defined in Scilab API "api_scilab.h". I am unable to return 3D matrices (which is returned by opencv function) through my C++ code to Scilab console. Currently, I am converting 3DMatrix to 1D Matrix, return it and convert 1D matrix back to 3D matrix whenever required. Is there any function in Scilab API by which I can directly return or pass 3D matrix as argument. Is there any other way I can return 3D matrix back to Scilab? Imread function is shown below: Mat img = imread(pstData[0],CV_LOAD_IMAGE_UNCHANGED); //3 dimensional matrix is returned from imread function //pstData[0] contains path of image int *n = NULL; n = (int*)malloc(sizeof(int) *img.rows *img.cols *3); //creating one dimensional matrix using malloc statement int i,j,k=0,r,b,g; for(int i = 0;i < img.rows;i++){ cv::Vec3b* pixel = img.ptr(i); //this is where i am assigning 3 dimensional RGB values into 1 dimensional array for(int j = 0;j < img.cols;j++){ n[k]=pixel[j][2];k++; //that is my problem "is there any function defined in "api_scilab.h" with help of which we can directly n[k]=pixel[j][1];k++; //pass 3 Dimensional matrix instead of converting into 1 dimensional matrix. n[k]=pixel[j][0];k++; } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From sejalpareshbhaivaghela at gmail.com Fri Jun 5 08:05:06 2015 From: sejalpareshbhaivaghela at gmail.com (Sejal Vaghela) Date: Fri, 5 Jun 2015 11:35:06 +0530 Subject: [Scilab-Dev] SCILAB demo (animation of 2d figure using drawnow and drawlater) Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: circle.sci Type: application/octet-stream Size: 489 bytes Desc: not available URL: From sgougeon at free.fr Wed Jun 10 00:03:07 2015 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 10 Jun 2015 00:03:07 +0200 Subject: [Scilab-Dev] save(..) with internal timestamp? MD5 varying with unchanged content to be saved. Message-ID: <5577629B.8050509@free.fr> Hi, I have N figures. I would like to re-export only those that were modified in the meanwhile. Indeed, exporting with xs2### is rather time-consuming, in such a way that i am looking for a short-circuit. The way that i imagined is the following, for a figure of handle f : 1) f is saved in file1.sod. This is quite faster than exporting. 2) later, f is re-saved in file2.sod 3) we compute the MD5 checksums of the contents of file1.sod and file2.sod 4) we compare both checksums. If they are different, we re-export f. Unfortunately, it looks that save(..) likely saves also an internal timestamp, or something varying external to the main saved content. This ruins the idea, and i do not see any reflief plan. Here is a proof: clf plot2d() f = gcf(); save test.sod f getmd5 test.sod sleep(5000) save test.sod f getmd5 test.sod Yielding: -->clf -->plot2d() -->f = gcf(); -->save test.sod f -->getmd5 test.sod ans = e015481486eb9708a4fe1d3df1cbbbb9 -->sleep(5000) -->save test.sod f -->getmd5 test.sod ans = 3c6319b5d3a2299caaacc2f95c3efb32 Other tests show that 1) renaming the file does not change its checksum returned by getmd5() 2) modifying the OS timestamp of the file (any of creation, last access, last write) does not change its checksum. Hence, it really looks that an internal timestamp is recorded with the proper data. So, my questions are : 1) do -- you developers -- confirm this save()'s behavior? I did you go the the source code. 2) Why doing that? Is is on purpose, or is it a bug? 3) Is there a way to avoid it? a) There is presently no usage option to avoid it b) On option, recording only the date with a fixed conventionnal hour such that 00:00:00.000 would be ok for me. 10s of export is <<< 24h ;) 4) Would you have any idea to do what i expect with figures, without using their saved handles? I posted a wish and proposal http://bugzilla.scilab.org/show_bug.cgi?id=11658 3 years ago, in order to open the possibillity to save copies of handles (in structures) and then becomes able to compare them. But the thread does not breathe... Reading you soon Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Jun 10 00:29:13 2015 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 10 Jun 2015 00:29:13 +0200 Subject: [Scilab-Dev] freeing the "@" symbol? Message-ID: <557768B9.3050905@free.fr> Hi, The symbols documentation page states that For historical reasons, different symbols may represent the same operator: { as the same meaning as [ } as the same meaning as ] @ as the same meaning as ~ ` as the same meaning as < It is highly recommended not to use these features because they will be removed in the future. But the future is now. Is there any plan to free "@" (instead of removing it)? Actually, i do not intend to set a liberation committee for that, but it could be useful for instance as a new free overloadable binary operator. Free symbols available on all keyboards and not so numerous. "@" would be a good guy. Read you soon Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From clement.david at scilab-enterprises.com Wed Jun 10 09:36:01 2015 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Wed, 10 Jun 2015 09:36:01 +0200 Subject: [Scilab-Dev] save(..) with internal timestamp? MD5 varying with unchanged content to be saved. In-Reply-To: <5577629B.8050509@free.fr> References: <5577629B.8050509@free.fr> Message-ID: <1433921761.4643.11.camel@scilab-enterprises.com> Hi Samuel, For the record, I checked and even if the md5sum of the two files are different, the h5diff tool does not report any difference. That's weird ! On a more advanced analysis, I converted the sod binary files to hexdump (using xxd on linux) and got a multiple one char diff on something which may be an entry descriptor located just before the "SCILAB_Class" string value. Extracted reduced hexdiff : diff -C 5 <(xxd test1.sod) <(xxd test2.sod) *** 9271,9281 **** 0024360: 0100 0000 0000 0000 0100 0000 0000 0000 ................ 0024370: 0300 0800 0100 0000 1700 0000 0800 0000 ................ 0024380: 0500 0800 0100 0000 0202 0201 0000 0000 ................ 0024390: 0800 1800 0100 0000 0301 f8fd 0100 0000 ................ 00243a0: 0000 0800 0000 0000 0000 0000 0000 0000 ................ ! 00243b0: 1200 0800 0000 0000 0100 0000 23e4 7755 ............#.wU 00243c0: 0c00 4000 0000 0000 0100 0d00 0800 1800 .. at ............. 00243d0: 5343 494c 4142 5f43 6c61 7373 0000 0000 SCILAB_Class.... 00243e0: 1300 0000 0400 0000 0101 0100 0000 0000 ................ 00243f0: 0100 0000 0000 0000 0100 0000 0000 0000 ................ 0024400: 6c69 7374 0000 0000 0c00 4800 0000 0000 list......H..... --- 9271,9281 ---- 0024360: 0100 0000 0000 0000 0100 0000 0000 0000 ................ 0024370: 0300 0800 0100 0000 1700 0000 0800 0000 ................ 0024380: 0500 0800 0100 0000 0202 0201 0000 0000 ................ 0024390: 0800 1800 0100 0000 0301 f8fd 0100 0000 ................ 00243a0: 0000 0800 0000 0000 0000 0000 0000 0000 ................ ! 00243b0: 1200 0800 0000 0000 0100 0000 28e4 7755 ............(.wU 00243c0: 0c00 4000 0000 0000 0100 0d00 0800 1800 .. at ............. 00243d0: 5343 494c 4142 5f43 6c61 7373 0000 0000 SCILAB_Class.... 00243e0: 1300 0000 0400 0000 0101 0100 0000 0000 ................ 00243f0: 0100 0000 0000 0000 0100 0000 0000 0000 ................ 0024400: 6c69 7374 0000 0000 0c00 4800 0000 0000 list......H..... *************** -- Cl?ment Le mercredi 10 juin 2015 ? 00:03 +0200, Samuel Gougeon a ?crit : > Hi, > > I have N figures. I would like to re-export only those that were > modified in the meanwhile. > Indeed, exporting with xs2### is rather time-consuming, in such a way > that i am looking for a short-circuit. > > The way that i imagined is the following, for a figure of handle f : > 1) f is saved in file1.sod. This is quite faster than exporting. > 2) later, f is re-saved in file2.sod > 3) we compute the MD5 checksums of the contents of file1.sod and > file2.sod > 4) we compare both checksums. If they are different, we re-export f. > > Unfortunately, it looks that save(..) likely saves also an internal > timestamp, or something varying external to the main saved content. > This ruins the idea, and i do not see any reflief plan. Here is a > proof: > clf > plot2d() > f = gcf(); > save test.sod f > getmd5 test.sod > sleep(5000) > save test.sod f > getmd5 test.sod > Yielding: > > -->clf > -->plot2d() > -->f = gcf(); > -->save test.sod f > -->getmd5 test.sod > ans = > e015481486eb9708a4fe1d3df1cbbbb9 > -->sleep(5000) > -->save test.sod f > -->getmd5 test.sod > ans = > 3c6319b5d3a2299caaacc2f95c3efb32 > > Other tests show that > 1) renaming the file does not change its checksum returned by > getmd5() > 2) modifying the OS timestamp of the file (any of creation, last > access, last write) does not change its checksum. > > Hence, it really looks that an internal timestamp is recorded with > the proper data. > So, my questions are : > 1) do -- you developers -- confirm this save()'s behavior? I did you > go the the source code. > 2) Why doing that? Is is on purpose, or is it a bug? > 3) Is there a way to avoid it? > a) There is presently no usage option to avoid it > b) On option, recording only the date with a fixed conventionnal > hour such that 00:00:00.000 would be ok for me. > 10s of export is <<< 24h ;) > 4) Would you have any idea to do what i expect with figures, without > using their saved handles? > I posted a wish and proposal > http://bugzilla.scilab.org/show_bug.cgi?id=11658?; 3 years ago, in > order to > open the possibillity to save copies of handles (in structures) > and then becomes able to compare them. > But the thread does not breathe... > > Reading you soon > > Samuel > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From Serge.Steer at inria.fr Wed Jun 10 09:47:25 2015 From: Serge.Steer at inria.fr (Serge Steer) Date: Wed, 10 Jun 2015 09:47:25 +0200 Subject: [Scilab-Dev] save(..) with internal timestamp? MD5 varying with unchanged content to be saved. In-Reply-To: <5577629B.8050509@free.fr> References: <5577629B.8050509@free.fr> Message-ID: <5577EB8D.8020305@inria.fr> A simple solution could be to save the date together with f dt=datenum() save test.sod datenum f then load test.sod datenum Serge Le 10/06/2015 00:03, Samuel Gougeon a ?crit : > Hi, > > I have N figures. I would like to re-export only those that were > modified in the meanwhile. > Indeed, exporting with xs2### is rather time-consuming, in such a way > that i am looking for a short-circuit. > > The way that i imagined is the following, for a figure of handle f : > 1) f is saved in file1.sod. This is quite faster than exporting. > 2) later, f is re-saved in file2.sod > 3) we compute the MD5 checksums of the contents of file1.sod and file2.sod > 4) we compare both checksums. If they are different, we re-export f. > > Unfortunately, it looks that save(..) likely saves also an internal > timestamp, or something varying external to the main saved content. > This ruins the idea, and i do not see any reflief plan. Here is a proof: > clf > plot2d() > f = gcf(); > save test.sod f > getmd5 test.sod > sleep(5000) > save test.sod f > getmd5 test.sod > Yielding: > > -->clf > -->plot2d() > -->f = gcf(); > -->save test.sod f > -->getmd5 test.sod > ans = > e015481486eb9708a4fe1d3df1cbbbb9 > -->sleep(5000) > -->save test.sod f > -->getmd5 test.sod > ans = > 3c6319b5d3a2299caaacc2f95c3efb32 > > Other tests show that > 1) renaming the file does not change its checksum returned by getmd5() > 2) modifying the OS timestamp of the file (any of creation, last > access, last write) does not change its checksum. > > Hence, it really looks that an internal timestamp is recorded with the > proper data. > So, my questions are : > 1) do -- you developers -- confirm this save()'s behavior? I did you > go the the source code. > 2) Why doing that? Is is on purpose, or is it a bug? > 3) Is there a way to avoid it? > a) There is presently no usage option to avoid it > b) On option, recording only the date with a fixed conventionnal > hour such that 00:00:00.000 would be ok for me. > 10s of export is <<< 24h ;) > 4) Would you have any idea to do what i expect with figures, without > using their saved handles? > I posted a wish and proposal > http://bugzilla.scilab.org/show_bug.cgi?id=11658 3 years ago, in > order to > open the possibillity to save copies of handles (in structures) > and then becomes able to compare them. > But the thread does not breathe... > > Reading you soon > > Samuel > > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine.monmayrant+scilab at laas.fr Wed Jun 10 09:55:00 2015 From: antoine.monmayrant+scilab at laas.fr (antoine.monmayrant+scilab at laas.fr) Date: Wed, 10 Jun 2015 09:55:00 +0200 Subject: [Scilab-Dev] save(..) with internal timestamp? MD5 varying with unchanged content to be saved. In-Reply-To: <1433921761.4643.11.camel@scilab-enterprises.com> References: <5577629B.8050509@free.fr> <1433921761.4643.11.camel@scilab-enterprises.com> Message-ID: <5577ED54.1040806@laas.fr> Le 06/10/2015 09:36 AM, Cl?ment David a ?crit : > Hi Samuel, > > For the record, > > I checked and even if the md5sum of the two files are different, the > h5diff tool does not report any difference. That's weird ! Not really, it is a hdf5 issue, not a scilab one: http://stackoverflow.com/questions/16019656/hdf5-file-h5py-with-version-control-hash-changes-on-every-save Antoine > > On a more advanced analysis, I converted the sod binary files to > hexdump (using xxd on linux) and got a multiple one char diff on > something which may be an entry descriptor located just before the > "SCILAB_Class" string value. > > Extracted reduced hexdiff : diff -C 5 <(xxd test1.sod) <(xxd test2.sod) > > *** 9271,9281 **** > 0024360: 0100 0000 0000 0000 0100 0000 0000 0000 ................ > 0024370: 0300 0800 0100 0000 1700 0000 0800 0000 ................ > 0024380: 0500 0800 0100 0000 0202 0201 0000 0000 ................ > 0024390: 0800 1800 0100 0000 0301 f8fd 0100 0000 ................ > 00243a0: 0000 0800 0000 0000 0000 0000 0000 0000 ................ > ! 00243b0: 1200 0800 0000 0000 0100 0000 23e4 7755 ............#.wU > 00243c0: 0c00 4000 0000 0000 0100 0d00 0800 1800 .. at ............. > 00243d0: 5343 494c 4142 5f43 6c61 7373 0000 0000 SCILAB_Class.... > 00243e0: 1300 0000 0400 0000 0101 0100 0000 0000 ................ > 00243f0: 0100 0000 0000 0000 0100 0000 0000 0000 ................ > 0024400: 6c69 7374 0000 0000 0c00 4800 0000 0000 list......H..... > --- 9271,9281 ---- > 0024360: 0100 0000 0000 0000 0100 0000 0000 0000 ................ > 0024370: 0300 0800 0100 0000 1700 0000 0800 0000 ................ > 0024380: 0500 0800 0100 0000 0202 0201 0000 0000 ................ > 0024390: 0800 1800 0100 0000 0301 f8fd 0100 0000 ................ > 00243a0: 0000 0800 0000 0000 0000 0000 0000 0000 ................ > ! 00243b0: 1200 0800 0000 0000 0100 0000 28e4 7755 ............(.wU > 00243c0: 0c00 4000 0000 0000 0100 0d00 0800 1800 .. at ............. > 00243d0: 5343 494c 4142 5f43 6c61 7373 0000 0000 SCILAB_Class.... > 00243e0: 1300 0000 0400 0000 0101 0100 0000 0000 ................ > 00243f0: 0100 0000 0000 0000 0100 0000 0000 0000 ................ > 0024400: 6c69 7374 0000 0000 0c00 4800 0000 0000 list......H..... > *************** > > -- > Cl?ment > > Le mercredi 10 juin 2015 ? 00:03 +0200, Samuel Gougeon a ?crit : >> Hi, >> >> I have N figures. I would like to re-export only those that were >> modified in the meanwhile. >> Indeed, exporting with xs2### is rather time-consuming, in such a way >> that i am looking for a short-circuit. >> >> The way that i imagined is the following, for a figure of handle f : >> 1) f is saved in file1.sod. This is quite faster than exporting. >> 2) later, f is re-saved in file2.sod >> 3) we compute the MD5 checksums of the contents of file1.sod and >> file2.sod >> 4) we compare both checksums. If they are different, we re-export f. >> >> Unfortunately, it looks that save(..) likely saves also an internal >> timestamp, or something varying external to the main saved content. >> This ruins the idea, and i do not see any reflief plan. Here is a >> proof: >> clf >> plot2d() >> f = gcf(); >> save test.sod f >> getmd5 test.sod >> sleep(5000) >> save test.sod f >> getmd5 test.sod >> Yielding: >> >> -->clf >> -->plot2d() >> -->f = gcf(); >> -->save test.sod f >> -->getmd5 test.sod >> ans = >> e015481486eb9708a4fe1d3df1cbbbb9 >> -->sleep(5000) >> -->save test.sod f >> -->getmd5 test.sod >> ans = >> 3c6319b5d3a2299caaacc2f95c3efb32 >> >> Other tests show that >> 1) renaming the file does not change its checksum returned by >> getmd5() >> 2) modifying the OS timestamp of the file (any of creation, last >> access, last write) does not change its checksum. >> >> Hence, it really looks that an internal timestamp is recorded with >> the proper data. >> So, my questions are : >> 1) do -- you developers -- confirm this save()'s behavior? I did you >> go the the source code. >> 2) Why doing that? Is is on purpose, or is it a bug? >> 3) Is there a way to avoid it? >> a) There is presently no usage option to avoid it >> b) On option, recording only the date with a fixed conventionnal >> hour such that 00:00:00.000 would be ok for me. >> 10s of export is <<< 24h ;) >> 4) Would you have any idea to do what i expect with figures, without >> using their saved handles? >> I posted a wish and proposal >> http://bugzilla.scilab.org/show_bug.cgi?id=11658 ; 3 years ago, in >> order to >> open the possibillity to save copies of handles (in structures) >> and then becomes able to compare them. >> But the thread does not breathe... >> >> Reading you soon >> >> Samuel >> >> _______________________________________________ >> 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 shubheksha at outlook.com Thu Jun 11 11:59:06 2015 From: shubheksha at outlook.com (Shubheksha Jalan) Date: Thu, 11 Jun 2015 15:29:06 +0530 Subject: [Scilab-Dev] Contribute to Scilab Message-ID: Hi, I'd like to contribute to the "Improvement of PDF generation" idea mentioned here: http://wiki.scilab.org/Contributor%20-%20PDF%20generation I've been looking through the Scilab source code lately. Any ideas regarding how to go about it would be appreciated. Nothing has been mentioned under the "More Information" section of "Docbook Viewer", can someone shed a little more light on what needs to be done for it? Thanking you, Shubheksha Jalan -------------- next part -------------- An HTML attachment was scrubbed... URL: From shubheksha at outlook.com Thu Jun 11 11:59:03 2015 From: shubheksha at outlook.com (Shubheksha Jalan) Date: Thu, 11 Jun 2015 15:29:03 +0530 Subject: [Scilab-Dev] Contribute to Scilab Message-ID: Hi, I'd like to contribute to the "Improvement of PDF generation" idea mentioned here: http://wiki.scilab.org/Contributor%20-%20PDF%20generation I've been looking through the Scilab source code lately. Any ideas regarding how to go about it would be appreciated. Nothing has been mentioned under the "More Information" section of "Docbook Viewer", can someone shed a little more light on what needs to be done for it? Thanking you, Shubheksha Jalan -------------- next part -------------- An HTML attachment was scrubbed... URL: From clement.david at scilab-enterprises.com Thu Jun 11 17:31:32 2015 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Thu, 11 Jun 2015 17:31:32 +0200 Subject: [Scilab-Dev] Contribute to Scilab In-Reply-To: References: Message-ID: <1434036692.2445.24.camel@scilab-enterprises.com> Hi, Yep feel free to take this subject. You can take a look at the gsoc ML archive [1], we (me and calixte) detailled the subject but none of the student were selected this year. Basically the goal is to be able to generate XSL-FO [2] (kind of an XML graphical dialect) from the Docbook pages (kind of XML content) and then call Apache FOP [3] to generate the PDF files from the XSL-FO ones. Note that you have to preserve compatibility with `xmltopdf' [4]. That's mainly a java class (FODocbookTagConverter.java) to implement. [1]: http://mailinglists.scilab.org/Gsoc-Fwd-GSOC-IDEA-Improve-PDF -generation-td4031833.html [2]: http://en.wikipedia.org/wiki/XSL_Formatting_Objects [3]: https://xmlgraphics.apache.org/fop/ [4]: help xmltopdf -- Cl?ment DAVID Le jeudi 11 juin 2015 ? 15:29 +0530, Shubheksha Jalan a ?crit : > Hi, I'd like to contribute to the "Improvement of PDF generation" > idea mentioned here: > http://wiki.scilab.org/Contributor%20-%20PDF%20generation > > I've been looking through the Scilab source code lately. Any ideas > regarding how to go about it would be appreciated. > > Nothing has been mentioned under the "More Information" section of > "Docbook Viewer", can someone shed a little more light on what needs > to be done for it? > > Thanking you, > Shubheksha Jalan > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From shubheksha at outlook.com Fri Jun 12 07:04:23 2015 From: shubheksha at outlook.com (Shubheksha Jalan) Date: Fri, 12 Jun 2015 10:34:23 +0530 Subject: [Scilab-Dev] Contribute to Scilab In-Reply-To: <1434036692.2445.24.camel@scilab-enterprises.com> References: , <1434036692.2445.24.camel@scilab-enterprises.com> Message-ID: Hi, The first link doesn't seem to work, so I couldn't go through the details of the task. I was browsing through the latest code I cloned and there is already a file by the name of FODocbookTagConverter.java, so I'm assuming we have to add functionality to it. Also, this page appears to be broken, so I could not get the details of what needs to be done for this task: http://wiki.scilab.org/Contributor%20-%20Docbook%20Viewer. It'd be helpful if you can provide some information about it. Thanking you, Shubheksha Jalan > From: clement.david at scilab-enterprises.com > To: dev at lists.scilab.org > Date: Thu, 11 Jun 2015 17:31:32 +0200 > Subject: Re: [Scilab-Dev] Contribute to Scilab > > Hi, > > Yep feel free to take this subject. You can take a look at the gsoc ML > archive [1], we (me and calixte) detailled the subject but none of the > student were selected this year. > > Basically the goal is to be able to generate XSL-FO [2] (kind of an XML > graphical dialect) from the Docbook pages (kind of XML content) and > then call Apache FOP [3] to generate the PDF files from the XSL-FO > ones. Note that you have to preserve compatibility with `xmltopdf' [4]. > > That's mainly a java class (FODocbookTagConverter.java) to implement. > > [1]: http://mailinglists.scilab.org/Gsoc-Fwd-GSOC-IDEA-Improve-PDF > -generation-td4031833.html > [2]: http://en.wikipedia.org/wiki/XSL_Formatting_Objects > [3]: https://xmlgraphics.apache.org/fop/ > [4]: help xmltopdf > > -- > Cl?ment DAVID > > Le jeudi 11 juin 2015 ? 15:29 +0530, Shubheksha Jalan a ?crit : > > Hi, I'd like to contribute to the "Improvement of PDF generation" > > idea mentioned here: > > http://wiki.scilab.org/Contributor%20-%20PDF%20generation > > > > I've been looking through the Scilab source code lately. Any ideas > > regarding how to go about it would be appreciated. > > > > Nothing has been mentioned under the "More Information" section of > > "Docbook Viewer", can someone shed a little more light on what needs > > to be done for it? > > > > Thanking you, > > Shubheksha Jalan > > > > _______________________________________________ > > 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 scilab-enterprises.com Fri Jun 12 16:17:18 2015 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Fri, 12 Jun 2015 16:17:18 +0200 Subject: [Scilab-Dev] Contribute to Scilab In-Reply-To: References: , <1434036692.2445.24.camel@scilab-enterprises.com> Message-ID: <1434118638.7029.12.camel@scilab-enterprises.com> Hello, Well the Docbook viewer was not a good idea, JavaHelp based system seems to be sufficient by now. Le vendredi 12 juin 2015 ? 10:34 +0530, Shubheksha Jalan a ?crit : > Also, this page appears to be broken, so I could not get the details > of what needs to be done for this task: > http://wiki.scilab.org/Contributor%20-%20Docbook%20Viewer. It'd be > helpful if you can provide some information about it. -- Cl?met From sgougeon at free.fr Sat Jun 13 08:57:20 2015 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 13 Jun 2015 08:57:20 +0200 Subject: [Scilab-Dev] save(..) with internal timestamp? MD5 varying with unchanged content to be saved. In-Reply-To: <5577ED54.1040806@laas.fr> References: <5577629B.8050509@free.fr> <1433921761.4643.11.camel@scilab-enterprises.com> <5577ED54.1040806@laas.fr> Message-ID: <557BD450.9030508@free.fr> Hi, Le 10/06/2015 09:55, antoine.monmayrant+scilab at laas.fr a ?crit : > .../... > Not really, it is a hdf5 issue, not a scilab one: > > http://stackoverflow.com/questions/16019656/hdf5-file-h5py-with-version-control-hash-changes-on-every-save > > > Antoine Thanks Antoine. This very clear reference made me posting on bugzilla to have a similar save() option disabling HDF5 version control when needed: http://bugzilla.scilab.org/13941 Best regards Samuel From sgougeon at free.fr Sat Jun 13 09:02:13 2015 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 13 Jun 2015 09:02:13 +0200 Subject: [Scilab-Dev] save(..) with internal timestamp? MD5 varying with unchanged content to be saved. In-Reply-To: <557BD450.9030508@free.fr> References: <5577629B.8050509@free.fr> <1433921761.4643.11.camel@scilab-enterprises.com> <5577ED54.1040806@laas.fr> <557BD450.9030508@free.fr> Message-ID: <557BD575.9010107@free.fr> Le 13/06/2015 08:57, Samuel Gougeon a ?crit : > > Thanks Antoine. This very clear reference made me posting on bugzilla > to have a similar save() option disabling HDF5 version control when > needed: > http://bugzilla.scilab.org/13941 h5open() proposes several drivers: http://help.scilab.org/docs/5.5.2/en_US/h5open.html May be some of them do not implement the HDF5 version control. Tests to be done. SG From saikiran638.rguiiit at gmail.com Mon Jun 15 08:03:29 2015 From: saikiran638.rguiiit at gmail.com (SAI KIRAN NARAGAM) Date: Mon, 15 Jun 2015 11:33:29 +0530 Subject: [Scilab-Dev] Regarding an error in developing Symphony toolbox for Scilab Message-ID: Sir/Madam, We are developing an optimization-toolbox using coin-or symphony( SYMPHONY ) for Scilab. For that we installed symphony libraries and dependencies, g++ (4.8.2) using apt-get in ubuntu 14.04 . It is working with g++ (4.8.2) and g++-4.4 . Some people install symphony by manually downloading and following steps. So, we took another computer and installed symphony manually using those steps. This method working with g++(4.8.2) but not with g++-4.4. We are getting the below error which in our opinion related with Technical description of incremental link . ? We don't know whether this problem is caused by compiler or scilab . Please help us out. Thanks & Regards, Sai Kiran. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: error.png Type: image/png Size: 41162 bytes Desc: not available URL: From clement.david at scilab-enterprises.com Wed Jun 17 09:43:11 2015 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Wed, 17 Jun 2015 09:43:11 +0200 Subject: [Scilab-Dev] freeing the "@" symbol? In-Reply-To: <557768B9.3050905@free.fr> References: <557768B9.3050905@free.fr> Message-ID: <1434526991.2399.12.camel@scilab-enterprises.com> Hello Samuel, And thanks for sharing your views. In fact some symbols already involved to cleaner ones on YaSp : > { as the same meaning as [ > } as the same meaning as ] In Scilab 6, the '{}' symbols will be used to define cells. As cells are just matrix extension (to the cost of more runtime checks) everything should be fine if the symbols are used consistently (eg. '{1]' will produce an error). > @ as the same meaning as ~ It works in YaSp but totally agree that it might a good candidate to deprecate ! > ` as the same meaning as < This syntax produce an error in YaSp. -- Cl?ment From stephane.mottelet at utc.fr Mon Jun 22 14:35:30 2015 From: stephane.mottelet at utc.fr (=?UTF-8?B?U3TDqXBoYW5lIE1vdHRlbGV0?=) Date: Mon, 22 Jun 2015 14:35:30 +0200 Subject: [Scilab-Dev] floating point operations in different versions of Scilab Message-ID: <55880112.2080707@utc.fr> Hello Scilab devmasters ! I have noticed subtle (but real) differences between successive versions of Scilab, here's the whole story: I use fsqp to solve an optimization problem where the computation of the cost function and its gradient uses a lot of sparse/full matrix products, and I noticed different convergence behaviour of the same code depending on the Scilab version. E.g. with Scilab 5.5.0 and 5.5.1 fsqp converges within the prescribed tolerance (norm of the gradient), but with 5.5.2 fsqp stops its iterations without reaching it. When relaxing the tolerance successful convergence is obtained but I got slightly different results at the end. I am wondering about which pathway I should follow to identify the problem, so my questions are the following : -is it possible that the scilab version which has been used to compile fsqp could produce such a behaviour ? -did the sparse/sparse and sparse/full product routines change recently ? Best regards, S. -- D?partement de G?nie Informatique EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable Universit? de Technologie de Compi?gne - CS 60319 60203 Compi?gne cedex From stephane.mottelet at utc.fr Thu Jun 25 15:06:43 2015 From: stephane.mottelet at utc.fr (=?UTF-8?B?U3TDqXBoYW5lIE1vdHRlbGV0?=) Date: Thu, 25 Jun 2015 15:06:43 +0200 Subject: [Scilab-Dev] question about Scilab 6 toolbox development Message-ID: <558BFCE3.5070102@utc.fr> Helllo, I am trying to port a toolbox (which uses compiled sources) to Scilab 6, is there an example somewhere ? I have the following error message under OSX : ilib_gen_Make : Une erreur s'est produite lors de la d?tection du compilateur. Mettre ilib_verbose(2) pour plus d'informations. The whole log is given below : S. macmottelet-gi-0:SCI mottelet$ /Applications/scilab-branch-YaSp-1435149914.app/Contents/MacOS/bin/scilab -nw -f spset/builder.sce JavaVM: requested Java version (1.5) not available. Using Java at "/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home" instead. Scilab branch-YaSp-1435149914 (Jun 25 2015, 06:40:36) Cr?ation de la passerelle... G?n?re un fichier gateway G?n?re un fichier loader G?n?re un Makefile ilib_gen_Make : Configure : G?n?re le Makefile. Detection of C/C++/Fortran Compilers checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... none checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... gfortran checking whether we are using the GNU Fortran 77 compiler... yes checking whether gfortran accepts -g... yes checking for gfortran... gfortran checking whether we are using the GNU Fortran compiler... yes checking whether gfortran accepts -g... yes checking build system type... x86_64-apple-darwin13.4.0 checking host system type... x86_64-apple-darwin13.4.0 checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld checking if the linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) is GNU ld... no checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm checking the name lister (/usr/bin/nm) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 196608 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert x86_64-apple-darwin13.4.0 file names to x86_64-apple-darwin13.4.0 format... func_convert_file_noop checking how to convert x86_64-apple-darwin13.4.0 file names to toolchain format... func_convert_file_noop checking for /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld option to reload object files... -r checking for objdump... no checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... no checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm output from gcc object... ok checking for sysroot... no checking for mt... no checking if : is a manifest tool... no checking for dsymutil... dsymutil checking for nmedit... nmedit checking for lipo... lipo checking for otool... otool checking for otool64... no checking for -single_module linker flag... yes checking for -exported_symbols_list linker flag... yes checking for -force_load linker flag... yes checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fno-common -DPIC checking if gcc PIC flag -fno-common -DPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin13.4.0 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking how to run the C++ preprocessor... g++ -E checking for ld used by g++... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld checking if the linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) is GNU ld... no checking whether the g++ linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fno-common -DPIC checking if g++ PIC flag -fno-common -DPIC works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking if g++ supports -c -o file.o... (cached) yes checking whether the g++ linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin13.4.0 dyld checking how to hardcode library paths into programs... immediate checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for gfortran option to produce PIC... -fno-common checking if gfortran PIC flag -fno-common works... yes checking if gfortran static flag -static works... no checking if gfortran supports -c -o file.o... yes checking if gfortran supports -c -o file.o... (cached) yes checking whether the gfortran linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin13.4.0 dyld checking how to hardcode library paths into programs... immediate checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for gfortran option to produce PIC... -fno-common checking if gfortran PIC flag -fno-common works... yes checking if gfortran static flag -static works... no checking if gfortran supports -c -o file.o... yes checking if gfortran supports -c -o file.o... (cached) yes checking whether the gfortran linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin13.4.0 dyld checking how to hardcode library paths into programs... immediate checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... (cached) /usr/bin/grep checking Eigen/Sparse usability... no checking Eigen/Sparse presence... no checking for Eigen/Sparse... no checking Eigen/Sparse usability... no checking Eigen/Sparse presence... no checking for Eigen/Sparse... no ilib_gen_Make : Une erreur s'est produite lors de la d?tection du compilateur. Mettre ilib_verbose(2) pour plus d'informations. at line 28 of function generateConfigure ( /Applications/scilab-branch-YaSp-1435149914.app/Contents/MacOS/share/scilab/modules/dynamic_link/macros/ilib_gen_Make_unix.sci line 281 ) at line 65 of function ilib_gen_Make_unix ( /Applications/scilab-branch-YaSp-1435149914.app/Contents/MacOS/share/scilab/modules/dynamic_link/macros/ilib_gen_Make_unix.sci line 80 ) at line 58 of function ilib_gen_Make ( /Applications/scilab-branch-YaSp-1435149914.app/Contents/MacOS/share/scilab/modules/dynamic_link/macros/ilib_gen_Make.sci line 69 ) at line 108 of function ilib_build ( /Applications/scilab-branch-YaSp-1435149914.app/Contents/MacOS/share/scilab/modules/dynamic_link/macros/ilib_build.sci line 118 ) at line 134 of function tbx_build_gateway ( /Applications/scilab-branch-YaSp-1435149914.app/Contents/MacOS/share/scilab/modules/modules_manager/macros/tbx_build_gateway.sci line 145 ) at line 9 of function builder_gw_c ( /Users/mottelet/svn/sysmetab/trunk/SYSMETAB/SCI/spset/sci_gateway//c/builder_gateway_c.sce line 11 ) at line 11 of executed file /Users/mottelet/svn/sysmetab/trunk/SYSMETAB/SCI/spset/sci_gateway//c/builder_gateway_c.sce at line 13 of function tbx_builder ( /Applications/scilab-branch-YaSp-1435149914.app/Contents/MacOS/share/scilab/modules/modules_manager/macros/tbx_builder.sci line 23 ) at line 49 of function tbx_builder_gateway_lang ( /Applications/scilab-branch-YaSp-1435149914.app/Contents/MacOS/share/scilab/modules/modules_manager/macros/tbx_builder_gateway_lang.sci line 71 ) at line 6 of function builder_gateway ( /Users/mottelet/svn/sysmetab/trunk/SYSMETAB/SCI/spset//sci_gateway/builder_gateway.sce line 8 ) at line 4 of executed file /Users/mottelet/svn/sysmetab/trunk/SYSMETAB/SCI/spset//sci_gateway/builder_gateway.sce at line 13 of function tbx_builder ( /Applications/scilab-branch-YaSp-1435149914.app/Contents/MacOS/share/scilab/modules/modules_manager/macros/tbx_builder.sci line 23 ) at line 32 of function tbx_builder_gateway ( /Applications/scilab-branch-YaSp-1435149914.app/Contents/MacOS/share/scilab/modules/modules_manager/macros/tbx_builder_gateway.sci line 45 ) at line 33 of function main_builder ( spset/builder.sce line 41 ) at line 49 of executed file spset/builder.sce -- D?partement de G?nie Informatique EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable Universit? de Technologie de Compi?gne - CS 60319 60203 Compi?gne cedex From vincent.couvert at scilab-enterprises.com Fri Jun 26 15:41:39 2015 From: vincent.couvert at scilab-enterprises.com (Vincent COUVERT) Date: Fri, 26 Jun 2015 15:41:39 +0200 Subject: [Scilab-Dev] question about Scilab 6 toolbox development In-Reply-To: <558BFCE3.5070102@utc.fr> References: <558BFCE3.5070102@utc.fr> Message-ID: <558D5693.20205@scilab-enterprises.com> Hello St?phane, This issue will be fixed in tomorrow nightly-builds by commit: https://codereview.scilab.org/#/c/16729/ (http://gitweb.scilab.org/?p=scilab.git;a=commit;h=2088da7ea3e9b060f526f324796eb08fd58bfb42) Thanks for your feedback. Vincent On 06/25/2015 03:06 PM, St?phane Mottelet wrote: > Helllo, > > I am trying to port a toolbox (which uses compiled sources) to Scilab > 6, is there an example somewhere ? I have the following error message > under OSX : > > ilib_gen_Make : Une erreur s'est produite lors de la d?tection du > compilateur. Mettre ilib_verbose(2) pour plus d'informations. > > The whole log is given below : > > S. > > macmottelet-gi-0:SCI mottelet$ > /Applications/scilab-branch-YaSp-1435149914.app/Contents/MacOS/bin/scilab > -nw -f spset/builder.sce > JavaVM: requested Java version (1.5) not available. Using Java at > "/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home" > instead. > Scilab branch-YaSp-1435149914 (Jun 25 2015, 06:40:36) > Cr?ation de la passerelle... > G?n?re un fichier gateway > G?n?re un fichier loader > G?n?re un Makefile > ilib_gen_Make : Configure : G?n?re le Makefile. > Detection of C/C++/Fortran Compilers > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... ./install-sh -c -d > checking for gawk... no > checking for mawk... no > checking for nawk... no > checking for awk... awk > checking whether make sets $(MAKE)... yes > checking whether make supports nested variables... yes > checking whether to enable maintainer-specific portions of > Makefiles... no > checking for gcc... gcc > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking whether gcc understands -c and -o together... yes > checking for style of include used by make... GNU > checking dependency style of gcc... none > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking dependency style of g++... none > checking for g77... no > checking for xlf... no > checking for f77... no > checking for frt... no > checking for pgf77... no > checking for cf77... no > checking for fort77... no > checking for fl32... no > checking for af77... no > checking for xlf90... no > checking for f90... no > checking for pgf90... no > checking for pghpf... no > checking for epcf90... no > checking for gfortran... gfortran > checking whether we are using the GNU Fortran 77 compiler... yes > checking whether gfortran accepts -g... yes > checking for gfortran... gfortran > checking whether we are using the GNU Fortran compiler... yes > checking whether gfortran accepts -g... yes > checking build system type... x86_64-apple-darwin13.4.0 > checking host system type... x86_64-apple-darwin13.4.0 > checking how to print strings... printf > checking for a sed that does not truncate output... /usr/bin/sed > checking for grep that handles long lines and -e... /usr/bin/grep > checking for egrep... /usr/bin/grep -E > checking for fgrep... /usr/bin/grep -F > checking for ld used by gcc... > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld > > checking if the linker > (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) > is GNU ld... no > checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm > checking the name lister (/usr/bin/nm) interface... BSD nm > checking whether ln -s works... yes > checking the maximum length of command line arguments... 196608 > checking whether the shell understands some XSI constructs... yes > checking whether the shell understands "+="... yes > checking how to convert x86_64-apple-darwin13.4.0 file names to > x86_64-apple-darwin13.4.0 format... func_convert_file_noop > checking how to convert x86_64-apple-darwin13.4.0 file names to > toolchain format... func_convert_file_noop > checking for > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld > option to reload object files... -r > checking for objdump... no > checking how to recognize dependent libraries... pass_all > checking for dlltool... no > checking how to associate runtime and link libraries... printf %s\n > checking for ar... ar > checking for archiver @FILE support... no > checking for strip... strip > checking for ranlib... ranlib > checking command to parse /usr/bin/nm output from gcc object... ok > checking for sysroot... no > checking for mt... no > checking if : is a manifest tool... no > checking for dsymutil... dsymutil > checking for nmedit... nmedit > checking for lipo... lipo > checking for otool... otool > checking for otool64... no > checking for -single_module linker flag... yes > checking for -exported_symbols_list linker flag... yes > checking for -force_load linker flag... yes > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking for dlfcn.h... yes > checking for objdir... .libs > checking if gcc supports -fno-rtti -fno-exceptions... yes > checking for gcc option to produce PIC... -fno-common -DPIC > checking if gcc PIC flag -fno-common -DPIC works... yes > checking if gcc static flag -static works... no > checking if gcc supports -c -o file.o... yes > checking if gcc supports -c -o file.o... (cached) yes > checking whether the gcc linker > (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) > supports shared libraries... yes > checking dynamic linker characteristics... darwin13.4.0 dyld > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking how to run the C++ preprocessor... g++ -E > checking for ld used by g++... > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld > > checking if the linker > (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) > is GNU ld... no > checking whether the g++ linker > (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) > supports shared libraries... yes > checking for g++ option to produce PIC... -fno-common -DPIC > checking if g++ PIC flag -fno-common -DPIC works... yes > checking if g++ static flag -static works... no > checking if g++ supports -c -o file.o... yes > checking if g++ supports -c -o file.o... (cached) yes > checking whether the g++ linker > (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) > supports shared libraries... yes > checking dynamic linker characteristics... darwin13.4.0 dyld > checking how to hardcode library paths into programs... immediate > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for gfortran option to produce PIC... -fno-common > checking if gfortran PIC flag -fno-common works... yes > checking if gfortran static flag -static works... no > checking if gfortran supports -c -o file.o... yes > checking if gfortran supports -c -o file.o... (cached) yes > checking whether the gfortran linker > (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) > supports shared libraries... yes > checking dynamic linker characteristics... darwin13.4.0 dyld > checking how to hardcode library paths into programs... immediate > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... no > checking for gfortran option to produce PIC... -fno-common > checking if gfortran PIC flag -fno-common works... yes > checking if gfortran static flag -static works... no > checking if gfortran supports -c -o file.o... yes > checking if gfortran supports -c -o file.o... (cached) yes > checking whether the gfortran linker > (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) > supports shared libraries... yes > checking dynamic linker characteristics... darwin13.4.0 dyld > checking how to hardcode library paths into programs... immediate > checking how to run the C preprocessor... gcc -E > checking for grep that handles long lines and -e... (cached) > /usr/bin/grep > checking Eigen/Sparse usability... no > checking Eigen/Sparse presence... no > checking for Eigen/Sparse... no > checking Eigen/Sparse usability... no > checking Eigen/Sparse presence... no > checking for Eigen/Sparse... no > ilib_gen_Make : Une erreur s'est produite lors de la d?tection du > compilateur. Mettre ilib_verbose(2) pour plus d'informations. > at line 28 of function generateConfigure ( > /Applications/scilab-branch-YaSp-1435149914.app/Contents/MacOS/share/scilab/modules/dynamic_link/macros/ilib_gen_Make_unix.sci > line 281 ) > at line 65 of function ilib_gen_Make_unix ( > /Applications/scilab-branch-YaSp-1435149914.app/Contents/MacOS/share/scilab/modules/dynamic_link/macros/ilib_gen_Make_unix.sci > line 80 ) > at line 58 of function ilib_gen_Make ( > /Applications/scilab-branch-YaSp-1435149914.app/Contents/MacOS/share/scilab/modules/dynamic_link/macros/ilib_gen_Make.sci > line 69 ) > at line 108 of function ilib_build ( > /Applications/scilab-branch-YaSp-1435149914.app/Contents/MacOS/share/scilab/modules/dynamic_link/macros/ilib_build.sci > line 118 ) > at line 134 of function tbx_build_gateway ( > /Applications/scilab-branch-YaSp-1435149914.app/Contents/MacOS/share/scilab/modules/modules_manager/macros/tbx_build_gateway.sci > line 145 ) > at line 9 of function builder_gw_c ( > /Users/mottelet/svn/sysmetab/trunk/SYSMETAB/SCI/spset/sci_gateway//c/builder_gateway_c.sce > line 11 ) > at line 11 of executed file > /Users/mottelet/svn/sysmetab/trunk/SYSMETAB/SCI/spset/sci_gateway//c/builder_gateway_c.sce > at line 13 of function tbx_builder ( > /Applications/scilab-branch-YaSp-1435149914.app/Contents/MacOS/share/scilab/modules/modules_manager/macros/tbx_builder.sci > line 23 ) > at line 49 of function tbx_builder_gateway_lang ( > /Applications/scilab-branch-YaSp-1435149914.app/Contents/MacOS/share/scilab/modules/modules_manager/macros/tbx_builder_gateway_lang.sci > line 71 ) > at line 6 of function builder_gateway ( > /Users/mottelet/svn/sysmetab/trunk/SYSMETAB/SCI/spset//sci_gateway/builder_gateway.sce > line 8 ) > at line 4 of executed file > /Users/mottelet/svn/sysmetab/trunk/SYSMETAB/SCI/spset//sci_gateway/builder_gateway.sce > at line 13 of function tbx_builder ( > /Applications/scilab-branch-YaSp-1435149914.app/Contents/MacOS/share/scilab/modules/modules_manager/macros/tbx_builder.sci > line 23 ) > at line 32 of function tbx_builder_gateway ( > /Applications/scilab-branch-YaSp-1435149914.app/Contents/MacOS/share/scilab/modules/modules_manager/macros/tbx_builder_gateway.sci > line 45 ) > at line 33 of function main_builder ( spset/builder.sce > line 41 ) > at line 49 of executed file spset/builder.sce > From clement.david at scilab-enterprises.com Tue Jun 30 09:18:01 2015 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Tue, 30 Jun 2015 09:18:01 +0200 Subject: [Scilab-Dev] floating point operations in different versions of Scilab In-Reply-To: <55880112.2080707@utc.fr> References: <55880112.2080707@utc.fr> Message-ID: <1435648681.11353.18.camel@scilab-enterprises.com> Hello St?phane, Sorry for the lag but I tried to investigate a little bit ! Did you try to reproduce on a reduced test case which does not depends on fsqp ? For the 5.5.2 release, I did not notice anything that might impact the behavior of fsqp. -- Cl?ment Le lundi 22 juin 2015 ? 14:35 +0200, St?phane Mottelet a ?crit : > Hello Scilab devmasters ! > > I have noticed subtle (but real) differences between successive > versions > of Scilab, here's the whole story: > > I use fsqp to solve an optimization problem where the computation of > the > cost function and its gradient uses a lot of sparse/full matrix > products, and I noticed different convergence behaviour of the same > code > depending on the Scilab version. > > E.g. with Scilab 5.5.0 and 5.5.1 fsqp converges within the prescribed > > tolerance (norm of the gradient), but with 5.5.2 fsqp stops its > iterations without reaching it. When relaxing the tolerance > successful > convergence is obtained but I got slightly different results at the > end. > > I am wondering about which pathway I should follow to identify the > problem, so my questions are the following : > > -is it possible that the scilab version which has been used to > compile > fsqp could produce such a behaviour ? > -did the sparse/sparse and sparse/full product routines change > recently ? > > Best regards, > > S. > > From stephane.mottelet at utc.fr Tue Jun 30 10:15:13 2015 From: stephane.mottelet at utc.fr (=?UTF-8?B?U3TDqXBoYW5lIE1vdHRlbGV0?=) Date: Tue, 30 Jun 2015 10:15:13 +0200 Subject: [Scilab-Dev] floating point operations in different versions of Scilab In-Reply-To: <1435648681.11353.18.camel@scilab-enterprises.com> References: <55880112.2080707@utc.fr> <1435648681.11353.18.camel@scilab-enterprises.com> Message-ID: <55925011.50304@utc.fr> Hello, I investigated also and found (by elimination) that the problem is due to "qr" which does not give the same results accross different versions of Scilab. It seems to a know issue and is due to varying conventions between versions of LAPACK for the diagonal of r in [q,r]=qr(a). S. Le 30/06/2015 09:18, Cl?ment David a ?crit : > Hello St?phane, > > Sorry for the lag but I tried to investigate a little bit ! > > Did you try to reproduce on a reduced test case which does not depends > on fsqp ? > > For the 5.5.2 release, I did not notice anything that might impact the > behavior of fsqp. > > -- > Cl?ment > > Le lundi 22 juin 2015 ? 14:35 +0200, St?phane Mottelet a ?crit : >> Hello Scilab devmasters ! >> >> I have noticed subtle (but real) differences between successive >> versions >> of Scilab, here's the whole story: >> >> I use fsqp to solve an optimization problem where the computation of >> the >> cost function and its gradient uses a lot of sparse/full matrix >> products, and I noticed different convergence behaviour of the same >> code >> depending on the Scilab version. >> >> E.g. with Scilab 5.5.0 and 5.5.1 fsqp converges within the prescribed >> >> tolerance (norm of the gradient), but with 5.5.2 fsqp stops its >> iterations without reaching it. When relaxing the tolerance >> successful >> convergence is obtained but I got slightly different results at the >> end. >> >> I am wondering about which pathway I should follow to identify the >> problem, so my questions are the following : >> >> -is it possible that the scilab version which has been used to >> compile >> fsqp could produce such a behaviour ? >> -did the sparse/sparse and sparse/full product routines change >> recently ? >> >> Best regards, >> >> S. >> >> > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -- D?partement de G?nie Informatique EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable Universit? de Technologie de Compi?gne - CS 60319 60203 Compi?gne cedex