From Clement.David at esi-group.com Thu Jun 13 15:02:21 2019 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Thu, 13 Jun 2019 13:02:21 +0000 Subject: [Scilab-Dev] tests: <-- ENGLISH IMPOSED --> removed and gettext() added: why? In-Reply-To: References: Message-ID: <44fc679962aee3c0cca7d85e4a33e773cecd3327.camel@esi-group.com> Hello Samuel, There should be no real difference, having ENGLISH IMPOSED might have subtle bugs related to the system locales whereas using gettext() will rely on an extra Scilab function call (so will be less a "unit test"). IMHO commits having only this kind of diff is useless; there should be something else, could you point us the related code-review ? Thanks, -- Cl?ment Le vendredi 31 mai 2019 ? 18:57 +0200, Samuel Gougeon a ?crit : > Hello, > In some commits just before the release of 6.0.2, and more recently on the master, i noticed that > when some tests are tagged with the <-- ENGLISH IMPOSED --> flag and some error messages are > tested against their english version, without calling gettext, the reviewer removes the flag and > adds gettext(). > > What's the reason for this? What's the purpose of the <-- ENGLISH IMPOSED --> flag, then ? > Theoretically, the message in english can be different from the message_id (also in english). > Is it the reason? Or what else? > Thanks for your insight about this topic. > Regards > Samuel > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From sgougeon at free.fr Fri Jun 14 00:38:14 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 14 Jun 2019 00:38:14 +0200 Subject: [Scilab-Dev] tests: <-- ENGLISH IMPOSED --> removed and gettext() added: why? In-Reply-To: <44fc679962aee3c0cca7d85e4a33e773cecd3327.camel@esi-group.com> References: <44fc679962aee3c0cca7d85e4a33e773cecd3327.camel@esi-group.com> Message-ID: <6babaebf-6c0d-39ab-62bf-2fcdcb04dc12@free.fr> Hello Cl?ment, Le 13/06/2019 ? 15:02, Cl?ment David a ?crit?: > Hello Samuel, > > There should be no real difference, having ENGLISH IMPOSED might have subtle bugs related to the > system locales whereas using gettext() will rely on an extra Scilab function call (so will be less a > "unit test"). > > IMHO commits having only this kind of diff is useless; there should be something else, could you > point us the related code-review ? Both cases i had in mind were not commited just for this. But this change was made in addition before merging. Here is one case : https://codereview.scilab.org/#/c/20723/6..7 There was another one around the 6.0.2 release, but i failed refinding it. I agree about the extra function call. But as i wrote before, i got aware that using gettext() rather than ENGLISH IMPOSED is more robust for (rare but possible) cases having a translation even for en_US. Regards Samuel From antoine.elias at scilab-enterprises.com Fri Jun 14 12:54:07 2019 From: antoine.elias at scilab-enterprises.com (Antoine ELIAS) Date: Fri, 14 Jun 2019 12:54:07 +0200 Subject: [Scilab-Dev] tests: <-- ENGLISH IMPOSED --> removed and gettext() added: why? In-Reply-To: <6babaebf-6c0d-39ab-62bf-2fcdcb04dc12@free.fr> References: <44fc679962aee3c0cca7d85e4a33e773cecd3327.camel@esi-group.com> <6babaebf-6c0d-39ab-62bf-2fcdcb04dc12@free.fr> Message-ID: <01c7ca8d-84b2-9f0b-766f-9306a4ddce6f@scilab-enterprises.com> Hahaha it was me \o/ Seriously, I don't care about localization in test. A long time ago we had a discussion about localization in tests. I would have preferred to have some tests about localization mechanism and no localization in the others. The goal of all tests is *not* to check localization. But the final decision was different. In your commit you have mix localization and no localization, so I update to full localization that's all. Antoine Le 14/06/2019 ? 00:38, Samuel Gougeon a ?crit?: > Hello Cl?ment, > > Le 13/06/2019 ? 15:02, Cl?ment David a ?crit?: >> Hello Samuel, >> >> There should be no real difference, having ENGLISH IMPOSED might have >> subtle bugs related to the >> system locales whereas using gettext() will rely on an extra Scilab >> function call (so will be less a >> "unit test"). >> >> IMHO commits having only this kind of diff is useless; there should >> be something else, could you >> point us the related code-review ? > > Both cases i had in mind were not commited just for this. But this > change was made in addition before merging. > Here is one case : > > https://codereview.scilab.org/#/c/20723/6..7 > > There was another one around the 6.0.2 release, but i failed refinding > it. > > I agree about the extra function call. But as i wrote before, i got > aware that using gettext() rather than ENGLISH IMPOSED is more robust > for (rare but possible) cases having a translation even for en_US. > > 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 Tue Jun 18 19:43:52 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Tue, 18 Jun 2019 19:43:52 +0200 Subject: [Scilab-Dev] tests: <-- ENGLISH IMPOSED --> removed and gettext() added: why? In-Reply-To: <01c7ca8d-84b2-9f0b-766f-9306a4ddce6f@scilab-enterprises.com> References: <44fc679962aee3c0cca7d85e4a33e773cecd3327.camel@esi-group.com> <6babaebf-6c0d-39ab-62bf-2fcdcb04dc12@free.fr> <01c7ca8d-84b2-9f0b-766f-9306a4ddce6f@scilab-enterprises.com> Message-ID: <397815ae-376a-9950-08e5-9b298db10de2@free.fr> Le 14/06/2019 ? 12:54, Antoine ELIAS a ?crit?: > Hahaha it was me \o/ > > Seriously, I don't care about localization in test. > A long time ago we had a discussion about localization in tests. > I would have preferred to have some tests about localization mechanism > and no localization in the others. > The goal of all tests is *not* to check localization. > But the final decision was different. > > In your commit you have mix localization and no localization, so I > update to full localization that's all. Thanks for the piece of history. I have finally found the other case here: https://codereview.scilab.org/#/c/20831/2/scilab/modules/dynamic_link/tests/nonreg_tests/bug_7907.tst OK about the fact that, finally, we don't care. Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Tue Jun 18 21:06:37 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Tue, 18 Jun 2019 21:06:37 +0200 Subject: [Scilab-Dev] Xcos block: getting the position of ports in the interface function Message-ID: <6bd1b7ca-1083-4f01-d9f8-c09a0bce764b@free.fr> Hello, It could be useful for some blocks to set the label according to some parameter's value. Now, i would like to set such a label with some Scilab code in the interface function, and to avoid overlaying the ports and links connected to them. To do this, we need to know the position of ports, while the block might have been rotated. I have found no block property (.graphics.*, .model.*) providing ports positions (or the block orientation). Have i missed anything? Is there another way to detect ports positions ? Thanks Samuel From Clement.David at esi-group.com Mon Jun 24 11:48:31 2019 From: Clement.David at esi-group.com (=?iso-8859-1?Q?Cl=E9ment_David?=) Date: Mon, 24 Jun 2019 09:48:31 +0000 Subject: [Scilab-Dev] Xcos block: getting the position of ports in the interface function In-Reply-To: <6bd1b7ca-1083-4f01-d9f8-c09a0bce764b@free.fr> References: <6bd1b7ca-1083-4f01-d9f8-c09a0bce764b@free.fr> Message-ID: Hello Samuel, The ports labels could be set on the on `blk.graphics.in_label` and `blk.graphics.out_label` depending on block's parameters by the interface function as it is done by the BIGSOM_f (or others). About the position, they are computed by Xcos as dataflow (on the left and right) or as eventflow (on the top and bottom) and it is not possible to fix them within the interface function. You could also get the rotation, flip and mirror information from the blk.graphics.style value. Thanks, -- Cl?ment DAVID > -----Original Message----- > From: dev On Behalf Of Samuel Gougeon > Sent: Tuesday, June 18, 2019 9:07 PM > To: List dedicated to development questions > Subject: [Scilab-Dev] Xcos block: getting the position of ports in the interface > function > > Hello, > > It could be useful for some blocks to set the label according to some > parameter's value. > Now, i would like to set such a label with some Scilab code in the interface > function, and to avoid overlaying the ports and links connected to them. > > To do this, we need to know the position of ports, while the block might have > been rotated. > > I have found no block property (.graphics.*, .model.*) providing ports positions > (or the block orientation). > Have i missed anything? > Is there another way to detect ports positions ? > > Thanks > > Samuel > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From sgougeon at free.fr Tue Jun 25 12:55:25 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Tue, 25 Jun 2019 12:55:25 +0200 Subject: [Scilab-Dev] Xcos block: getting the position of ports in the interface function In-Reply-To: References: <6bd1b7ca-1083-4f01-d9f8-c09a0bce764b@free.fr> Message-ID: Hello Cl?ment, Thanks for your answer. During my first disp(graphics) tests, i likely focussed on /.in_style/ and its /rotation=/ flag, instead of on /.style/ that is only the one showing /flip=, mirror=/ and /rotation=/ flags. So i missed the info. Other tests done for CSCOPE show that in /.style/, /rotation=/ is in [0,90], and it's a combination with /flip=/ and /mirror=/ that builds any actual rotation in [0, 270]. And that the /flip=/ and /mirror=/ roles are inverted when /rotation=90 /(so: flip and mirror are in the icon's referential, not in the user's one. This is also what we see when flipping a 90?-rotated block). Anyway, this will allow to decide where is the relevant free place(s) to set a label around the icon, wrt existing ports. Since combinations of flip, mirror and rotation flags together with ports positions are not trivial, writing a short shared internal function (likely in scicos/macros/utils) returning "free sides" could be useful. I am going to do it when required. Best regards Samuel Le 24/06/2019 ? 11:48, Cl?ment David a ?crit?: > Hello Samuel, > > The ports labels could be set on the on `blk.graphics.in_label` and `blk.graphics.out_label` depending on block's parameters by the interface function as it is done by the BIGSOM_f (or others). About the position, they are computed by Xcos as dataflow (on the left and right) or as eventflow (on the top and bottom) and it is not possible to fix them within the interface function. > > You could also get the rotation, flip and mirror information from the blk.graphics.style value. > > Thanks, > > -- > Cl?ment DAVID -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Tue Jun 25 13:38:19 2019 From: sgougeon at free.fr (Samuel Gougeon) Date: Tue, 25 Jun 2019 13:38:19 +0200 Subject: [Scilab-Dev] Recursive extraction on a function's identifier Message-ID: <38efbad5-9532-9aeb-7df8-2d15115f6750@free.fr> Hello, Let function s = myfun() ?? clear s ?? s.a = %pi ?? s.b = %z endfunction Presently, we get --> myfun.a Attempt to reference field of non-structure array. --> myfun().a ?ans? = ?? 3.1415927 The type of the symbol myfun as a function is known when calling myfun.a, isn't it? So, is there a technical or a usage reason to not understand implicitly myfun.a as myfun().a ? As well, couldn't we expect an error message routing the user to defining %function_e() (unless Scilab provides a default definition) ? Thanks Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: