Re: [Scilab-users] Variable scope in Scilab
Anyway, to me this topic looks (very) much less critical than the (bug or intentional?) disabling of funcprot() in Scilab 6. In Scilab 6, on one hand all "control" keywords select/if/then/else/return/ etc are now protected. On the other hand, funcprot() no longer works and makes fragile all native macros and builtin symbols... A very inconsistent and impacting roadmap. Putting Scilab in students hands is much more prone to errors due to this unprotection, than due to external initializations.. Samuel Le 10/05/2021 à 21:41, Samuel Gougeon a écrit : Hello, Le 26/02/2021 à 14:38, Stéphane Mottelet a écrit : Hi all, In Scilab the scope of variables is quite permissive but even in Julia (really strict rules) we can have the following behavior: .../... ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
Re: [Scilab-users] Variable scope in Scilab
Hello, Le 26/02/2021 à 14:38, Stéphane Mottelet a écrit : Hi all, In Scilab the scope of variables is quite permissive but even in Julia (really strict rules) we can have the following behavior: function y=f(x) y=x+a; end a=1; f(2) a=2; f(3) -> a=1; --> f(2) ans = 3. --> a=2; --> f(3) ans = 5. Yesterday afternoon I was my students for a Scilab beginners tutorial, and by accident one of them had "x" defined before in the main workspace and tried to call f without arguments. I reproduce the experiment here by explicitely defining x before the call: x=1; f --> x=1; --> f ans = 3. Allowing the function inner scope to see variables of the outer scope is one thing, you may or may not agree this is not the point here, but allowing to call f without arguments just because the formal input parameter has the same symbol as an outer scope symbol is another thing. I knew this was possible even if i never used such a feature, but my students were so puzzled by this, particularly those who already learned other low-level languages, that I decided to propose the suppression of this, that I consider as a serious potential source of many bugs. Don't tell me that this would break some user code because I frankly have no consideration for this kind of crappy shortcut and, sorry if it may sound rude, for programmers who use it... If low-level languages would be mandatory references imposing all their constrains, Scilab and other high level languages would not exist. Most often, the same people knowing "only" low level languages do not understand vectorized syntaxes and prefer to write as many explicit (nested) /for/ loops as needed. Very nice... :-/ About the topic: likely, i would not consider input and output arguments in the same way: * Input arguments*: As soon as external variables can be seen from the function, i do not see fundamental differences between an input argument -- that technically speaking can always be optional --, and any other internal variable. /It's the author's responsibility to properly test and initialize input arguments as is. We can't replace this responsability with an exception to a general scoping rule./ Accepting that the result can be built from external objects out of the list of input arguments.. already weakens the specific role of these ones (by the way as in object oriented programming, where operands are most often class attributes "in an external context" out of the list of input arguments). You propose to "reinforce" the strictness of their role, but without weakening the accessibility of external objects. Doesn't it look a bit arbitrary, and vain? I don't think it would make programming neither easier nor really more "reliable". *Output arguments*: they are more clearly expected to be products of the function, not of anything else. Initializing them from outside looks more awkward and tricky. My two cents.. Regards Samuel ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
Re: [Scilab-users] Curing scf() & figure() slowliness: a good target for Scilab 6.0.1
Le 25/02/2017 à 18:05, Samuel Gougeon a écrit : Hello, Opening a new empty figure (without drawing anything) is a so common elementary task and it has become so long that i have built a short benchmark about it from Scilab 4.1.2 to Scilab 6.0. Detailed results are here-below. The main conclusions are the following: 1. with no pre-existing figure,*scf**() is **20 times slower in **5.5 and 6.0 than in *its best performances in *5.3.0*. On my computer, it takes 0.062 s with 5.3.0 and 1.3 s now (5.5.2|6.0). Scilab 5.4.0, 5.4.1 and 5.5.0 have dramatically damaged performances. The loss is even 10x bigger with figure(): it is ~200 times slower with Scilab 5.5 & 6.0 than with Scilab 4.1.2 2. Since Scilab 5.5.0, the time taken to open a new figure increases linearly with the number of already opened figures. On my computer, opening the first one (after loading scf()) takes 1.8 s, and opening the 20th one takes almost 10 s. This is still the case with Scilab 6.0. *Detailled results: * 1. Opening the first figure : Only 2 tests are reported with figure() instead of scf(). t=0; for i=1:50, tic(); scf(); t=t+toc(); xdel(); end; t, t/50 [s] [s] 4.1.2 base figure() 6.0.0 : 62.39/50 1.24818.5 2.32 5.5.2 : 73.62/50 1.4723 21.8 5.5.0 : 69.94/50 1.3988 20.8 5.4.1 : 37.33/50 0.7466 11.1 5.4.0 : 24.07/50 0.4814 7.14 5.3.0 : 3.102/50 0.0620 0.92 5.1.0 : 4.069/50 0.0814 1.21 4.1.2 : 3.370/50 0.0674 1.00 0.014 2. Opening 20 figures : t=[]; for i=1:20, tic(); scf(); t(i)=toc(); end; sum(t)/20 6.0.0 : 5.30 [1.35 => 9.51] 5.5.2 : 5.68 [1.77 => 9.92] 5.5.0 : 5.66 [1.82 => 9.85] range from the #1 to #20 5.4.1 : 1.18 5.4.0 : 0.923 5.3.0 : 0.110 5.1.0 : 4.1.2 : 0.0774 Samuel This issue is fixed in Scilab 6.1.0, on Windows 10. Fortunately. Here are the current Scilab 6.1.0 performances (on another computer than in 2017): It is still ~5x slower than with Scilab 4.1.2 (on the same computer), but it no longer depends on the number or figures currently opened. Samuel ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
Re: [Scilab-users] Scilab compilation from scratch (was Re: spec can crash scilab)
Le 10/05/2021 à 15:35, Clément David a écrit : -Original Message- From: users On Behalf Of Antoine Monmayrant Sent: Monday, May 10, 2021 1:02 PM To: users@lists.scilab.org Subject: Re: [Scilab-users] Scilab compilation from scratch (was Re: spec can crash scilab) Le 10/05/2021 à 09:12, Clément David a écrit : To fix, remove libstdc++.so and libgfortran.so on the Prerequirements; Er, OK, I'm glad to do that, but I don't see what you are talking about. Where are those 'Prerequirements' defined? (I'm really not versed into compiling, I just barely know the basics...) What we called Prerequirements (or thirdparties) are binaries used for the Scilab compilation but coming from external sources (for example, libxml2 or curl). At configure time, a detection is performed to use them rather than using the system's ones. If you used the cheatsheet, they are delivered with the svn command and should be located on the "usr" directory. Ah, OK, so I should just get rid of them after the svn command to rely on the binaries provided by my system. Thanks. Antoine Clément ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
Re: [Scilab-users] Scilab compilation from scratch (was Re: spec can crash scilab)
> -Original Message- > From: users On Behalf Of Antoine > Monmayrant > Sent: Monday, May 10, 2021 1:02 PM > To: users@lists.scilab.org > Subject: Re: [Scilab-users] Scilab compilation from scratch (was Re: spec can > crash scilab) > > > Le 10/05/2021 à 09:12, Clément David a écrit : > > To fix, remove libstdc++.so and libgfortran.so on the Prerequirements; > Er, OK, I'm glad to do that, but I don't see what you are talking about. > Where are those 'Prerequirements' defined? > > (I'm really not versed into compiling, I just barely know the basics...) What we called Prerequirements (or thirdparties) are binaries used for the Scilab compilation but coming from external sources (for example, libxml2 or curl). At configure time, a detection is performed to use them rather than using the system's ones. If you used the cheatsheet, they are delivered with the svn command and should be located on the "usr" directory. Clément ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
Re: [Scilab-users] Scilab compilation from scratch (was Re: spec can crash scilab)
Le 10/05/2021 à 10:25, Stéphane Mottelet a écrit : I added also 'F77=gfortran-8' in the configure. What do you mean? As a command line option to configure? Antoine ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
Re: [Scilab-users] Scilab compilation from scratch (was Re: spec can crash scilab)
Le 10/05/2021 à 09:12, Clément David a écrit : To fix, remove libstdc++.so and libgfortran.so on the Prerequirements; Er, OK, I'm glad to do that, but I don't see what you are talking about. Where are those 'Prerequirements' defined? (I'm really not versed into compiling, I just barely know the basics...) Antoine ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
Re: [Scilab-users] Scilab compilation from scratch (was Re: spec can crash scilab)
Hi, I added also 'F77=gfortran-8' in the configure. S. Le 10/05/2021 à 09:12, Clément David a écrit : This one is less obvious and will require more explanation. In Scilab 6, we use modern C++ (C++11 and later) on our codebase which requires to have modern compilers and runtime libraries (libstdc++ libgfortran). For the compilation chain, we build gcc 8 on an old centos 6 distribution so runtimes are available. For people using Scilab, to avoid clashing between the system libstdc++/libgfortran and Scilab libstdc++/libgfortran, the Scilab runtime libraries are renamed to libscistdc++/libscigfortran. For building toolboxes against the Scilab runtime libraries and their libstdc++.so and libgfortran.so development libraries are provided on the Prerequirements. This is the source of your issue as the Prerequirements LDFLAGS are detected and used at configure-time. To fix, remove libstdc++.so and libgfortran.so on the Prerequirements; this will make your Scilab-build tied to your system; this is good for development purposes. Regards, Clément -Original Message- From: users On Behalf Of Antoine Monmayrant Sent: Sunday, May 9, 2021 4:39 PM To: users@lists.scilab.org Subject: Re: [Scilab-users] Scilab compilation from scratch (was Re: spec can crash scilab) Hello all, Just a quick update: (1) I installed & configured as default : openjdk-8 gcc-8 g++8 (2) I had to rm everything and restart from scratch: somehow, my first try at compiling with openjdk-11 had left some *.class files behind (with the wrong version) that make clean is not removing (3) Now I am stuck at libscigfortran not being found. I'm pretty sure I miss some mystery -lrandomlibame flag or someLD_* stuff... : /usr/bin/ld: warning: libscigfortran.so.5, needed by /home/amonmayr/softs/scilab- recompile/scilab_master/scilab/usr/lib/liblapack.so, not found (try using -rpath or -rpath-link) If anyone who knows more than me about ld flags wants to chime in, I could do with a bit of help... Cheers, Antoine PS: I tried to join config.log but the email got too big for the mailing list... On 07/05/2021 18:18, Clément David wrote: Hello Antoine, This issue might comes from a wrong jdk version, you should have openjdk8 installed on your machine and it should be listed at configure time. Could you post the config.log file for further investigation ? Thanks, Clément -Original Message- From: users On Behalf Of Antoine Monmayrant Sent: Friday, May 7, 2021 5:40 PM To: users@lists.scilab.org Subject: [Scilab-users] Scilab compilation from scratch (was Re: spec can crash scilab) Hello all, In order to try to mitigate bug 15330, I try to compile scilab from source on Linux Ubuntu 18.04 64bits. I follow the explanations from https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/wiki.scilab.org/Compilation%20of%20Scilab [Linux x86_64 cheat sheet]. Sadly, I don't go really far as the prebuild of java fails: Makefile:756: recipe for target 'java' failed Am I missing something? Are there other infos somewhere, in particular concerning the dependencies ? Is there a more detailed tutorial for building scilab? Cheers, Antoine ___ users mailing list users@lists.scilab.org https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -- Stéphane Mottelet Ingénieur de recherche EA 4297 Transformations Intégrées de la Matière Renouvelable Département Génie des Procédés Industriels Sorbonne Universités - Université de Technologie de Compiègne CS 60319, 60203 Compiègne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
Re: [Scilab-users] Scilab compilation from scratch (was Re: spec can crash scilab)
This one is less obvious and will require more explanation. In Scilab 6, we use modern C++ (C++11 and later) on our codebase which requires to have modern compilers and runtime libraries (libstdc++ libgfortran). For the compilation chain, we build gcc 8 on an old centos 6 distribution so runtimes are available. For people using Scilab, to avoid clashing between the system libstdc++/libgfortran and Scilab libstdc++/libgfortran, the Scilab runtime libraries are renamed to libscistdc++/libscigfortran. For building toolboxes against the Scilab runtime libraries and their libstdc++.so and libgfortran.so development libraries are provided on the Prerequirements. This is the source of your issue as the Prerequirements LDFLAGS are detected and used at configure-time. To fix, remove libstdc++.so and libgfortran.so on the Prerequirements; this will make your Scilab-build tied to your system; this is good for development purposes. Regards, Clément > -Original Message- > From: users On Behalf Of Antoine > Monmayrant > Sent: Sunday, May 9, 2021 4:39 PM > To: users@lists.scilab.org > Subject: Re: [Scilab-users] Scilab compilation from scratch (was Re: spec can > crash scilab) > > Hello all, > > Just a quick update: > (1) I installed & configured as default : openjdk-8 gcc-8 g++8 > (2) I had to rm everything and restart from scratch: somehow, my first try at > compiling with openjdk-11 had left some *.class files behind (with the wrong > version) that make clean is not removing > (3) Now I am stuck at libscigfortran not being found. I'm pretty sure I miss > some mystery -lrandomlibame flag or someLD_* stuff... : > /usr/bin/ld: warning: libscigfortran.so.5, needed by > /home/amonmayr/softs/scilab- > recompile/scilab_master/scilab/usr/lib/liblapack.so, > not found (try using -rpath or -rpath-link) > > If anyone who knows more than me about ld flags wants to chime in, I could > do with a bit of help... > > Cheers, > > > Antoine > PS: I tried to join config.log but the email got too big for the mailing > list... > > On 07/05/2021 18:18, Clément David wrote: > > Hello Antoine, > > > > This issue might comes from a wrong jdk version, you should have > > openjdk8 installed on your machine and it should be listed at > > configure time. Could you post the config.log file for further > > investigation ? > > > > Thanks, > > > > Clément > > > > -Original Message- > > From: users On Behalf Of Antoine > > Monmayrant > > Sent: Friday, May 7, 2021 5:40 PM > > To: users@lists.scilab.org > > Subject: [Scilab-users] Scilab compilation from scratch (was Re: spec > > can crash scilab) > > > > Hello all, > > > > In order to try to mitigate bug 15330, I try to compile scilab from > > source on Linux Ubuntu 18.04 64bits. > > I follow the explanations from > > https://wiki.scilab.org/Compilation%20of%20Scilab [Linux x86_64 cheat > > sheet]. > > Sadly, I don't go really far as the prebuild of java fails: > > > > > > Makefile:756: recipe for target 'java' failed > > > > Am I missing something? > > Are there other infos somewhere, in particular concerning the > > dependencies ? > > Is there a more detailed tutorial for building scilab? > > > > Cheers, > > > > Antoine > > > > > > ___ > > users mailing list > > users@lists.scilab.org > > http://lists.scilab.org/mailman/listinfo/users > > ___ > > users mailing list > > users@lists.scilab.org > > http://lists.scilab.org/mailman/listinfo/users > > > > > ___ > users mailing list > users@lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
