> (/home/caioc2/scilab/scilab/.libs/lt-scilab-bin) > 18: 0x21f45 <__libc_start_main> > (/lib/x86_64-linux-gnu/libc.so.6) > 19: 0x26df < > > (/home/caioc2/scilab/scilab/.libs/lt-scilab-bin) > End of stack Anyone can confirm the issue? Thanks Caio SOUZA -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Aug 5 17:24:03 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 5 Aug 2016 17:24:03 +0200 Subject: [Scilab-Dev] vector^scalar allowed again in Scilab 6? Message-ID: <57A4AF93.7000301@free.fr> Hello, The warning message about the vector^scalar operation yielded in Scilab 5.5 has been removed from Scilab 6.0, as if this operation would become again allowed instead of becoming actually forbidden: Scilab 5: -->x = 1:3 x = 1. 2. 3. -->x^2 ! Warning: Syntax "vector ^ scalar" is obsolete. It will be removed in Scilab 6.0. Use "vector .^ scalar" instead. ans = 1. 4. 9. Scilab 6.0.0-b2: --> warning("on") --> x = 1:3 x = 1. 2. 3. --> x^2 ans = 1. 4. 9. Is it on purpose? Is this shortcut restored? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre-aime.agnel at scilab-enterprises.com Wed Aug 10 17:56:59 2016 From: pierre-aime.agnel at scilab-enterprises.com (=?UTF-8?Q?Pierre-Aim=c3=a9_Agnel?=) Date: Wed, 10 Aug 2016 17:56:59 +0200 Subject: [Scilab-Dev] vector^scalar allowed again in Scilab 6? In-Reply-To: <57A4AF93.7000301@free.fr> References: <57A4AF93.7000301@free.fr> Message-ID: Hello, It was changed at resolution of http://bugzilla.scilab.org/show_bug.cgi?id=14316 I am not sure though whether enforcing the 'vector ^ scalar' error should be reintroduced. My 2-cents: there are many operations that have the same behaviour that their dot-operation counterpart when used with a scalar. I think the operation should remain available, but I can also enforce the obsolescence in the release for 6.0.0. Best regards Le 05/08/2016 ? 17:24, Samuel Gougeon a ?crit : > Hello, > > The warning message about the vector^scalar operation yielded in > Scilab 5.5 > has been removed from Scilab 6.0, as if this operation would become > again allowed instead of becoming actually forbidden: > > Scilab 5: > > -->x = 1:3 > x = > 1. 2. 3. > > -->x^2 > ! > Warning: Syntax "vector ^ scalar" is obsolete. It will be removed in > Scilab 6.0. > Use "vector .^ scalar" instead. > ans = > 1. 4. 9. > > Scilab 6.0.0-b2: > --> warning("on") > > --> x = 1:3 > x = > 1. 2. 3. > > --> x^2 > ans = > 1. 4. 9. > > Is it on purpose? Is this shortcut restored? > > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -- Pierre-Aim? Agnel R&D Projects Manager Phone: +33.1.80.77.04.67 Mobile: +33.6.82.49.35.23 ----------------------------------------------------------- Scilab Enterprises 143bis rue Yves Le Coz - 78000 Versailles, France Phone: +33.1.80.77.04.60 http://www.scilab-enterprises.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Aug 10 20:02:15 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 10 Aug 2016 20:02:15 +0200 Subject: [Scilab-Dev] vector^scalar allowed again in Scilab 6? In-Reply-To: References: <57A4AF93.7000301@free.fr> Message-ID: <57AB6C27.9000102@free.fr> Hello Pierre-Aim?, Le 10/08/2016 17:56, Pierre-Aim? Agnel a ?crit : > > Hello, > > It was changed at resolution of > http://bugzilla.scilab.org/show_bug.cgi?id=14316 > > I am not sure though whether enforcing the 'vector ^ scalar' error > should be reintroduced. My 2-cents: there are many operations that > have the same behaviour that their dot-operation counterpart when used > with a scalar. > > I think the operation should remain available, but I can also enforce > the obsolescence in the release for 6.0.0. > Thanks for your answer. I understand that the reversion of the vector^scalar change was done when fixing #14316, but as far as i understand, things are not connected. This reversion was not mandatory to fix #14346. IMO, what was planed for Scilab 6 was great. I know that this syntax vector^scalar instead of vector.^scalar was very widespread. But instead of parsing vector^scalar as vector.^scalar as in Scilab <6 or always yielding an error, why not making Scilab 6 testing whether the overload %s_p_s() (or other%@_p_@() overload according to operands types) exists. Then, users wanting to work with the old equivocal behavior could define deff("r=%s_p_s(a,b)","r=a.^b") in their library (or startup file) instead of changing all their code. Or/and include their own warning in their overload whether they wish to actually upgrade their code. And that's it. Best regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre-aime.agnel at scilab-enterprises.com Thu Aug 11 10:27:21 2016 From: pierre-aime.agnel at scilab-enterprises.com (=?UTF-8?Q?Pierre-Aim=c3=a9_Agnel?=) Date: Thu, 11 Aug 2016 10:27:21 +0200 Subject: [Scilab-Dev] vector^scalar allowed again in Scilab 6? In-Reply-To: <57AB6C27.9000102@free.fr> References: <57A4AF93.7000301@free.fr> <57AB6C27.9000102@free.fr> Message-ID: <9a72a94d-5715-178f-2b70-6cc4558a7849@scilab-enterprises.com> Hi Samuel, Le 10/08/2016 ? 20:02, Samuel Gougeon a ?crit : > Hello Pierre-Aim?, > > Le 10/08/2016 17:56, Pierre-Aim? Agnel a ?crit : >> >> Hello, >> >> It was changed at resolution of >> http://bugzilla.scilab.org/show_bug.cgi?id=14316 >> >> I am not sure though whether enforcing the 'vector ^ scalar' error >> should be reintroduced. My 2-cents: there are many operations that >> have the same behaviour that their dot-operation counterpart when >> used with a scalar. >> >> I think the operation should remain available, but I can also enforce >> the obsolescence in the release for 6.0.0. >> > > Thanks for your answer. > I understand that the reversion of the vector^scalar change was done > when fixing #14316, > but as far as i understand, things are not connected. This reversion > was not mandatory to fix #14346. > > IMO, what was planed for Scilab 6 was great. > > I know that this syntax vector^scalar instead of vector.^scalar was > very widespread. But instead of parsing vector^scalar as > vector.^scalar as in Scilab <6 or always yielding an error, why not > making Scilab 6 testing whether the overload %s_p_s() (or > other%@_p_@() overload according to operands types) exists. Then, > users wanting to work with the old equivocal behavior could define > deff("r=%s_p_s(a,b)","r=a.^b") in their library (or startup file) > instead of changing all their code. Or/and include their own warning > in their overload whether they wish to actually upgrade their code. > And that's it. > In my humble opinion, this is a great proposal that can benefit everyone, we just have to check the already existing overloads to see if there are any interferences. > Best regards > Samuel > > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -- Pierre-Aim? Agnel R&D Projects Manager Phone: +33.1.80.77.04.67 Mobile: +33.6.82.49.35.23 ----------------------------------------------------------- Scilab Enterprises 143bis rue Yves Le Coz - 78000 Versailles, France Phone: +33.1.80.77.04.60 http://www.scilab-enterprises.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Aug 17 23:39:23 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 17 Aug 2016 23:39:23 +0200 Subject: [Scilab-Dev] debug: remanent breakpoints Message-ID: <57B4D98B.5050306@free.fr> Hello the Scilab Team, I would like to point a special behavior of the new debugger. It looks a bit strange (and may be unhandy) to me, but after all it could be on purpose: When * we define some breakpoints in a function, * then we quit the debugger, * then we modify the function -- adding or removing lines, etc -- * then we exec() the function file to update it * then we reenter the debugger The former breakpoints are then still defined at unchanged line numbers, but, obviously, the contents pointed by these references are no longer the same, since the function content has changed. So, my questions are : * When we quit and reenter the debugger, former breakpoints are still defined. They are remanent from the previous debug session. Is this behavior on purpose? I think it could be so, but then imo it would be worthwhile to document it. Moreover, an debug() launching option or/and a debug() environment variable tuning its behavior could be useful. * When some breakpoints have been defined for a function, *and* the function is then updated (exec(), redefined with deff() or with lib(), etc), its former breakpoints are not removed. Is this behavior implemented on purpose? IMO, it could be useful as is, when the modification of the function did not change the number and order of its lines. But quite often it won't be the case: we will wish to cancel former breakpoints and redefine new ones for this function. Unfortunately, there is no way to easily remove all breakpoints of a function in a once: We have to remove them one by one. This is very unhandy. Knowing what are the expected behaviors will help in reporting wishes or bugs. Thanks Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Aug 24 12:41:32 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 24 Aug 2016 12:41:32 +0200 Subject: [Scilab-Dev] vector^scalar allowed again in Scilab 6? In-Reply-To: <9a72a94d-5715-178f-2b70-6cc4558a7849@scilab-enterprises.com> References: <57A4AF93.7000301@free.fr> <57AB6C27.9000102@free.fr> <9a72a94d-5715-178f-2b70-6cc4558a7849@scilab-enterprises.com> Message-ID: <57BD79DC.3000202@free.fr> Le 11/08/2016 10:27, Pierre-Aim? Agnel a ?crit : > > Hi Samuel, > > Le 10/08/2016 ? 20:02, Samuel Gougeon a ?crit : >> .../... >> Thanks for your answer. >> I understand that the reversion of the vector^scalar change was done >> when fixing #14316, >> but as far as i understand, things are not connected. This reversion >> was not mandatory to fix #14346. >> >> IMO, what was planed for Scilab 6 was great. This was as well pointed by Calixte in http://bugzilla.scilab.org/14079 Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: