Hello Antoine and sorry for the lag, This change is not strictly *needed* but for the Scilab 6.0.0 major release we can change some behavior to ease long-term development and ease learning.
The "x+[]" behavior hard is such a behavior that might be changed to be more consistent. In the team, there was almost 50/50 pro/con ratio about this change and the more important argument was : This will ease JIT implementation and will clarify the behavior on `A(find(...)+...) = ...` So now, after the community reaction (which is also not 100% against), I think that we failed on communicating early and provide a *reasonably* verbose implementation. The change is made (I personally will not vote for a revert) and my goal is now to ease user transition. That's the goal of this thread and I will adapt the existing commit. About the warning, I fixed some of them (even if I'm not the original committer of the change) and there is almost no warning presence on current tested code. Now let's manage the transition by adding the right warnings and user helpers. Cheers, -- Clément Le vendredi 08 avril 2016 à 08:52 +0200, [email protected] a écrit : > Here is an honest question to the scilab team (Clement in particular): > > What is so important with this change that you cannot drop it? > > So far, it only seems to confuse or angry active developers and I can confirm > that it occasionall > confuse long time users like my self. > > To be honest, I don't see in this code where there might be a 'x+[]', it > seems to appear further > down the line, in scilab own macros. > > Anyway, my point is not to criticize the work done on scilab development, but > on this particular > change, I can see now the issues it raises while I am clearly not convince > that it will bring > anything particularly key to scilab, apart from removing one oddity and its > companion convenience. > > Cheers, > > Antoine > > > Le 04/07/2016 10:48 PM, Eric Dubois a écrit : > > Hello > > > > I suspect that a beta cycle is not enough and that some toolbox developers > > or other users are > > not aware of this coming change. Once again this is much shorter than > > previous changes, which > > were handled much more smoothly by the Scilab team... Why still shorten the > > adaptation time? > > Except to mark the difference with the predecessors? > > > > Happy to see that at least (and at last) someone does not find compelling > > the case of changing > > this behaviour. > > > > By the way I have spent something like 2 weeks modifying my code and, even > > if I hope having > > found most of the concerned cases, I am sure not to have found all... and > > like Samuel the > > resulting code is sometimes less clean than before. And I, have been > > obliged to stop ongoing > > developments to do this stuff, which is from my point of view a bad > > oiutcome. > > > > Garanti sans virus. www.avast.com > > > > 2016-04-07 22:30 GMT+02:00 Samuel Gougeon <[email protected]>: > > > Hello, > > > > > > Le 07/04/2016 10:16, Clément David a écrit : > > > > Hello (again) Scilab devs, > > > > > > > > TLDR: I don't want to re-open the []+"" behavior change flame-war but > > > > just to remove a > > > > warning on working Scilab 6 code and ask you about the merge > > > > timing. > > > > > > > > > > > > After the []+"" behavior change, the oldEmptyBehaviour has been > > > > introduced by Pierre-Aimé to > > > > ease > > > > the transition from Scilab 5 to Scilab 6. This will help user > > > > transitioning using the beta > > > > version > > > > and thanks to that we also fix some issues in Scilab itself. > > > > > > > > However, the current implementation display a warning in both Scilab 5 > > > > enforced and Scilab 6 > > > > execution mode. I proposed a patchset [1] to remove the warning in the > > > > Scilab 6 execution > > > > mode but > > > > preserve it on the Scilab 5 mode (eg. after a call to > > > > oldEmptyBehaviour("on") ). > > > > > > > > What's your thought about this change ? should we pass it now or after > > > > the 6.0.0 release ? > > > > Is the > > > > beta cycle sufficient enough to manage the behavior change ? > > > > > > I am afraid that i do not catch all what you mean. > > > With "Scilab 5 enforced execution mode", do you mean in Scilab 6 with > > > oldEmptyBehaviour("on") > > > mode? > > > So, instead of using this mode to still ACCEPT and NOT warn users whether > > > []+a is met, it > > > would warn users, > > > while in oldEmptyBehaviour("off"), meeting []+a would no longer warn > > > users? > > > > > > If what i understand above is right: imo, enabling users to ignore this > > > warning by masking it > > > would be > > > quite "dangerous", because changing this behavior has consequences as > > > serious as quiet. > > > > > > BTW: > > > * This would be a first case of Switch-warning-on-specific-case > > > application. > > > To be discussed in the "upgrade warning() thread" > > > * The discussion with Eric and other users is not a flame-war. The more i > > > modified my code > > > about this feature, > > > the more i thought that even if "[]+a == a" is not "logical", it is > > > very handy, it does not > > > hurt, and it prevents nothing. > > > Removing it compels to add as many if/then/else. And what for? > > > > > > Best regards > > > Samuel > > > > > > > > > _______________________________________________ > > > dev mailing list > > > [email protected] > > > http://lists.scilab.org/mailman/listinfo/dev > > > > > > > > > > > > _______________________________________________ > > dev mailing list > > [email protected] > > http://lists.scilab.org/mailman/listinfo/dev > _______________________________________________ > dev mailing list > [email protected] > http://lists.scilab.org/mailman/listinfo/dev _______________________________________________ dev mailing list [email protected] http://lists.scilab.org/mailman/listinfo/dev
