From stephane.mottelet at utc.fr Wed Apr 3 15:04:03 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Wed, 3 Apr 2019 15:04:03 +0200 Subject: [Scilab-Dev] conda recipe for scilab In-Reply-To: References: <1553858324088-0.post@n3.nabble.com> <636ce807-af6d-a417-f2db-aa42b3ecbe58@utc.fr> <559d08f1-5ed1-581c-b295-175b35fb5341@utc.fr> <92ce38fc-a6e2-8204-2219-55b825ecbea3@utc.fr> <13bef891-fce4-a326-0e85-f4b1ad4316e9@utc.fr> Message-ID: <3c786178-cbbd-ca9f-9e2f-3ce5c4c7eca1@utc.fr> Can you give me the link to your latest build log ? In your 29 march build logs, Do not use TCL/TK (--without-tk) ................. = no TCL include (--with-tcl-include) ................. = TCL library (--with-tcl-library) ................. = TK include (--with-tk-include) ................... = TK library (--with-tk-library) ................... = Install XML Help (--with-install-help-xml) ....... = Compilation tests (--enable-compilation-tests) ... = no Make the package relocatable (--enable-relocatable)= no Use FFTW (--without-fftw) ........................ = Use MATIO (--without-matio) ...................... = no Compile with Scilab thirdparties ................. = false Not using Xcos because of the option --without-gui Not using code coverage I see that coverage module is not configured, although you didn't explicitely gave --enable-coverage=no in configure options. I have no idea why this is desactivated for you (here I build under High Sierra although you are building under Mavericks, maybe this matters ?) 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Wed Apr 3 15:17:44 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Wed, 3 Apr 2019 15:17:44 +0200 Subject: [Scilab-Dev] conda recipe for scilab In-Reply-To: <3c786178-cbbd-ca9f-9e2f-3ce5c4c7eca1@utc.fr> References: <1553858324088-0.post@n3.nabble.com> <636ce807-af6d-a417-f2db-aa42b3ecbe58@utc.fr> <559d08f1-5ed1-581c-b295-175b35fb5341@utc.fr> <92ce38fc-a6e2-8204-2219-55b825ecbea3@utc.fr> <13bef891-fce4-a326-0e85-f4b1ad4316e9@utc.fr> <3c786178-cbbd-ca9f-9e2f-3ce5c4c7eca1@utc.fr> Message-ID: As a potential quick and dirty fix, I would recommend to build with --enable-coverage=no Le 03/04/2019 ? 15:04, St?phane Mottelet a ?crit?: > Can you give me the link to your latest build log ? In your 29 march > build logs, > > Do not use TCL/TK (--without-tk) ................. = no > TCL include (--with-tcl-include) ................. = > TCL library (--with-tcl-library) ................. = > TK include (--with-tk-include) ................... = > TK library (--with-tk-library) ................... = > Install XML Help (--with-install-help-xml) ....... = > Compilation tests (--enable-compilation-tests) ... = no > Make the package relocatable (--enable-relocatable)= no > Use FFTW (--without-fftw) ........................ = > Use MATIO (--without-matio) ...................... = no > Compile with Scilab thirdparties ................. = false > Not using Xcos because of the option --without-gui > Not using code coverage > > I see that coverage module is not configured, although you didn't > explicitely gave > > --enable-coverage=no > > in configure options. I have no idea why this is desactivated for you > (here I build under High Sierra although you are building under > Mavericks, maybe this matters ?) > > 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 > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.corlay at gmail.com Wed Apr 3 15:40:24 2019 From: sylvain.corlay at gmail.com (Sylvain Corlay) Date: Wed, 3 Apr 2019 15:40:24 +0200 Subject: [Scilab-Dev] conda recipe for scilab In-Reply-To: References: <1553858324088-0.post@n3.nabble.com> <636ce807-af6d-a417-f2db-aa42b3ecbe58@utc.fr> <559d08f1-5ed1-581c-b295-175b35fb5341@utc.fr> <92ce38fc-a6e2-8204-2219-55b825ecbea3@utc.fr> <13bef891-fce4-a326-0e85-f4b1ad4316e9@utc.fr> <3c786178-cbbd-ca9f-9e2f-3ce5c4c7eca1@utc.fr> Message-ID: Thanks St?phane, Regarding your earlier question, the log for the build is available here: https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=25973&view=logs&jobId=ce7cbaa7-582c-5570-40f4-267b3d85fc9f I will post a separate message on the list summarizing all the issues that we encountered while putting together the conda recipe for scilab. Several of them appear to be legitimate bugs. Sylvain On Wed, Apr 3, 2019 at 3:17 PM St?phane Mottelet wrote: > As a potential quick and dirty fix, I would recommend to build with > --enable-coverage=no > > Le 03/04/2019 ? 15:04, St?phane Mottelet a ?crit : > > Can you give me the link to your latest build log ? In your 29 march build > logs, > > Do not use TCL/TK (--without-tk) ................. = no > TCL include (--with-tcl-include) ................. = > TCL library (--with-tcl-library) ................. = > TK include (--with-tk-include) ................... = > TK library (--with-tk-library) ................... = > Install XML Help (--with-install-help-xml) ....... = > Compilation tests (--enable-compilation-tests) ... = no > Make the package relocatable (--enable-relocatable)= no > Use FFTW (--without-fftw) ........................ = > Use MATIO (--without-matio) ...................... = no > Compile with Scilab thirdparties ................. = false > Not using Xcos because of the option --without-gui > Not using code coverage > > I see that coverage module is not configured, although you didn't > explicitely gave > > --enable-coverage=no > > in configure options. I have no idea why this is desactivated for you > (here I build under High Sierra although you are building under Mavericks, > maybe this matters ?) > > 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)344234688http://www.utc.fr/~mottelet > > > _______________________________________________ > dev mailing listdev at lists.scilab.orghttps://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)344234688http://www.utc.fr/~mottelet > > _______________________________________________ > 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 Apr 5 14:22:25 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 5 Apr 2019 14:22:25 +0200 Subject: [Scilab-Dev] conda recipe for scilab In-Reply-To: References: <1553858324088-0.post@n3.nabble.com> <92ce38fc-a6e2-8204-2219-55b825ecbea3@utc.fr> <13bef891-fce4-a326-0e85-f4b1ad4316e9@utc.fr> <3c786178-cbbd-ca9f-9e2f-3ce5c4c7eca1@utc.fr> Message-ID: Le 03/04/2019 ? 15:40, Sylvain Corlay a ?crit?: > Thanks St?phane, > > Regarding your earlier question, the log for the build is available here: > > https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=25973&view=logs&jobId=ce7cbaa7-582c-5570-40f4-267b3d85fc9f > > > I will post a separate message on the list summarizing all the issues > that we encountered while putting together the conda recipe for > scilab. Several of them appear to be legitimate bugs. OK. However, was your last build sucessful with --enable-coverage=no ? > > Sylvain > > On Wed, Apr 3, 2019 at 3:17 PM St?phane Mottelet > > wrote: > > As a potential quick and dirty fix, I would recommend to build > with --enable-coverage=no > > Le 03/04/2019 ? 15:04, St?phane Mottelet a ?crit?: >> Can you give me the link to your latest build log ? In your 29 >> march build logs, >> >> Do not use TCL/TK (--without-tk) ................. = no >> TCL include (--with-tcl-include) ................. = >> TCL library (--with-tcl-library) ................. = >> TK include (--with-tk-include) ................... = >> TK library (--with-tk-library) ................... = >> Install XML Help (--with-install-help-xml) ....... = >> Compilation tests (--enable-compilation-tests) ... = no >> Make the package relocatable (--enable-relocatable)= no >> Use FFTW (--without-fftw) ........................ = >> Use MATIO (--without-matio) ...................... = no >> Compile with Scilab thirdparties ................. = false >> Not using Xcos because of the option --without-gui >> Not using code coverage >> >> I see that coverage module is not configured, although you didn't >> explicitely gave >> >> --enable-coverage=no >> >> in configure options. I have no idea why this is desactivated for >> you (here I build under High Sierra although you are building >> under Mavericks, maybe this matters ?) >> >> 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 >> >> _______________________________________________ >> 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 > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev > > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.corlay at gmail.com Fri Apr 5 18:13:44 2019 From: sylvain.corlay at gmail.com (Sylvain Corlay) Date: Fri, 5 Apr 2019 18:13:44 +0200 Subject: [Scilab-Dev] conda recipe for scilab In-Reply-To: References: <1553858324088-0.post@n3.nabble.com> <92ce38fc-a6e2-8204-2219-55b825ecbea3@utc.fr> <13bef891-fce4-a326-0e85-f4b1ad4316e9@utc.fr> <3c786178-cbbd-ca9f-9e2f-3ce5c4c7eca1@utc.fr> Message-ID: Hi, sorry for the late reply. It does not fix the issue. The option appears to not be recognized: configure: WARNING: unrecognized options: --enable-coverage Best, Sylvain On Fri, Apr 5, 2019 at 2:22 PM St?phane Mottelet wrote: > Le 03/04/2019 ? 15:40, Sylvain Corlay a ?crit : > > Thanks St?phane, > > Regarding your earlier question, the log for the build is available here: > > > https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=25973&view=logs&jobId=ce7cbaa7-582c-5570-40f4-267b3d85fc9f > > > I will post a separate message on the list summarizing all the issues that > we encountered while putting together the conda recipe for scilab. Several > of them appear to be legitimate bugs. > > OK. However, was your last build sucessful with --enable-coverage=no ? > > > Sylvain > > On Wed, Apr 3, 2019 at 3:17 PM St?phane Mottelet > wrote: > >> As a potential quick and dirty fix, I would recommend to build with >> --enable-coverage=no >> >> Le 03/04/2019 ? 15:04, St?phane Mottelet a ?crit : >> >> Can you give me the link to your latest build log ? In your 29 march >> build logs, >> >> Do not use TCL/TK (--without-tk) ................. = no >> TCL include (--with-tcl-include) ................. = >> TCL library (--with-tcl-library) ................. = >> TK include (--with-tk-include) ................... = >> TK library (--with-tk-library) ................... = >> Install XML Help (--with-install-help-xml) ....... = >> Compilation tests (--enable-compilation-tests) ... = no >> Make the package relocatable (--enable-relocatable)= no >> Use FFTW (--without-fftw) ........................ = >> Use MATIO (--without-matio) ...................... = no >> Compile with Scilab thirdparties ................. = false >> Not using Xcos because of the option --without-gui >> Not using code coverage >> >> I see that coverage module is not configured, although you didn't >> explicitely gave >> >> --enable-coverage=no >> >> in configure options. I have no idea why this is desactivated for you >> (here I build under High Sierra although you are building under Mavericks, >> maybe this matters ?) >> >> 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)344234688http://www.utc.fr/~mottelet >> >> >> _______________________________________________ >> dev mailing listdev at lists.scilab.orghttps://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)344234688http://www.utc.fr/~mottelet >> >> _______________________________________________ >> dev mailing list >> dev at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/dev >> >> > > _______________________________________________ > dev mailing listdev at lists.scilab.orghttps://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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 stephane.mottelet at utc.fr Fri Apr 5 18:17:43 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 5 Apr 2019 18:17:43 +0200 Subject: [Scilab-Dev] conda recipe for scilab In-Reply-To: References: <1553858324088-0.post@n3.nabble.com> <92ce38fc-a6e2-8204-2219-55b825ecbea3@utc.fr> <13bef891-fce4-a326-0e85-f4b1ad4316e9@utc.fr> <3c786178-cbbd-ca9f-9e2f-3ce5c4c7eca1@utc.fr> Message-ID: <583cf793-e610-dc0b-965e-685eb277e121@utc.fr> sorry its ?--enable-code-coverage (./configure --help) S. Le 05/04/2019 ? 18:13, Sylvain Corlay a ?crit?: > Hi, sorry for the late reply. > > It does not fix the issue. The option appears to not be recognized: > configure: WARNING: unrecognized options: --enable-coverage > Best, > > Sylvain > > On Fri, Apr 5, 2019 at 2:22 PM St?phane Mottelet > > wrote: > > Le 03/04/2019 ? 15:40, Sylvain Corlay a ?crit?: > >> Thanks St?phane, >> >> Regarding your earlier question, the log for the build is >> available here: >> >> https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=25973&view=logs&jobId=ce7cbaa7-582c-5570-40f4-267b3d85fc9f >> >> >> I will post a separate message on the list summarizing all the >> issues that we encountered while putting together the conda >> recipe for scilab. Several of them appear to be legitimate bugs. > > OK. However, was your last build sucessful with --enable-coverage=no ? > >> >> Sylvain >> >> On Wed, Apr 3, 2019 at 3:17 PM St?phane Mottelet >> > wrote: >> >> As a potential quick and dirty fix, I would recommend to >> build with --enable-coverage=no >> >> Le 03/04/2019 ? 15:04, St?phane Mottelet a ?crit?: >>> Can you give me the link to your latest build log ? In your >>> 29 march build logs, >>> >>> Do not use TCL/TK (--without-tk) ................. = no >>> TCL include (--with-tcl-include) ................. = >>> TCL library (--with-tcl-library) ................. = >>> TK include (--with-tk-include) ................... = >>> TK library (--with-tk-library) ................... = >>> Install XML Help (--with-install-help-xml) ....... = >>> Compilation tests (--enable-compilation-tests) ... = no >>> Make the package relocatable (--enable-relocatable)= no >>> Use FFTW (--without-fftw) ........................ = >>> Use MATIO (--without-matio) ...................... = no >>> Compile with Scilab thirdparties ................. = false >>> Not using Xcos because of the option --without-gui >>> Not using code coverage >>> >>> I see that coverage module is not configured, although you >>> didn't explicitely gave >>> >>> --enable-coverage=no >>> >>> in configure options. I have no idea why this is >>> desactivated for you (here I build under High Sierra >>> although you are building under Mavericks, maybe this matters ?) >>> >>> 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 >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> dev mailing list >> dev at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/dev >> >> >> >> _______________________________________________ >> dev mailing list >> dev at lists.scilab.org >> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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 > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.corlay at gmail.com Fri Apr 5 19:47:24 2019 From: sylvain.corlay at gmail.com (Sylvain Corlay) Date: Fri, 5 Apr 2019 19:47:24 +0200 Subject: [Scilab-Dev] conda recipe for scilab In-Reply-To: <583cf793-e610-dc0b-965e-685eb277e121@utc.fr> References: <1553858324088-0.post@n3.nabble.com> <92ce38fc-a6e2-8204-2219-55b825ecbea3@utc.fr> <13bef891-fce4-a326-0e85-f4b1ad4316e9@utc.fr> <3c786178-cbbd-ca9f-9e2f-3ce5c4c7eca1@utc.fr> <583cf793-e610-dc0b-965e-685eb277e121@utc.fr> Message-ID: Thanks! this configure option is recognized but launching scilab fails over the same missing symbol error. S. On Fri, Apr 5, 2019 at 6:17 PM St?phane Mottelet wrote: > sorry its > > --enable-code-coverage > > (./configure --help) > > S. > Le 05/04/2019 ? 18:13, Sylvain Corlay a ?crit : > > Hi, sorry for the late reply. > > It does not fix the issue. The option appears to not be recognized: > configure: WARNING: unrecognized options: --enable-coverage > Best, > > Sylvain > > On Fri, Apr 5, 2019 at 2:22 PM St?phane Mottelet > wrote: > >> Le 03/04/2019 ? 15:40, Sylvain Corlay a ?crit : >> >> Thanks St?phane, >> >> Regarding your earlier question, the log for the build is available here: >> >> >> https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=25973&view=logs&jobId=ce7cbaa7-582c-5570-40f4-267b3d85fc9f >> >> >> I will post a separate message on the list summarizing all the issues >> that we encountered while putting together the conda recipe for scilab. >> Several of them appear to be legitimate bugs. >> >> OK. However, was your last build sucessful with --enable-coverage=no ? >> >> >> Sylvain >> >> On Wed, Apr 3, 2019 at 3:17 PM St?phane Mottelet < >> stephane.mottelet at utc.fr> wrote: >> >>> As a potential quick and dirty fix, I would recommend to build with >>> --enable-coverage=no >>> >>> Le 03/04/2019 ? 15:04, St?phane Mottelet a ?crit : >>> >>> Can you give me the link to your latest build log ? In your 29 march >>> build logs, >>> >>> Do not use TCL/TK (--without-tk) ................. = no >>> TCL include (--with-tcl-include) ................. = >>> TCL library (--with-tcl-library) ................. = >>> TK include (--with-tk-include) ................... = >>> TK library (--with-tk-library) ................... = >>> Install XML Help (--with-install-help-xml) ....... = >>> Compilation tests (--enable-compilation-tests) ... = no >>> Make the package relocatable (--enable-relocatable)= no >>> Use FFTW (--without-fftw) ........................ = >>> Use MATIO (--without-matio) ...................... = no >>> Compile with Scilab thirdparties ................. = false >>> Not using Xcos because of the option --without-gui >>> Not using code coverage >>> >>> I see that coverage module is not configured, although you didn't >>> explicitely gave >>> >>> --enable-coverage=no >>> >>> in configure options. I have no idea why this is desactivated for you >>> (here I build under High Sierra although you are building under Mavericks, >>> maybe this matters ?) >>> >>> 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)344234688http://www.utc.fr/~mottelet >>> >>> >>> _______________________________________________ >>> dev mailing listdev at lists.scilab.orghttps://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)344234688http://www.utc.fr/~mottelet >>> >>> _______________________________________________ >>> dev mailing list >>> dev at lists.scilab.org >>> http://lists.scilab.org/mailman/listinfo/dev >>> >>> >> >> _______________________________________________ >> dev mailing listdev at lists.scilab.orghttps://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev >> >> _______________________________________________ >> dev mailing list >> dev at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/dev >> >> > > _______________________________________________ > dev mailing listdev at lists.scilab.orghttps://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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 stephane.mottelet at utc.fr Fri Apr 5 20:08:22 2019 From: stephane.mottelet at utc.fr (=?utf-8?Q?St=C3=A9phane_Mottelet?=) Date: Fri, 5 Apr 2019 20:08:22 +0200 Subject: [Scilab-Dev] conda recipe for scilab In-Reply-To: References: <1553858324088-0.post@n3.nabble.com> <92ce38fc-a6e2-8204-2219-55b825ecbea3@utc.fr> <13bef891-fce4-a326-0e85-f4b1ad4316e9@utc.fr> <3c786178-cbbd-ca9f-9e2f-3ce5c4c7eca1@utc.fr> <583cf 793-e610-dc0b-965e-685eb277e121@utc.fr> Message-ID: I mean enable-code-coverage=no > Le 5 avr. 2019 ? 19:47, Sylvain Corlay a ?crit : > > Thanks! this configure option is recognized but launching scilab fails over the same missing symbol error. > > S. > >> On Fri, Apr 5, 2019 at 6:17 PM St?phane Mottelet wrote: >> sorry its >> >> --enable-code-coverage >> >> (./configure --help) >> >> S. >>> Le 05/04/2019 ? 18:13, Sylvain Corlay a ?crit : >>> Hi, sorry for the late reply. >>> >>> It does not fix the issue. The option appears to not be recognized: >>> >>> configure: WARNING: unrecognized options: --enable-coverage >>> >>> Best, >>> >>> Sylvain >>> >>>> On Fri, Apr 5, 2019 at 2:22 PM St?phane Mottelet wrote: >>>>> Le 03/04/2019 ? 15:40, Sylvain Corlay a ?crit : >>>>> Thanks St?phane, >>>>> >>>>> Regarding your earlier question, the log for the build is available here: >>>>> >>>>> https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=25973&view=logs&jobId=ce7cbaa7-582c-5570-40f4-267b3d85fc9f >>>>> >>>>> I will post a separate message on the list summarizing all the issues that we encountered while putting together the conda recipe for scilab. Several of them appear to be legitimate bugs. >>>> OK. However, was your last build sucessful with --enable-coverage=no ? >>>>> >>>>> Sylvain >>>>> >>>>>> On Wed, Apr 3, 2019 at 3:17 PM St?phane Mottelet wrote: >>>>>> As a potential quick and dirty fix, I would recommend to build with --enable-coverage=no >>>>>> >>>>>>> Le 03/04/2019 ? 15:04, St?phane Mottelet a ?crit : >>>>>>> Can you give me the link to your latest build log ? In your 29 march build logs, >>>>>>> >>>>>>> Do not use TCL/TK (--without-tk) ................. = no >>>>>>> TCL include (--with-tcl-include) ................. = >>>>>>> TCL library (--with-tcl-library) ................. = >>>>>>> TK include (--with-tk-include) ................... = >>>>>>> TK library (--with-tk-library) ................... = >>>>>>> Install XML Help (--with-install-help-xml) ....... = >>>>>>> Compilation tests (--enable-compilation-tests) ... = no >>>>>>> Make the package relocatable (--enable-relocatable)= no >>>>>>> Use FFTW (--without-fftw) ........................ = >>>>>>> Use MATIO (--without-matio) ...................... = no >>>>>>> >>>>>>> Compile with Scilab thirdparties ................. = false >>>>>>> >>>>>>> Not using Xcos because of the option --without-gui >>>>>>> >>>>>>> Not using code coverage >>>>>>> >>>>>>> I see that coverage module is not configured, although you didn't explicitely gave >>>>>>> >>>>>>> --enable-coverage=no >>>>>>> >>>>>>> in configure options. I have no idea why this is desactivated for you (here I build under High Sierra although you are building under Mavericks, maybe this matters ?) >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> _______________________________________________ >>>>>> dev mailing list >>>>>> dev at lists.scilab.org >>>>>> http://lists.scilab.org/mailman/listinfo/dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> dev mailing list >>>>> dev at lists.scilab.org >>>>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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 >>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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 > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.corlay at gmail.com Fri Apr 5 20:10:22 2019 From: sylvain.corlay at gmail.com (Sylvain Corlay) Date: Fri, 5 Apr 2019 20:10:22 +0200 Subject: [Scilab-Dev] conda recipe for scilab In-Reply-To: References: <1553858324088-0.post@n3.nabble.com> <92ce38fc-a6e2-8204-2219-55b825ecbea3@utc.fr> <13bef891-fce4-a326-0e85-f4b1ad4316e9@utc.fr> <3c786178-cbbd-ca9f-9e2f-3ce5c4c7eca1@utc.fr> Message-ID: Yes, naturally! This is what I did. Sylvain On Fri, Apr 5, 2019 at 8:08 PM St?phane Mottelet wrote: > I mean enable-code-coverage=no > > Le 5 avr. 2019 ? 19:47, Sylvain Corlay a > ?crit : > > Thanks! this configure option is recognized but launching scilab fails > over the same missing symbol error. > > S. > > On Fri, Apr 5, 2019 at 6:17 PM St?phane Mottelet > wrote: > >> sorry its >> >> --enable-code-coverage >> >> (./configure --help) >> >> S. >> Le 05/04/2019 ? 18:13, Sylvain Corlay a ?crit : >> >> Hi, sorry for the late reply. >> >> It does not fix the issue. The option appears to not be recognized: >> configure: WARNING: unrecognized options: --enable-coverage >> Best, >> >> Sylvain >> >> On Fri, Apr 5, 2019 at 2:22 PM St?phane Mottelet < >> stephane.mottelet at utc.fr> wrote: >> >>> Le 03/04/2019 ? 15:40, Sylvain Corlay a ?crit : >>> >>> Thanks St?phane, >>> >>> Regarding your earlier question, the log for the build is available here: >>> >>> >>> https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=25973&view=logs&jobId=ce7cbaa7-582c-5570-40f4-267b3d85fc9f >>> >>> >>> I will post a separate message on the list summarizing all the issues >>> that we encountered while putting together the conda recipe for scilab. >>> Several of them appear to be legitimate bugs. >>> >>> OK. However, was your last build sucessful with --enable-coverage=no ? >>> >>> >>> Sylvain >>> >>> On Wed, Apr 3, 2019 at 3:17 PM St?phane Mottelet < >>> stephane.mottelet at utc.fr> wrote: >>> >>>> As a potential quick and dirty fix, I would recommend to build with >>>> --enable-coverage=no >>>> >>>> Le 03/04/2019 ? 15:04, St?phane Mottelet a ?crit : >>>> >>>> Can you give me the link to your latest build log ? In your 29 march >>>> build logs, >>>> >>>> Do not use TCL/TK (--without-tk) ................. = no >>>> TCL include (--with-tcl-include) ................. = >>>> TCL library (--with-tcl-library) ................. = >>>> TK include (--with-tk-include) ................... = >>>> TK library (--with-tk-library) ................... = >>>> Install XML Help (--with-install-help-xml) ....... = >>>> Compilation tests (--enable-compilation-tests) ... = no >>>> Make the package relocatable (--enable-relocatable)= no >>>> Use FFTW (--without-fftw) ........................ = >>>> Use MATIO (--without-matio) ...................... = no >>>> Compile with Scilab thirdparties ................. = false >>>> Not using Xcos because of the option --without-gui >>>> Not using code coverage >>>> >>>> I see that coverage module is not configured, although you didn't >>>> explicitely gave >>>> >>>> --enable-coverage=no >>>> >>>> in configure options. I have no idea why this is desactivated for you >>>> (here I build under High Sierra although you are building under Mavericks, >>>> maybe this matters ?) >>>> >>>> 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)344234688http://www.utc.fr/~mottelet >>>> >>>> >>>> _______________________________________________ >>>> dev mailing listdev at lists.scilab.orghttps://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)344234688http://www.utc.fr/~mottelet >>>> >>>> _______________________________________________ >>>> dev mailing list >>>> dev at lists.scilab.org >>>> http://lists.scilab.org/mailman/listinfo/dev >>>> >>>> >>> >>> _______________________________________________ >>> dev mailing listdev at lists.scilab.orghttps://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev >>> >>> _______________________________________________ >>> dev mailing list >>> dev at lists.scilab.org >>> http://lists.scilab.org/mailman/listinfo/dev >>> >>> >> >> _______________________________________________ >> dev mailing listdev at lists.scilab.orghttps://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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 > > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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 stephane.mottelet at utc.fr Fri Apr 5 20:14:24 2019 From: stephane.mottelet at utc.fr (=?utf-8?Q?St=C3=A9phane_Mottelet?=) Date: Fri, 5 Apr 2019 20:14:24 +0200 Subject: [Scilab-Dev] conda recipe for scilab In-Reply-To: References: <1553858324088-0.post@n3.nabble.com> <92ce38fc-a6e2-8204-2219-55b825ecbea3@utc.fr> <13bef891-fce4-a326-0e85-f4b1ad4316e9@utc.fr> <3c786178-cbbd-ca9f-9e2f-3ce5c4c7eca1@utc.fr> Message-ID: <69CF14CB-7EA7-4086-A44F-7AFE43CA436D@utc.fr> Ok. I don?t think I can help you further, maybe Antoine or Cl?ment could have an Idea ? S. > Le 5 avr. 2019 ? 20:10, Sylvain Corlay a ?crit : > > Yes, naturally! This is what I did. > > Sylvain > >> On Fri, Apr 5, 2019 at 8:08 PM St?phane Mottelet wrote: >> I mean enable-code-coverage=no >> >>> Le 5 avr. 2019 ? 19:47, Sylvain Corlay a ?crit : >>> >>> Thanks! this configure option is recognized but launching scilab fails over the same missing symbol error. >>> >>> S. >>> >>>> On Fri, Apr 5, 2019 at 6:17 PM St?phane Mottelet wrote: >>>> sorry its >>>> >>>> --enable-code-coverage >>>> >>>> (./configure --help) >>>> >>>> S. >>>>> Le 05/04/2019 ? 18:13, Sylvain Corlay a ?crit : >>>>> Hi, sorry for the late reply. >>>>> >>>>> It does not fix the issue. The option appears to not be recognized: >>>>> >>>>> configure: WARNING: unrecognized options: --enable-coverage >>>>> >>>>> Best, >>>>> >>>>> Sylvain >>>>> >>>>>> On Fri, Apr 5, 2019 at 2:22 PM St?phane Mottelet wrote: >>>>>>> Le 03/04/2019 ? 15:40, Sylvain Corlay a ?crit : >>>>>>> Thanks St?phane, >>>>>>> >>>>>>> Regarding your earlier question, the log for the build is available here: >>>>>>> >>>>>>> https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=25973&view=logs&jobId=ce7cbaa7-582c-5570-40f4-267b3d85fc9f >>>>>>> >>>>>>> I will post a separate message on the list summarizing all the issues that we encountered while putting together the conda recipe for scilab. Several of them appear to be legitimate bugs. >>>>>> OK. However, was your last build sucessful with --enable-coverage=no ? >>>>>>> >>>>>>> Sylvain >>>>>>> >>>>>>>> On Wed, Apr 3, 2019 at 3:17 PM St?phane Mottelet wrote: >>>>>>>> As a potential quick and dirty fix, I would recommend to build with --enable-coverage=no >>>>>>>> >>>>>>>>> Le 03/04/2019 ? 15:04, St?phane Mottelet a ?crit : >>>>>>>>> Can you give me the link to your latest build log ? In your 29 march build logs, >>>>>>>>> >>>>>>>>> Do not use TCL/TK (--without-tk) ................. = no >>>>>>>>> TCL include (--with-tcl-include) ................. = >>>>>>>>> TCL library (--with-tcl-library) ................. = >>>>>>>>> TK include (--with-tk-include) ................... = >>>>>>>>> TK library (--with-tk-library) ................... = >>>>>>>>> Install XML Help (--with-install-help-xml) ....... = >>>>>>>>> Compilation tests (--enable-compilation-tests) ... = no >>>>>>>>> Make the package relocatable (--enable-relocatable)= no >>>>>>>>> Use FFTW (--without-fftw) ........................ = >>>>>>>>> Use MATIO (--without-matio) ...................... = no >>>>>>>>> >>>>>>>>> Compile with Scilab thirdparties ................. = false >>>>>>>>> >>>>>>>>> Not using Xcos because of the option --without-gui >>>>>>>>> >>>>>>>>> Not using code coverage >>>>>>>>> >>>>>>>>> I see that coverage module is not configured, although you didn't explicitely gave >>>>>>>>> >>>>>>>>> --enable-coverage=no >>>>>>>>> >>>>>>>>> in configure options. I have no idea why this is desactivated for you (here I build under High Sierra although you are building under Mavericks, maybe this matters ?) >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> _______________________________________________ >>>>>>>> dev mailing list >>>>>>>> dev at lists.scilab.org >>>>>>>> http://lists.scilab.org/mailman/listinfo/dev >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> dev mailing list >>>>>>> dev at lists.scilab.org >>>>>>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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 >>>>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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 >>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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 > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Sun Apr 7 19:25:27 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Sun, 7 Apr 2019 19:25:27 +0200 Subject: [Scilab-Dev] protect / unprotect: recent progress & analysis Message-ID: <96b5a750-2fbf-7781-0276-41287717283a@free.fr> Hello Antoine, On 2019-01-18, you called in a private mail for comments about the initial implementation of some variables protect / unprotect features commited @ https://codereview.scilab.org/20712 First of all, thanks a lot for the implementation progress about this long-wished feature. Excellent news. After your call, please find below some (sometime naive) remarks and questions about the initial commit, mainly about the expected behavior of the features. As a contribution to the features analysis, Best regards Samuel * Do protect() and unprotect() return anything? * Do we have assert_checkequal(size(isprotected(["a", "b", "c"])), [1 3]) * Will current "permanent variables" be protected with protect() or with another special protection? unprotect %inf // => error ? // IMO, one should avoid keeping concurrent protection features. * Protection of global variables: What will happen or is expected in the following cases, from the top level (console)? global a protect a clear a clearglobal a // See also: http://bugzilla.scilab.org/15250 // http://bugzilla.scilab.org/14928 * Protection and scope: When protecting a variable in a function, what will happen when leaving the function? a = 1; b = 2; function r = test(g) disp(isprotected("g")) // Is the protection status of a variable as input argument heritated by the passed copy? // I guess that no, but this should be clearly stated and tested. a = a, protect a global b, protect b c = %pi/%e; r = c; protect c r endfunction e = 3; protect e d = test(e); // Do we get an error due to deletion of protected internal c ? isprotected("a") // => %F : protect a // just protects the local copie, doesn't it? isprotected("b") // => %T | %F ? isprotected("d") // => %T | %F ? * Will funcprot() be kept? If yes, how will it cope with the new protect/unprotect feature? funcprot(2); unprotect linspace // => error ? linspace = 1; // => error ? // Conversely: funcprot(0) function test(), a=1; endfunction protect test test = 3; // => error ? * class protection: in order to replace funcprot(), we could imagine a "class protection" more general than only for Scilab functions: each time that a new object of type 13 (or #n) or of typeof "function" (or whatever) is created, a given protection status is automatically ascribed to it. protect("-type", 13) // <=> funcprot(2) unprotect("-type", 13) // <=> funcprot(0) protect("-type", 14) // <=> as a libprot * Protection level: As with the current funcprot() implementation, we may imagine transfering to the new protect() function the 3-status possibility: unprotected / warnable / protected. Then, unprotect() becomes useless. It is replaced with protect(0, ["a" "b" "cd"]) // in addition to protect(1, ["a" "b" "cd"]) protect(2, ["a" "b" "cd"]) To stay console-oriented, the 0|1|2 status could also be figures "0"|"1"|"2", provided that no Scilab variable name can start with a 0-9 figure. To me, even without "warnable" status, these syntaxes would be preferable, avoiding a useless unprotect() interface while the job is basically the same. Just the value to ascribe to the new status is changed. This requires an additional input arg, not a specific function. Scilab is not a low-level language. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Antoine.Elias at esi-group.com Tue Apr 9 09:52:36 2019 From: Antoine.Elias at esi-group.com (Antoine Elias) Date: Tue, 9 Apr 2019 07:52:36 +0000 Subject: [Scilab-Dev] protect / unprotect: recent progress & analysis In-Reply-To: <96b5a750-2fbf-7781-0276-41287717283a@free.fr> References: <96b5a750-2fbf-7781-0276-41287717283a@free.fr> Message-ID: Hello Samuel, Just a question what is the goal of this feature ? Because after more than 10 years on Scilab, I never need this, so I need your help to understand needs and cases. Currently, un/protect is only on local variables not on global. ( but that could change if needed ) Look Answers/Questions in blue in your message Regards, Antoine De : Samuel Gougeon Envoy? : dimanche 7 avril 2019 19:25 ? : Antoine Elias ; List dedicated to development questions Objet : protect / unprotect: recent progress & analysis Hello Antoine, On 2019-01-18, you called in a private mail for comments about the initial implementation of some variables protect / unprotect features commited @ https://codereview.scilab.org/20712 First of all, thanks a lot for the implementation progress about this long-wished feature. Excellent news. After your call, please find below some (sometime naive) remarks and questions about the initial commit, mainly about the expected behavior of the features. As a contribution to the features analysis, Best regards Samuel * Do protect() and unprotect() return anything? Antoine: Currently nothing, do you have any request ? I can return status of un/protect and %f for non-existing variable. * Do we have assert_checkequal(size(isprotected(["a", "b", "c"])), [1 3]) Antoine: Yep * Will current "permanent variables" be protected with protect() or with another special protection? unprotect %inf // => error ? // IMO, one should avoid keeping concurrent protection features. Antoine: Current protection of predefined variable ( %pi, %inf, %nan, %e, ? ) is done by the same feature. I don't know if we should forbidden unprotect of predefined variables. * Protection of global variables: What will happen or is expected in the following cases, from the top level (console)? global a protect a clear a clearglobal a // See also: http://bugzilla.scilab.org/15250 // http://bugzilla.scilab.org/14928 Antoine: Clearly, I don't know ? Who is the strongest between local protection or clearglobal ? * Protection and scope: When protecting a variable in a function, what will happen when leaving the function? a = 1; b = 2; function r = test(g) disp(isprotected("g")) // Is the protection status of a variable as input argument heritated by the passed copy? // I guess that no, but this should be clearly stated and tested. a = a, protect a global b, protect b c = %pi/%e; r = c; protect c r endfunction e = 3; protect e d = test(e); // Do we get an error due to deletion of protected internal c ? isprotected("a") // => %F : protect a // just protects the local copie, doesn't it? isprotected("b") // => %T | %F ? isprotected("d") // => %T | %F ? Antoine: When leaving a function, ALL local variables are deleted regardless their protection. Why ? Because we don't know where to put them ? Antoine: funcprot defines a global behavior for redefinition of functions, that's not exactly the same scope. Maybe we can include functions in un/protect feature but what to do with funcprot ? I think it will be difficult to keep both and that will be puzzling for users. * Will funcprot() be kept? If yes, how will it cope with the new protect/unprotect feature? funcprot(2); unprotect linspace // => error ? linspace = 1; // => error ? // Conversely: funcprot(0) function test(), a=1; endfunction protect test test = 3; // => error ? * class protection: in order to replace funcprot(), we could imagine a "class protection" more general than only for Scilab functions: each time that a new object of type 13 (or #n) or of typeof "function" (or whatever) is created, a given protection status is automatically ascribed to it. protect("-type", 13) // <=> funcprot(2) unprotect("-type", 13) // <=> funcprot(0) protect("-type", 14) // <=> as a libprot * Protection level: As with the current funcprot() implementation, we may imagine transfering to the new protect() function the 3-status possibility: unprotected / warnable / protected. Then, unprotect() becomes useless. It is replaced with protect(0, ["a" "b" "cd"]) // in addition to protect(1, ["a" "b" "cd"]) protect(2, ["a" "b" "cd"]) To stay console-oriented, the 0|1|2 status could also be figures "0"|"1"|"2", provided that no Scilab variable name can start with a 0-9 figure. To me, even without "warnable" status, these syntaxes would be preferable, avoiding a useless unprotect() interface while the job is basically the same. Just the value to ascribe to the new status is changed. This requires an additional input arg, not a specific function. Scilab is not a low-level language. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Apr 12 15:27:32 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 12 Apr 2019 15:27:32 +0200 Subject: [Scilab-Dev] Proposal: replace eye() of size [-1 -1] with %eye = 1:0*$:1 as a new predefined constant Message-ID: <9a38dbfd-8bd9-8808-8a2a-d4862d249e76@free.fr> Hello devs, eye() builds a very specific object, of size [-1,-1]. In the Bugzilla report http://bugzilla.scilab.org/16060 , * I show that the added value of this specific object looks very poor with respect to the complexity and specific processing it requires in the code. * An idea is presented to replace eye() with a new predefined constant %eye = 1:0*$:1 as a true implicitlist object, * and shows on some examples how it can easily work instead of eye(). IMO, in order to simplify Scilab code without removing any feature, the eye() syntax and object should be deprecated and replaced. Indeed, i think that setting negative sizes is a rather bad way to encode such an object. Looking forward to read you, Regards Samuel PS: IMO we should take a special care about what we do with implicitlist objects, how we use and make them evolving. They look rather underexploited. So, anticipating other possible extended usages would be wise. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Apr 12 18:40:32 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 12 Apr 2019 18:40:32 +0200 Subject: [Scilab-Dev] protect / unprotect: recent progress & analysis In-Reply-To: References: <96b5a750-2fbf-7781-0276-41287717283a@free.fr> Message-ID: <3c25a170-877b-d06a-d081-0f9965f6d6de@free.fr> Hello Antoine, Le 09/04/2019 ? 09:52, Antoine Elias a ?crit : > > Hello Samuel, > > Just a question what is the goal of this feature ? > > Because after more than 10 years on Scilab, I never need this, so I > need your help to understand needs and cases. > uman predef @ displays a first list of threads about this topic. * One may wish to protect some custom variables in the scilab.ini file. Please see for instance o http://mailinglists.scilab.org/Protecting-a-new-variable-by-using-predef-tp4027293.html o http://mailinglists.scilab.org/Users-fr-Protection-de-variables-tp4037331.html * When creating a library, one may want and need to provide some protected constants as members of the library. Please see o http://mailinglists.scilab.org/problem-defining-protected-functions-in-scilab-tp2615970.html o http://mailinglists.scilab.org/Library-workaround-wanted-predef-bug-tp4034383.html * A workaround for libraries existed up to Scilab 5.5, consisting in including a myConstantes.sci file just setting variables to be included... and protected, provided that the library is loaded at startup. But 1. this worked only for libraries in ATOMS modules loaded at Scilab startup 2. In files.sci, Scilab 6 genlib() now ignores everything that is not a function. A short list of bugs/wishes reported on Bugzilla has been published here: http://mailinglists.scilab.org/Scilab-users-Replacing-predef-with-an-actual-varprot-a-top-5-priority-for-Scilab-6-1-At-last-protecte-tp4036564.html with some comment about sharing the need for variables protection. So, a priori the need applies to any variables type, including libraries. Another user case: You are a teacher, and you prepare some Scilab materials -- scripts.sce, etc -- for a practical session with some work to do with Scilab. When newbies students work with your script, they do really many things, and often some unexpected ones, as overwriting some variables predefined in the script, etc. If you don't want to spend your time during the session to debug the results of their freedom instead of focusing on the topic of the session, protecting predefined variables is expected to help a lot... My first message does not aim to tell all what should be done, but to tell what we -- devs and users -- /should//be aware of /when designing, then documenting, and finally using the protection of variables, as well with respect to existing features : funcprot(), predef(), clear, scope management of variables, global, clearglobal. > Currently, un/protect is only on local variables not on global. ( but > that could change if needed ) > *To me, protecting global variables is not needed*. *I mean, in the global storage*. The main threat are clear() instructions loved by a subset of Scilabers. clearglobal() is likely much less used. But, as far as i understand, global works with a local "copy", *that could be protected as a local variable*. There is no reason to prevent this, but it must be clearly stated that such a protection won't apply to the global counterpart. Example: --> global a --> a = 1; --> clear a --> a Undefined variable: a --> global a --> a // we locally retrieve a copy of the global instance a = 1. --> clear a --> a = 3 // only local a = 3. --> // protect a --> global a --> a // the global content overwrites the local one a = 1. Now, if we uncomment the /// protect a/ instruction, what will be expected? The priority between /global/ and the /local protection/ will have to be clarified and documented. > Look Answers/Questions in blue in your message > My replies in magenta: > Regards, > > Antoine > > *De :*Samuel Gougeon > *Envoy? :* dimanche 7 avril 2019 19:25 > *? :* Antoine Elias ; List dedicated to > development questions > *Objet :* protect / unprotect: recent progress & analysis > > Hello Antoine, > > On 2019-01-18, you called in a private mail for comments about the > initial implementation of some variables protect / unprotect features > commited @ https://codereview.scilab.org/20712 > > First of all, thanks a lot for the implementation progress about this > long-wished feature. > Excellent news. > > After your call, please find below some (sometime naive) remarks and > questions about the initial commit, mainly about the expected behavior > of the features. > > As a contribution to the features analysis, > > Best regards > Samuel > > * Do protect() and unprotect() return anything? > > Antoine: Currently nothing, do you have any request ? > > I can return status of un/protect and %f for non-existing variable. > Samuel: I think that returning a matrix of booleans indicating the /actual new status/ of variables might be useful, indeed. > * Do we have > assert_checkequal(size(isprotected(["a", "b", "c"])), [1 3]) > > Antoine: Yep > > * Will current "permanent variables" be protected with protect() or > with another special protection? > unprotect %inf // => error ? > // IMO, one should avoid keeping concurrent protection features. > > Antoine: Current protection of predefined variable ( %pi, %inf, %nan, > %e, ?) is done by the same feature. > > I don't know if we should forbidden unprotect of predefined variables. > Samuel: I don't think there should be a special mechanism for them. But as listed below, protection levels might be defined. > * Protection of global variables: What will happen or is expected in > the following cases, from the top level (console)? > global a > protect a > clear a > clearglobal a > // See also: http://bugzilla.scilab.org/15250 > // http://bugzilla.scilab.org/14928 > > Antoine: Clearly, I don't know ? > > Who is the strongest between local protection or clearglobal ? > > * Protection and scope: > When protecting a variable in a function, what will happen when > leaving the function? > a = 1; > b = 2; > function r = test(g) > disp(isprotected("g")) > // Is the protection status of a variable as input argument > heritated by the passed copy? > // I guess that no, but this should be clearly stated and tested. > a = a, protect a > global b, protect b > c = %pi/%e; > r = c; > protect c r > endfunction > e = 3; protect e > d = test(e); // Do we get an error due to deletion of > protected internal c ? > isprotected("a") // => %F : protect a // just protects the local > copie, doesn't it? > isprotected("b") // => %T | %F ? > isprotected("d") // => %T | %F ? > > Antoine: When leaving a function, ALL local variables are deleted > regardless their protection. > > Why ? Because we don't know where to put them ? > Samuel: This sounds reasonable. But this could yield an error instead of silently leaving. > Antoine: funcprot defines a global behavior for redefinition of > functions, that's not exactly the same scope. > Samuel: Indeed, in 5.5.2, functions look somewhat "global": -->function test() --> linspace = 1; -->endfunction -->test() Warning : redefining function: linspace . Use funcprot(0) to avoid this message It is no longer the case in 6.0 : --> funcprot() ans = 1. --> function test() > linspace = 1; > endfunction --> test() --> > Maybe we can include functions in un/protect feature but what to do > with funcprot ? > > I think it will be difficult to keep both and that will be puzzling > for users. > Samuel: clearly, if some "class protection" is implemented and enabled in addition to some object protection, funcprot() would have to be deprecated and removed. Now, the question is: *is a general class protection actually needed?* For all data types: likely not. For libraries: i don't think so. But other contributions to this discussion would be welcome. Reverse question: If funcprot() is kept, will protect() will apply to functions as well, or will be excluded? If it applies to them, how will this cope with funcprot()? Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Apr 12 19:03:29 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 12 Apr 2019 19:03:29 +0200 Subject: [Scilab-Dev] protect / unprotect: recent progress & analysis In-Reply-To: <3c25a170-877b-d06a-d081-0f9965f6d6de@free.fr> References: <96b5a750-2fbf-7781-0276-41287717283a@free.fr> <3c25a170-877b-d06a-d081-0f9965f6d6de@free.fr> Message-ID: <364ea613-e6a1-5adb-da98-f0ba15c4dcab@free.fr> Le 12/04/2019 ? 18:40, Samuel Gougeon a ?crit : > .../... > >> Maybe we can include functions in un/protect feature but what to do >> with funcprot ? >> >> I think it will be difficult to keep both and that will be puzzling >> for users. >> > Samuel: clearly, if some "class protection" is implemented and enabled > in addition to some object protection, funcprot() would have to be > deprecated and removed. > > Now, the question is: *is a general class protection actually needed?* > For all data types: likely not. For libraries: i don't think so. But > other contributions to this discussion would be welcome. > Reverse question: If funcprot() is kept, will protect() will apply to > functions as well, or will be excluded? If it applies to them, how > will this cope with funcprot()? Because presently funcprot() does not prevent silently clearing a function, it looks unrelevant to extend its mechanism to some other data types. But * would it be hard to change this behavior: warning or yielding an error /as well /when a function is cleared? * Then, would it be hard to extend the changed behavior to any given data type? Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Tue Apr 23 22:14:11 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 23 Apr 2019 22:14:11 +0200 Subject: [Scilab-Dev] list as output in function call Message-ID: <467b8408-74c0-f86c-376d-0106bcfc4409@utc.fr> Hello all, After seeing this question on stackoverflow https://stackoverflow.com/questions/55757856/ndgrid-input-and-output-from-cell-array I realized that the current features of Scilab are quite asymmetric w.r.t. the use of an "expanded" list as input, which is supported, as in x = list(1:2,1:2,1:2) ndgrid(x(:)) and as output, which is not supported, as in X = list(,,) X(:) = ndgrid(x(:)) Would it be complicated to implement the above ? S. From antoine.elias at scilab-enterprises.com Tue Apr 23 22:28:59 2019 From: antoine.elias at scilab-enterprises.com (Antoine ELIAS) Date: Tue, 23 Apr 2019 22:28:59 +0200 Subject: [Scilab-Dev] list as output in function call In-Reply-To: <467b8408-74c0-f86c-376d-0106bcfc4409@utc.fr> References: <467b8408-74c0-f86c-376d-0106bcfc4409@utc.fr> Message-ID: Hello St?phane, Just to be sure, you want that we fill the X-list with all outputs of ngdrid. Following witch information, size(X) or size(outputs) ? In your cas I suppose that the size is the same. What append if X is not a list or does not have the good size ? Some functions that returns multiple arguments, "look" how many as expected by caller a = size(x) vs [a,b] = size(x) for example. Does we must provide size(X) to ngrid ? Just a question, specific to ndgrid, why do not update the function to return a list in case of nargout == 1 ? Regards, Antoine Le 23/04/2019 ? 22:14, St?phane Mottelet a ?crit?: > Hello all, > > After seeing this question on stackoverflow > > https://stackoverflow.com/questions/55757856/ndgrid-input-and-output-from-cell-array > > > I realized that the current features of Scilab are quite asymmetric > w.r.t. the use of an "expanded" list as input, which is supported, as in > > x = list(1:2,1:2,1:2) > ndgrid(x(:)) > > and as output, which is not supported, as in > > X = list(,,) > X(:) = ndgrid(x(:)) > > Would it be complicated to implement the above ? > > S. > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From stephane.mottelet at utc.fr Tue Apr 23 22:46:42 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 23 Apr 2019 22:46:42 +0200 Subject: [Scilab-Dev] list as output in function call In-Reply-To: References: <467b8408-74c0-f86c-376d-0106bcfc4409@utc.fr> Message-ID: <95b9c9eb-03ec-b206-9df8-1233a0e85ca3@utc.fr> Le 23/04/2019 ? 22:28, Antoine ELIAS a ?crit?: > Hello St?phane, > > Just to be sure, you want that we fill the X-list with all outputs of > ngdrid. > Following witch information, size(X) or size(outputs) ? > In your cas I suppose that the size is the same. > What append if X is not a list or does not have the good size ? the same thing that happens if in ngrid(x(:)) x is not a list or has not the good size :-D > > Some functions that returns multiple arguments, "look" how many as > expected by caller > a = size(x) vs [a,b] = size(x) for example. > Does we must provide size(X) to ngrid ? After messing around the ast module I know it is not simple. But seeing this na?vely, it seems as simple as giving the number of outputs when running [X(1),X(2),X(3)] = ndgrid(x(:)) > > Just a question, specific to ndgrid, why do not update the function to > return a list in case of nargout == 1 ? This kind of behaviour is the default in Julia, for all functions. But we don't need this in Scilab... S. > > Regards, > Antoine > Le 23/04/2019 ? 22:14, St?phane Mottelet a ?crit?: >> Hello all, >> >> After seeing this question on stackoverflow >> >> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/stackoverflow.com/questions/55757856/ndgrid-input-and-output-from-cell-array >> >> >> I realized that the current features of Scilab are quite asymmetric >> w.r.t. the use of an "expanded" list as input, which is supported, as in >> >> x = list(1:2,1:2,1:2) >> ndgrid(x(:)) >> >> and as output, which is not supported, as in >> >> X = list(,,) >> X(:) = ndgrid(x(:)) >> >> Would it be complicated to implement the above ? >> >> S. >> >> _______________________________________________ >> dev mailing list >> dev at lists.scilab.org >> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev >> > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev > From sgougeon at free.fr Tue Apr 23 22:50:24 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Tue, 23 Apr 2019 22:50:24 +0200 Subject: [Scilab-Dev] list as output in function call In-Reply-To: References: <467b8408-74c0-f86c-376d-0106bcfc4409@utc.fr> Message-ID: <80c51541-77aa-9f41-bced-0b6baee95119@free.fr> Hello, Le 23/04/2019 ? 22:28, Antoine ELIAS a ?crit : > Hello St?phane, > > Just to be sure, you want that we fill the X-list with all outputs of > ngdrid. > Following witch information, size(X) or size(outputs) ? > In your cas I suppose that the size is the same. > What append if X is not a list or does not have the good size ? > > Some functions that returns multiple arguments, "look" how many as > expected by caller > a = size(x) vs [a,b] = size(x) for example. > Does we must provide size(X) to ngrid ? I am not sure that this would be enough. This topic is discussed in the report http://bugzilla.scilab.org/14372 and its comments > > Just a question, specific to ndgrid, why do not update the function to > return a list in case of nargout == 1 ? You likely mean as a unique explicit argout, instead of the varargout "implicit" list. Wrapping the result in a list would break a lot of code, and would make addressing the results more complicated for most frequent cases. Regards Samuel From antoine.elias at scilab-enterprises.com Wed Apr 24 09:25:07 2019 From: antoine.elias at scilab-enterprises.com (Antoine ELIAS) Date: Wed, 24 Apr 2019 09:25:07 +0200 Subject: [Scilab-Dev] list as output in function call In-Reply-To: <95b9c9eb-03ec-b206-9df8-1233a0e85ca3@utc.fr> References: <467b8408-74c0-f86c-376d-0106bcfc4409@utc.fr> <95b9c9eb-03ec-b206-9df8-1233a0e85ca3@utc.fr> Message-ID: <47beb95f-d67a-8a89-79d1-0d767bec990f@scilab-enterprises.com> Le 23/04/2019 ? 22:46, St?phane Mottelet a ?crit?: > Le 23/04/2019 ? 22:28, Antoine ELIAS a ?crit?: > >> Hello St?phane, >> >> Just to be sure, you want that we fill the X-list with all outputs of >> ngdrid. >> Following witch information, size(X) or size(outputs) ? >> In your cas I suppose that the size is the same. >> What append if X is not a list or does not have the good size ? > the same thing that happens if in ngrid(x(:)) x is not a list or has > not the good size :-D I'm not sure that we speak about the same things ( there are 2 X/x in your example ). I speak about number of outputs from the function and size of container that "receive" data. >> >> Some functions that returns multiple arguments, "look" how many as >> expected by caller >> a = size(x) vs [a,b] = size(x) for example. >> Does we must provide size(X) to ngrid ? > > After messing around the ast module I know it is not simple. But > seeing this na?vely, it seems as simple as giving the number of > outputs when running I think it would not be very difficult to do. But my questions are most about goals and implications of this kind of features. I'm not really ready to break code or/and compatibility for very situational features to avoid typing few characters ;) I understand that will be useful but sometimes is not easy to imagine implications ( like a + [], we learn from our mistakes :p ) > > [X(1),X(2),X(3)] = ndgrid(x(:)) > >> >> Just a question, specific to ndgrid, why do not update the function >> to return a list in case of nargout == 1 ? > > This kind of behaviour is the default in Julia, for all functions. But > we don't need this in Scilab... It was the same in very first versions of Scilab 6 ( before alphas I think ) but for compatibility with familly 5, we change that ;) > > S. > >> >> Regards, >> Antoine >> Le 23/04/2019 ? 22:14, St?phane Mottelet a ?crit?: >>> Hello all, >>> >>> After seeing this question on stackoverflow >>> >>> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/stackoverflow.com/questions/55757856/ndgrid-input-and-output-from-cell-array >>> >>> >>> I realized that the current features of Scilab are quite asymmetric >>> w.r.t. the use of an "expanded" list as input, which is supported, >>> as in >>> >>> x = list(1:2,1:2,1:2) >>> ndgrid(x(:)) >>> >>> and as output, which is not supported, as in >>> >>> X = list(,,) >>> X(:) = ndgrid(x(:)) >>> >>> Would it be complicated to implement the above ? >>> >>> S. >>> >>> _______________________________________________ >>> dev mailing list >>> dev at lists.scilab.org >>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev >>> >> >> _______________________________________________ >> dev mailing list >> dev at lists.scilab.org >> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev >> > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From antoine.elias at scilab-enterprises.com Wed Apr 24 09:25:14 2019 From: antoine.elias at scilab-enterprises.com (Antoine ELIAS) Date: Wed, 24 Apr 2019 09:25:14 +0200 Subject: [Scilab-Dev] list as output in function call In-Reply-To: <80c51541-77aa-9f41-bced-0b6baee95119@free.fr> References: <467b8408-74c0-f86c-376d-0106bcfc4409@utc.fr> <80c51541-77aa-9f41-bced-0b6baee95119@free.fr> Message-ID: <395e75be-b64f-042f-5978-661ca57ad07d@scilab-enterprises.com> Le 23/04/2019 ? 22:50, Samuel Gougeon a ?crit?: > Hello, > > Le 23/04/2019 ? 22:28, Antoine ELIAS a ?crit : >> Hello St?phane, >> >> Just to be sure, you want that we fill the X-list with all outputs of >> ngdrid. >> Following witch information, size(X) or size(outputs) ? >> In your cas I suppose that the size is the same. >> What append if X is not a list or does not have the good size ? >> >> Some functions that returns multiple arguments, "look" how many as >> expected by caller >> a = size(x) vs [a,b] = size(x) for example. >> Does we must provide size(X) to ngrid ? > > I am not sure that this would be enough. > This topic is discussed in the report http://bugzilla.scilab.org/14372 > and its comments > >> >> Just a question, specific to ndgrid, why do not update the function >> to return a list in case of nargout == 1 ? > > You likely mean as a unique explicit argout, instead of the varargout > "implicit" list. > Wrapping the result in a list would break a lot of code, and would > make addressing the results more complicated for most frequent cases. > Absolutely not ;) I said that only for this specific case "ndgrid". I think that only break non-working code. and varargout is a real list ! ( Do not discriminate ^^ ) > Regards > Samuel > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From sgougeon at free.fr Wed Apr 24 10:07:42 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 24 Apr 2019 10:07:42 +0200 Subject: [Scilab-Dev] list as output in function call In-Reply-To: <395e75be-b64f-042f-5978-661ca57ad07d@scilab-enterprises.com> References: <467b8408-74c0-f86c-376d-0106bcfc4409@utc.fr> <80c51541-77aa-9f41-bced-0b6baee95119@free.fr> <395e75be-b64f-042f-5978-661ca57ad07d@scilab-enterprises.com> Message-ID: <23778568-ba07-037f-dcf1-8ebca9e7af5b@free.fr> Le 24/04/2019 ? 09:25, Antoine ELIAS a ?crit : > Le 23/04/2019 ? 22:50, Samuel Gougeon a ?crit : >> Hello, >> >> Le 23/04/2019 ? 22:28, Antoine ELIAS a ?crit : >> .../... >>> >>> Just a question, specific to ndgrid, why do not update the function >>> to return a list in case of nargout == 1 ? >> >> You likely mean as a unique explicit argout, instead of the varargout >> "implicit" list. >> Wrapping the result in a list would break a lot of code, and would >> make addressing the results more complicated for most frequent cases. >> > Absolutely not ;) > I said that only for this specific case "ndgrid". Yes, this is what i understood. > I think that only break non-working code. With the current implementation, the following works, with argn(1)==1: --> X = ndgrid(1:4) X = 1. 1. 1. 1. 2. 2. 2. 2. 3. 3. 3. 3. 4. 4. 4. 4. > and varargout is a real list ! ( Do not discriminate ^^ ) Yes, it is build as a real list to feed the return. But is not /processed/ as a classic list when returning, since it is assigned in a distributive way, while it's not the case for a simple list. So yes we have to discriminate both, as the test below shows it: --> function varargout = test() > varargout = list("a","b","c") > endfunction --> [a,b,c] = test() c = c b = b a = a --> function L = test() > L = list("a","b","c") > endfunction --> [a,b,c] = test() Wrong number of output arguments. And, alone, returning a list as the first element in or out of varargout would not fix the issue: --> function varargout = test() > varargout = list(list("a","b","c")) > endfunction --> a = list(,,); --> a(:) = test() Unable to insert multiple item in a list. --> function [r,varargout] = test() > if argn(1)==1 > r = list("a","b","c") > varargout = list() > end > endfunction --> a = list(,,); --> a(:) = test() Unable to insert multiple item in a list. For the general discussion, i think that, from a user's point a view, when using a container as LHS argument, a distributive assignment would be *often* very useful. It might be either through a new *.=* "operator", or through the classic "=" one but only when for instance the RHS is a container as well, * either a list with the right number of elements at depth = 0 * or a cell or struct array with the same sizes as the cell or struct (or struct or cell) on the LHS AFAIR, this kind of feature is already reported as a wish. Best regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Apr 24 10:36:57 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 24 Apr 2019 10:36:57 +0200 Subject: [Scilab-Dev] list as output in function call In-Reply-To: <23778568-ba07-037f-dcf1-8ebca9e7af5b@free.fr> References: <467b8408-74c0-f86c-376d-0106bcfc4409@utc.fr> <80c51541-77aa-9f41-bced-0b6baee95119@free.fr> <395e75be-b64f-042f-5978-661ca57ad07d@scilab-enterprises.com> <23778568-ba07-037f-dcf1-8ebca9e7af5b@free.fr> Message-ID: Le 24/04/2019 ? 10:07, Samuel Gougeon a ?crit : > .../... > > For the general discussion, i think that, from a user's point a view, > when using a container as LHS argument, a distributive assignment > would be *often* very useful. It might be either through a new *.=* > "operator", or through the classic "=" one but only when for instance > the RHS is a container as well, > > * either a list with the right number of elements at depth = 0 > * or a cell or struct array with the same sizes as the cell or > struct (or struct or cell) on the LHS > > AFAIR, this kind of feature is already reported as a wish. > By the way, while it was possible in Scilab 5.5.2 to assign the elements of a list to all elements of the field of an array of structures, it is no longer the case in Scilab 6.0: --> clear s --> s.a = %pi; --> s.b = "a"; --> s(2).a = %e; --> s(2).b = "b" s = 2x1 struct array with fields: a b --> setfield("a", list(%i, 3.1), s) setfield: Wrong type for input argument #3: List expected. In Scilab 5, we get the right assignment: -->setfield("a",list(%i,3.1),s) -->s.a ans = ans(1) i ans(2) 3.1 -->s(2).a ans = 3.1 This Scilab 6 restriction weakens the usage of arrays of structures. Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: