From clement.david at scilab-enterprises.com Thu Apr 7 10:01:12 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Thu, 07 Apr 2016 10:01:12 +0200 Subject: [Scilab-Dev] [warning()] Extending management mode for a specific message Message-ID: <1460016072.19415.2.camel@scilab-enterprises.com> Hello Scilab devs, hello all, If you track the codereview, you may have notice that I made some warning() modification [1] to centralize warning message management. The idea is to allow a specific message management instead of globally shut off the warnings. Samuel reacted rapidly and I totally agree that it might need to be discussed. Let's copy the first remarks there and continue the discussion. > The "stop" flag has been introduced in quite "urging" circumstances, without (public) discussion. > Yet, it has a meaning completely different? > than for other flags, since it introduces the fact that we can specify a? > "do on warning" action. This is a useful feature, but imo it should be? > extended. It would be much more powerful and used if it was a hook for > any action (pause, whereami, disp("additional info"), etc). It might be a major behavior modification but I am also in favor of such a change, especially I was initially a bit confused about the 'stop' mode that does not map any existing Scilab behavior. The mode management below might be available either globally or for a specific warning. To ease implementation, I suggest to have : ?1. "on"??????: enable a warning ?2. "off"?????: disable it ?3. "error"???: throw an error (previously named "stop") ?4. "pause"???: pause scilab on warning, might be useful to quickly manage them ?5. "execstr" : might execstr an extra argument as Samuel suggested. This might superseed "error"? ? ? ? ? ? ? ? ? or "pause" but is harder to use as it will require an extra argument. > In the same idea, some other languages (i have PHP in mind) have a series? > of warning levels (notices, warning, etc). Managing things in the such a? > way in Scilab would be nice. Yep I am fully aware of such a feature in the Java world [2]. With such concepts everything is an error with an associated level and depending on the display (or logged) level the user might see an error, a warning or just an information. On that point we might also migrate existing functions to manage mode arguments similarly to warning(). AFAIK in Scilab, the following functions might behave similarly : ?error() ?warning() ?// may be disp() or print() but the usage might differ and to manage other (less critical) levels, I only suggest to have logger fonctionnalities in an external toolbox at this time. > Finally, -- may be it is mainly about the documentation -- warning() has? > 1) syntaxes used to trigger already existing actions (standard display,? >????stop), etc, to write in the code ; and > 2) syntaxes that control how Scilab must behave when it meets a warning > These are two clearly distinct sub-sets of instructions. In the help, they > are not clearly separated, and i get quite confused when reading it. > It was not so disturbing when only "on" "off" was available. But it is? > no longer the case. Yep I tried to separate the two concepts : display and special modes ; but with the introduction to specific message targets the initial display feature is lost in the mass. I will update the help to manage that. [1]: https://codereview.scilab.org/#/c/18041 [2]: https://docs.oracle.com/javase/8/docs/api/java/util/logging/Logger.html Thanks for your remarks and request on this topic, -- Cl?ment From clement.david at scilab-enterprises.com Thu Apr 7 10:16:11 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Thu, 07 Apr 2016 10:16:11 +0200 Subject: [Scilab-Dev] [oldEmptyBehaviour()] displaying a warning message in both Scilab 5 and Scilab 6 behavior Message-ID: <1460016971.19415.15.camel@scilab-enterprises.com> 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 ? [1]:?https://codereview.scilab.org/#/c/18044 Thanks for your thought, -- Cl?ment From sgougeon at free.fr Thu Apr 7 22:30:58 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 7 Apr 2016 22:30:58 +0200 Subject: [Scilab-Dev] [oldEmptyBehaviour()] displaying a warning message in both Scilab 5 and Scilab 6 behavior In-Reply-To: <1460016971.19415.15.camel@scilab-enterprises.com> References: <1460016971.19415.15.camel@scilab-enterprises.com> Message-ID: <5706C382.8050705@free.fr> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From grocer.toolbox at gmail.com Thu Apr 7 22:48:13 2016 From: grocer.toolbox at gmail.com (Eric Dubois) Date: Thu, 7 Apr 2016 22:48:13 +0200 Subject: [Scilab-Dev] [oldEmptyBehaviour()] displaying a warning message in both Scilab 5 and Scilab 6 behavior In-Reply-To: <5706C382.8050705@free.fr> References: <1460016971.19415.15.camel@scilab-enterprises.com> <5706C382.8050705@free.fr> Message-ID: 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 <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> 2016-04-07 22:30 GMT+02:00 Samuel Gougeon : > 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 > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Apr 8 01:11:18 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 8 Apr 2016 01:11:18 +0200 Subject: [Scilab-Dev] [warning()] Extending management mode for a specific message In-Reply-To: <1460016072.19415.2.camel@scilab-enterprises.com> References: <1460016072.19415.2.camel@scilab-enterprises.com> Message-ID: <5706E916.4060304@free.fr> Hello (again), Thanks Cl?ment for putting the discussion in the even more public domain :) If i may abstract, *there are 3 distinct topics*: 1. become able to identify each warning() with an id, and then become able to switch it "on" or "off" in a specific targeted way. 2. become able to define which action a triggered warning must do: * up to now, it was only possible to display a message set as warning() input parameter. * warning("stop") tends to make a (specific) warning to stop instead of only displaying a message. Currently, the only difference with error() is that an error() can't be turned off. * we could rather think about a more general "do_on_trigger" action, "stop" being a too specific case that should not be defined as is. 3. Manage graded warning levels instead of a binary "on"|"off" coupled to a set of specific functions "warning()", "error()", ...: notice (mainly information messages) < warning (beware) < error Moreover, *there are 2 distinct types of calls*: 1. *event calls*: these are warning(..) instructions written in the code, where the warning must occur. Presently: * warning(message) : disp(message), and goes on * error(message): disp(message), and stops 2. *setting calls*: these are calls that defines how warning() must behave or provide infos about current settings: 1. presently: warning("on"), warning("off"), warning("query") As you, i think that leveling warning()/error() is a task quite independent from both other topics. But we could anticipate the evolution. I do not think that it should be rejected in an external toolbox, because it's a "central common device" for flow-control. But it could be done later. Would it be complicated to implement it, without respect to existing warning() and error() in all existing codes? What about the proposal https://codereview.scilab.org/#/c/18041/3 ? IMO, * "stop" should really not be introduced. A more general syntax ["do", instructions] should be introduced instead * "stop" or any ["do", instructions] should not be mixed with "on" and "off" flags, because o ["do", instructions] are to be defined in the code where the warning must occur. It replace or "complements" the message ; o whereas "on" or "off" are setting instructions, anywhere (else) in the code * "warningName" is actually the warning's id/tag. But in the page, we don't see any syntax where this tag is defined. From the page, should we understand that the (translated) warning message IS the tag?? If so, i think that the tag must rather be independent from the message, and shall be invariant, whatever is the session language. Actually, calls on events are defined by developers, while settings are done by users. The identification must be common to both sides, so as simple as possible. * Nothing is proposed to query ALL existing tags names and their statuses. So, which prototypes could we dream about? :) * *in the code,on event: warning([level,] { **"my message" | **["do", Scilab_instructions ] } [,"tag", tagName] )* o level : 0, 1, 2: it would be straightforward to support this by opening warning() to overloading for argin#1 not a string. We could have: + 0: notices + 1: alerts + 2: errors + No need to do that in an external module + No back-compatibility issues: errors() would remain in place -- may be undocumented in Scilab 6.x? --, and former errors() calls progressively converted: error(message) => warning(2, message) If is provided, + the next argin can't be "on" or "off" + the next argin could be "query", to query the status of all warning at a given level. But this feature would not be at all a priority. o "do": like a property, would expect the next argin to be a string defining actions to perform (Scilab instruction(s)). So + warning("stop") would rather be something like warning("do","whereami(); error();..") + warning("pause") would rather be warning("do","pause") + warning("do", "disp(""My message"")") would be an equivalent of warning("My message") o otherwise, the text is still considered as the message to be displayed. o "tag": specific string (attribute), expecting tagName in next argin * *as settings*, anywhere: o warning("query"): The overall status for all untagged warnings of level==1 (as now) warning(level, "query"): The overall status for all untagged warnings of the given level. warning( "query","tags"): List existing tags (of all levels), their statuses, and their levels. warning(level, "query","tags"): List existing tags of given level, and their statuses: = filtered output from warning("query","tags") o warning("on"): turn on all tagged or untagged warnings, whatever is their levels warning("on", "tagged"): turn on all tagged warnings, whatever is their levels warning("on", "untagged"): turn on all untagged warnings, whatever is their levels warning("on", "tag", tagName): turn on the given warning o warning("off",...) same things *BUT*: to implement that, a look-up table of warnings shall be set and stored somewhere. This looks similar to the gettext() philosophy: AFAIU, all warning tags shall be harvested when compiling the code. So: a library of macros shall have a new component (in the lib file) = list of warnings tags (and levels) defined in its public and privates functions. * => need to modify genlib(). The new xml format of the "lib" file could have a new xml tag. * => need to modify load() (and/or its duplicate lib()) : to read warning tags from the library and merge them in the overall list. * => need to modify execstr() and deff()... This is a lot of work... Now, i may understand from your proposal that you don't want to go on this way. You might want to define the look-up table of tagNames only from the setting point of view. If so, i am sorry, but i think it is better to not implement this "tag" feature, because it would be hardly usable. The ["do", instructions] feature does not need such a table. It could already be a great improvement, with warning() overloading. By the way: despite the announcement, the localization of functions with gettext()==_() in external modules has never worked: http://bugzilla.scilab.org/13796 Is it because such a "harvest+registering" procedure is actually not yet implemented for gettext() out of Scilab? This opening had not been discussed, and if finally still unavailable. Then, this "warning() discussion" could be the opportunity to implement both (at least for functions. For built-in, how to do?) There were my lengthy thoughts, likely wrong on some aspects. Hope to soon read other contributions, comments, and corrections. Regards Samuel Le 07/04/2016 10:01, Cl?ment David a ?crit : > Hello Scilab devs, hello all, > > If you track the codereview, you may have notice that I made some warning() modification [1] to > centralize warning message management. The idea is to allow a specific message management instead of > globally shut off the warnings. > > Samuel reacted rapidly and I totally agree that it might need to be discussed. Let's copy the first > remarks there and continue the discussion. > >> The "stop" flag has been introduced in quite "urging" circumstances, without (public) discussion. >> Yet, it has a meaning completely different >> than for other flags, since it introduces the fact that we can specify a >> "do on warning" action. This is a useful feature, but imo it should be >> extended. It would be much more powerful and used if it was a hook for >> any action (pause, whereami, disp("additional info"), etc). > It might be a major behavior modification but I am also in favor of such a change, especially I was > initially a bit confused about the 'stop' mode that does not map any existing Scilab behavior. The > mode management below might be available either globally or for a specific warning. To ease > implementation, I suggest to have : > > 1. "on" : enable a warning > 2. "off" : disable it > 3. "error" : throw an error (previously named "stop") > 4. "pause" : pause scilab on warning, might be useful to quickly manage them > 5. "execstr" : might execstr an extra argument as Samuel suggested. This might superseed "error" > or "pause" but is harder to use as it will require an extra argument. > >> In the same idea, some other languages (i have PHP in mind) have a series >> of warning levels (notices, warning, etc). Managing things in the such a >> way in Scilab would be nice. > Yep I am fully aware of such a feature in the Java world [2]. With such concepts everything is an > error with an associated level and depending on the display (or logged) level the user might see an > error, a warning or just an information. On that point we might also migrate existing functions to > manage mode arguments similarly to warning(). > > AFAIK in Scilab, the following functions might behave similarly : > > error() > warning() > // may be disp() or print() but the usage might differ > > and to manage other (less critical) levels, I only suggest to have logger fonctionnalities in an > external toolbox at this time. > > >> Finally, -- may be it is mainly about the documentation -- warning() has >> 1) syntaxes used to trigger already existing actions (standard display, >> stop), etc, to write in the code ; and >> 2) syntaxes that control how Scilab must behave when it meets a warning >> These are two clearly distinct sub-sets of instructions. In the help, they >> are not clearly separated, and i get quite confused when reading it. >> It was not so disturbing when only "on" "off" was available. But it is >> no longer the case. > Yep I tried to separate the two concepts : display and special modes ; but with the introduction to > specific message targets the initial display feature is lost in the mass. I will update the help to > manage that. > > > [1]: https://codereview.scilab.org/#/c/18041 > [2]: https://docs.oracle.com/javase/8/docs/api/java/util/logging/Logger.html > > Thanks for your remarks and request on this topic, > > -- > Cl?ment > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine.monmayrant+scilab at laas.fr Fri Apr 8 08:52:11 2016 From: antoine.monmayrant+scilab at laas.fr (antoine.monmayrant+scilab at laas.fr) Date: Fri, 8 Apr 2016 08:52:11 +0200 Subject: [Scilab-Dev] [oldEmptyBehaviour()] displaying a warning message in both Scilab 5 and Scilab 6 behavior In-Reply-To: References: <1460016971.19415.15.camel@scilab-enterprises.com> <5706C382.8050705@free.fr> Message-ID: <5707551B.4070803@laas.fr> 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 occasionally confuse long time users like my self. I just tried to run a script from one of my colleagues using 5.5.2: operation +: Warning adding a matrix with the empty matrix will give an empty matrix result. operation -: Warning adding a matrix with the empty matrix will give an empty matrix result. operation +: Warning adding a matrix with the empty matrix will give an empty matrix result. operation -: Warning adding a matrix with the empty matrix will give an empty matrix result. ... few 1000 lines ... operation +: Warning adding a matrix with the empty matrix will give an empty matrix result. operation -: Warning adding a matrix with the empty matrix will give an empty matrix result. operation +: Warning adding a matrix with the empty matrix will give an empty matrix result. operation -: Warning adding a matrix with the empty matrix will give an empty matrix result. at line 395 of function plot ( /home/myhome/softs/scilab-6.0.0-beta-1/share/scilab/modules/graphics/macros/plot.sci line 407 ) at line 258 of executed file /home/myhome/mypath/Ngc21_LR_discretes.sce 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 >: > > 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 > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev > > > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From clement.david at scilab-enterprises.com Fri Apr 8 11:13:27 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Fri, 08 Apr 2016 11:13:27 +0200 Subject: [Scilab-Dev] [warning()] Extending management mode for a specific message In-Reply-To: <5706E916.4060304@free.fr> References: <1460016072.19415.2.camel@scilab-enterprises.com> <5706E916.4060304@free.fr> Message-ID: <1460106807.2522.17.camel@scilab-enterprises.com> Hello Samuel and good in depth analysis, To summarize : Le vendredi 08 avril 2016 ? 01:11 +0200, Samuel Gougeon a ?crit?: > Now, i may understand from your proposal that you don't want to go on this way.? > You might want to define the look-up table of tagNames only from the setting point of view. > If so, i am sorry, but i think it is better to not implement this "tag" feature, because it would > be hardly usable. Yep exactly, initially I thought about that "tag" or "simplified message" but discarded it due to the complexity of such a feature and the approaching Scilab 6 release. My need was just to hide the []+"" warning temporarly on some user code to check the tests. > The ["do", instructions] feature does not need such a table. It could already be a great > improvement,? > with warning() overloading. Yep I will try to add that instead of the "stop" feature. The complexity is the same and it will be easier to manage. About the naming, I prefer a "execstr" instead of "do" but it might also be possible to simply pass a function that will be called on warning (similarly to uicontrol's callback). What do you prefer ? -- Cl?ment From clement.david at scilab-enterprises.com Fri Apr 8 12:09:37 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Fri, 08 Apr 2016 12:09:37 +0200 Subject: [Scilab-Dev] [oldEmptyBehaviour()] displaying a warning message in both Scilab 5 and Scilab 6 behavior In-Reply-To: <5706C382.8050705@free.fr> References: <1460016971.19415.15.camel@scilab-enterprises.com> <5706C382.8050705@free.fr> Message-ID: <1460110177.2522.31.camel@scilab-enterprises.com> Hello, (I may not have formulated the current status and my proposal clearly enough) > > 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") ). > 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? > BTW: > * 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? Currently, to remove the warning we have to explicitly write if/then/else code. There is a warning in add and subtract codes on the *normal execution mode* (whatever it is). In my view, this is useful to ease porting but a stable Scilab release should not contain a warning in normal execution mode. In the source code, a warning is present on?: 1. 1+[] 2. 1+[] if oldEmptyBehaviour has been set I want to remove the 1. warning but this might break without warning existing code non-ported code. It currently breaks with a warning. Thanks for asking for clarification, -- Cl?ment From clement.david at scilab-enterprises.com Fri Apr 8 12:32:17 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Fri, 08 Apr 2016 12:32:17 +0200 Subject: [Scilab-Dev] [oldEmptyBehaviour()] displaying a warning message in both Scilab 5 and Scilab 6 behavior In-Reply-To: References: <1460016971.19415.15.camel@scilab-enterprises.com> <5706C382.8050705@free.fr> Message-ID: <1460111537.2522.42.camel@scilab-enterprises.com> Hello Eric, Le jeudi 07 avril 2016 ? 22:48 +0200, Eric Dubois a ?crit?: > 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?? Hmm after questioning?myself, I think that is due to the Scilab 6.0.0 major version nature. We want to push the better into it before the release. I guess the next iteration to 6.1 will be much more focused on new features (added functions) and without existing behavior modification. > Happy to see that at least (and at last) someone does not find compelling the case of changing > this behaviour.? Samuel is not the only one, I am also quiet conservative and my question is only about warning on valid code :). > 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. That's exactly the needed information I requested ! Thanks for writing me that you need more than a beta cycle to migrate your code. Probably other users will also need some time to notice the change and migrate. -- Cl?ment From grocer.toolbox at gmail.com Fri Apr 8 13:37:03 2016 From: grocer.toolbox at gmail.com (=?utf-8?Q?=C3=89ric_Dubois?=) Date: Fri, 8 Apr 2016 13:37:03 +0200 Subject: [Scilab-Dev] [oldEmptyBehaviour()] displaying a warning message in both Scilab 5 and Scilab 6 behavior In-Reply-To: <1460111537.2522.42.camel@scilab-enterprises.com> References: <1460016971.19415.15.camel@scilab-enterprises.com> <5706C382.8050705@free.fr> <1460111537.2522.42.camel@scilab-enterprises.com> Message-ID: <58307607-3F46-4608-ADA3-70F82FEEAD64@gmail.com> Hello Cl?ment As for me, I do not need more time I think: I have made all tests I could do (tests of existing demos, systematic search of declarations of empty matrices and manual exploration of their use in the rest of the code, running programs with empty matrices or with input that could lead to empty matrices every time I could imagine such cases). But I cannot be sure to have solved all potential problems and I am almost sure that some of my users will discover ones. What I wanted to say is that I fear that some users will only discover the problem with the stable 6.0 because they will not bother downloading the beta one (this was my cases when I started using Scilab). This mailing list cannot be representative of the median user! I do not understand why minor changes in "minor" Scilab upgrades should be announced much in advance, while major changes in major Scilab upgrades could be announced with much shorter notice. After all Scilab 6.0 is underway since a very Long Time and you have started communicating and exchanging with users on the major changes a long Time ago: the empty matrix behaviour comes therefore as a last minute surprise that is as odds with all the -virtuous- previous practices. I am not a computer scientist, so maybe I am wrong, but I had the feeling that alpha versions were quasi definitive versions, which were to be modified at the margin, to correct bugs or inappropriate features: the Scilab 6.0.alpha version does not conform to this scheme. More broadly I feel disturbed by this new handling of the project. In the same way, I feel also disturbed by the fact that toolboxes can remain a long Time unpackaged under Atoms, as indicated by Michael Baudin. Scilab remains a great software, and I appreciate the effort made to improve it, but these recent events are not very good signals as regards its future... Regards ?ric (alias Don Quichotte...) Envoy? de mon iPhone > Le 8 avr. 2016 ? 12:32, Cl?ment David a ?crit : > > Hello Eric, > >> Le jeudi 07 avril 2016 ? 22:48 +0200, Eric Dubois a ?crit : >> 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? > > Hmm after questioning myself, I think that is due to the Scilab 6.0.0 major version nature. We want > to push the better into it before the release. I guess the next iteration to 6.1 will be much more > focused on new features (added functions) and without existing behavior modification. > >> Happy to see that at least (and at last) someone does not find compelling the case of changing >> this behaviour. > > Samuel is not the only one, I am also quiet conservative and my question is only about warning on > valid code :). > >> 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. > > That's exactly the needed information I requested ! Thanks for writing me that you need more than a > beta cycle to migrate your code. Probably other users will also need some time to notice the change > and migrate. > > -- > Cl?ment > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From sgougeon at free.fr Fri Apr 8 13:43:18 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 8 Apr 2016 13:43:18 +0200 Subject: [Scilab-Dev] [warning()] Extending management mode for a specific message In-Reply-To: <1460106807.2522.17.camel@scilab-enterprises.com> References: <1460016072.19415.2.camel@scilab-enterprises.com> <5706E916.4060304@free.fr> <1460106807.2522.17.camel@scilab-enterprises.com> Message-ID: <57079956.3030303@free.fr> Hello Cl?ment, Le 08/04/2016 11:13, Cl?ment David a ?crit : > Hello Samuel and good in depth analysis, > > To summarize : > > Le vendredi 08 avril 2016 ? 01:11 +0200, Samuel Gougeon a ?crit : >> Now, i may understand from your proposal that you don't want to go on this way. >> You might want to define the look-up table of tagNames only from the setting point of view. >> If so, i am sorry, but i think it is better to not implement this "tag" feature, because it would >> be hardly usable. > Yep exactly, initially I thought about that "tag" or "simplified message" but discarded it due to > the complexity of such a feature and the approaching Scilab 6 release. My need was just to hide the > []+"" warning temporarly on some user code to check the tests. So, if you keep the feature, and keep it as is, imo it should not be officially documented >> The ["do", instructions] feature does not need such a table. It could already be a great >> improvement, >> with warning() overloading. > Yep I will try to add that instead of the "stop" feature. The complexity is the same and it will be > easier to manage. > > About the naming, I prefer a "execstr" instead of "do" but it might also be possible to simply pass > a function that will be called on warning (similarly to uicontrol's callback). What do you prefer ? Not using "execstr" would keep the warning message mandatory -- possibly empty "": Why not, ok (but then "" would still display the "WARNING:" header, while we could wish to remove it to fully customize the display.). Then, it shall become possible to provide any series of instructions, not only the name of a callback function. Future evolutions and adding argins should not be blocked/made hard due to hard argin list analysis. About the warning level=notices level: i wondered about this recent post on users@ about removing the verbosity of the external modules loading procedure, as an example. (by the way, a "modulesload" common tag would be nice :)) Regards Samuel From sgougeon at free.fr Fri Apr 8 17:31:58 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 8 Apr 2016 17:31:58 +0200 Subject: [Scilab-Dev] Coverage ? <= Re: Release Scilab 6.0.0 alpha 2 In-Reply-To: <1456730201.2803.11.camel@scilab-enterprises.com> References: <565D750D.1060701@laas.fr> <5395ECC5-F84B-4773-AD21-B8E9EBD313DF@scilab-enterprises.com> <56D34983.2080503@free.fr> <1456730201.2803.11.camel@scilab-enterprises.com> Message-ID: <5707CEEE.4040308@free.fr> Hi again, Le 29/02/2016 08:16, Cl?ment David a ?crit : > Hi Samuel, > > .../... > > The dev@ ML is in fact the right place to discuss new features or how to improve things. On the > "coverage" feature especially it has been mainly developed by calixte as a tool to validate its > analysis pass (not as a well as a designed from scratch new feature). > > On the team we asked ourself if we should integrate it or not as it was not in the roadmap for 6.0.0 > but is useful enough to be present. We decided to provide it (as an incomplete dev) ! . As is, one guesses and hopes that the 6.0 roadmap did nor plan to remove code-profiling functions. Yet, former ones have been removed. As soon as some useful functions are removed, shall they not be replaced with some equivalent ones at least as featured and efficient as the former ones? We should even write: _*Before*_ removing any useful features, a replacement at least as good as the former features shall be provided. This does not look like a matter of roadmap, just that no regression should be roadmapped. So, for my part, i sincerely do not understand why there should be any question, among developers, as well as among users, about providing a replacement ASAP, even if it is an experimental version. It shall simply be tagged as experimental, as in the other hand obsolete functions are tagged as is before removal. Unless assessing code's efficiency is considered useless. Could it be so, for a software that claims High Performance Computing capabilities? I don't believe it for one second. On the opposite, it looks like a key module. About new functions themselves, i will post comments later, in a specific thread. Best regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Sat Apr 9 17:34:43 2016 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Sat, 9 Apr 2016 17:34:43 +0200 Subject: [Scilab-Dev] problem with svn.forge.scilab.org access rights In-Reply-To: <56EFD5DB.8050904@utc.fr> References: <1458500116902-4033782.post@n3.nabble.com> <56EF16CB.1060804@utc.fr> <1458557054.2420.12.camel@scilab-enterprises.com> <56EFD5DB.8050904@utc.fr> Message-ID: <57092113.70102@utc.fr> Hello, Do you have a solution for this problem ? I remind you that the settings of the forge svn server are not coherent: when the source is set as "closed' it is not accessible from the project page, but completely visible from the internet via the http://svn.forge.scilab.org/ url. Google indexing the svn tree of my projet... If you don't care with this, I wil have no other solution than hosting the project to another place. Regards, S. Le 21/03/2016 12:07, St?phane Mottelet a ?crit : > Hello, > > Le 21/03/2016 11:44, Cl?ment David a ?crit : >> Hello St?phane, >> >> I checked and after setting the project as "Private project" the HTTP >> server prompt me for a login >> when accessing a URL. Is it what you expect ? > no. I reported the problem because I saw that since a few days Google > is indexing the whole svn tree of my project, although the source (not > the whole project itself) is set as "closed" in the forge > parameters... This is quite confusing ! >> >> AFAIK a project is either open or close ; advanced user rights are >> not taken in account when >> accessing the source code directly. > OK, so you mean that user rights only concern writing rights ? This is > not coherent because when the source is set as "closed' it is not > acessible from the project page, but completely visible from the > internet via the http://svn.forge.scilab.org/ url. > > S. >> >> -- >> Cl?ment >> >> Le dimanche 20 mars 2016 ? 22:31 +0100, St?phane Mottelet a ?crit : >>> Hello, >>> >>> I have a project "Sysmetab" on the forge and although the source tree >>> has been set as visible only for the owner and members of the project, >>> it is visible from anywhere (and anybody) by typing direct urls like >>> >>> http://svn.forge.scilab.org/sysmetab/ >>> >>> I think that all the parameters are correctly set on my side. Can >>> something be fixed on the forge admin side ? >>> >>> Thanks in advance, >>> >>> S. >>> _______________________________________________ >>> dev mailing list >>> dev at lists.scilab.org >>> http://lists.scilab.org/mailman/listinfo/dev >> _______________________________________________ >> dev mailing list >> dev at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/dev > > From diptiiitb17 at gmail.com Mon Apr 11 09:01:55 2016 From: diptiiitb17 at gmail.com (Dipti Ghosalkar) Date: Mon, 11 Apr 2016 12:31:55 +0530 Subject: [Scilab-Dev] Request to post to this list Message-ID: Email id: diptiiitb17 at gmail.com Thanks and Regards, Dipti.G -------------- next part -------------- An HTML attachment was scrubbed... URL: From diptiiitb17 at gmail.com Mon Apr 11 09:08:22 2016 From: diptiiitb17 at gmail.com (diptig) Date: Mon, 11 Apr 2016 00:08:22 -0700 (MST) Subject: [Scilab-Dev] Debugging Scilab's Xcos module on eclipse get crash with error :Minidumps Message-ID: <1460358502081-4033957.post@n3.nabble.com> hi, I am trying to debug Scilab source code using Eclipse by following this link: https://wiki.scilab.org/ScilabWithinEclipse My system specification : Windows 10 (64 bit) Eclipse Mars JDK 1.7 Scilab Source code : 5.2.2 I have created a java class TestXcos to run xcos as follow: public class TestXcos { public static void main(String[] args) { // TODO Auto-generated method stub Xcos.xcos(null, null); } } When I run this file as java application/ debug it as java application , then I'm able to get a xcos palatte window and a new blank window, but when I am executing Xcos example file ( eg. Command.zxos from demo folder present in xcos module of Scilab source code) the application crashes with following error: # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000000b5ae1c5, pid=9240, tid=16068 # # JRE version: Java(TM) SE Runtime Environment (7.0_79-b15) (build 1.7.0_79-b15) # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode windows-amd64 compressed oops) # Problematic frame: # C [api_scilab.dll+0x7e1c5] # # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows # # An error report file with more information is saved as: # C:\Users\Admin\workspace\xcos\hs_err_pid9240.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. Please help me resolve this Thanks in advance -- View this message in context: http://mailinglists.scilab.org/Debugging-Scilab-s-Xcos-module-on-eclipse-get-crash-with-error-Minidumps-tp4033957.html Sent from the Scilab developers - Mailing Lists Archives mailing list archive at Nabble.com. From clement.david at scilab-enterprises.com Mon Apr 11 14:50:18 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Mon, 11 Apr 2016 14:50:18 +0200 Subject: [Scilab-Dev] Request to post to this list In-Reply-To: References: Message-ID: <1460379018.2630.12.camel@scilab-enterprises.com> Hi Dipti and welcome, Everyone can access it, this is an open ML :). Please introduce yourself and do not hesitate to ask questions or post your development on Scilab. -- Cl?ment Le lundi 11 avril 2016 ? 12:31 +0530, Dipti Ghosalkar a ?crit?: > Email id: diptiiitb17 at gmail.com > > Thanks and Regards, > Dipti.G > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From clement.david at scilab-enterprises.com Mon Apr 11 19:43:19 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Mon, 11 Apr 2016 19:43:19 +0200 Subject: [Scilab-Dev] Debugging Scilab's Xcos module on eclipse get crash with error :Minidumps In-Reply-To: <1460358502081-4033957.post@n3.nabble.com> References: <1460358502081-4033957.post@n3.nabble.com> Message-ID: <1460396599.2630.17.camel@scilab-enterprises.com> Hi Diptig and welcome, As xcos use Scilab, you have to load all the scilab libraries if you want to extend it. The ScilabWithinEclipse wiki page explicit that by *connecting* into a running scilab instead of launching a new Scilab process. When starting a simulation or when double-clicking a block, you need to have a running Scilab to perform any computation. Regards, -- Cl?ment Le lundi 11 avril 2016 ? 00:08 -0700, diptig a ?crit?: > hi, > > I am trying to debug Scilab source code using Eclipse by following this > link: https://wiki.scilab.org/ScilabWithinEclipse > My system specification : > Windows 10 (64 bit) > Eclipse Mars > JDK 1.7 > Scilab Source code : 5.2.2 > > I have created a java class TestXcos to run xcos as follow: > public class TestXcos { > ????????public static void main(String[] args) { > ????????????????// TODO Auto-generated method stub > ????????????????Xcos.xcos(null, null); > ????????} > } > > When I run this file as java application/ debug it as java application , > then I'm able to get a xcos palatte window and a new blank window, but when > I am executing Xcos example file ( eg. Command.zxos from demo folder present > in xcos module of Scilab source code) the application crashes with following > error: > > > # A fatal error has been detected by the Java Runtime Environment: > # > #??EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000000b5ae1c5, > pid=9240, tid=16068 > # > # JRE version: Java(TM) SE Runtime Environment (7.0_79-b15) (build > 1.7.0_79-b15) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode > windows-amd64 compressed oops) > # Problematic frame: > # C??[api_scilab.dll+0x7e1c5] > # > # Failed to write core dump. Minidumps are not enabled by default on client > versions of Windows > # > # An error report file with more information is saved as: > # C:\Users\Admin\workspace\xcos\hs_err_pid9240.log > # > # If you would like to submit a bug report, please visit: > #???http://bugreport.java.com/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > > > Please help me resolve this > Thanks in advance > > > > > > -- > View this message in context: http://mailinglists.scilab.org/Debugging-Scilab-s-Xcos-module-on-ecl > ipse-get-crash-with-error-Minidumps-tp4033957.html > Sent from the Scilab developers - Mailing Lists Archives mailing list archive at Nabble.com. > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From sgougeon at free.fr Mon Apr 11 21:07:55 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Mon, 11 Apr 2016 21:07:55 +0200 Subject: [Scilab-Dev] [a, b, c] = list(%pi, %i, %t, "Text")(:) anomaly Message-ID: <570BF60B.7020105@free.fr> Hello Scilab Team, I am wondering about the following: L = list(%pi, %i, %t, "Text"); // Then [a, b, c] = L(:) // works, while [a, b, c] = list(%pi, %i, %t, "Text")(:) // doesn't: --> [a, b, c] = list(%pi, %i, %t, "Text")(:) list: Wrong number of output argument(s): 1 expected. Is it the expected behavior? Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Tue Apr 12 13:36:18 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Tue, 12 Apr 2016 13:36:18 +0200 Subject: [Scilab-Dev] and(%nan) ==%T Message-ID: <570CDDB2.5050805@free.fr> Hello, I am wondering about the following answers: --> s = %nan; --> or(s) ans = F --> and(s) ans = T With this last answer, we have a case such that although all entries are false -- otherwiseor() would answer %T--, and()applied to them is True. Is there a reason for that, or is it a bug? This behavior was already present in Scilab 4.1.2 and is still here in Scilab 6.0-b1 Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Tue Apr 12 13:59:12 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Tue, 12 Apr 2016 13:59:12 +0200 Subject: [Scilab-Dev] or(%nan) ==%F ? In-Reply-To: <570CDDB2.5050805@free.fr> References: <570CDDB2.5050805@free.fr> Message-ID: <570CE310.4050209@free.fr> Le 12/04/2016 13:36, Samuel Gougeon a ?crit : > Hello, > > I am wondering about the following answers: > > --> s = %nan; > --> or(s) > ans = > F > > --> and(s) > ans = > T > > With this last answer, we have a case such that although all entries > are false -- otherwiseor() would answer %T--, and()applied to them is > True. > > Is there a reason for that, or is it a bug? > > This behavior was already present in Scilab 4.1.2 and is still here in > Scilab 6.0-b1 . The title of my post was and(%nan)==%T, while the strange thing is rather that or(%nan)==%F. Indeed, s being a real with unknown value, prob(s==0)/prob(s~=0) = 0, in such a way that or(%nan) should rather be %T -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Apr 13 17:33:50 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 13 Apr 2016 17:33:50 +0200 Subject: [Scilab-Dev] or(%nan) ==%F ? In-Reply-To: <570CE310.4050209@free.fr> References: <570CDDB2.5050805@free.fr> <570CE310.4050209@free.fr> Message-ID: <570E66DE.7020303@free.fr> Le 12/04/2016 13:59, Samuel Gougeon a ?crit : > .../... > The title of my post was and(%nan)==%T, while the strange thing is > rather that or(%nan)==%F. > Indeed, s being a real with unknown value, > prob(s==0)/prob(s~=0) = 0, in such a way that or(%nan) should rather be %T No comment that could support this behavior.. => or(%nan)==%F is posted as a bug @ http://bugzilla.scilab.org/14522 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Apr 13 20:43:05 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 13 Apr 2016 20:43:05 +0200 Subject: [Scilab-Dev] uiwait() Message-ID: <570E9339.4090007@free.fr> Hello Scilab devs, uiwait() is a builtin used once and only in the function datatipCreatePopupMenu(). Apparently, it is used to wait for an answer from the user/Context menu before returning. Can this function be used for other uicontrols? I mean: it would be useful to be able to turn modal some (any?) ui object, for instance waiting for a button being clicked, for an item in a drop-down list to be selected, etc, before going on with the processing. This function is not documented. Is it on purpose? Can it be used only on a uiContextMenu handle? Thanks for any further information. Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Thu Apr 14 00:20:37 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 14 Apr 2016 00:20:37 +0200 Subject: [Scilab-Dev] uiwait() In-Reply-To: <570E9339.4090007@free.fr> References: <570E9339.4090007@free.fr> Message-ID: <570EC635.4010701@free.fr> Le 13/04/2016 20:43, Samuel Gougeon a ?crit : > Hello Scilab devs, > > uiwait() is a builtin used once and only in the function > datatipCreatePopupMenu(). > Apparently, it is used to wait for an answer from the user/Context > menu before returning. > > Can this function be used for other uicontrols? > I mean: it would be useful to be able to turn modal some (any?) ui object, > for instance waiting for a button being clicked, for an item in a > drop-down > list to be selected, etc, before going on with the processing. > > This function is not documented. Is it on purpose? Can it be used only on > a uiContextMenu handle? A trial answers: --> uiwait(gca()) uiwait: Wrong type for input argument #1: A 'Uicontextmenu' handle expected. A pity. By the way, datatipCreatePopupMenu() seems to be some dead code, with some other SCI\modules\graphics\macros\datatips\* macros. SG -------------- next part -------------- An HTML attachment was scrubbed... URL: From clement.david at scilab-enterprises.com Thu Apr 14 15:04:29 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Thu, 14 Apr 2016 15:04:29 +0200 Subject: [Scilab-Dev] [oldEmptyBehaviour()] displaying a warning message in both Scilab 5 and Scilab 6 behavior In-Reply-To: <5707551B.4070803@laas.fr> References: <1460016971.19415.15.camel@scilab-enterprises.com> <5706C382.8050705@free.fr> <5707551B.4070803@laas.fr> Message-ID: <1460639069.2921.53.camel@scilab-enterprises.com> 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, antoine.monmayrant+scilab at laas.fr 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 : > > > 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 > > > dev at lists.scilab.org > > > http://lists.scilab.org/mailman/listinfo/dev > > > > > > > > > > > > _______________________________________________ > > dev mailing list > > dev at lists.scilab.org > > http://lists.scilab.org/mailman/listinfo/dev > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From diptiiitb17 at gmail.com Mon Apr 18 07:41:34 2016 From: diptiiitb17 at gmail.com (diptig) Date: Sun, 17 Apr 2016 22:41:34 -0700 (MST) Subject: [Scilab-Dev] Request to post to this list In-Reply-To: <1460379018.2630.12.camel@scilab-enterprises.com> References: <1460379018.2630.12.camel@scilab-enterprises.com> Message-ID: Hi, My name is Dipti Ghosalkar and I'm working as software engineer under FOSSEE Project in IIT Bombay. I'm a java programmer and I'm trying to make some changes in xcos UI which is written java swing. For which I'm trying to dedug scilab source code by following link : https://wiki.scilab.org/ScilabWithinEclipse but I'm getting stuck at a point as mention in post : http://mailinglists.scilab.org/Debugging-Scilab-s-Xcos-module-on-eclipse-get-crash-with-error-Minidumps-td4033957.html And thanks for your reply on same. Thanks and Regards, Dipti.G On Mon, Apr 11, 2016 at 6:20 PM, Cl?ment David-2 [via Scilab / Xcos - Mailing Lists Archives] wrote: > Hi Dipti and welcome, > > Everyone can access it, this is an open ML :). Please introduce yourself > and do not hesitate to ask > questions or post your development on Scilab. > > -- > Cl?ment > > Le lundi 11 avril 2016 ? 12:31 +0530, Dipti Ghosalkar a ?crit : > > Email id: [hidden email] > > > > > Thanks and Regards, > > Dipti.G > > _______________________________________________ > > dev mailing list > > [hidden email] > > http://lists.scilab.org/mailman/listinfo/dev > _______________________________________________ > dev mailing list > [hidden email] > http://lists.scilab.org/mailman/listinfo/dev > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://mailinglists.scilab.org/Request-to-post-to-this-list-tp4033956p4033960.html > To start a new topic under Scilab developers - Mailing Lists Archives, > email ml-node+s994242n2574944h99 at n3.nabble.com > To unsubscribe from Scilab / Xcos - Mailing Lists Archives, click here > > . > NAML > > -- View this message in context: http://mailinglists.scilab.org/Request-to-post-to-this-list-tp4033956p4033992.html Sent from the Scilab developers - Mailing Lists Archives mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From diptiiitb17 at gmail.com Tue Apr 19 11:36:21 2016 From: diptiiitb17 at gmail.com (diptig) Date: Tue, 19 Apr 2016 02:36:21 -0700 (MST) Subject: [Scilab-Dev] Debugging Scilab's Xcos module on eclipse get crash with error :Minidumps In-Reply-To: <1460396599.2630.17.camel@scilab-enterprises.com> References: <1460358502081-4033957.post@n3.nabble.com> <1460396599.2630.17.camel@scilab-enterprises.com> Message-ID: <1461058581239-4034002.post@n3.nabble.com> Hi Cl?ment, Thanks for your reply.. I have loaded the libraries of scilab. I have also attached a screenshot of the path for libraries. As you mentioned also tried to perform computation within running scilab process. But, unfortunately still it crashes. For your convenience I have also attached two more screenshots. Image1 Main code for invoking xcos Image 2 environment variable path for running scilab Image 3 xcos window Image 4 error encountered after pressing start button. Please, let me know if I am missing something. Thanks Dipti -- View this message in context: http://mailinglists.scilab.org/Debugging-Scilab-s-Xcos-module-on-eclipse-get-crash-with-error-Minidumps-tp4033957p4034002.html Sent from the Scilab developers - Mailing Lists Archives mailing list archive at Nabble.com. From sgougeon at free.fr Tue Apr 19 13:09:44 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Tue, 19 Apr 2016 13:09:44 +0200 Subject: [Scilab-Dev] slint() : remarks and suggestions Message-ID: <571611F8.20402@free.fr> Hello devs, The so-called /slint /module is a new experimental tool proposed and somewhat documented in Scilab master: http://www.scilab.org/fr/development/nightly_builds/master Scilab 6.0-b1 did not yet include it. slint is a Scilab code checker. The Scilab community has not been involved to design it, i mean beyond the CNES (as likely the customer havingordered for it). S/E is planning to include slint into Scilab. Due to this possible inclusion in Scilab, that would make slint() distributed to all users, i would like to make some remarks and suggestions about this module, as i would like a lot reading other comments from other users and developers about this module. Below i will focus on some aspects about slint() "interfaces" (prototypes, data formats), since interfaces turn rather locked after the first publication (wherever it is published, in Scilab or on ATOMS). I have not made deep tests about the current parser / slint engine, and beyond some unit tests about a subset of split code checks, i did not see any code sample gathering all features presently checked by slint(). 1. *In Scilab, or a complementary module* ? slint is not specific to any type or area of applications, since it is dedicated to Scilab code "qualification", whatever is the purpose of the code. However, it is a rather specific development tool, clearly oriented to developers working on "high standards". It is more about computing sciences than for engineering and prototyping. In its "/Scilab development/" category, ATOMS already proposes other development-specific modules -- that are tagged /Complementary/, such as /Scibench/, or /assert/. /assert/ in now included in Scilab, since it is used by almost all non-regression tests that are as well included (whether they aren't unchecked in Scilab's installer). /slint/ is somewhat another module for benchmarking, but applied to the code style and syntax, instead of to the code speed. IMO, it would not be shocking to put it only on ATOMS as a complementary module, and/or to leave the user decide through Scilab's installer if he/she wants to install it by default. 2. *slint's name: slint?* I am not convinced by this module name and (unique) function name. It does not clearly tell what it does. Should we guess that "s" stand for /S/cilab (if so, is it worthwhile to remind it?), and lint for code-washing residues? Here are some suggestions: codeCheck(), codeDiagn(), codeQualify(), codeValidate(), codeWash()... codeCheck() or codecheck() would look the most appropriate to me. By the way, slint's pages talk about /checking/ rules. 3. *Syntaxes* The current slint() help page shows the following: Calling Sequence slint(files [, conf, out]) slint(files [, out]) out = slint(files [, conf], print) Arguments files a matrix of strings, the .sci files or the directories to analyze. conf a scalar string, the name of the configuration file (by default it's SCI/modules/slint/etc/slint.xml). out a scalar string, the name of the output file. print a scalar boolean, if true the result is printed else the result is a struct. out a struct (if print is false). Description slint has been written to check the "quality" of the Scilab's code according to configurable rules. Examples slint("SCI/modules/elementary_functions/macros/atanm.sci"); *Remarks*: * slint() application to .sce scripts is not documented. Is this usage possible? Is it already runnable? * slint() application to compiled Scilab functions is not possible or documented. Yet, as for profiling tools, this kind of input would be handy. * print = %f should rather be the default. %T is currently the default. For boolean variables, for my own i try to use or document variables names with a final "?" => "print?", to remind that they are boolean. BTW, it is here "disp?" rather than "print?". Just a matter of documentation. * The /out/ structure of results o can be as well an input parameter. This usage is quite unexpected and is not explained. o Fields and organization of the structure is not documented. But running the example provides some insight to it: --> slint("SCI/modules/elementary_functions/macros/atanm.sci"); In SCI\modules\elementary_functions\macros\atanm.sci: At l. 0, c. 0: 00015: Maximum line length exceeded at lines: 24, 28, 35. At l. 24, c. 15: 00029: A function argument must be preceded by a single space. At l. 24, c. 15: 00029: A function argument must be preceded by a single space. At l. 27, c. 8: 00028: Operator <> should be surrounded by single spaces. At l. 28, c. 15: 00029: A function argument must be preceded by a single space. At l. 28, c. 15: 00029: A function argument must be preceded by a single space. At l. 31, c. 8: 00028: Operator == should be surrounded by single spaces. ... At l. 45, c. 7: 00028: Operator / should be surrounded by single spaces. At l. 45, c. 7: 00028: Operator * should be surrounded by single spaces. At l. 45, c. 7: 00033: Expression is not bracketed. At l. 47, c. 12: 00028: Operator == should be surrounded by single spaces. At l. 47, c. 29: 00028: Operator = should be surrounded by single spaces. Module developed with the contribution of CNES. And by grabbing the output in a variable and canceling the printing-in-console: --> results = slint("SCI/modules/elementary_functions/macros/atanm.sci", %f) results = file: [1x1 string] info: [1x1 struct] --> results.file ans = SCI\modules\elementary_functions\macros\atanm.sci --> results.info ans = 00029: [8x1 struct] 00015: [1x1 struct] 00028: [17x1 struct] 00009: [1x1 struct] 00033: [3x1 struct] --> results.info("00033").loc ans = ans(1) 39. 22. 39. 34. ans(2) 39. 22. 39. 26. ans(3) 45. 7. 45. 28. --> results.info("00033").msg ans = ans(1) Expression is not bracketed. ans(2) Expression is not bracketed. ans(3) Expression is not bracketed. *Comments and suggestions*: 1. imo, this structure for the results looks uselessly complicated, and finally inefficient. It makes choosing how to filter and view results very difficult: + the "info" field could be renamed "results". Its contents are for example not "contextual or configuration infos". To be clearer, they are results. + this .results field could rather be a simple list, with as many components as there are analyzed files. + Each .result(i) component could rather be a matrix of text. If a file has fully passed checkings, its results are []. The matrix would have the following columns: # line number (ideally with leading 0 to make lexicographical and numerical orders matching) # column number (idem) # checker id # message # file basename (with the file extension, but without the path) # file id (# rank in the list of files), converted into text + *Finally, wondering about all what is written here-above, i think that removing the splitting between .fileS and .results (.info) fields would even be preferable. * *A single matrix of text would be much simpler and more efficient*. To do so, for each new file, its full path shall be recorded in the results matrix, in the /message/ column, with the code-row=0, code-colum=0, checker-id=00000, given file basename and rank#. It would be much easier to filter and sort according to any column or multicolumn sorting. Very easy to record in a .csv file ; etc. Very easy to reimport, to compare or merge with other files ; to make statistics with that ; etc. All things very hard to do with the current structure. 2. The present structure is so rigid and unhandy that it prevents basic filtering operations (like for instance relisting results (out of console) in the order of rows of code in the file). By the way -- but this has no importance, since the structure should rather be abandoned --, 1. *id of checkers* starting with a digit prevents using the .dot field addressing. Why not prefixing them with a letter (say "r" as "rule" or "c" as "criteria")? 2. *.loc* field is a list. Yet, its components have all the same types and sizes, in such a way that they could rather be stored in rows of a matrix. This would allow filtering operations with find(). 3. *.msg* field: same remark: a matrix of text would be more handy. * *Checking rules look not to be categorized*. Yet, some rules are "only" about the code style, some others about deprecated or removed features, etc. Presently, it is not easy to filter results by type of "lint". We must somewhat look at all lints or at none or at some specific ids. For instance, if i want to use an external module and before i want to assess its runnability, i won't care about its code style (i am not the author, and i don't want to spend time on the code style of an external module), and i would wish to get and fix all deprecated or removed features in a straightforward way. To do so, defining subsets and tagging checkers in them would be handy. * Presently, slint() does not allow o to *provide a **Scilab version against which the Scilab code must be checked*. o to provide a subset of rules (or categories of rules) that must be checked, instead of checking all defined rules. 4. *Documentation pages*. The 40 pages about checkers (checking criteria/rules), with for most of them only half-a-line of description, and nothing else, and nothing more expected, made me deeply wondering: which reviewer has accepted that, and who has accepted to merge that? For instance, if we spam in the same way the help tree just by splitting the /axes_properties/ page in 40 distinct pages, with one property per page, do we have a chance on review to be accepted and merged? This way of doing is shocking. By the way, i have searched these 40 pages on GIT/master to propose merging them (in a table, even more suitable than in a variablelist), but i did not find them. Quite strange. Hoping to read other comments soon. BR Samuel Gougeon -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Tue Apr 19 15:14:04 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Tue, 19 Apr 2016 15:14:04 +0200 Subject: [Scilab-Dev] slint() : remarks and suggestions In-Reply-To: <571611F8.20402@free.fr> References: <571611F8.20402@free.fr> Message-ID: <57162F1C.1010204@free.fr> Le 19/04/2016 13:09, Samuel Gougeon a ?crit : > > 1. .../... > > > Calling Sequence > > slint(files [, conf, out]) slint(files [, out]) out = slint(files > [, conf], print) > > > Arguments > > files > a matrix of strings, the .sci files or the directories to > analyze. > conf > a scalar string, the name of the configuration file (by > default it's SCI/modules/slint/etc/slint.xml). > out > a scalar string, the name of the output file. > print > a scalar boolean, if true the result is printed else the > result is a struct. > out > a struct (if print is false). > > .../... > 2. > > > 3. The /out/ structure of results > * can be as well an input parameter. This usage is quite > unexpected and is not explained. > Actually both usages are briefly documented. It should not be too costy to choose more explicit and distinct names... SG -------------- next part -------------- An HTML attachment was scrubbed... URL: From clement.david at scilab-enterprises.com Wed Apr 20 18:49:29 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Wed, 20 Apr 2016 18:49:29 +0200 Subject: [Scilab-Dev] Debugging Scilab's Xcos module on eclipse get crash with error :Minidumps In-Reply-To: <1461058581239-4034002.post@n3.nabble.com> References: <1460358502081-4033957.post@n3.nabble.com> <1460396599.2630.17.camel@scilab-enterprises.com> <1461058581239-4034002.post@n3.nabble.com> Message-ID: <1461170969.8298.7.camel@scilab-enterprises.com> Hi Dipti, Could you send me the 'hs_err_pid*.log' file please ? On modern JVM it will contain a backtrace with mixed Java / native call stack. This is really useful to track mis-behavior. Thanks, -- Cl?ment Le mardi 19 avril 2016 ? 02:36 -0700, diptig a ?crit?: > Hi Cl?ment, > > Thanks for your reply.. > > I have loaded the libraries of scilab. I have also attached a screenshot of > the path for libraries. > > As you mentioned also tried to perform computation within running scilab > process. > > But, unfortunately still it crashes. > > For your convenience I have also attached two more screenshots. > > Image1 > > Main code for invoking xcos > > ? > > Image 2 > > environment variable path for running scilab > > ? > > Image 3 > > xcos window > > ? > > Image 4 > > error encountered after pressing start button. > > ? > > > Please, let me know if I am missing something. > > Thanks > Dipti > > ?? > > > > -- > View this message in context: http://mailinglists.scilab.org/Debugging-Scilab-s-Xcos-module-on-ecl > ipse-get-crash-with-error-Minidumps-tp4033957p4034002.html > Sent from the Scilab developers - Mailing Lists Archives mailing list archive at Nabble.com. > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From clement.david at scilab-enterprises.com Wed Apr 20 19:26:10 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Wed, 20 Apr 2016 19:26:10 +0200 Subject: [Scilab-Dev] uiwait() In-Reply-To: <570EC635.4010701@free.fr> References: <570E9339.4090007@free.fr> <570EC635.4010701@free.fr> Message-ID: <1461173170.8298.23.camel@scilab-enterprises.com> Hi Samuel, Le jeudi 14 avril 2016 ? 00:20 +0200, Samuel Gougeon a ?crit?: > Le 13/04/2016 20:43, Samuel Gougeon a ?crit?: > > Hello Scilab devs, > > > > uiwait() is a builtin used once and only in the function datatipCreatePopupMenu(). > > Apparently, it is used to wait for an answer from the user/Context menu before returning. > > > > Can this function be used for other uicontrols? > > I mean: it would be useful to be able to turn modal some (any?) ui object, > > for instance waiting for a button being clicked, for an item in a drop-down? > > list to be selected, etc, before going on with the processing. > > > > This function is not documented. Is it on purpose? Can it be used only on > > a uiContextMenu handle? > ?A trial answers: > --> uiwait(gca()) > > uiwait: Wrong type for input argument #1: A 'Uicontextmenu' handle expected. > > A pity. > By the way, datatipCreatePopupMenu() seems to be some dead code, > with some other SCI\modules\graphics\macros\datatips\* macros. Hmm do you mean that we might block scilab, waiting for axes / figure deletion ? currently this is not the case as both uicontrols callbacks and the console push commands to the Scilab queue. Blocking the Scilab execution thread will deadlock them. Currently such a management might be done in Scilab using a `while %t` loop managing some `get_click()` return value. >From the user point of view, indeed it might be useful to let the user implements a complex modal dialog using uicontrols with ease (this call might just hide a `while %t` loop). IMHO we might also implement the matlab behavior [1] with : uiresume() and waitfor() (or uiwaitfor() ). [1]:?http://fr.mathworks.com/help/matlab/ref/uiwait.html Thanks for the idea, could you open a bug to track it ? -- Cl?ment From clement.david at scilab-enterprises.com Wed Apr 20 19:31:01 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Wed, 20 Apr 2016 19:31:01 +0200 Subject: [Scilab-Dev] [oldEmptyBehaviour()] displaying a warning message in both Scilab 5 and Scilab 6 behavior In-Reply-To: <1460110177.2522.31.camel@scilab-enterprises.com> References: <1460016971.19415.15.camel@scilab-enterprises.com> <5706C382.8050705@free.fr> <1460110177.2522.31.camel@scilab-enterprises.com> Message-ID: <1461173461.8298.27.camel@scilab-enterprises.com> Hello all, Le vendredi 08 avril 2016 ? 12:09 +0200, Cl?ment David a ?crit?: > Hello, > > (I may not have formulated the current status and my proposal clearly enough) > > > > > > > > > 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") ). > > > > 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? > > > > BTW: > > * 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? > Currently, to remove the warning we have to explicitly write if/then/else code. There is a warning > in add and subtract codes on the *normal execution mode* (whatever it is). In my view, this is > useful to ease porting but a stable Scilab release should not contain a warning in normal > execution > mode. > > In the source code, a warning is present on?: > > 1. 1+[] > 2. 1+[] if oldEmptyBehaviour has been set > > I want to remove the 1. warning but this might break without warning existing code non-ported > code. > It currently breaks with a warning. Just to keep you informed : at the team meeting we decided to keep the warning for the 6.0.0 release to ease porting. We will remove it on a future release soon or later depending on the feedbacks. Thanks for all your inputs, it helped us when perform the warning removal. -- Cl?ment From clement.david at scilab-enterprises.com Wed Apr 20 19:35:41 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Wed, 20 Apr 2016 19:35:41 +0200 Subject: [Scilab-Dev] [warning()] Extending management mode for a specific message In-Reply-To: <57079956.3030303@free.fr> References: <1460016072.19415.2.camel@scilab-enterprises.com> <5706E916.4060304@free.fr> <1460106807.2522.17.camel@scilab-enterprises.com> <57079956.3030303@free.fr> Message-ID: <1461173741.8298.31.camel@scilab-enterprises.com> Hi Samuel, hi all, > > Le vendredi 08 avril 2016 ? 01:11 +0200, Samuel Gougeon a ?crit : > > > > > > Now, i may understand from your proposal that you don't want to go on this way. > > > You might want to define the look-up table of tagNames only from the setting point of view. > > > If so, i am sorry, but i think it is better to not implement this "tag" feature, because it > > > would > > > be hardly usable. > > Yep exactly, initially I thought about that "tag" or "simplified message" but discarded it due > > to > > the complexity of such a feature and the approaching Scilab 6 release. My need was just to hide > > the > > []+"" warning temporarly on some user code to check the tests. > > So, if you keep the feature, and keep it as is, imo it should not be? > officially documented > > > > > > > > > The ["do", instructions] feature does not need such a table. It could already be a great > > > improvement, > > > with warning() overloading. > > Yep I will try to add that instead of the "stop" feature. The complexity is the same and it will > > be > > easier to manage. > > > > About the naming, I prefer a "execstr" instead of "do" but it might also be possible to simply > > pass > > a function that will be called on warning (similarly to uicontrol's callback). What do you > > prefer ? > Not using "execstr" would keep the warning message mandatory -- possibly? > empty "": Why not, ok > (but then "" would still display the "WARNING:" header, while we could? > wish to remove it to fully > customize the display.). > Then, it shall become possible to provide any series of instructions,? > not only the name of a callback function. > > Future evolutions and adding argins should not be blocked/made hard due? > to hard argin list analysis. > > About the warning level=notices level: i wondered about this recent post? > on users@ about removing > the verbosity of the external modules loading procedure, as an example.? > (by the way, a "modulesload" > common tag would be nice :)) As we are near the release, we decided to postpone this change after Scilab 6.0.0. I will also try to implement a nice tag (or keyword) management to ease warning management (both in scilab and toolboxes). ? And also I have to write a SEP on it ;). -- Cl?ment From diptiiitb17 at gmail.com Thu Apr 21 08:21:15 2016 From: diptiiitb17 at gmail.com (diptig) Date: Wed, 20 Apr 2016 23:21:15 -0700 (MST) Subject: [Scilab-Dev] Debugging Scilab's Xcos module on eclipse get crash with error :Minidumps In-Reply-To: <1461170969.8298.7.camel@scilab-enterprises.com> References: <1460358502081-4033957.post@n3.nabble.com> <1460396599.2630.17.camel@scilab-enterprises.com> <1461058581239-4034002.post@n3.nabble.com> <1461170969.8298.7.camel@scilab-enterprises.com> Message-ID: <1461219675672-4034009.post@n3.nabble.com> Hi Clement, This is the file which was created during crash. hs_err_pid30084.log Thanks, Dipti -- View this message in context: http://mailinglists.scilab.org/Debugging-Scilab-s-Xcos-module-on-eclipse-get-crash-with-error-Minidumps-tp4033957p4034009.html Sent from the Scilab developers - Mailing Lists Archives mailing list archive at Nabble.com. From clement.david at scilab-enterprises.com Thu Apr 21 09:10:19 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Thu, 21 Apr 2016 09:10:19 +0200 Subject: [Scilab-Dev] Debugging Scilab's Xcos module on eclipse get crash with error :Minidumps In-Reply-To: <1461219675672-4034009.post@n3.nabble.com> References: <1460358502081-4033957.post@n3.nabble.com> <1460396599.2630.17.camel@scilab-enterprises.com> <1461058581239-4034002.post@n3.nabble.com> <1461170969.8298.7.camel@scilab-enterprises.com> <1461219675672-4034009.post@n3.nabble.com> Message-ID: <1461222619.2332.2.camel@scilab-enterprises.com> Hi Diptig, It seems that you might not have started Scilab. Did you use any javasci API to start a Scilab process behind the scene ? -- Cl?ment Le mercredi 20 avril 2016 ? 23:21 -0700, diptig a ?crit?: > Hi Clement, > > This is the file which was created during crash. > > hs_err_pid30084.log > ?? > > > Thanks, > > Dipti > > > > > -- > View this message in context: http://mailinglists.scilab.org/Debugging-Scilab-s-Xcos-module-on-ecl > ipse-get-crash-with-error-Minidumps-tp4033957p4034009.html > Sent from the Scilab developers - Mailing Lists Archives mailing list archive at Nabble.com. > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From diptiiitb17 at gmail.com Thu Apr 21 12:28:18 2016 From: diptiiitb17 at gmail.com (diptig) Date: Thu, 21 Apr 2016 03:28:18 -0700 (MST) Subject: [Scilab-Dev] Debugging Scilab's Xcos module on eclipse get crash with error :Minidumps In-Reply-To: <1461222619.2332.2.camel@scilab-enterprises.com> References: <1460358502081-4033957.post@n3.nabble.com> <1460396599.2630.17.camel@scilab-enterprises.com> <1461058581239-4034002.post@n3.nabble.com> <1461170969.8298.7.camel@scilab-enterprises.com> <1461219675672-4034009.post@n3.nabble.com> <1461222619.2332.2.camel@scilab-enterprises.com> Message-ID: <1461234498830-4034011.post@n3.nabble.com> Hi Clement, I didn't use any javasci API to start a Scilab process behind the scene. But once I have try this : I changed my class to call javasci API first and then calling Xcos function. try { Scilab sci = new Scilab(); sci.open(); Xcos.xcos("C:/Scilab/SCI_SRC/modules/xcos/demos/Bouncing_ball.zcos",null); } catch (JavasciException e) { // TODO Auto-generated catch block e.printStackTrace(); } In this case it shows a message saying "Simulation in progress" and nothing happens after that and it remains in this state only. You can see in image below: Thanks, Dipti -- View this message in context: http://mailinglists.scilab.org/Debugging-Scilab-s-Xcos-module-on-eclipse-get-crash-with-error-Minidumps-tp4033957p4034011.html Sent from the Scilab developers - Mailing Lists Archives mailing list archive at Nabble.com. From antoine.monmayrant+scilab at laas.fr Mon Apr 25 08:55:18 2016 From: antoine.monmayrant+scilab at laas.fr (antoine.monmayrant+scilab at laas.fr) Date: Mon, 25 Apr 2016 08:55:18 +0200 Subject: [Scilab-Dev] slint() : remarks and suggestions In-Reply-To: <571611F8.20402@free.fr> References: <571611F8.20402@free.fr> Message-ID: <571DBF56.3050703@laas.fr> Le 04/19/2016 01:09 PM, Samuel Gougeon a ?crit : > Hello devs, > > The so-called /slint /module is a new experimental tool proposed and > somewhat documented in Scilab master: > http://www.scilab.org/fr/development/nightly_builds/master > Scilab 6.0-b1 did not yet include it. slint is a Scilab code checker. > > The Scilab community has not been involved to design it, i mean beyond > the CNES (as likely the customer havingordered for it). S/E is > planning to include slint into Scilab. > > Due to this possible inclusion in Scilab, that would make slint() > distributed to all users, i would like to make some remarks and > suggestions about this module, as i would like a lot reading other > comments from other users and developers about this module. > Below i will focus on some aspects about slint() "interfaces" > (prototypes, data formats), since interfaces turn rather locked after > the first publication (wherever it is published, in Scilab or on > ATOMS). I have not made deep tests about the current parser / slint > engine, and beyond some unit tests about a subset of split code > checks, i did not see any code sample gathering all features presently > checked by slint(). > > 1. *In Scilab, or a complementary module* ? > slint is not specific to any type or area of applications, since > it is dedicated to Scilab code "qualification", whatever is the > purpose of the code. > However, it is a rather specific development tool, clearly > oriented to developers working on "high standards". It is more > about computing sciences than for engineering and prototyping. > In its "/Scilab development/" category, ATOMS already proposes > other development-specific modules -- that are tagged > /Complementary/, such as /Scibench/, or /assert/. /assert/ in now > included in Scilab, since it is used by almost all non-regression > tests that are as well included (whether they aren't unchecked in > Scilab's installer). /slint/ is somewhat another module for > benchmarking, but applied to the code style and syntax, instead of > to the code speed. IMO, it would not be shocking to put it only on > ATOMS as a complementary module, and/or to leave the user decide > through Scilab's installer if he/she wants to install it by default. > > 2. *slint's name: slint?* > I am not convinced by this module name and (unique) function name. > It does not clearly tell what it does. Should we guess that "s" > stand for /S/cilab (if so, is it worthwhile to remind it?), and > lint for code-washing residues? > Here are some suggestions: codeCheck(), codeDiagn(), > codeQualify(), codeValidate(), codeWash()... codeCheck() or > codecheck() would look the most appropriate to me. By the way, > slint's pages talk about /checking/ rules. > Hi, That's maybe the only point where I feel competent enough to make a remark. The name is not really self-explanatory. I first though it was related to some exotic version of Integer "SpecialLengthINTeger", "SuperLightINTeger". "codecheck" or "checkrules" or even "checkcoderules" would be way more explicit. Antoine > > 1. > > > 2. *Syntaxes* > The current slint() help page shows the following: > > > Calling Sequence > > slint(files [, conf, out]) slint(files [, out]) out = slint(files > [, conf], print) > > > Arguments > > files > a matrix of strings, the .sci files or the directories to > analyze. > conf > a scalar string, the name of the configuration file (by > default it's SCI/modules/slint/etc/slint.xml). > out > a scalar string, the name of the output file. > print > a scalar boolean, if true the result is printed else the > result is a struct. > out > a struct (if print is false). > > > Description > > slint has been written to check the "quality" of the Scilab's code > according to configurable rules. > > > Examples > > slint("SCI/modules/elementary_functions/macros/atanm.sci"); > > *Remarks*: > * slint() application to .sce scripts is not documented. Is this > usage possible? Is it already runnable? > > * slint() application to compiled Scilab functions is not > possible or documented. Yet, as for profiling tools, this kind > of input would be handy. > > * print = %f should rather be the default. %T is currently the > default. For boolean variables, for my own i try to use or > document variables names with a final "?" => "print?", to > remind that they are boolean. BTW, it is here "disp?" rather > than "print?". Just a matter of documentation. > > * The /out/ structure of results > o can be as well an input parameter. This usage is quite > unexpected and is not explained. > > o Fields and organization of the structure is not > documented. But running the example provides some insight > to it: > --> > slint("SCI/modules/elementary_functions/macros/atanm.sci"); > In SCI\modules\elementary_functions\macros\atanm.sci: > At l. 0, c. 0: 00015: Maximum line length exceeded at > lines: 24, 28, 35. > At l. 24, c. 15: 00029: A function argument must be > preceded by a single space. > At l. 24, c. 15: 00029: A function argument must be > preceded by a single space. > At l. 27, c. 8: 00028: Operator <> should be surrounded > by single spaces. > At l. 28, c. 15: 00029: A function argument must be > preceded by a single space. > At l. 28, c. 15: 00029: A function argument must be > preceded by a single space. > At l. 31, c. 8: 00028: Operator == should be surrounded > by single spaces. > ... > At l. 45, c. 7: 00028: Operator / should be surrounded > by single spaces. > At l. 45, c. 7: 00028: Operator * should be surrounded > by single spaces. > At l. 45, c. 7: 00033: Expression is not bracketed. > At l. 47, c. 12: 00028: Operator == should be surrounded > by single spaces. > At l. 47, c. 29: 00028: Operator = should be surrounded > by single spaces. > Module developed with the contribution of CNES. > > And by grabbing the output in a variable and canceling the > printing-in-console: > > --> results = > slint("SCI/modules/elementary_functions/macros/atanm.sci", %f) > results = > file: [1x1 string] > info: [1x1 struct] > > --> results.file > ans = > SCI\modules\elementary_functions\macros\atanm.sci > > --> results.info > ans = > 00029: [8x1 struct] > 00015: [1x1 struct] > 00028: [17x1 struct] > 00009: [1x1 struct] > 00033: [3x1 struct] > > --> results.info("00033").loc > ans = > ans(1) > 39. 22. > 39. 34. > > ans(2) > 39. 22. > 39. 26. > > ans(3) > 45. 7. > 45. 28. > > --> results.info("00033").msg > ans = > ans(1) > Expression is not bracketed. > > ans(2) > Expression is not bracketed. > > ans(3) > Expression is not bracketed. > > *Comments and suggestions*: > 1. imo, this structure for the results looks uselessly > complicated, and finally inefficient. It makes > choosing how to filter and view results very difficult: > + the "info" field could be renamed "results". Its > contents are for example not "contextual or > configuration infos". To be clearer, they are results. > + this .results field could rather be a simple list, > with as many components as there are analyzed files. > + Each .result(i) component could rather be a matrix > of text. If a file has fully passed checkings, its > results are []. > The matrix would have the following columns: > # line number (ideally with leading 0 to make > lexicographical and numerical orders matching) > # column number (idem) > # checker id > # message > # file basename (with the file extension, but > without the path) > # file id (# rank in the list of files), > converted into text > > + *Finally, wondering about all what is written > here-above, i think that removing the splitting > between .fileS and .results (.info) fields would > even be preferable. * > *A single matrix of text would be much simpler and > more efficient*. To do so, for each new file, its > full path shall be recorded in the results matrix, > in the /message/ column, with the code-row=0, > code-colum=0, checker-id=00000, given file > basename and rank#. > It would be much easier to filter and sort > according to any column or multicolumn sorting. > Very easy to record in a .csv file ; etc. Very > easy to reimport, to compare or merge with other > files ; to make statistics with that ; etc. All > things very hard to do with the current structure. > > 2. The present structure is so rigid and unhandy that it > prevents basic filtering operations (like for instance > relisting results (out of console) in the order of > rows of code in the file). > By the way -- but this has no importance, since the > structure should rather be abandoned --, > 1. *id of checkers* starting with a digit prevents > using the .dot field addressing. Why not prefixing > them with a letter (say "r" as "rule" or "c" as > "criteria")? > > 2. *.loc* field is a list. Yet, its components have > all the same types and sizes, in such a way that > they could rather be stored in rows of a matrix. > This would allow filtering operations with find(). > > 3. *.msg* field: same remark: a matrix of text would > be more handy. > > * *Checking rules look not to be categorized*. Yet, some rules > are "only" about the code style, some others about deprecated > or removed features, etc. > Presently, it is not easy to filter results by type of "lint". > We must somewhat look at all lints or at none or at some > specific ids. For instance, if i want to use an external > module and before i want to assess its runnability, i won't > care about its code style (i am not the author, and i don't > want to spend time on the code style of an external module), > and i would wish to get and fix all deprecated or removed > features in a straightforward way. To do so, defining subsets > and tagging checkers in them would be handy. > > * Presently, slint() does not allow > o to *provide a **Scilab version against which the Scilab > code must be checked*. > o to provide a subset of rules (or categories of rules) that > must be checked, instead of checking all defined rules. > > 3. *Documentation pages*. > The 40 pages about checkers (checking criteria/rules), with for > most of them only half-a-line of description, and nothing else, > and nothing more expected, made me deeply wondering: which > reviewer has accepted that, and who has accepted to merge that? > For instance, if we spam in the same way the help tree just by > splitting the /axes_properties/ page in 40 distinct pages, with > one property per page, do we have a chance on review to be > accepted and merged? > This way of doing is shocking. > By the way, i have searched these 40 pages on GIT/master to > propose merging them (in a table, even more suitable than in a > variablelist), but i did not find them. Quite strange. > > > Hoping to read other comments soon. > BR > > Samuel Gougeon > > > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Mon Apr 25 22:43:32 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Mon, 25 Apr 2016 22:43:32 +0200 Subject: [Scilab-Dev] slint() : remarks and suggestions In-Reply-To: <571611F8.20402@free.fr> References: <571611F8.20402@free.fr> Message-ID: <571E8174.8050708@free.fr> Hello, Here are some additional remarks about the "conf" configuration file, and the file of results: Le 19/04/2016 13:09, Samuel Gougeon a ?crit : > .../... > > * Presently, slint() does not allow > o to *provide a **Scilab version against which the Scilab > code must be checked*. > o to provide a subset of rules (or categories of rules) that > must be checked, instead of checking all defined rules. > . * Apparently, the so-called "configuration" file is somewhat used to that, but it's rather unhandy: to set a set of rules, we have to edit the conf file, to turn enable="true"into enable="false"for each rule that we want to cancel (or the opposite), to save modifications, and then call slint() with the file as "conf" parameter... instead of directly passing the vector of rules indices, or a vector of text ids (case-insensitive, please) such as ["uselessarg" "FunctionName" "redefinition"], or a vector of ids of rules subsets. Rather cumbersome. * The format of the file of results is not documented. It is an XML file. Why has this encoding been chosen? XML is for parsers rather than for humans -- whereas a CSV is directly readable --, but here for which parser? Nothing is told about how to process/update/upgrade input files using results. Is there anything planned, for instance with Scinotes that could use input files and XMLed results to edit files and highlight parts to be updated, or even to automate the upgrade? If nothing is presently planned in such a way, imo encoding results in CSV would be better. Best regards Samuel Gougeon -------------- next part -------------- An HTML attachment was scrubbed... URL: From clement.david at scilab-enterprises.com Tue Apr 26 11:54:01 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Tue, 26 Apr 2016 11:54:01 +0200 Subject: [Scilab-Dev] LONG TIME EXECUTION tests timeout duration ? Message-ID: <1461664441.2525.9.camel@scilab-enterprises.com> Hello Scilab devs, To ease http://build.scilab.org tests management, I introduced a new developer options that avoid a test/scilab lock [1]. It basically kill the Scilab process used by each test after a timeout and thus clarify the LONG TERM EXECUTION tag. FYI we have another watchdog (either provided by jenkins or bash scripting) that kill each module testing after a fixed amount of time but this is an hard to tweak settings. In the past, we spend so much time trying to track modules issues whereas tests issues are more fine-grained. I initially fixed the duration at 15 minutes per test if not tagged LONG TERM EXECUTION. After a team meeting, we decided to change to a 5 minutes limit. Does it seems OK on your side ? [1]: https://codereview.scilab.org/#/c/18106/ Thanks for your inputs, -- Cl?ment From sgougeon at free.fr Sat Apr 30 20:17:52 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 30 Apr 2016 20:17:52 +0200 Subject: [Scilab-Dev] New profiling module (code coverage) Message-ID: <5724F6D0.9030502@free.fr> Hello, This message continues in a separate thread the discussion opened @ http://mailinglists.scilab.org/Release-Scilab-6-0-0-alpha-2-tp4033142p4033143.html It aims to test and assess interfaces of the new Scilab code /coverage/ module, that has been implemented without any Scilab Enhancement Proposal. This module aims to replace profiling functions that are removed in Scilab 6: * add_profiling() => covStart() * reset_profiling() => no equivalent * remove_profiling() => covStop() * profile() => no equivalent * showprofile() => no equivalent * plotprofile() => abandoned (actually, without displaying the lines of code, it was hardly useful) -------------------- * *"c**o**v**...**" naming*: "cov" rather makes thinking about /cov/ariance rather than coverage, "code coverage" being an expression quite specific to software engineering. It is not explicit for users that would simply want to test and benchmark the code of their "macros". *"codebench()*" is suggested as an alternative name of a unique function, with an action parameter: *codebench("start" ...)*, codebench("write",..) etc. By the way, replacing former profiling functions needs as well to replace their *timing feature* (cumulated time spent to run each line of code), not only their coverage one (the number of times that each line has been run). So, the same profiling function should go beyond coverage, without implementing extra specific functions. *Time counters* have been implemented : https://codereview.scilab.org/#/c/16397/ Timing features look to be already available in Scilab 6.0-b1, despite this commit hereabove has not yet been included in the distrib. Strange. * *add_profiling() / covStart(paths)*: o *covStart("isempty") does**not work* (and does not yield any error message), contrarily to what /help covStart/ tells. It should work. Currently, only /covStart(isempty)/ is able to yields results. Profiling functions shall be as well console-oriented: input arguments of text type should be accepted as well, like with former profiling functions. o *covStart(libraryname)* allows to set a whole library for profiling. This is an improvement. With the former add_profiling(), it was only possible to set functions one by one. But: --> covStart(differential_equationlib) covStart: Wrong type for input argument #1: A two-columns string matrix expected. The documentation is not consistent with this requirement. And this requirement is not consistent neither with the function case (as isempty hereabove), nor with the following (that is accepted):. --> covStart differential_equationlib --> By the way, after that, no results are produced with covWrite(..) (see below). o *c**ovStart(paths)*: Since it is now possible to provide a file path instead of a function name, we could think that it becomes possible to get as well the /profile of scripts/ out of functions. However, from first tests, nothing is produced by covWrite("html",".") when the covStart() has been applied only to some scripts. The fact that scripts.sce are excluded should be explicitly documented, unless profiling is extended to them. * * * *covWri**t**e(..)*: o showprofile(fun ) has no replacement:*.* + Displaying profiling results in the console is no longer possible. 95% of time, i used to use this way to get and read results. It was the most handy. It allowed to have the code edited in Scinotes and related profiling scores displayed in the console aside. Now, we have to switch between the web browser and Scilab's IDE (since results can now be displayed only in HTML, after having found the right file of results and clicked on it...) . Display in console was straightforward and efficient, to improve the code "on-the-fly", without to have to manage any HTML files. *imo, this limitation to HTML is **a critical regression*. + covWrite(..)outputs results in HTML /after/ each line of code, instead of before each line number: *This is a blocking regression*. It prevents any use of new profiling functions. This trivial bug #12807 was as well for a long time somewhat killing showprofile(). It is back. Why? Imagine that you manufacture suitcases, but the designer has put the handle under them, between their wheels. Currently, covWrite() is somewhat in this status. See attached uman.html.zip, and please tell me where is the handle. + outputs from covWrite() are unclear/undocumented (see attached file, from the covWrite basic example): # items in the header are not clearly defined: instrs, coverage rates, .. # Both percentages for each line have no legend # Color codes (red/black) have no legend # red "x 0" on some lines have no legend # Spent times are displayed with an irrelevant relative accuracy (too many digits) o c = profile(fun) has no replacement: + It was possible to get results in a matrix of text c. It is no longer the case. *This is a medium regression*. + It was possible to get the profile of a single chosen function (or of a subset of them with a for loop) among all ones set for profiling. It is no longer the case: We are now compelled either to overwrite all previous results in the same given destination directory, or to create a new destination directory containing all results each time that we want new results for a single function among all profiled ones.*This is a major regression. * o *covWrite() does**not work on a library*: covStop(); covStart("differential_equationlib"); // then run examples from inttrap(), integrate() and intc() help pages covWrite("html", ".") // produces only a ./report.html file that is empty. * reset_profiling() has no replacement: It is no longer possible to reset counters of a chosen function or of a set of chosen functions. To do so, stopping and restarting *all of them* is now mandatory. * remove_profiling(fun) / *covStop()*: o In one hand, remove_profiling(fun) did not allow to stop profiling of all profiled functions. This was unhandy. covStop() allows this. This is nice. o In the other hand, covStop() does not allow to stop profiling for a single function or a file or an explicit set of files or a library. The only way to stop profiling is now to stop it for *all* "started" functions. It could be disturbing if profiling a function makes it slower, or covWrite() cannot export resuls for a subset of "started" functions. But does profiling a function make it slower? Tests to be done. IMO, covWrite() and covStop(..) shall have the same input modes as allowed with covStart(). * Neither binary files of results nor covMerge() that processes them have been tested. When simpler usages will work... ----------------- *Partial (and personal) conclusions:* * Removed profiling functions need replacements. * The new profiling module has been designed without SEP. Just matching features of former profiling functions would not have needed any SEP. But this is not the situation at all. The new module is clearly not ready. It is hardly an alpha release. Other tests, comments and users opinions are somewhat needed and welcome. Regards Samuel Gougeon -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: uman.html.zip Type: application/x-zip-compressed Size: 34585 bytes Desc: not available URL: