From Jean-Pierre.Dussault at USherbrooke.CA Wed Jul 1 20:07:31 2015 From: Jean-Pierre.Dussault at USherbrooke.CA (Jean-Pierre Dussault) Date: Wed, 01 Jul 2015 14:07:31 -0400 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: <55942C63.50507@USherbrooke.CA> Le 2015-06-30 03: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. I might be slightly off topic, but floating point is sometimes unpredictable: scilab provides the function ieee to specify the behaviour of floating point operations. BUT, on my 5.5.1 under Ubuntu 14.04, -->ieee(0) -->exp(2000) ans = Inf -->1/0 !--error 27 Division by zero... -->ieee(1) -->exp(2000) ans = Inf -->1/0 ans = Inf and according to the doc, ieee(1) : floating point exception produces a warning... The first exp(2000) should have produced an error, the second a warning and if using ieee(2), Inf. 1/0 should produce a warning with ieee(1) and correctly produces an error with ieee(0) Unfortunately, the correct treatement of IEEE 754 floating point operations is very often very messy, not only in scilab. Now, what if the external code is compiled using different assumptions with respect to the desired behavior when "exeptions" or Inf are produced? An increased messyness! Just my 2 cents on this topic! JPD > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Fri Jul 3 16:08:18 2015 From: stephane.mottelet at utc.fr (=?UTF-8?B?U3TDqXBoYW5lIE1vdHRlbGV0?=) Date: Fri, 03 Jul 2015 16:08:18 +0200 Subject: [Scilab-Dev] problem compiling toolbox with Yasp Message-ID: <55969752.7080402@utc.fr> Hello, Thanks for the fix (Eigen dependency) in Yasp nightly build. Now I have two problems, each specific to a different toolbox, which compile fine under Scilab 5.5.2 (OSX 10.9.5) *with the first toolbox (with ApiScilab interfacing style) Commande : /Applications/scilab-branch-YaSp-1435585794.app/Contents/MacOS/share/scilab/modules/dynamic_link/src/scripts/scicompile.sh spset libspset.cpp libspset.h libspset.hxx sparse_set.c stderr : Ex?cute le makefile ilib_compile : Commande de compilation : make CFLAGS=" -D__SCILAB_TOOLBOX__ -g -I/Applications/scilab-branch-YaSp-1435585794.app/Contents/MacOS/share/scilab/../../include/scilab/ -I/Applications/scilab-branch-YaSp-1435585794.app/Contents/MacOS/share/scilab/../../include/ " CXXFLAGS=" -D__SCILAB_TOOLBOX__ -g -I/Applications/scilab-branch-YaSp-1435585794.app/Contents/MacOS/share/scilab/../../include/scilab/ -I/Applications/scilab-branch-YaSp-1435585794.app/Contents/MacOS/share/scilab/../../include/ " FFLAGS="-I/Applications/scilab-branch-YaSp-1435585794.app/Contents/MacOS/share/scilab/../../include/scilab/ " Sortie : stderr : libspset.cpp:13:60: warning: conversion from string literal to 'wchar_t *' is deprecated [-Wc++11-compat-deprecated-writable-strings] stderr : if(wcscmp(_pwstFuncName, L"spset") == 0){ addCFunction(L"spset", &sparse_set, MODULE_NAME); } stderr : ^ stderr : libspset.cpp:13:83: warning: conversion from string literal to 'wchar_t *' is deprecated [-Wc++11-compat-deprecated-writable-strings] stderr : if(wcscmp(_pwstFuncName, L"spset") == 0){ addCFunction(L"spset", &sparse_set, MODULE_NAME); } stderr : ^ stderr : libspset.cpp:9:21: note: expanded from macro 'MODULE_NAME' stderr : #define MODULE_NAME L"libspset" stderr : ^ stderr : 2 warnings generated. stderr : sparse_set.c:6:10: fatal error: 'MALLOC.h' file not found stderr : #include "MALLOC.h" stderr : ^ stderr : 1 error generated. stderr : make: *** [sparse_set.lo] Error 1 (...) *with the second one (fsqp Atoms module, old stack interfacing style) : no problem at built time, but at loading time I got : macmottelet-gi-0:SCI mottelet$ /Applications/scilab-branch-YaSp-1435585794.app/Contents/MacOS/bin/scilab -nw -f fsqp/loader.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-1435585794 (Jun 30 2015, 06:35:20) Start fsqp toolbox Load macros Load gateways addinter : La biblioth?que partag?e n'a pas ?t? charg?e: dlopen(/Users/mottelet/svn/sysmetab/tags/4.0/SYSMETAB/SCI/fsqp/sci_gateway/c//libfsqp.dylib, 10): Symbol not found: _SearchInDynLinks Referenced from: /Users/mottelet/svn/sysmetab/tags/4.0/SYSMETAB/SCI/fsqp/sci_gateway/c//libfsqp.dylib Expected in: flat namespace in /Users/mottelet/svn/sysmetab/tags/4.0/SYSMETAB/SCI/fsqp/sci_gateway/c//libfsqp.dylib at line 18 of executed file loader.sce at line 20 of executed file /Users/mottelet/svn/sysmetab/tags/4.0/SYSMETAB/SCI/fsqp/sci_gateway/loader_gateway.sce at line 32 of executed file /Users/mottelet/svn/sysmetab/tags/4.0/SYSMETAB/SCI/fsqp/etc/fsqp_toolbox.start at line 10 of executed file fsqp/loader.sce What can I do myself to fix this ? Thanks for your help 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 contact at pierre-vuillemin.fr Fri Jul 10 10:06:56 2015 From: contact at pierre-vuillemin.fr (contact at pierre-vuillemin.fr) Date: Fri, 10 Jul 2015 10:06:56 +0200 Subject: [Scilab-Dev] Functions with long names, compatibility between scilab 6 and 5.x Message-ID: <7da4a4cd8ebcd68205e966583ac35358@pierre-vuillemin.fr> Hello all, I have developed a set of tools to ease the process of writing optimisation problems (it helps mainly to write linear constraint matrices but can also directly put simple optimisation problems like 1,2 or inf norm problem into standard forms) and I have tried to package them as a toolbox. I use the yasp branch of scilab as I tend to use long variables/functions names, yet sometimes it is a bit challenging to debug my code as scilab simply shuts down. That is why, I have tried to use the stable version to debug, but I have run into some problems during the "building" and execution of my tools : - the first point is not really an issue, just a question: with the stable version, the routine "genlib" used during the building phase of the toolbox produces 2 files : "lib" and "names". This does not seem to be the case with the yasp version? Will the "names" file disappear in scilab 6? - more important: the long names of my functions are an issue with the stable version. In particular, "genlib" generated binary files with full names, and the "names" file contains also the full names of my functions. Yet during the execution, scilab calls the functions with their truncated names, which obviously does not work. It there a clever way to handle the problem other than truncating the names of the binary files? Best regards, Pierre Vuillemin From sgougeon at free.fr Fri Jul 10 19:16:13 2015 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 10 Jul 2015 19:16:13 +0200 Subject: [Scilab-Dev] Functions with long names, compatibility between scilab 6 and 5.x In-Reply-To: <7da4a4cd8ebcd68205e966583ac35358@pierre-vuillemin.fr> References: <7da4a4cd8ebcd68205e966583ac35358@pierre-vuillemin.fr> Message-ID: <559FFDDD.9060909@free.fr> Hello, Le 10/07/2015 10:06, contact at pierre-vuillemin.fr a ?crit : > .../... > - more important: the long names of my functions are an issue with the > stable version. In particular, "genlib" generated binary files with > full names, and the "names" file contains also the full names of my > functions. no, of .bin files. Defining function this_is_a_very_very_long_function_name() disp("That''s OK") endfunction in a file named test.sci makes genlib() generating test.bin and names containing "test", not "function this_is_a_very_very_long_function_name". Then, loading the library with lib(..) is OK: this_is_a_very_very_long_function_name() is loaded and can be run as expected. If you wish to prevent warnings, just enter warning off in the console or in your personnal starting file. HTH Samuel From sgougeon at free.fr Wed Jul 15 12:25:18 2015 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 15 Jul 2015 12:25:18 +0200 Subject: [Scilab-Dev] Functions with long names, compatibility between scilab 6 and 5.x In-Reply-To: <1398ae0d8bd01af2aff361973006a7a9@pierre-vuillemin.fr> References: <7da4a4cd8ebcd68205e966583ac35358@pierre-vuillemin.fr> <559FFDDD.9060909@free.fr> <1398ae0d8bd01af2aff361973006a7a9@pierre-vuillemin.fr> Message-ID: <55A6350E.5060205@free.fr> Hi Pierre, Le 15/07/2015 09:37, contact at pierre-vuillemin.fr a ?crit : > .../... > but this_is_a_very_very_long_function_name() is unknown. . You are right! When i did successfully the trial before posting to answer you, i used clear this_is_a_very_very_long_function_name before using lib, because i compiled this_is_a_very_very_long_function_name() by hand during previous tests. So, to be sure that the function will be loaded by lib(..) instead of coming from a former compilation, i did this "clear..." BUT after tests of reproducibility before answering you here, i have just found that "clear" is bugged, and just posted that: http://bugzilla.scilab.org/13979 ! I am unable to reproduce in Scilab 5.5.2 the formerly posted successful story. In all ways, indeed, as you were claiming it, it fails. These tests have shown other bugs. For instance, lib() is not (yet?) available in YaSp (2015-07-12 release)..., and since getd() is bugged http://bugzilla.scilab.org/13890, it turns hard to work with YaSp. > Besides, in the help page of "genlib", it is written that "Scilab > tacitly assumes that file foo.sci defines at least a function named > foo" which is not the case here. . That's also right. As you certainly also tested it, other tests confirm that. There are other "strange" constrains with libraries. For example, genlib() needs a library name (first argin), but when loading a library with lib(), the genlib library name (that looks to build the "lib" file) looks to not be used. At least, the name of the library loaded by lib looks to depend on the name of the lhs as test_lib = lib(libdir), instead of on the genlib libname... It would not be unpleasant to rationalize / simplify that with Scilab 6. Best regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Jul 15 12:31:16 2015 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 15 Jul 2015 12:31:16 +0200 Subject: [Scilab-Dev] lib() unavailable on YaSp? Message-ID: <55A63674.60905@free.fr> Hello S/E, lib() looks to be unknown in Scilab 6 (2015-07-12): -->dir ans = f3.bin f3.sci lib names -->lib(".") lib: is not a valid module file. Indeed, the gateway.xml where lib was formerly declared in 5.5.2 does not (yet?) include lib. Is it on purpose and definitive, or is it to come? Since getd() can't neither be used (http://bugzilla.scilab.org/13890), it turns hard to work with sets of macros with YaSp. Best regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Jul 15 13:15:03 2015 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 15 Jul 2015 13:15:03 +0200 Subject: [Scilab-Dev] lib() unavailable on YaSp? In-Reply-To: <55A63674.60905@free.fr> References: <55A63674.60905@free.fr> Message-ID: <55A640B7.7030405@free.fr> Le 15/07/2015 12:31, Samuel Gougeon a ?crit : > Hello S/E, > lib() looks to be unknown in Scilab 6 (2015-07-12): > -->dir > ans = > > f3.bin f3.sci lib names > > -->lib(".") > lib: is not a valid module file. Actually, lib() well exists, but is bugged: the first character of the given path is corrupted: http://bugzilla.scilab.org/13981 Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine.elias at scilab-enterprises.com Wed Jul 15 13:24:36 2015 From: antoine.elias at scilab-enterprises.com (Antoine ELIAS) Date: Wed, 15 Jul 2015 13:24:36 +0200 Subject: [Scilab-Dev] lib() unavailable on YaSp? In-Reply-To: <55A63674.60905@free.fr> References: <55A63674.60905@free.fr> Message-ID: <55A642F4.8000009@scilab-enterprises.com> Hello Samuel, It seems that you try to open a lib file build with Scilab 5 ( 24th first bytes with lot of 0x28 "(" ) use genlib("libname", "sci_files_path") to build lib and bin files to Scilab 6 And call lib("your_path") Scilab 6, no more create "names" file. New "lib" file ( xml format, it is readable ) contains all needed information. I am not sure I understand the link between gateway.xml and macros getd is already in my todolist ;) Antoine Le 15/07/2015 12:31, Samuel Gougeon a ?crit : > Hello S/E, > lib() looks to be unknown in Scilab 6 (2015-07-12): > -->dir > ans = > > f3.bin f3.sci lib names > > -->lib(".") > lib: is not a valid module file. > > Indeed, the gateway.xml where lib was formerly declared in 5.5.2 does not (yet?) include lib. > > Is it on purpose and definitive, or is it to come? > Since getd() can't neither be used (http://bugzilla.scilab.org/13890), it turns hard to work with sets of macros with YaSp. > > Best regards > Samuel > > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -- Antoine ELIAS Software developer ----------------------- Scilab Enterprises 143bis rue Yves Le Coz - 78000 Versailles Phone: 01.80.77.04.70 http://www.scilab-enterprises.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Jul 15 14:00:43 2015 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 15 Jul 2015 14:00:43 +0200 Subject: [Scilab-Dev] lib() unavailable on YaSp? In-Reply-To: <55A642F4.8000009@scilab-enterprises.com> References: <55A63674.60905@free.fr> <55A642F4.8000009@scilab-enterprises.com> Message-ID: <55A64B6B.3020806@free.fr> Hello Antoine, Thanks for your fast answer: Le 15/07/2015 13:24, Antoine ELIAS a ?crit : > > It seems that you try to open a lib file build with Scilab 5 ( 24th > first bytes with lot of 0x28 "(" ) > use genlib("libname", "sci_files_path") to build lib and bin files to > Scilab 6 > And call lib("your_path") > > Scilab 6, no more create "names" file. > New "lib" file ( xml format, it is readable ) contains all needed > information. . It works! So, this means that *all* ATOMS modules and modules on the forge or other contribs will have to be recompiled for Scilab 6, *even those that have only macros*. This is a big change, that in my opinion could deserve being announced quite early and officially on users@ and dev@, unless S/E gets the charge to generate a new version of each ATOMS module for Scilab 6. When save() was changed to work with HDF5, former calling sequences were warnobsoleted a long time ago. It could be worthwhile to do the same with lib() in Scilab 6, supporting the former processing and lib and names files format, but then warnobsoleting the user to recompile the library. Thanks a lot for the hint. > > I am not sure I understand the link between gateway.xml and macros . I was pointing SCI\modules\functions\sci_gateway\functions_gateway.xml, out of which lib has been moved. Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From contact at pierre-vuillemin.fr Wed Jul 15 09:37:13 2015 From: contact at pierre-vuillemin.fr (contact at pierre-vuillemin.fr) Date: Wed, 15 Jul 2015 09:37:13 +0200 Subject: [Scilab-Dev] Functions with long names, compatibility between scilab 6 and 5.x In-Reply-To: <559FFDDD.9060909@free.fr> References: <7da4a4cd8ebcd68205e966583ac35358@pierre-vuillemin.fr> <559FFDDD.9060909@free.fr> Message-ID: <1398ae0d8bd01af2aff361973006a7a9@pierre-vuillemin.fr> I see, my confusion came from my habit of naming my .sci files as the (generaly only) function it contains. Yet concerning your example I must still be misunderstanding something as I can't manage to make it work: - the file test.sci contains only function this_is_a_very_very_long_function_name() disp("That''s OK") endfunction - then I generate a library by calling genlib as genlib("testLib","./") // I am in the same directory as test.sci The file "names" contains indeed "test" - Then I load the library : testLib = lib("./") but this_is_a_very_very_long_function_name() is unknown. Besides, in the help page of "genlib", it is written that "Scilab tacitly assumes that file foo.sci defines at least a function named foo" which is not the case here. Le 10.07.2015 19:16, Samuel Gougeon a ?crit?: > Hello, > > Le 10/07/2015 10:06, contact at pierre-vuillemin.fr a ?crit : >> .../... >> - more important: the long names of my functions are an issue with the >> stable version. In particular, "genlib" generated binary files with >> full names, and the "names" file contains also the full names of my >> functions. > > no, of .bin files. Defining > function this_is_a_very_very_long_function_name() > disp("That''s OK") > endfunction > in a file named test.sci > makes genlib() generating test.bin and names containing "test", not > "function this_is_a_very_very_long_function_name". > > Then, loading the library with lib(..) is OK: > this_is_a_very_very_long_function_name() is loaded and can be run as > expected. > > If you wish to prevent warnings, just enter > warning off > in the console or in your personnal starting file. > > HTH > Samuel > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From sgougeon at free.fr Wed Jul 15 14:35:37 2015 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 15 Jul 2015 14:35:37 +0200 Subject: [Scilab-Dev] lib() unavailable on YaSp? In-Reply-To: <55A642F4.8000009@scilab-enterprises.com> References: <55A63674.60905@free.fr> <55A642F4.8000009@scilab-enterprises.com> Message-ID: <55A65399.70105@free.fr> Le 15/07/2015 13:24, Antoine ELIAS a ?crit : > .../... > Scilab 6, no more create "names" file. > New "lib" file ( xml format, it is readable ) contains all needed > information. . Why not renaming it lib.xml? 1) This would better show its format, and -- overall -- 2) this would allow to distribute modules containing only macros under a *single version* compatible with *both* Scilab 5 and Scilab 6 (including both {"lib" and "names"} and "lib.xml" files), since .bin contents are unchanged: .bin generated with YaSp look OK for Scilab 5, and conversely. Example: for the module http://atoms.scilab.org/toolboxes/uman, the supported Scilab version is set to "any" in order to see the (same version of the) module in ATOMS in Scilab 5 as well as in Scilab 6. But with the present "lib" coming from Scilab 5, the module does not load at Scilab 6 startup (error). If i replace it with the "lib" file got from YaSp, the module won't load with Scilab 5. If the "lib" file from Scilab 6 was renamed "lib.xml", it would not be necessary to create a new version of "uman" specific to Scilab 6: adding "lib.xml" to "~\macros\" would be enough, and in the still long expected meantime from Scilab 5.5 to the official Scilab 6 (may be still 2 years, for all the alphas and betas...?), the same and only version will be OK, without having to maintain two versions for their parallel fixes and upgrades. Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Jul 15 14:53:03 2015 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 15 Jul 2015 14:53:03 +0200 Subject: [Scilab-Dev] lib() unavailable on YaSp? In-Reply-To: <55A65399.70105@free.fr> References: <55A63674.60905@free.fr> <55A642F4.8000009@scilab-enterprises.com> <55A65399.70105@free.fr> Message-ID: <55A657AF.4020208@free.fr> Le 15/07/2015 14:35, Samuel Gougeon a ?crit : > Le 15/07/2015 13:24, Antoine ELIAS a ?crit : >> .../... >> Scilab 6, no more create "names" file. >> New "lib" file ( xml format, it is readable ) contains all needed >> information. > . > Why not renaming it lib.xml? > 1) This would better show its format, and -- overall -- > 2) this would allow to distribute modules containing only macros under > a *single version* compatible with *both* Scilab 5 and Scilab 6 > (including both {"lib" and "names"} and "lib.xml" files), since .bin > contents are unchanged: .bin generated with YaSp look OK for Scilab 5, > and conversely. . OK: a module may provide both lib files, and in its startup file, test the Scilab version and copy the right lib file in its ~\macros\ directory. But this is quite tricky. From now (5.5) and until Scilab 6.1, genlib() could generate both "lib" and "lib.xml" files, and lib() use the right file among both. This would make the transition softer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Jul 15 15:02:49 2015 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 15 Jul 2015 15:02:49 +0200 Subject: [Scilab-Dev] lib() unavailable on YaSp? In-Reply-To: <55A657AF.4020208@free.fr> References: <55A63674.60905@free.fr> <55A642F4.8000009@scilab-enterprises.com> <55A65399.70105@free.fr> <55A657AF.4020208@free.fr> Message-ID: <55A659F9.2010007@free.fr> Le 15/07/2015 14:53, Samuel Gougeon a ?crit : > .../... > OK: a module may provide both lib files, and in its startup file, test > the Scilab version and copy the right lib file in its ~\macros\ directory. > But this is quite tricky. From now (5.5) and until Scilab 6.1, > genlib() could generate both "lib" and "lib.xml" files, and lib() use > the right file among both. . By the way, this trick won't work for modules installed for all users, since the user would then need write privileges on SCI\contrib\\\macros\ So, let's forget it. Modifying genlib() and lib() would be much better. -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine.elias at scilab-enterprises.com Wed Jul 15 16:57:45 2015 From: antoine.elias at scilab-enterprises.com (Antoine ELIAS) Date: Wed, 15 Jul 2015 16:57:45 +0200 Subject: [Scilab-Dev] lib() unavailable on YaSp? In-Reply-To: <55A659F9.2010007@free.fr> References: <55A63674.60905@free.fr> <55A642F4.8000009@scilab-enterprises.com> <55A65399.70105@free.fr> <55A657AF.4020208@free.fr> <55A659F9.2010007@free.fr> Message-ID: <55A674E9.7020901@scilab-enterprises.com> ".bin" are a "dump" of Scilab 5 macros stack representation, so it is impossible in Scilab 6 to reproduce it. I am afraid that you need to rebuild your toolboxes especially to Scilab 6. Some compatibility points will be managed by ATOMS. example : tbx_2 -> deps : tbx_1 ( any ) If you install tbx_2 on Scilab 6, atoms will looking for latest version of tbx_1 >= 6 If you install tbx_2 on Scilab 5, atoms will looking for latest version of tbx_1 5.0 <= x < 6 ( not currently coded, we need to update process that generate ATOMS dependencies ) But yes, that a lot of work to rebuild all toolboxes for Scilab 6, check behaviors, tests, demos, dependencies. Anyway, thank you for the problem analysis. Antoine Le 15/07/2015 15:02, Samuel Gougeon a ?crit : > Le 15/07/2015 14:53, Samuel Gougeon a ?crit : >> .../... >> OK: a module may provide both lib files, and in its startup file, test the Scilab version and copy the right lib file in its ~\macros\ directory. >> But this is quite tricky. From now (5.5) and until Scilab 6.1, genlib() could generate both "lib" and "lib.xml" files, and lib() use the right file among both. > . > By the way, this trick won't work for modules installed for all users, since the user would then need write privileges on SCI\contrib\\\macros\ > So, let's forget it. Modifying genlib() and lib() would be much better. > > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -- Antoine ELIAS Software developer ----------------------- Scilab Enterprises 143bis rue Yves Le Coz - 78000 Versailles Phone: 01.80.77.04.70 http://www.scilab-enterprises.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From contact at pierre-vuillemin.fr Thu Jul 16 09:09:06 2015 From: contact at pierre-vuillemin.fr (Pierre Vuillemin) Date: Thu, 16 Jul 2015 09:09:06 +0200 Subject: [Scilab-Dev] Functions with long names, compatibility between scilab 6 and 5.x In-Reply-To: <55A6350E.5060205@free.fr> References: <7da4a4cd8ebcd68205e966583ac35358@pierre-vuillemin.fr> <559FFDDD.9060909@free.fr> <1398ae0d8bd01af2aff361973006a7a9@pierre-vuillemin.fr> <55A6350E.5060205@free.fr> Message-ID: <86188cf5c69fc830bde206214d020e06@pierre-vuillemin.fr> Hi Samuel, thank you for the explanations, I was starting to really wonder why I could not manage to reproduce the example :). About lib() not working in YaSp : that is quite strange as I use lib() in the loader of my toolbox and in some macros to call internal functions and it works. I use the version 1435245504 under windows. The library must be generated with the YaSp version though (as you have pointed out in your other post) and it must contain at least one function with the same name of the file (I do not really understand this restriction though). Indeed, the name given to a library through genlib() does not appear to be used anywhere (not even when libraryinfo() or whereis() are called). It may either be discarded or appear in libraryinfo(). Concerning libraryinfo(), I also find quite distrubing that it requires, as argument, the name (i.e. a string) of the variable containing the library and not the variable itself (or even better, the name given to the library with genlib()?). Best regards. Le 15.07.2015 12:25, Samuel Gougeon a ?crit : > Hi Pierre, > > Le 15/07/2015 09:37, contact at pierre-vuillemin.fr a ?crit : > >> .../... >> but this_is_a_very_very_long_function_name() is unknown. > . > You are right! When i did successfully the trial before posting to answer you, i used > clear this_is_a_very_very_long_function_name > before using lib, because i compiled this_is_a_very_very_long_function_name() by hand during previous tests. > So, to be sure that the function will be loaded by lib(..) instead of coming from a former compilation, i did this "clear..." > > BUT after tests of reproducibility before answering you here, i have just found that "clear" is bugged, and just posted that: http://bugzilla.scilab.org/13979 [1] > ! > I am unable to reproduce in Scilab 5.5.2 the formerly posted successful story. In all ways, indeed, as you were claiming it, it fails. > > These tests have shown other bugs. For instance, lib() is not (yet?) available in YaSp (2015-07-12 release)..., > and since getd() is bugged http://bugzilla.scilab.org/13890 [2], it turns hard to work with YaSp. > >> Besides, in the help page of "genlib", it is written that "Scilab tacitly assumes that file foo.sci defines at least a function named foo" which is not the case here. > . > That's also right. As you certainly also tested it, other tests confirm that. > There are other "strange" constrains with libraries. For example, genlib() needs a library name (first argin), but when loading a library with lib(), the genlib library name (that looks to build the "lib" file) looks to not be used. At least, the name of the library loaded by lib looks to depend on the name of the lhs as test_lib = lib(libdir), instead of on the genlib libname... It would not be unpleasant to rationalize / simplify that with Scilab 6. > > Best regards > Samuel > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev [3] Links: ------ [1] http://bugzilla.scilab.org/13979 [2] http://bugzilla.scilab.org/13890 [3] http://lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From siddheshwani.iitb at gmail.com Fri Jul 24 11:17:05 2015 From: siddheshwani.iitb at gmail.com (Siddhesh) Date: Fri, 24 Jul 2015 02:17:05 -0700 (MST) Subject: [Scilab-Dev] Developement of scilab extension 'Scilab2C' to add support for scilab functions Message-ID: <1437729425013-4032613.post@n3.nabble.com> Dear all, I am trying to add support for some commonly used scilab functions in ' Scilab2C ' extension. This extension is useful for converting scilab code to C code. But support for scilab functions is very limited. It mainly supports those functions which are available in c compiler like trignometric functions, log etc. I want to extend support for other scilab functions like cumprod, cumsum etc which are not available in c. My question is - to add support for these functions, writing these functions in c is the only way, or is there any other way like compiling scilab fuctions in certain format or library, which can be directly called from c and easily compiled together with c code. Waiting for early reply. -- View this message in context: http://mailinglists.scilab.org/Developement-of-scilab-extension-Scilab2C-to-add-support-for-scilab-functions-tp4032613.html Sent from the Scilab developers - Mailing Lists Archives mailing list archive at Nabble.com. From clement.david at scilab-enterprises.com Fri Jul 24 14:56:14 2015 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Fri, 24 Jul 2015 14:56:14 +0200 Subject: [Scilab-Dev] Developement of scilab extension 'Scilab2C' to add support for scilab functions In-Reply-To: <1437729425013-4032613.post@n3.nabble.com> References: <1437729425013-4032613.post@n3.nabble.com> Message-ID: <1437742574.2984.11.camel@scilab-enterprises.com> Hello Sidedhesh, Thanks for trying this code generator, it need to be improved and more interest on real use-case. In my view, all the Scilab algorithm should be emitted as equivalent C code to ease compactness and general usage of it. Even if re-using the code in a library seems to be viable alternative, linking against Scilab code might have some strong licensing restriction (google GPL vs LGPL). Do not hesitate to ask, if you need more info to go deeper into the code. -- Cl?ment Le vendredi 24 juillet 2015 ? 02:17 -0700, Siddhesh a ?crit : > Dear all, > > I am trying to add support for some commonly used scilab functions in > ' > Scilab2C ??' extension > . This > extension is useful for converting scilab code to C code. But support > for > scilab functions is very limited. It mainly supports those functions > which > are available in c compiler like trignometric functions, log etc. > > I want to extend support for other scilab functions like cumprod, > cumsum etc > which are not available in c. > My question is - to add support for these functions, writing these > functions > in c is the only way, or is there any other way like compiling scilab > fuctions in certain format or library, which can be directly called > from c > and easily compiled together with c code. > > Waiting for early reply. > > > > -- > View this message in context: http://mailinglists.scilab.org/Develope > ment-of-scilab-extension-Scilab2C-to-add-support-for-scilab-functions > -tp4032613.html > Sent from the Scilab developers - Mailing Lists Archives mailing list > archive at Nabble.com. > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From yann.debray at scilab-enterprises.com Thu Jul 30 16:09:52 2015 From: yann.debray at scilab-enterprises.com (Scilab communications) Date: Thu, 30 Jul 2015 16:09:52 +0200 Subject: [Scilab-Dev] Scilab 6.0.0-alpha-1 Release In-Reply-To: <551BAD43.6030205@scilab-enterprises.com> References: <551BAD43.6030205@scilab-enterprises.com> Message-ID: <55BA3030.1060408@scilab-enterprises.com> Dear Scilab users, Scilab team is happy to announce the release of the first alpha version of Scilab 6.0. Scilab 6.0.0 will be a major new release of Scilab, the open source platform for numerical computation. This 6.0.0-alpha-1 release, is a preview for *developers*, *partners *and *community evaluation*. As an alpha, this release is not yet ready for production usage. If you are new to Scilab, or if you are simply a user of Scilab, you should probably continue using the 5.5.2 release, and wait for a beta version before trying the 6 family. However, if you have already developed code on Scilab, or if you are an experienced user, then you should start looking at this release. Please try the work you have done on earlier releases of Scilab with this version: checking for compatibility may save you time later. If you find bugs or incompatibilities, please report them on our Bug Tracker: this will help get a better product, faster, which ultimately will be benefit you too. Sincerely yours -- 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 stephane.mottelet at utc.fr Thu Jul 30 18:08:38 2015 From: stephane.mottelet at utc.fr (=?UTF-8?B?U3TDqXBoYW5lIE1vdHRlbGV0?=) Date: Thu, 30 Jul 2015 18:08:38 +0200 Subject: [Scilab-Dev] problem compiling toolbox C gateway with Scilab 6.0 alpha In-Reply-To: <55969752.7080402@utc.fr> References: <55969752.7080402@utc.fr> Message-ID: <55BA4C06.4040404@utc.fr> Hello all, I still have this compilation problem under 6.0-alpha although the toolbox compiles fine under Scilab 5.5.2. If I look carefully in the error log, there seems to be a problem with a macro which returns the module name (spset is the name of the macro at the scilab level) L"spset" instead of "spset" For the second toolbox (fsqp) I know I have to revamp all the gateway which uses the stack... Thanks for your help. Le 03/07/2015 16:08, St?phane Mottelet a ?crit : > Hello, > > Thanks for the fix (Eigen dependency) in Yasp nightly build. Now I > have two problems, each specific to a different toolbox, which compile > fine under Scilab 5.5.2 (OSX 10.9.5) > > *with the first toolbox (with ApiScilab interfacing style) > > Commande : > /Applications/scilab-branch-YaSp-1435585794.app/Contents/MacOS/share/scilab/modules/dynamic_link/src/scripts/scicompile.sh > spset libspset.cpp libspset.h libspset.hxx sparse_set.c > stderr : > Ex?cute le makefile > ilib_compile : Commande de compilation : make CFLAGS=" > -D__SCILAB_TOOLBOX__ -g > -I/Applications/scilab-branch-YaSp-1435585794.app/Contents/MacOS/share/scilab/../../include/scilab/ > -I/Applications/scilab-branch-YaSp-1435585794.app/Contents/MacOS/share/scilab/../../include/ > " CXXFLAGS=" -D__SCILAB_TOOLBOX__ -g > -I/Applications/scilab-branch-YaSp-1435585794.app/Contents/MacOS/share/scilab/../../include/scilab/ > -I/Applications/scilab-branch-YaSp-1435585794.app/Contents/MacOS/share/scilab/../../include/ > " > FFLAGS="-I/Applications/scilab-branch-YaSp-1435585794.app/Contents/MacOS/share/scilab/../../include/scilab/ > " > Sortie : > stderr : libspset.cpp:13:60: warning: conversion from string literal > to 'wchar_t *' is deprecated [-Wc++11-compat-deprecated-writable-strings] > stderr : if(wcscmp(_pwstFuncName, L"spset") == 0){ > addCFunction(L"spset", &sparse_set, MODULE_NAME); } > stderr : ^ > stderr : libspset.cpp:13:83: warning: conversion from string literal > to 'wchar_t *' is deprecated [-Wc++11-compat-deprecated-writable-strings] > stderr : if(wcscmp(_pwstFuncName, L"spset") == 0){ > addCFunction(L"spset", &sparse_set, MODULE_NAME); } > stderr : ^ > stderr : libspset.cpp:9:21: note: expanded from macro 'MODULE_NAME' > stderr : #define MODULE_NAME L"libspset" > stderr : ^ > stderr : 2 warnings generated. > stderr : sparse_set.c:6:10: fatal error: 'MALLOC.h' file not found > stderr : #include "MALLOC.h" > stderr : ^ > stderr : 1 error generated. > stderr : make: *** [sparse_set.lo] Error 1 > > (...) > > *with the second one (fsqp Atoms module, old stack interfacing style) > : no problem at built time, but at loading time I got : > > macmottelet-gi-0:SCI mottelet$ > /Applications/scilab-branch-YaSp-1435585794.app/Contents/MacOS/bin/scilab > -nw -f fsqp/loader.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-1435585794 (Jun 30 2015, 06:35:20) > > Start fsqp toolbox > > Load macros > > Load gateways > addinter : La biblioth?que partag?e n'a pas ?t? charg?e: > dlopen(/Users/mottelet/svn/sysmetab/tags/4.0/SYSMETAB/SCI/fsqp/sci_gateway/c//libfsqp.dylib, > 10): Symbol not found: _SearchInDynLinks > Referenced from: > /Users/mottelet/svn/sysmetab/tags/4.0/SYSMETAB/SCI/fsqp/sci_gateway/c//libfsqp.dylib > Expected in: flat namespace > in > /Users/mottelet/svn/sysmetab/tags/4.0/SYSMETAB/SCI/fsqp/sci_gateway/c//libfsqp.dylib > > at line 18 of executed file loader.sce > at line 20 of executed file > /Users/mottelet/svn/sysmetab/tags/4.0/SYSMETAB/SCI/fsqp/sci_gateway/loader_gateway.sce > at line 32 of executed file > /Users/mottelet/svn/sysmetab/tags/4.0/SYSMETAB/SCI/fsqp/etc/fsqp_toolbox.start > at line 10 of executed file fsqp/loader.sce > > > What can I do myself to fix this ? Thanks for your help > > 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 Fri Jul 31 16:17:20 2015 From: stephane.mottelet at utc.fr (=?UTF-8?B?U3TDqXBoYW5lIE1vdHRlbGV0?=) Date: Fri, 31 Jul 2015 16:17:20 +0200 Subject: [Scilab-Dev] Scilab 6 and "hidden" functions ? Message-ID: <55BB8370.6070605@utc.fr> Hello, Trying to test the plotlib under Scilab 6, i discovered that it is impossible to define a function named "hidden" (this is a plotlib function emulating a Matlab function) function hidden(varargin) endfunction [Scilab6] function hidden(varargin) [Scilab6] ^~~~~~^ [Scilab6] /Users/mottelet/h.sci : 1.10 - 1.16 : syntax error, unexpected hidden, expecting [ or identifier In fact, "hidden" seems to be a new keyword, because the following seems to be ok : hidden function f(varargin) endfunction So there seems to be a parsing problem, because even "hidden" is a new pre-statement for function definition, I don't see any reason to forbid "hidden" as a function name. 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