From Clement.David at esi-group.com Fri Jun 1 10:05:28 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Fri, 1 Jun 2018 08:05:28 +0000 Subject: [Scilab-Dev] Scilab and Jupyter In-Reply-To: References: Message-ID: Hello St?phane, The result of the project is available on github [1] but it have not been merged yet [2] as it need to have some cleanup for integration (especially in term of dependencies). This is not related at all to Scilab Cloud which allow the user to deploy graphical applications (with plots, uicontrols and computation on the server side). However if you like the idea if having a complete Scilab Jupyter kernel shipped with Scilab, I can help you having so. [1]: https://github.com/Bitiquinho/Scilab-Jupyter-Kernel [2]: https://codereview.scilab.org/18489 -- Cl?ment Le jeudi 31 mai 2018 ? 15:18 +0200, St?phane Mottelet a ?crit : > Hello, > > Does somebody know if this work > > https://summerofcode.withgoogle.com/archive/2016/projects/6165785793789952/ > > led to subsequent developments into scilab ? > > E.g. does it have something in common with https://scilab.io/cloud/ ? > > S. > From stephane.mottelet at utc.fr Fri Jun 1 10:34:28 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 1 Jun 2018 10:34:28 +0200 Subject: [Scilab-Dev] Scilab and Jupyter In-Reply-To: References: Message-ID: <79593bef-e3a0-f024-ae14-3c5a2e5baf8c@utc.fr> Hello Cl?ment, Le 01/06/2018 ? 10:05, Cl?ment David a ?crit?: > Hello St?phane, > > The result of the project is available on github [1] but it have not been merged yet [2] as it need > to have some cleanup for integration (especially in term of dependencies). This is not related at > all to Scilab Cloud which allow the user to deploy graphical applications (with plots, uicontrols > and computation on the server side). > > However if you like the idea if having a complete Scilab Jupyter kernel shipped with Scilab, I can > help you having so. > > [1]: https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/github.com/Bitiquinho/Scilab-Jupyter-Kernel > [2]: https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/codereview.scilab.org/18489 OK. At first I will try to understand the technical details... S. > > -- > Cl?ment > > Le jeudi 31 mai 2018 ? 15:18 +0200, St?phane Mottelet a ?crit : >> Hello, >> >> Does somebody know if this work >> >> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/summerofcode.withgoogle.com/archive/2016/projects/6165785793789952/ >> >> led to subsequent developments into scilab ? >> >> E.g. does it have something in common with https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/scilab.io/cloud/ ? >> >> S. >> > _______________________________________________ > dev mailing list > dev at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet From Clement.David at esi-group.com Fri Jun 1 10:39:55 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Fri, 1 Jun 2018 08:39:55 +0000 Subject: [Scilab-Dev] 1 boolean = 4 bytes => 1 byte ? In-Reply-To: <8ec9ec2d-c08a-ba30-0b6d-303a06d298de@free.fr> References: <0b3c5aec-d0ce-521b-4061-150e93ab57ff@free.fr> <1526980369.2237.20.camel@esi-group.com> <8ec9ec2d-c08a-ba30-0b6d-303a06d298de@free.fr> Message-ID: Hello Samuel, > > After some diving into the ast/types source code and debugging session I got some information : > > > > --> disp(%t) > > // gdb resolved the value as a > where m_iSize = 1 > > // (the size of the inner m_pRealData) > > --> disp([%t %f %t %f]) > > // gdb resolved the value as a > where m_iSize = 4 > > // (the size of the inner m_pRealData) > > > > So in Scilab 6, there is 4 byte per boolean; to me a first thing to do before changing the > > current > > implementation is to let `who()` return both the memory used (including the Scilab header) and > > the > > memory used by the inner data storage. > > > > Note: as discussed in this ML, the overhead per for Scilab datatype (not inner value) is 208 > > byte > > per value, to me it is more important to reduce it first as it will impact all ArrayOf based > > datatype. > > So, i understand that it is hard, or even impossible, or useless, to assess the > impact of a change in term of back-compatibility wrt existing datafiles. > > I understand also that the Scilab devs team has finally decided -- at least as a first step -- > to retrieve the former who() behavior to get the memory, so including the Scilab header. > To me, it would be anyway better to drop the "word" unit (set of 8 bytes) and to > return the memory preferably in bytes. Beyond the recovery of [x,mem]=who(..), > this would already be an improvement. > > As far as i understand it -- what's not sure --, i am not convinced by the last point, in terms of > priority. > The main concern of the initial report is the better usage of the memory, > noticeably when doing operations on big arrays with big intermediate boolean arrays. > Some operations may fail because of insufficient intermediate memory. > Now, even if 1000 variables are simultaneously defined in the workspace > -- this never happens, but let's assume it is so --, > and that each one takes 208 bytes (really per value ?? i assume it is rather per container. Is it > right?), > then this uses 208 kbytes, what's nothing. > Now, if a single boolean array is defined and used to process a whole 1000x1000x4 RGBA image, > it uses alone 16 MB instead of 4MB, that's >>> 208 kbytes. > Avoiding to waste these 12 MB was the main aim of my initial report. > > Please correct me if my calculations are wrong, with respect to this aim. Your calculations are correct and I fully agree with you : wasting 4byte per boolean value might be an issue for some computation. To clarify, the idea behind reducing the ArrayOf<> size is to follow PHP internal value optimization [1] to improve performance on allocation (basically using less memory means having more Scilab values stored on fast smallbins allocated memory area). [1]: https://nikic.github.io/2015/05/05/Internal-value-representation-in-PHP-7-part-1.html -- Cl?ment From sgougeon at free.fr Thu Jun 21 20:34:52 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 21 Jun 2018 20:34:52 +0200 Subject: [Scilab-Dev] message id changed in the code => needs to update .pot and .mo? Message-ID: <44c24862-348d-cc95-381f-1488efaaeb7b@free.fr> Hello, A general question about localization: let's assume that a localized message id is changed in the source tree. Does compiling Scilab automatically regenerate the .pot and .mo files with the new msgid, or is it necessary to do it by hand (so noticeably for all existing .mo files)? Thanks Samuel From stephane.mottelet at utc.fr Fri Jun 22 10:28:34 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 22 Jun 2018 10:28:34 +0200 Subject: [Scilab-Dev] legacy 5.x syntax deserves to be abandonned Message-ID: <1026695b-3657-3c2c-5d13-4c7c0d206c9a@utc.fr> Hello, While fixing http://bugzilla.scilab.org/show_bug.cgi?id=15623 http://bugzilla.scilab.org/show_bug.cgi?id=15624 I discovered that gross syntax errors such as max(,), max(1,) mean(,)... are not trapped by the parser. As a consequence, tokens of type internalType:ScilabVoid are given to the gateway in the input arguments. There are a lot of scilab functions which do not correctly handle this. For example, max(1,) and atan(1,) crash Scilab max(,), gives a message about a missing overloading function for ScilabVoid type. Why such an dumb syntax has been kept as valid in Scilab 6 ? Does even somebody remember if there exist some legacy code needing this ? There is a potentially huge number of gateways to be fixed because of this too permissive syntax. However, all problems can be fixed by yanking lines 661:666 in parseScilab.yy (666: Number of the Beast). S. -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet From stephane.mottelet at utc.fr Fri Jun 22 10:32:39 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 22 Jun 2018 10:32:39 +0200 Subject: [Scilab-Dev] legacy 5.x syntax deserves to be abandonned In-Reply-To: <1026695b-3657-3c2c-5d13-4c7c0d206c9a@utc.fr> References: <1026695b-3657-3c2c-5d13-4c7c0d206c9a@utc.fr> Message-ID: <62b7b220-9882-be59-d7db-180d4b3bc8f2@utc.fr> Le 22/06/2018 ? 10:28, St?phane Mottelet a ?crit?: > Hello, > > While fixing > > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=15623 > > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=15624 > > > I discovered that gross syntax errors such as > > max(,), max(1,) mean(,)... > > are not trapped by the parser. As a consequence, tokens of type > internalType:ScilabVoid are given to the gateway in the input arguments. > > There are a lot of scilab functions which do not correctly handle > this. For example, > > max(1,) and atan(1,) crash Scilab > > max(,), gives a message about a missing overloading function for > ScilabVoid type. > > Why such an dumb syntax has been kept as valid in Scilab 6 ? Does even > somebody remember if there exist some legacy code needing this ? > > There is a potentially huge number of gateways to be fixed because of > this too permissive syntax. > > However, all problems can be fixed by yanking lines 661:666 in > parseScilab.yy (666: Number of the Beast). > > S. > Here are the error messages after the fix in parseScilab.yy: --> max(,) max(,) ???? ^ Error: syntax error, unexpected "," --> max(1,) max(1,) ????? ^^ Error: syntax error, unexpected ) S. -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet From stephane.mottelet at utc.fr Fri Jun 22 13:02:09 2018 From: stephane.mottelet at utc.fr (stephane.mottelet at utc.fr) Date: Fri, 22 Jun 2018 13:02:09 +0200 Subject: [Scilab-Dev] legacy 5.x syntax deserves to be abandonned In-Reply-To: <1026695b-3657-3c2c-5d13-4c7c0d206c9a@utc.fr> Message-ID: <20180622130209.Horde.7S2525al40D_F0W80fF30x3@webmail.utc.fr> The following (fixed) bug http://bugzilla.scilab.org/10279 shows that such a syntax was considered as an error, but only for user-defined functions. (it has not been fixed at the parser level). I don't see any reason why the syntax should be accepted for built-in functions. S. Quoting St?phane Mottelet : > Hello, > > While fixing > > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=15623 > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=15624 > > I discovered that gross syntax errors such as > > max(,), max(1,) mean(,)... > > are not trapped by the parser. As a consequence, tokens of type > internalType:ScilabVoid are given to the gateway in the input > arguments. > > There are a lot of scilab functions which do not correctly handle > this. For example, > > max(1,) and atan(1,) crash Scilab > > max(,), gives a message about a missing overloading function for > ScilabVoid type. > > Why such an dumb syntax has been kept as valid in Scilab 6 ? Does > even somebody remember if there exist some legacy code needing this ? > > There is a potentially huge number of gateways to be fixed because > of this too permissive syntax. > > However, all problems can be fixed by yanking lines 661:666 in > parseScilab.yy (666: Number of the Beast). > > 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 > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.utc.fr/~mottelet > > _______________________________________________ > dev mailing list > dev at lists.scilab.orghttps://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: