From sgougeon at free.fr Sat Feb 2 18:09:44 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 2 Feb 2019 18:09:44 +0100 Subject: [Scilab-Dev] test_run: <-- REOPENED --> status, vs <-- NOT FIXED --> Message-ID: Hello, In the code of test_run(), we can observe that the detection of a tag "<-- REOPENED -->" is implemented. Yet, such a tag is not documented. In addition, no such tag can be found in all existing Scilab tests. I am documenting the versioning of the "<-- NOT FIXED -->" tag. And i am wondering about this "REOPENED" tag whether it must be documented as well or not. Is it an old tag undocumented after deprecation but not removed from test_run for compatibility reason? Or is it a dark feature that deserves being actually documented? Or is it a dark feature that was just a trial and that should be removed from the code? Any hint would be helpful about the status of this tag, and its role wrt other ones, noticeably wrt the "NOT FIXED" tag. Thanks Samuel From sgougeon at free.fr Sat Feb 2 18:28:13 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 2 Feb 2019 18:28:13 +0100 Subject: [Scilab-Dev] listfiles() output is in anti-alphabetical order Message-ID: Hello, Seeing that --> test_run graphics bug_3* TMPDIR = C:\path\SCI_TMP_3556_28568 001/065 - [graphics] bug_3999................................passed 002/065 - [graphics] bug_3991................................passed 003/065 - [graphics] bug_3975................................passed ... processes entries in anti-alphabetical order, and analysing it, i have found that listfiles() does the same since at least Scilab 4.1.2. In the listfiles() code, there is the instruction filesi = filesi($:-1:1); post-processing the output from findfile(). May be this reversing was formerly needed after findfiles() whether findfiles() had this reversed order. Such an effect was recently detected in linspace(), where the compensation of a wrong upstream order had not been canceled after fixing the upstream order. Or maybe it was for another reason. By now, as far as we can test it, removing this reordering does not yield any trouble and makes listfiles() output more expected. Does anyone know a reason for this reversion? Does anyone have an objection against making listfiles() yielding its result in alphabetical order, as more expected? Thanks Samuel PS: If anyone could spend some time to build a unique full-featured file-listing function replacing and extending listfiles() + findfiles() + ls() + dir().., i would vote for such a more radical solution. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Sat Feb 2 19:32:28 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 2 Feb 2019 19:32:28 +0100 Subject: [Scilab-Dev] test_run: new tag "<-- BROKEN --> by {#bug_id of breaking bug]" Message-ID: <12f5f493-5049-d79a-6907-661ee42415c5@free.fr> Hello, I am wondering about the processing of any unitary or non-regression test that fails not because the bug that it tests is back, but because another external bug breaks the code of the test. This is currently the case for instance for test_run graphics datatipSetDisplay test_run graphics bug_10298 test_run cacsd bug_13359 test_run cacsd bug_15827 that all are broken by the bug 15790 . Currently, we tend to reopen these tests with the "<-- NOT FIXED -->" tag. But this processing is not really fair. It is rather puzzling. As a general policy, i am not in favour of multiplying the number of available tags. However, what about creating a new one to point this situation? It could be // <-- BROKEN --> by 15790 Such a test would be skipped, and in the test_run report, "skipped: broken by 15790" would be displayed. What do you think about this proposal? Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Sat Feb 2 19:40:50 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 2 Feb 2019 19:40:50 +0100 Subject: [Scilab-Dev] test_run: new tag "<-- BROKEN --> by {#bug_id of breaking bug]" In-Reply-To: <12f5f493-5049-d79a-6907-661ee42415c5@free.fr> References: <12f5f493-5049-d79a-6907-661ee42415c5@free.fr> Message-ID: <1034be68-9bc9-55f6-73dc-3e8d12ac0007@free.fr> Le 02/02/2019 ? 19:32, Samuel Gougeon a ?crit : > > As a general policy, i am not in favour of multiplying the number of > available tags. > However, what about creating a new one to point this situation? > It could be > // <-- BROKEN --> by 15790 > Such a test would be skipped, and in the test_run report, "skipped: > broken by 15790" would be displayed. > Another processing could be: the test is run anyway. Then, * if it passes: "passed. No longer broken by 15790" is displayed. This would focus on the fact that the test's header must be updated. * otherwise: "failed: broken by 15790" is displayed This would focus on fixing the bug 15790. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Feb 6 03:27:42 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 6 Feb 2019 03:27:42 +0100 Subject: [Scilab-Dev] varn([]) changed In-Reply-To: References: <0c7c011b-e48a-1a72-1029-db0bacfb0b12@free.fr> <0511d8b9-7db0-4333-de0f-fba5cf7e5e1c@scilab-enterprises.com> <5a96f936-7450-f8bd-b03f-9307ebac90c7@scilab-enterprises.com> Message-ID: <7fcbf4c0-3ab9-0005-9c7f-052fbc38a2f7@free.fr> Le 15/01/2019 ? 11:31, Samuel Gougeon a ?crit : > .../... > Then, in order to avoid useless errors, the new implementation > varn([]) => [] > is rather handy. I don't see any trap that it could yield. This change is now documented. From sgougeon at free.fr Wed Feb 6 04:16:57 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 6 Feb 2019 04:16:57 +0100 Subject: [Scilab-Dev] get(h_matrix, prop) changed from 5.5.2 to 6.0.0, inconsistent in both cases Message-ID: <3f1bdf43-dbc7-e12b-6694-ddec1fb53170@free.fr> Hello, In preparation to Scilab 6.0.2, some unitary or non-regression tests about graphics and GUI show some changes about the format of some properties: test_run graphics plot2d_demo show_error test_run graphics plot_demo show_error test_run graphics bug_14042 show_error test_run gui layer show_error The first fixes simply propose to update the .dia.ref with the transpose of properties values (e.g. https://codereview.scilab.org/#/c/20768 ) However, the analysis shows that the behavior of get(), that is also called from %h_e(), changed from Scilab 5.5.2 to Scilab 6.0.0. In both cases, and up to now, the size of the *get(h, prop)* output is not consistent when h is a vector of handles. In *5.5.2*:, the output is always a row: -->plot(); -->f = gcf(); Axes = f.children Axes = 2 by 1 matrix of handles: ========================= Axes Axes -->get(Axes, "visible") ans = !on on ! -->get(Axes*'*, "visible") ans = !on on ! In *6.0.0* and up to now (6.0.2-), the output is always a column: --> f = gcf(); Axes = f.children Axes = 2 by 1 matrix of handles: ========================= Axes Axes --> get(Axes, "visible") ans = !on ! !on ! --> get(Axes*'*, "visible") ans = !on ! !on ! To me, the default size of the output should match the size of the matrix of handles. Shouldn't it? When the value of the property is not scalar, it is the user's responsability to reshape the matrix of handles in a way that is compatible with the purpose. Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Wed Feb 6 08:14:04 2019 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Wed, 6 Feb 2019 08:14:04 +0100 Subject: [Scilab-Dev] get(h_matrix, prop) changed from 5.5.2 to 6.0.0, inconsistent in both cases In-Reply-To: <3f1bdf43-dbc7-e12b-6694-ddec1fb53170@free.fr> References: <3f1bdf43-dbc7-e12b-6694-ddec1fb53170@free.fr> Message-ID: <1cfe9b24-bc40-3204-6233-1f4923cca1f9@utc.fr> Hello, Le 06/02/2019 ? 04:16, Samuel Gougeon a ?crit?: > > Hello, > > In preparation to Scilab 6.0.2, some unitary or non-regression tests > about graphics and GUI show some changes about the format of some > properties: > > test_run graphics plot2d_demo show_error > test_run graphics plot_demo show_error > test_run graphics bug_14042 show_error > test_run gui layer show_error > > The first fixes simply propose to update the .dia.ref with the > transpose of properties values > (e.g. https://codereview.scilab.org/#/c/20768 ) > > However, the analysis shows that the behavior of get(), that is also > called from %h_e(), > changed from Scilab 5.5.2 to Scilab 6.0.0. > > In both cases, and up to now, the size of the *get(h, prop)* output is > not consistent when h is a vector of handles. > > In *5.5.2*:, the output is always a row: > -->plot(); > -->f = gcf(); Axes = f.children > ?Axes? = > 2 by 1 matrix of handles: > ========================= > Axes > Axes > > -->get(Axes, "visible") > ?ans? = > !on? on? ! > -->get(Axes*'*, "visible") > ?ans? = > !on? on? ! > > In *6.0.0* and up to now (6.0.2-), the output is always a column: > > --> f = gcf(); Axes = f.children > ?Axes? = > 2 by 1 matrix of handles: > ========================= > Axes > Axes > > --> get(Axes, "visible") > ?ans? = > !on? ! > !on? ! > --> get(Axes*'*, "visible") > ?ans? = > !on? ! > !on? ! > > To me, the default size of the output should match the size of the > matrix of handles. > > Shouldn't it? > > When the value of the property is not scalar, it is the user's > responsability to > reshape the matrix of handles in a way that is compatible with the > purpose. > Sometimes the user does not even know how to resize if the values do not have the same size: plot(1:2,sin(1:2));plot(1:3,cos(1:3)); h=gca().children.children.data ?h? = ?? 1.?? 0.5403023 ?? 2.? -0.4161468 ?? 3.? -0.9899925 ?? 1.?? 0.841471 ?? 2.?? 0.9092974 a cell array would be more handy: ?ans? = ? [3x2 constant] ? [2x2 constant] S. > Regards > > Samuel > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Feb 6 08:48:22 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 6 Feb 2019 08:48:22 +0100 Subject: [Scilab-Dev] get(h_matrix, prop) changed from 5.5.2 to 6.0.0, inconsistent in both cases In-Reply-To: <1cfe9b24-bc40-3204-6233-1f4923cca1f9@utc.fr> References: <3f1bdf43-dbc7-e12b-6694-ddec1fb53170@free.fr> <1cfe9b24-bc40-3204-6233-1f4923cca1f9@utc.fr> Message-ID: <5b22e838-a36d-77f8-3086-d3b88dad451b@free.fr> Le 06/02/2019 ? 08:14, St?phane Mottelet a ?crit : > > Hello, > > Le 06/02/2019 ? 04:16, Samuel Gougeon a ?crit : >> >> Hello, >> >> In preparation to Scilab 6.0.2, some unitary or non-regression tests >> about graphics and GUI show some changes about the format of some >> properties: >> >> test_run graphics plot2d_demo show_error >> test_run graphics plot_demo show_error >> test_run graphics bug_14042 show_error >> test_run gui layer show_error >> >> The first fixes simply propose to update the .dia.ref with the >> transpose of properties values >> (e.g. https://codereview.scilab.org/#/c/20768 ) >> >> However, the analysis shows that the behavior of get(), that is also >> called from %h_e(), >> changed from Scilab 5.5.2 to Scilab 6.0.0. >> >> In both cases, and up to now, the size of the *get(h, prop)* output >> is not consistent when h is a vector of handles. >> >> In *5.5.2*:, the output is always a row: >> -->plot(); >> -->f = gcf(); Axes = f.children >> Axes = >> 2 by 1 matrix of handles: >> ========================= >> Axes >> Axes >> >> -->get(Axes, "visible") >> ans = >> !on on ! >> -->get(Axes*'*, "visible") >> ans = >> !on on ! >> >> In *6.0.0* and up to now (6.0.2-), the output is always a column: >> >> --> f = gcf(); Axes = f.children >> Axes = >> 2 by 1 matrix of handles: >> ========================= >> Axes >> Axes >> >> --> get(Axes, "visible") >> ans = >> !on ! >> !on ! >> --> get(Axes*'*, "visible") >> ans = >> !on ! >> !on ! >> >> To me, the default size of the output should match the size of the >> matrix of handles. >> >> Shouldn't it? >> >> When the value of the property is not scalar, it is the user's >> responsability to >> reshape the matrix of handles in a way that is compatible with the >> purpose. >> > Sometimes the user does not even know how to resize if the values do > not have the same size: > It is always possible to split get(H,prop) with an external loop in case of heterogeneous sizes of the set of H(i).prop. This is still the user's responsability. But many properties have a scalar value. For instance, gcf() has 27 scalar properties over 33. gca() has 35 scalar properties over 61. etc This is why imho, /by default/, concatenating ouputs according to the H size would be more handy. Best regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Feb 6 08:53:42 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 6 Feb 2019 08:53:42 +0100 Subject: [Scilab-Dev] listfiles() output is in anti-alphabetical order In-Reply-To: References: Message-ID: Le 02/02/2019 ? 18:28, Samuel Gougeon a ?crit : > > Hello, > > Seeing that > > --> test_run graphics bug_3* > TMPDIR = C:\path\SCI_TMP_3556_28568 > > 001/065 - [graphics] bug_3999................................passed > 002/065 - [graphics] bug_3991................................passed > 003/065 - [graphics] bug_3975................................passed > ... > > processes entries in anti-alphabetical order, and analysing it, i have > found that listfiles() does the same since at least Scilab 4.1.2. In > the listfiles() code, there is the instruction > filesi = filesi($:-1:1); > post-processing the output from findfile(). > > May be this reversing was formerly needed after findfiles() whether > findfiles() had this reversed order. > Such an effect was recently detected in linspace(), where the > compensation of a wrong upstream order had not been canceled after > fixing the upstream order. > Or maybe it was for another reason. By now, as far as we can test it, > removing this reordering does not yield any trouble and makes > listfiles() output more expected. > > Does anyone know a reason for this reversion? > Does anyone have an objection against making listfiles() yielding its > result in alphabetical order, as more expected? > > Thanks > Samuel This sorting issue is now reported as bug 15955 . By the way, paths in the output list may mix relative and absolute ones. This somewhat breaks any attempt to sort the whole output list in a relevant way. This is reported as bug 15956 . Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Clement.David at esi-group.com Thu Feb 14 17:31:30 2019 From: Clement.David at esi-group.com (=?iso-8859-1?Q?Cl=E9ment_David?=) Date: Thu, 14 Feb 2019 16:31:30 +0000 Subject: [Scilab-Dev] test_run: <-- REOPENED --> status, vs <-- NOT FIXED --> In-Reply-To: References: Message-ID: Hello Samuel, After a deep dive into Scilab source code, it seems that this REOPENED tag has been introduced (or re-introduced) in 91c98ab05 [1]. It seems used to tag a nonreg test as not fixed when the bug reappears. As none of the tests is using it, this might be removed. [1]: http://cgit.scilab.org/scilab/commit/?h=6.0&id=91c98ab05 -- Cl?ment -----Original Message----- From: dev On Behalf Of Samuel Gougeon Sent: Saturday, February 2, 2019 6:10 PM To: List dedicated to development questions Subject: [Scilab-Dev] test_run: <-- REOPENED --> status, vs <-- NOT FIXED --> Hello, In the code of test_run(), we can observe that the detection of a tag "<-- REOPENED -->" is implemented. Yet, such a tag is not documented. In addition, no such tag can be found in all existing Scilab tests. I am documenting the versioning of the "<-- NOT FIXED -->" tag. And i am wondering about this "REOPENED" tag whether it must be documented as well or not. Is it an old tag undocumented after deprecation but not removed from test_run for compatibility reason? Or is it a dark feature that deserves being actually documented? Or is it a dark feature that was just a trial and that should be removed from the code? Any hint would be helpful about the status of this tag, and its role wrt other ones, noticeably wrt the "NOT FIXED" tag. Thanks Samuel _______________________________________________ dev mailing list dev at lists.scilab.org http://lists.scilab.org/mailman/listinfo/dev From Clement.David at esi-group.com Thu Feb 14 17:35:24 2019 From: Clement.David at esi-group.com (=?iso-8859-1?Q?Cl=E9ment_David?=) Date: Thu, 14 Feb 2019 16:35:24 +0000 Subject: [Scilab-Dev] Scilab 6.0.2 is now shipped Message-ID: Dear Scilab devs, Thanks to our efforts, Scilab 6.0.2 is available! This second revision of the 6.0 branch fixes up to 305 bugs and implements missing features from the 5.5.2 version. Some commits are still in review in the 6.0 branch but they will probably be moved to the master branch in the next few days. If you find any critical issue or instability that might need a 6.0.x release please alert us. Our next target is 6.1.0 with new features and improvements for our users. This long road trip is not defined yet if you have ideas, suggestions and even code for some features please contribute via a Scilab Enhancement Proposal or by emailing us directly. For the complete list of changes and bugs fixed, please take a look at the CHANGES file. -- Cl?ment From sgougeon at free.fr Fri Feb 15 11:51:37 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 15 Feb 2019 11:51:37 +0100 Subject: [Scilab-Dev] Bugzilla : "Nightly" & "regression" keywords Message-ID: <9ae82229-5824-0a12-c466-8c27b9995549@free.fr> Hello devs, I would like to make public some thoughts about some usages on Bugzilla. Presently, for each new Scilab release, two version tags must be created: say "6.0.2" and "6.0.2 nightly & dev" or "6.1.0 master". Then, what to do with the former "6.0.1 nightly & devs" ? * Still open reports should be retagged 6.0.2 ? * and resolved ones be retagged "6.0.1" * and finally the "6.0.1 nightly & devs" be completely removed. When accumulated over versions, the "nightly & devs" tags are duplicates, and all this stuff does not increase bugs management wrt Scilab versions. The main issue there is that "/nightly & devs/" does *not* define a version. It is just a tag for /any /version. This is why, IMHO /"Nightly & dev" should be defined as a Bugzilla "Keyword"/. The user's attention can be brought on it in the "Version"'s tooltip, by updating the tip : By the way, IMO another new Keyword -- "*/Regression/*" is missing. It would be very usefull as well. Looking forward to reading you, Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nciphligflenmflk.png Type: image/png Size: 6182 bytes Desc: not available URL: From sgougeon at free.fr Wed Feb 20 18:02:01 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 20 Feb 2019 18:02:01 +0100 Subject: [Scilab-Dev] Bad merge 6.0.2 => master ?! Message-ID: Hello, With the master, --> [v,o]=getversion() o = !VC++ x64 tk release Feb 15 2019 17:35:24 ! v = scilab-branch-master I was trying to use the edit() feature --> edit linspace 45 merged in the master in May 2018, and already used in the master. But it is no longer available! Editing edit.sci shows that the feature has been overwritten with the former edit.sci version! So, what happened ?? Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Feb 20 18:45:26 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 20 Feb 2019 18:45:26 +0100 Subject: [Scilab-Dev] Bad merge 6.0.2 => master ?! In-Reply-To: References: Message-ID: Le 20/02/2019 ? 18:02, Samuel Gougeon a ?crit : > Hello, > > With the master, > > --> [v,o]=getversion() > o = > !VC++ x64 tk release Feb 15 2019 17:35:24 ! > v = > scilab-branch-master > > I was trying to use the edit() feature > > > --> edit linspace 45 > > merged in the master in May 2018, and already used in the master. > But it is no longer available! > Editing edit.sci shows that the feature has been overwritten with the > former edit.sci version! > > So, what happened ?? checkout on a Merge remote-tracking branch 'origin/6.0' restores the right code base, as CR20665 on 2018-12-17 or as CR20856 on 2019-02-15 15:55 while checkout on Merge origin/6.0 into master shows the former old code, as CR20835 on 2019-02-15 14:29 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Feb 20 19:03:31 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 20 Feb 2019 19:03:31 +0100 Subject: [Scilab-Dev] Wrong footer for online help Message-ID: <88857586-8fa9-d59b-46d9-e2ec38b838fc@free.fr> Dear Scilab devs, The footer of all online help pages for Scilab 6.0.2 is outdated: The ESI copyright for the 2017-2019 period is missing, and Scilab enterprises is still displayed as the editor: I am afraid that the related template is not public -- and so can't be fixed by contributors --, since the template GIT/modules/helptools/data/template/template_web.html or template_web.html do not match the published one: Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fpipjmmlpiiojkpk.png Type: image/png Size: 7798 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pdfbgealgmkdhcdn.png Type: image/png Size: 6167 bytes Desc: not available URL: From sgougeon at free.fr Wed Feb 20 19:24:53 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 20 Feb 2019 19:24:53 +0100 Subject: [Scilab-Dev] Wrong footer for online help In-Reply-To: <88857586-8fa9-d59b-46d9-e2ec38b838fc@free.fr> References: <88857586-8fa9-d59b-46d9-e2ec38b838fc@free.fr> Message-ID: <3c9f31e9-4aee-f7e7-8e65-e34545ac2a64@free.fr> By the way, following the "/Translation status/" link displayed on the bottom right part of the footer of the help portal https://help.scilab.org leads to records for /2013/... Samuel Le 20/02/2019 ? 19:03, Samuel Gougeon a ?crit : > > Dear Scilab devs, > > The footer of all online help pages for Scilab 6.0.2 is outdated: The > ESI copyright for the 2017-2019 period is missing, and Scilab > enterprises is still displayed as the editor: > > I am afraid that the related template is not public -- and so can't be > fixed by contributors --, since the template > GIT/modules/helptools/data/template/template_web.html or > template_web.html do not match the published one: > > Regards > Samuel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 7798 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 6167 bytes Desc: not available URL: From sgougeon at free.fr Fri Feb 22 14:54:05 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 22 Feb 2019 14:54:05 +0100 Subject: [Scilab-Dev] Bug 15822: : call for contribution Message-ID: Hi, Is there anyone there that would wish and could contribute fixing the bug 15822 ? Any GSOC candidate? Anyone else? This bug blocks major simplifications when making or improving help pages. It blocks sharing (sometime huge) pieces of contents, and is a huge source of wasted time. I had a look to the code, but did not end with anything trivial. Some good start is provided in the bug report comment#1. Thanks Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: