From jdb61858 at suoox.com Thu Mar 5 04:42:11 2020 From: jdb61858 at suoox.com (RolandB) Date: Wed, 4 Mar 2020 20:42:11 -0700 (MST) Subject: [Scilab-Dev] Customer Service Policy Suggestion Message-ID: <1583379731475-0.post@n3.nabble.com> Dear developers and decision-makers at ESI, I know that "Customer Service" sounds a bit off, as Scilab is a free and open source software and the vast majority of the Scilab users aren't paying customers to begin with. But from what I understand, you have at least some commercial interest in Scilab users as you offer training, development and support/maintenance services commercially. Now even if only a small percentage of all the Scilab users request your services, I figure that it should be in your interest to have as broad a user base as possible, because a small percentage of a huge user base will always be more customers than a small percentage of a mediocre user base. I know that everything is not free and everything I could wish for cannot be implemented in the official Scilab releases, because that would cost unlimited developer resources and would also deprive you of any chance to earn some money with customized developments and support. But at least what is officially released should be substantially bug free. Otherwise you will exasperate current and potentially future users and eventually you might lose them to other scientific computing solutions. IMO in order to make the official releases less bugged and more attractive, you should care more about the users' issues and include them into decision-making. Not to say that you have to do as they wish, but you should at least hear them out. If you put off the users of the free Scilab releases, who may be professors and students to a significant extent, then in a few years those turned-into-engineers students might not be your paying customers but just Mathwork's ones... You might have the best expertise when it comes to coding and testing Scilab and therefore might think that you can dispense with what the users could contribute. But you just don't have the breadth of applications and implemented solutions all the users have combined. Just look at the few weeks following every major release where bug report numbers are skyrocketing. Why not just announce something like a beta test version a month or so before the planned release date of the official release? The majority of bug reports could then be dealt with and the official release would be much less off-putting to your potential future customers. Regards, Roland Saur-Brosch P.S.: And please, pretty please, take care of the registration issue (bugs 15700, 16119 and 16130). Many people have special characters in their email address. At least announce somewhere that email addresses with special characters do not work, despite the registration seems to be accepted in the first place. Also, please consider implementing SRS with the mailing list server. Some email providers have SPF active and without SRS the users that are using those email providers are effectively precluded from posting anything on the mailing list. Please make and keep contributions to Scilab attractive and easy (and possible in the first place). -- Sent from: http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944.html From sylvain.corlay at gmail.com Thu Mar 5 10:14:51 2020 From: sylvain.corlay at gmail.com (Sylvain Corlay) Date: Thu, 5 Mar 2020 10:14:51 +0100 Subject: [Scilab-Dev] Scilab 6.1.0 is available! In-Reply-To: References: Message-ID: Hello, Is there any update on the support of GCC 7 for Scilab 6.1? This is a major blocker for us to package it for the conda ecosystem. Best, On Thu, Feb 27, 2020 at 4:12 PM Sylvain Corlay wrote: > Patching the source to use resolves that > particular issue with C++17 in GCC7. > > However, the Scilab build now fails with many occurrences of the error: > > error: template with C linkage > > - You can see the raw build logs here: > https://dev.azure.com/conda-forge/84710dde-1620-425b-80d0-4cf5baca359d/_apis/build/builds/125787/logs/7 > - The scilab recipe update including the patches for is > available here: https://github.com/conda-forge/scilab-feedstock/pull/11 > > Officially supporting older versions of GCC than GCC 8 (which is from May > 2018) would be greatly appreciated. > > Best, > > > On Thu, Feb 27, 2020 at 2:28 PM Sylvain Corlay > wrote: > >> Hi Cl?ment, >> >> Regarding the Java, we already skip xcos in the build but we were really >> hoping that we could start including it with this version. >> >> For the filesystem thingy, I will be patching the source as part of the >> conda recipe to use instead and see how it goes - >> although it would be really nice if we could support more compilers out of >> the box. >> >> Sylvain >> >> On Thu, Feb 27, 2020 at 2:25 PM Cl?ment David < >> Clement.David at esi-group.com> wrote: >> >>> Hello Sylvain, >>> >>> First, thank you for your work on the conda packaging. The c++17 >>> requirements is only needed for a single file that is used to implement >>> fullpath() (named fullpath.cpp). The used API is reduced to >>> std::filesystem::weakly_canonical and std::filesystem::absolute [1]. I >>> guess using a light patch might relax the use of the filesystem header, for >>> example, something like [2]. >>> >>> About the Java8 requirement, I guess you could ./configure >>> --without-xcos as a first approach. I started porting the Java code out of >>> javax.xml.bind [3] but that's very repetitive and error prone work. >>> >>> [1]: >>> https://codereview.scilab.org/#/c/21041/25/scilab/modules/fileio/src/cpp/fullpath.cpp >>> [2]: >>> https://stackoverflow.com/questions/45867379/why-does-gcc-not-seem-to-have-the-filesystem-standard-library >>> [3]: https://codereview.scilab.org/#/c/20630/ >>> >>> Regards, >>> >>> -- >>> Cl?ment >>> >>> > -----Original Message----- >>> > From: dev On Behalf Of Sylvain Corlay >>> > Sent: Thursday, February 27, 2020 1:50 PM >>> > To: List dedicated to the development of Scilab >>> > Subject: Re: [Scilab-Dev] Scilab 6.1.0 is available! >>> > >>> > Congratulations on the release. >>> > >>> > I am the author of the conda package for scilab, and unfortunately, it >>> does not >>> > seem that 6.1.0 can be successfully packaged for conda-forge with the >>> new >>> > requirement for the C++17 header, which requires GCC 8. >>> > >>> > Conda-forge is still based on GCC 7, which is fairly recent, with >>> C++17 enabled by >>> > default. Would you consider not using the from the C++17 >>> standard >>> > so that Scilab can be made available to a wider audience? >>> > >>> > Another blocker to the packaging of Scilab is the outdated version of >>> java that is >>> > required by the GUI. Is there any plan to support a more recent >>> version of >>> > OpenJDK? >>> > >>> > Best, >>> > >>> > Sylvain Corlay >>> > >>> > On Tue, Feb 25, 2020 at 2:10 PM Cl?ment David >> > group.com > wrote: >>> > >>> > >>> > Dear Scilab-ers, >>> > >>> > >>> > >>> > A brand new Scilab 6.1.0 >>> is >>> > released today! >>> > >>> > >>> > >>> > This version includes further improvement atop Scilab 6.0 for >>> better >>> > stability and increased algorithm performance. It also includes a >>> reworked >>> > display for more compact and meaningful value printing; web tools for >>> HTTP, >>> > JSON support; better debug support and various algorithm >>> rewrite/extension. >>> > >>> > >>> > >>> > This first iteration of the 6.1 branch fixes up to 245 bugs and >>> implements >>> > missing features from the 6.0.2 version. We would like to give a >>> special thanks >>> > to Samuel and Stephane who have been very active this year. >>> > >>> > >>> > >>> > If you find any critical issue or instability that might need a >>> 6.1.x release >>> > please alert us . If you are a toolbox >>> maintainer, >>> > please rebuild your code, upgrade it when needed and publish it to >>> > atoms.scilab.org . >>> > >>> > >>> > >>> > For the complete list of changes and bugs fixed, please take a >>> look at >>> > the CHANGES file. >>> > >>> > >>> > >>> > -- >>> > >>> > Cl?ment on behalf of the Scilab team >>> > >>> > _______________________________________________ >>> > dev mailing list >>> > dev at lists.scilab.org >>> > http://lists.scilab.org/mailman/listinfo/dev >>> > >>> >>> _______________________________________________ >>> dev mailing list >>> dev at lists.scilab.org >>> http://lists.scilab.org/mailman/listinfo/dev >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Clement.David at esi-group.com Thu Mar 5 11:40:44 2020 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Thu, 5 Mar 2020 10:40:44 +0000 Subject: [Scilab-Dev] Scilab 6.1.0 is available! In-Reply-To: References: Message-ID: Hello Sylvain, I took a look at the trace, it looks like g++ 7 is confused with the xml.h include ; as libxml2 is already protected with ifdef __cplusplus extern "C" you might just move the #include from XMLDocument.hxx:28 out of the extern "C". Sorry about that but gcc-7 is not our target for official releases, Debian/Ubuntu/Fedora all ship gcc-8 with a more stable c++17 support. I could only help to debug issues on the conda side. Regards, -- Cl?ment > -----Original Message----- > From: dev On Behalf Of Sylvain Corlay > Sent: Thursday, March 5, 2020 10:15 AM > To: List dedicated to the development of Scilab > Subject: Re: [Scilab-Dev] Scilab 6.1.0 is available! > > Hello, > > Is there any update on the support of GCC 7 for Scilab 6.1? > > This is a major blocker for us to package it for the conda ecosystem. > > Best, > > On Thu, Feb 27, 2020 at 4:12 PM Sylvain Corlay > wrote: > > > Patching the source to use resolves that > particular issue with C++17 in GCC7. > > However, the Scilab build now fails with many occurrences of the error: > > error: template with C linkage > > > - You can see the raw build logs here: https://dev.azure.com/conda- > forge/84710dde-1620-425b-80d0- > 4cf5baca359d/_apis/build/builds/125787/logs/7 > - The scilab recipe update including the patches for is > available here: https://github.com/conda-forge/scilab-feedstock/pull/11 > > Officially supporting older versions of GCC than GCC 8 (which is from > May 2018) would be greatly appreciated. > > > Best, > > > On Thu, Feb 27, 2020 at 2:28 PM Sylvain Corlay > > wrote: > > > Hi Cl?ment, > > Regarding the Java, we already skip xcos in the build but we > were really hoping that we could start including it with this version. > > For the filesystem thingy, I will be patching the source as part of > the conda recipe to use instead and see how it goes - > although it would be really nice if we could support more compilers out of the > box. > > Sylvain > > On Thu, Feb 27, 2020 at 2:25 PM Cl?ment David > > > wrote: > > > Hello Sylvain, > > First, thank you for your work on the conda packaging. > The c++17 requirements is only needed for a single file that is used to implement > fullpath() (named fullpath.cpp). The used API is reduced to > std::filesystem::weakly_canonical and std::filesystem::absolute [1]. I guess using > a light patch might relax the use of the filesystem header, for example, > something like [2]. > > About the Java8 requirement, I guess you could > ./configure --without-xcos as a first approach. I started porting the Java code > out of javax.xml.bind [3] but that's very repetitive and error prone work. > > [1]: > https://codereview.scilab.org/#/c/21041/25/scilab/modules/fileio/src/cpp/fullp > ath.cpp > [2]: > https://stackoverflow.com/questions/45867379/why-does-gcc-not-seem-to- > have-the-filesystem-standard-library > [3]: https://codereview.scilab.org/#/c/20630/ > > Regards, > > -- > Cl?ment > > > -----Original Message----- > > From: dev > On Behalf Of Sylvain Corlay > > Sent: Thursday, February 27, 2020 1:50 PM > > To: List dedicated to the development of Scilab > > > > Subject: Re: [Scilab-Dev] Scilab 6.1.0 is available! > > > > Congratulations on the release. > > > > I am the author of the conda package for scilab, and > unfortunately, it does not > > seem that 6.1.0 can be successfully packaged for > conda-forge with the new > > requirement for the C++17 header, > which requires GCC 8. > > > > Conda-forge is still based on GCC 7, which is fairly > recent, with C++17 enabled by > > default. Would you consider not using the > from the C++17 standard > > so that Scilab can be made available to a wider > audience? > > > > Another blocker to the packaging of Scilab is the > outdated version of java that is > > required by the GUI. Is there any plan to support a > more recent version of > > OpenJDK? > > > > Best, > > > > Sylvain Corlay > > > > On Tue, Feb 25, 2020 at 2:10 PM Cl?ment David > > group.com > group.com> > > wrote: > > > > > > Dear Scilab-ers, > > > > > > > > A brand new Scilab 6.1.0 > is > > released today! > > > > > > > > This version includes further improvement atop > Scilab 6.0 for better > > stability and increased algorithm performance. It also > includes a reworked > > display for more compact and meaningful value > printing; web tools for HTTP, > > JSON support; better debug support and various > algorithm rewrite/extension. > > > > > > > > This first iteration of the 6.1 branch fixes up to 245 > bugs and implements > > missing features from the 6.0.2 version. We would > like to give a special thanks > > to Samuel and Stephane who have been very active > this year. > > > > > > > > If you find any critical issue or instability that might > need a 6.1.x release > > please alert us . If you > are a toolbox maintainer, > > please rebuild your code, upgrade it when needed and > publish it to > > atoms.scilab.org > . > > > > > > > > For the complete list of changes and bugs fixed, > please take a look at > > the CHANGES > file. > > > > > > > > -- > > > > Cl?ment on behalf of the Scilab team > > > > > _______________________________________________ > > 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 sylvain.corlay at gmail.com Thu Mar 5 11:56:05 2020 From: sylvain.corlay at gmail.com (Sylvain Corlay) Date: Thu, 5 Mar 2020 11:56:05 +0100 Subject: [Scilab-Dev] Scilab 6.1.0 is available! In-Reply-To: References: Message-ID: Hi Cl?ment, Indeed, this is what I ended up doing - and there are a couple of instances of the same error in various places. This appears to be a legitimate error C++ even though this passes with GCC 8. On the choice of dropping GCC<8, this seems a bit early, even if the latest flavors of Ubuntu, or Debian Sid already have GCC8 available. GCC6 and GCC7 are recent compilers and people target older distributions in their builds. Best, Sylvain Corlay On Thu, Mar 5, 2020 at 11:41 AM Cl?ment David wrote: > Hello Sylvain, > > I took a look at the trace, it looks like g++ 7 is confused with the xml.h > include ; as libxml2 is already protected with ifdef __cplusplus extern "C" > you might just move the #include from XMLDocument.hxx:28 out of the > extern "C". > > Sorry about that but gcc-7 is not our target for official releases, > Debian/Ubuntu/Fedora all ship gcc-8 with a more stable c++17 support. I > could only help to debug issues on the conda side. > > Regards, > > -- > Cl?ment > > > -----Original Message----- > > From: dev On Behalf Of Sylvain Corlay > > Sent: Thursday, March 5, 2020 10:15 AM > > To: List dedicated to the development of Scilab > > Subject: Re: [Scilab-Dev] Scilab 6.1.0 is available! > > > > Hello, > > > > Is there any update on the support of GCC 7 for Scilab 6.1? > > > > This is a major blocker for us to package it for the conda ecosystem. > > > > Best, > > > > On Thu, Feb 27, 2020 at 4:12 PM Sylvain Corlay > > wrote: > > > > > > Patching the source to use resolves that > > particular issue with C++17 in GCC7. > > > > However, the Scilab build now fails with many occurrences of the > error: > > > > error: template with C linkage > > > > > > - You can see the raw build logs here: > https://dev.azure.com/conda- > > forge/84710dde-1620-425b-80d0- > > 4cf5baca359d/_apis/build/builds/125787/logs/7 > > - The scilab recipe update including the patches for > is > > available here: https://github.com/conda-forge/scilab-feedstock/pull/11 > > > > Officially supporting older versions of GCC than GCC 8 (which is > from > > May 2018) would be greatly appreciated. > > > > > > Best, > > > > > > On Thu, Feb 27, 2020 at 2:28 PM Sylvain Corlay > > > wrote: > > > > > > Hi Cl?ment, > > > > Regarding the Java, we already skip xcos in the build but > we > > were really hoping that we could start including it with this version. > > > > For the filesystem thingy, I will be patching the source > as part of > > the conda recipe to use instead and see how it > goes - > > although it would be really nice if we could support more compilers out > of the > > box. > > > > Sylvain > > > > On Thu, Feb 27, 2020 at 2:25 PM Cl?ment David > > > > > wrote: > > > > > > Hello Sylvain, > > > > First, thank you for your work on the conda > packaging. > > The c++17 requirements is only needed for a single file that is used to > implement > > fullpath() (named fullpath.cpp). The used API is reduced to > > std::filesystem::weakly_canonical and std::filesystem::absolute [1]. I > guess using > > a light patch might relax the use of the filesystem header, for example, > > something like [2]. > > > > About the Java8 requirement, I guess you could > > ./configure --without-xcos as a first approach. I started porting the > Java code > > out of javax.xml.bind [3] but that's very repetitive and error prone > work. > > > > [1]: > > > https://codereview.scilab.org/#/c/21041/25/scilab/modules/fileio/src/cpp/fullp > > ath.cpp > > [2]: > > https://stackoverflow.com/questions/45867379/why-does-gcc-not-seem-to- > > have-the-filesystem-standard-library > > [3]: https://codereview.scilab.org/#/c/20630/ > > > > Regards, > > > > -- > > Cl?ment > > > > > -----Original Message----- > > > From: dev > > On Behalf Of Sylvain Corlay > > > Sent: Thursday, February 27, 2020 1:50 PM > > > To: List dedicated to the development of Scilab > > > > > > Subject: Re: [Scilab-Dev] Scilab 6.1.0 is > available! > > > > > > Congratulations on the release. > > > > > > I am the author of the conda package for scilab, > and > > unfortunately, it does not > > > seem that 6.1.0 can be successfully packaged for > > conda-forge with the new > > > requirement for the C++17 header, > > which requires GCC 8. > > > > > > Conda-forge is still based on GCC 7, which is > fairly > > recent, with C++17 enabled by > > > default. Would you consider not using the > > from the C++17 standard > > > so that Scilab can be made available to a wider > > audience? > > > > > > Another blocker to the packaging of Scilab is the > > outdated version of java that is > > > required by the GUI. Is there any plan to > support a > > more recent version of > > > OpenJDK? > > > > > > Best, > > > > > > Sylvain Corlay > > > > > > On Tue, Feb 25, 2020 at 2:10 PM Cl?ment David > > > > group.com > > > group.com> > > wrote: > > > > > > > > > Dear Scilab-ers, > > > > > > > > > > > > A brand new Scilab 6.1.0 > > is > > > released today! > > > > > > > > > > > > This version includes further improvement > atop > > Scilab 6.0 for better > > > stability and increased algorithm performance. > It also > > includes a reworked > > > display for more compact and meaningful value > > printing; web tools for HTTP, > > > JSON support; better debug support and various > > algorithm rewrite/extension. > > > > > > > > > > > > This first iteration of the 6.1 branch > fixes up to 245 > > bugs and implements > > > missing features from the 6.0.2 version. We would > > like to give a special thanks > > > to Samuel and Stephane who have been very active > > this year. > > > > > > > > > > > > If you find any critical issue or > instability that might > > need a 6.1.x release > > > please alert us > . If you > > are a toolbox maintainer, > > > please rebuild your code, upgrade it when needed > and > > publish it to > > > atoms.scilab.org > > . > > > > > > > > > > > > For the complete list of changes and bugs > fixed, > > please take a look at > > > the CHANGES > > file. > > > > > > > > > > > > -- > > > > > > Cl?ment on behalf of the Scilab team > > > > > > > > _______________________________________________ > > > dev mailing list > > > dev at lists.scilab.org dev at lists.scilab.org> > > > > > > > http://lists.scilab.org/mailman/listinfo/dev > > > > > > > > > _______________________________________________ > > dev mailing list > > dev at lists.scilab.org > > http://lists.scilab.org/mailman/listinfo/dev > > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chinluh.tan at bytecode-asia.com Sat Mar 7 07:30:01 2020 From: chinluh.tan at bytecode-asia.com (Chin Luh Tan) Date: Sat, 07 Mar 2020 14:30:01 +0800 Subject: [Scilab-Dev] Scilab 6.1 in Raspberry Pi Message-ID: <170b3afb486.1233dd2ce539756.7154408045681835357@bytecode-asia.com> Hi Scilab developers,? Ever since Raspberry Pi 4 released with extra RAM of 2G and 4G version, Scilab could be run quite smoothly under Ubuntu Server RaspPi version. (In fact, the speed is quite acceptable even in Raspberry Pi 3). Even it is still having some bugs, the binary provided by the Ubuntu repository could just run after apt-get in Raspberry Pi. (Scilab 6.01 / 6.02 under current LTS 18.04 and 19.10 respectively).? Since the release of Scilab 6.1 is quite new, it is only available in unstable release, or we need to recompile from scratch (no-gui). However, even the scilab-cli could launch with both method, I encounter the following crash whenever Scilab 6.1 (scilab-cli) start to echo character '0' on the screen ________________________ ubuntu at ubuntu:~/scilab_master/scilab/bin$ ./scilab-cli Scilab branch-master (Mar? 7 2020, 02:45:45) --> a = 1; --> b = 0; --> a a? = ?? 1. --> b b? = terminate called after throwing an instance of 'std::length_error' ? what():? basic_string::_M_replace_aux A fatal error has been detected by Scilab. Please check your user-defined functions (or external module ones) should they appear in the stack trace. Otherwise you can report a bug on?http://bugzilla.scilab.org/?with: * a sample code which reproduces the issue * the result of [a, b] = getdebuginfo() * the following information: [ubuntu:24308] Signal: Aborted (6) [ubuntu:24308] Signal code:? (-6) Call stack: ?? 1: 0x324d8? ????????????????????????? (/lib/aarch64-linux-gnu/libc.so.6) End of stack _________________________________ Anyone has any idea on what likely causing the problem? More details: -->? [a, b] = getdebuginfo() a? = ? "Total memory:??? 1892552" ? "Used memory:??? 1137908" ? "Free memory:???? 754644" ? "Shared memory:????????? 0" ? "Buffers memory:????? 53452" ? "Cached memory:???? 813852" ? "Used -/+ buffers/cache:???? 270604" ? "Free -/+ buffers/cache:??? 1621948" ? "Total swap:????????? 0" ? "Used swap:????????? 0" ? "Free swap:????????? 0" ? "SCI: /home/ubuntu/scilab_master/scilab" ? "SCIHOME: /home/ubuntu/.Scilab/scilab-branch-master" ? "TMPDIR: /tmp/SCI_TMP_24419_wVkgKB" b? = ? "Scilab Version: scilab-branch-master" ? "Compilation date: Mar? 7 2020" ? "Compilation time: 02:45:44" ? "Compileur version: 8.3.0" ? "XML version: 2.9.4" ? "Compiler Architecture: X64" compiled using gcc version 8, openjdk-8, jogl2 2.3.2 with the patch from changes 17530.? Thanks in advance.? Regards, Chin Luh -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Fri Mar 13 11:18:45 2020 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 13 Mar 2020 11:18:45 +0100 Subject: [Scilab-Dev] new logflags syntax of plot() in 6.1 Message-ID: <87170509-31bc-99ac-904e-46b7e71b0f4d@utc.fr> Hi, I don't approve this commit (https://codereview.scilab.org/#/c/20879/8) which was merged just before the release (I didn't even have the time to give it a -1). It represents a complete breakdown with the spirit of "plot", whose help page says "plot has been rebuild to better handle Matlab syntax. To improve graphical compatibility, Matlab users should use plot (rather than plot2d)". Until now, the behavior of plot was customized by means of "propertyName/value" pairs given after the (x,y) pairs. With this new logflags syntax, we have an optionnal first argument of "value" type without its "propertyName", moreover this is a "value" of an Axes property. At worse, but it would not have been more coherent, the expected feature could have been implemented as a pair "log_flags",string among other "propertyName/value". plot() had the merit of being more user friendly that plot2d(). With this commit, it started its convergence towards plot2d(), which is not a reference of user friendliness. One implicit rule is: when we introduce functions with Matlab's functions names and trying to emulate some of its features, then the Scilab function has to respect the subset of the Matlab API it implements and not mix with custom Scilab syntax. There are plenty of such functions in Scilab and this is a pity. We have implemented plot(), mesh(), surf(), light() and instead of breaking plot() to allow logarithmic plots it would have been simpler to emulate the corresponding functions in Matlab, namely, semilogx(), semilogy(), loglog(). So I hope that this commit will be quickly reverted in favor of https://codereview.scilab.org/#/c/21436/, in order to prevent bad habits of average users who could start using the logflags syntax. S. -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet From chinluh.tan at bytecode-asia.com Mon Mar 16 17:01:53 2020 From: chinluh.tan at bytecode-asia.com (Chin Luh Tan) Date: Tue, 17 Mar 2020 00:01:53 +0800 Subject: [Scilab-Dev] Scilab 6.1 in Raspberry Pi In-Reply-To: <170b3afb486.1233dd2ce539756.7154408045681835357@bytecode-asia.com> References: <170b3afb486.1233dd2ce539756.7154408045681835357@bytecode-asia.com> Message-ID: <170e4147f33.ececf427317615.7304837097223851573@bytecode-asia.com> the proposed solution at : https://codereview.scilab.org/#/c/21440/ thanks. rgds, Chin Luh ---- On Sat, 07 Mar 2020 14:30:01 +0800 Chin Luh Tan wrote ---- Hi Scilab developers,? Ever since Raspberry Pi 4 released with extra RAM of 2G and 4G version, Scilab could be run quite smoothly under Ubuntu Server RaspPi version. (In fact, the speed is quite acceptable even in Raspberry Pi 3). Even it is still having some bugs, the binary provided by the Ubuntu repository could just run after apt-get in Raspberry Pi. (Scilab 6.01 / 6.02 under current LTS 18.04 and 19.10 respectively).? Since the release of Scilab 6.1 is quite new, it is only available in unstable release, or we need to recompile from scratch (no-gui). However, even the scilab-cli could launch with both method, I encounter the following crash whenever Scilab 6.1 (scilab-cli) start to echo character '0' on the screen ________________________ ubuntu at ubuntu:~/scilab_master/scilab/bin$ ./scilab-cli Scilab branch-master (Mar? 7 2020, 02:45:45) --> a = 1; --> b = 0; --> a a? = ?? 1. --> b b? = terminate called after throwing an instance of 'std::length_error' ? what():? basic_string::_M_replace_aux A fatal error has been detected by Scilab. Please check your user-defined functions (or external module ones) should they appear in the stack trace. Otherwise you can report a bug on?http://bugzilla.scilab.org/?with: * a sample code which reproduces the issue * the result of [a, b] = getdebuginfo() * the following information: [ubuntu:24308] Signal: Aborted (6) [ubuntu:24308] Signal code:? (-6) Call stack: ?? 1: 0x324d8? ????????????????????????? (/lib/aarch64-linux-gnu/libc.so.6) End of stack _________________________________ Anyone has any idea on what likely causing the problem? More details: -->? [a, b] = getdebuginfo() a? = ? "Total memory:??? 1892552" ? "Used memory:??? 1137908" ? "Free memory:???? 754644" ? "Shared memory:????????? 0" ? "Buffers memory:????? 53452" ? "Cached memory:???? 813852" ? "Used -/+ buffers/cache:???? 270604" ? "Free -/+ buffers/cache:??? 1621948" ? "Total swap:????????? 0" ? "Used swap:????????? 0" ? "Free swap:????????? 0" ? "SCI: /home/ubuntu/scilab_master/scilab" ? "SCIHOME: /home/ubuntu/.Scilab/scilab-branch-master" ? "TMPDIR: /tmp/SCI_TMP_24419_wVkgKB" b? = ? "Scilab Version: scilab-branch-master" ? "Compilation date: Mar? 7 2020" ? "Compilation time: 02:45:44" ? "Compileur version: 8.3.0" ? "XML version: 2.9.4" ? "Compiler Architecture: X64" compiled using gcc version 8, openjdk-8, jogl2 2.3.2 with the patch from changes 17530.? Thanks in advance.? Regards, Chin Luh _______________________________________________ dev mailing list dev at lists.scilab.org http://lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: