From Clement.David at esi-group.com Wed Sep 5 16:21:29 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Wed, 5 Sep 2018 14:21:29 +0000 Subject: [Scilab-Dev] xcos In-Reply-To: References:

Message-ID: Hello Johan, Thanks for taking a look at Xcos, this is a great Scilab functionnality that deserve more love ! I will try to help you understanding the codebase, do not hesitate to ask if needed. For Scilab 6, Xcos GUI is coded in Java as you have correctly noted *BUT* the Diagram, Block, Link and Annotation data (available on Scilab through scicos API) are stored in C++ (to relax memory constraints on huge diagrams). To pass data from C++ to Java, an object identified by a (ScicosID, Kind) pair could retrieve its properties through a Controller object. The GUI fully interacts with Scilab this way. You are correct about Bug 14670 fix, to avoid opening twice an XcosDiagram for a specific block (eg. ScicosID) Scilab 5.5.2 stored a reference to all the opened diagrams and create only a new XcosDiagram if needed. I will review it, do you know how to use codereview.scilab.org to push fixes ? Thanks for your help, -- Cl?ment Le mardi 28 ao?t 2018 ? 21:59 -0300, Johan Wesselink a ?crit : > I have a quick and dirty fix. Not for real use, but it shows a proof of concept. I am certainly > cutting corners here. > > Would like to know how to translate this into a better solution? > Add a function to the Xcos class that returns a diagram based on cell that is passed? > > Started with this simple problem. Really like Xcos, but it is still very broken. Like to > contribute if possible. > > Thanks. > > > Op di 28 aug. 2018 om 17:40 schreef Johan Wesselink : > > Good day, > > > > I was having a look into some superblock problems. > > In version 6.0.1. there are many problems with the super block. > > > > I have checkout the latest version of the GIT repository and can build and debug it using > > eclipse. > > > > On this moment I am interested in Bug 14670 Super block can be opened more then once. > > I already discovered that the xcos/block/actian/BlockParametersAction.java contains the method > > ActionPerformed on line 96 that actually generates the diagram. > > I am a little bit curious for the architecture. > > I see that a XcosDiagram is created using the UID, Kind and Id of cell that is the SUPER_f > > block. This is created diagram is then added to the root diagram. > > Maybe a very simplistic view, but is it possible to get the root diagram and search for a sub > > diagram with the same UID, Kind and Id. And so, if this is present does that mean that the > > diagram is already created and that it only should be shown? > > Or do not understand how it works. > > > > Sincerely > > Johan > > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From johanwesselink23 at gmail.com Wed Sep 5 21:09:42 2018 From: johanwesselink23 at gmail.com (Johan Wesselink) Date: Wed, 5 Sep 2018 16:09:42 -0300 Subject: [Scilab-Dev] xcos In-Reply-To: References:

Message-ID: I am aware that it is a MVC architecture. The Model in this case is the C++ part. The controller is instantiated in JAVA and has a JNI interface. The view in this case is actually everything that makes the view visible include the diagram structure info. One thing that makes me very curious. The models are made using modelica. How is the image of the model imported into the view? Something I still haven't found (did not yet look very good also). Started simple with the diagram problem. The fix I made is not very well implemented. It doesn't make me happy, but it works. The idea is that I think that every root diagram has a number of child diagrams. These are created from superblock. If a superblock and all of it recursive children are converted into a diagram. I noticed that the diagram ID and Kind are equal to the ID and Kind of the superblock. This makes it possible to make a list with diagrams, for a given root, and look at them I simple iterate over them and compare the Kind and ID of the SuperBlock with the those of the diagrams stored in the list.. This works, but for big diagrams this can be done way better. I would prefer a map that maps a superblock to a diagram. This makes it possible to look up a diagram with O(1), which is way faster. Notice that for small diagrams, most practical examples for know there is no measurable performance difference. I do not know how the CodeReview system works, but I am eager to learn. I think you need some kind of login for it? Or can the normal login be used also? My idea is to have a look at some problems with SuperBlocks. These make it very difficult for me to run some older diagrams I have. Johan Wesselink Op wo 5 sep. 2018 om 11:21 schreef Cl?ment David < Clement.David at esi-group.com>: > Hello Johan, > > Thanks for taking a look at Xcos, this is a great Scilab functionnality > that deserve more love ! I > will try to help you understanding the codebase, do not hesitate to ask if > needed. > > For Scilab 6, Xcos GUI is coded in Java as you have correctly noted *BUT* > the Diagram, Block, Link > and Annotation data (available on Scilab through scicos API) are stored in > C++ (to relax memory > constraints on huge diagrams). To pass data from C++ to Java, an object > identified by a (ScicosID, > Kind) pair could retrieve its properties through a Controller object. The > GUI fully interacts with > Scilab this way. > > You are correct about Bug 14670 fix, to avoid opening twice an XcosDiagram > for a specific block (eg. > ScicosID) Scilab 5.5.2 stored a reference to all the opened diagrams and > create only a new > XcosDiagram if needed. I will review it, do you know how to use > codereview.scilab.org to push fixes > ? > > Thanks for your help, > > -- > Cl?ment > > > Le mardi 28 ao?t 2018 ? 21:59 -0300, Johan Wesselink a ?crit : > > I have a quick and dirty fix. Not for real use, but it shows a proof of > concept. I am certainly > > cutting corners here. > > > > Would like to know how to translate this into a better solution? > > Add a function to the Xcos class that returns a diagram based on cell > that is passed? > > > > Started with this simple problem. Really like Xcos, but it is still very > broken. Like to > > contribute if possible. > > > > Thanks. > > > > > > Op di 28 aug. 2018 om 17:40 schreef Johan Wesselink < > johanwesselink23 at gmail.com>: > > > Good day, > > > > > > I was having a look into some superblock problems. > > > In version 6.0.1. there are many problems with the super block. > > > > > > I have checkout the latest version of the GIT repository and can build > and debug it using > > > eclipse. > > > > > > On this moment I am interested in Bug 14670 Super block can be opened > more then once. > > > I already discovered that the > xcos/block/actian/BlockParametersAction.java contains the method > > > ActionPerformed on line 96 that actually generates the diagram. > > > I am a little bit curious for the architecture. > > > I see that a XcosDiagram is created using the UID, Kind and Id of cell > that is the SUPER_f > > > block. This is created diagram is then added to the root diagram. > > > Maybe a very simplistic view, but is it possible to get the root > diagram and search for a sub > > > diagram with the same UID, Kind and Id. And so, if this is present > does that mean that the > > > diagram is already created and that it only should be shown? > > > Or do not understand how it works. > > > > > > Sincerely > > > Johan > > > > > > > _______________________________________________ > > 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 johanwesselink23 at gmail.com Thu Sep 6 03:36:30 2018 From: johanwesselink23 at gmail.com (Johan Wesselink) Date: Wed, 5 Sep 2018 22:36:30 -0300 Subject: [Scilab-Dev] xcos In-Reply-To: References:

Message-ID: I will have a look at gerrit. I already did some reading on the subject. Interesting stuff. Thanks. Op wo 5 sep. 2018 om 16:09 schreef Johan Wesselink < johanwesselink23 at gmail.com>: > I am aware that it is a MVC architecture. The Model in this case is the > C++ part. The controller is instantiated in JAVA and has a JNI interface. > The view in this case is actually everything that makes the view visible > include the diagram structure info. One thing that makes me very curious. > The models are made using modelica. How is the image of the model imported > into the view? Something I still haven't found (did not yet look very good > also). Started simple with the diagram problem. > > The fix I made is not very well implemented. It doesn't make me happy, but > it works. The idea is that I think that every root diagram has a number of > child diagrams. These are created from superblock. If a superblock and all > of it recursive children are converted into a diagram. I noticed that the > diagram ID and Kind are equal to the ID and Kind of the superblock. This > makes it possible to make a list with diagrams, for a given root, and look > at them I simple iterate over them and compare the Kind and ID of the > SuperBlock with the those of the diagrams stored in the list.. This works, > but for big diagrams this can be done way better. I would prefer a map that > maps a superblock to a diagram. This makes it possible to look up a diagram > with O(1), which is way faster. Notice that for small diagrams, most > practical examples for know there is no measurable performance difference. > > I do not know how the CodeReview system works, but I am eager to learn. I > think you need some kind of login for it? Or can the normal login be used > also? > > My idea is to have a look at some problems with SuperBlocks. These make it > very difficult for me to run some older diagrams I have. > > Johan Wesselink > > > > Op wo 5 sep. 2018 om 11:21 schreef Cl?ment David < > Clement.David at esi-group.com>: > >> Hello Johan, >> >> Thanks for taking a look at Xcos, this is a great Scilab functionnality >> that deserve more love ! I >> will try to help you understanding the codebase, do not hesitate to ask >> if needed. >> >> For Scilab 6, Xcos GUI is coded in Java as you have correctly noted *BUT* >> the Diagram, Block, Link >> and Annotation data (available on Scilab through scicos API) are stored >> in C++ (to relax memory >> constraints on huge diagrams). To pass data from C++ to Java, an object >> identified by a (ScicosID, >> Kind) pair could retrieve its properties through a Controller object. The >> GUI fully interacts with >> Scilab this way. >> >> You are correct about Bug 14670 fix, to avoid opening twice an >> XcosDiagram for a specific block (eg. >> ScicosID) Scilab 5.5.2 stored a reference to all the opened diagrams and >> create only a new >> XcosDiagram if needed. I will review it, do you know how to use >> codereview.scilab.org to push fixes >> ? >> >> Thanks for your help, >> >> -- >> Cl?ment >> >> >> Le mardi 28 ao?t 2018 ? 21:59 -0300, Johan Wesselink a ?crit : >> > I have a quick and dirty fix. Not for real use, but it shows a proof of >> concept. I am certainly >> > cutting corners here. >> > >> > Would like to know how to translate this into a better solution? >> > Add a function to the Xcos class that returns a diagram based on cell >> that is passed? >> > >> > Started with this simple problem. Really like Xcos, but it is still >> very broken. Like to >> > contribute if possible. >> > >> > Thanks. >> > >> > >> > Op di 28 aug. 2018 om 17:40 schreef Johan Wesselink < >> johanwesselink23 at gmail.com>: >> > > Good day, >> > > >> > > I was having a look into some superblock problems. >> > > In version 6.0.1. there are many problems with the super block. >> > > >> > > I have checkout the latest version of the GIT repository and can >> build and debug it using >> > > eclipse. >> > > >> > > On this moment I am interested in Bug 14670 Super block can be opened >> more then once. >> > > I already discovered that the >> xcos/block/actian/BlockParametersAction.java contains the method >> > > ActionPerformed on line 96 that actually generates the diagram. >> > > I am a little bit curious for the architecture. >> > > I see that a XcosDiagram is created using the UID, Kind and Id of >> cell that is the SUPER_f >> > > block. This is created diagram is then added to the root diagram. >> > > Maybe a very simplistic view, but is it possible to get the root >> diagram and search for a sub >> > > diagram with the same UID, Kind and Id. And so, if this is present >> does that mean that the >> > > diagram is already created and that it only should be shown? >> > > Or do not understand how it works. >> > > >> > > Sincerely >> > > Johan >> > > >> > >> > _______________________________________________ >> > 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 stephane.mottelet at utc.fr Thu Sep 6 14:47:53 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Thu, 6 Sep 2018 14:47:53 +0200 Subject: [Scilab-Dev] News from outside Message-ID: <843ff42c-c7b1-8fc6-4df5-32cf8602c788@utc.fr> Hello all, Seen on https://nickhigham.wordpress.com/2018/06/19/whats-new-in-matlab r2018a/ [...] This is a consequence of a change in the way MATLAB stores complex arrays. Prior to R2018a it stored the real parts together and the imaginary parts together. In R2018 it uses an interleaved format in which the real and imaginary parts of a number are stored together; this is the storage format used in the C and C++ languages S. -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet From grocer.toolbox at gmail.com Sat Sep 8 10:41:56 2018 From: grocer.toolbox at gmail.com (=?UTF-8?B?w4lyaWMgRHVib2lz?=) Date: Sat, 8 Sep 2018 10:41:56 +0200 Subject: [Scilab-Dev] strings cannot be cut into several lines Message-ID: Hello Can someone explain me why in Scilab 6, you cannot wirte a string on several lines each line ending by "..."? When you have a very long string, you have 2 choices that are not appealing: - write this string on a line, which is not very readable; - define several strings covering different components of the string and then add them to build your string, which is a time consuming. This change makes my productivity when programming in Scilab decline and I do not see teh drawbacks that the old working entailed. Thansk for your answer. Regards ?ric -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine.elias at scilab-enterprises.com Sat Sep 8 17:36:23 2018 From: antoine.elias at scilab-enterprises.com (Antoine ELIAS) Date: Sat, 8 Sep 2018 17:36:23 +0200 Subject: [Scilab-Dev] strings cannot be cut into several lines In-Reply-To: References: Message-ID: <72fd9897-d751-d79c-16e6-a9b3cb386a1d@scilab-enterprises.com> Hello Eric, In Scilab 5, you could write strings on multiple lines using ... but not only, it worked with everything. -->1.. -->2 ?ans? = ??? 12. and more horrible -->fun.. -->ction toto(.. -->) -->disp("fu.. -->nction"); -->endf... -->unction -->toto() ?function In fact "..." are used to ignore the following end line. I hope you can understand we want to remove this kind of coding style. To replace ... for strings case can you use + operator. -->"string1 and ... -->string2" become -->"string1 and " + ... -->"string2" ?ans? = ?string1 and string2 Antoine Le 08/09/2018 ? 10:41, ?ric Dubois a ?crit?: > Hello > > Can someone explain me why in Scilab 6, you cannot wirte a string on > several lines each line ending by "..."? > > When you have a very long string, you have 2 choices that are not > appealing: > - write this string on a line, which is not very readable; > - define several strings covering different components of the string > and then add them to build your string, which is a time consuming. > > This change makes my productivity when programming in Scilab decline > and I do not see teh drawbacks that the old working entailed. > > Thansk for your answer. > > Regards > > ?ric > > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From grocer.toolbox at gmail.com Sun Sep 9 11:21:01 2018 From: grocer.toolbox at gmail.com (=?UTF-8?B?w4lyaWMgRHVib2lz?=) Date: Sun, 9 Sep 2018 11:21:01 +0200 Subject: [Scilab-Dev] strings cannot be cut into several lines In-Reply-To: References: Message-ID: Thanks Antoine for your quick and precised answer. I understand the point, but besides "ascending compatibility" (which as a user I give -quite naturally- more weight than you as a developper), it makes the writing of long strings rather heavy and I think that an exception should have been made for strings. In fact, for long strings the solution you mention (and I mentionned also in ly previous e-mail) consisting in adding strings seems to mesomehow artificial, since it amounts to build a variable by splitting it into several ones. As an example of my point, take the Troll code of the macroeconomic model "Opale", that has been recently realeased by the French Treasury ( https://www.tresor.economie.gouv.fr/Articles/2018/09/05/la-dg-tresor-met-a-la-disposition-du-public-les-codes-sources-des-modeles-mesange-opale-et-saphir). Since Troll is proprietary and not Opensource software, I have undertaken (and in fact managed) to translate it into Scilab (which involves many blocks, sucha s a symbolic derivativefor instance. If you take an excerpt of the code that adds some equations to an existing model, it is written in Troll : ADDEQ bottom td_p3m_d7_ch : DEL(1: LOG(td_p3m_d7_ch)) = p3md7cst'c + p3md7balpos'c * balpos + p3md7balneg'c * balneg + p3md7juppos'c * juppos + p3md7jupneg'c * jupneg + p3md7filneg'c * filneg + p3md7indic1999q3'c* indic1999q3 + p3md7rdbr0'c * DEL(LOG(TD_B6_S143/TD_P3M_D5_CH)) + p3md7rdbr1'c * DEL(LOG(TD_B6_S143/TD_P3M_D5_CH))(-1) + p3md7tcho0'c * DEL(TCHO) + p3md7vs0'c * DEL(TEMPVS1) + mup3md7'c * ( LOG(td_p3m_d7_ch(-1)) - p3m_d7_ch_cale(-1) - 1 * LOG(TD_B6_S143(-1)/TD_P3M_D5_CH(-1)) ) + DEL(p3m_d7_ch_cale), td_p3p_d7_ch : td_p3p_d7_ch = coefp3pd7_ch * td_p3g_d7_ch , td_p51s_dhfz7_ch : DEL(LOG(td_p51s_dhfz7_ch)) = -0.002801 + 0.257006 * (DEL(LOG(td_p51s_dhfz7_ch(-2)))-DEL(p51s_dhfz7_ch_cale(-2))) - 0.592343 * DEL(LOG(td_p51s_dhfz5_ch/TD_B1_BMNA5_CH)) + 1.363988 * DEL(LOG(td_b1_bmna7_ch)) + 0.002681 * DEL(TUC) // ?a devrait ?tre DEL(TUC)(-1) => ? changer - 0.093789 * ( LOG(td_p51s_dhfz7_ch(-1))- LOG(td_b1_bmna7_ch(-1)) - ( -1.854938 -0.018102 * COUT_REEL(-1) ) - p51s_dhfz7_ch_cale(-1) ) + DEL(p51s_dhfz7_ch_cale), In Scilab 5.5.2 it should be written: ADDEQ('bottom','... td_p3m_d7_ch : DEL(1: LOG(td_p3m_d7_ch)) = p3md7cst''c ... + p3md7balpos''c * balpos ... + p3md7balneg''c * balneg ... + p3md7juppos''c * juppos ... + p3md7jupneg''c * jupneg ... + p3md7filneg''c * filneg ... + p3md7indic1999q3''c* indic1999q3 ... + p3md7rdbr0''c * DEL(LOG(TD_B6_S143/TD_P3M_D5_CH)) ... + p3md7rdbr1''c * DEL(LOG(TD_B6_S143/TD_P3M_D5_CH))(-1) ... + p3md7tcho0''c * DEL(TCHO) ... + p3md7vs0''c * DEL(TEMPVS1) ... + mup3md7''c * ( ... LOG(td_p3m_d7_ch(-1)) - p3m_d7_ch_cale(-1) ... - 1 * LOG(TD_B6_S143(-1)/TD_P3M_D5_CH(-1)) ... ) ... + DEL(p3m_d7_ch_cale), ... ... td_p3p_d7_ch : td_p3p_d7_ch = coefp3pd7_ch * td_p3g_d7_ch , ... ... td_p51s_dhfz7_ch : DEL(LOG(td_p51s_dhfz7_ch)) = -0.002801 ... + 0.257006 * (DEL(LOG(td_p51s_dhfz7_ch(-2)))-DEL(p51s_dhfz7_ch_cale(-2))) ... - 0.592343 * DEL(LOG(td_p51s_dhfz5_ch/TD_B1_BMNA5_CH)) ... + 1.363988 * DEL(LOG(td_b1_bmna7_ch)) ... + 0.002681 * DEL(TUC) ... - 0.093789 * ( ... LOG(td_p51s_dhfz7_ch(-1))- LOG(td_b1_bmna7_ch(-1)) - ... ( -1.854938 -0.018102 * COUT_REEL(-1) ) ... - p51s_dhfz7_ch_cale(-1) ) ... + DEL(p51s_dhfz7_ch_cale)') And in Scilab 6.0.1: ADDEQ('bottom','... td_p3m_d7_ch : DEL(1: LOG(td_p3m_d7_ch)) = p3md7cst''c'+ ... '+ p3md7balpos''c * balpos'+ ... '+ p3md7balneg''c * balneg'+ ... '+ p3md7juppos''c * juppos'+ ... '+ p3md7jupneg''c * jupneg'+ ... '+ p3md7filneg''c * filneg'+ ... '+ p3md7indic1999q3''c* indic1999q3 ... ' + p3md7rdbr0''c * DEL(LOG(TD_B6_S143/TD_P3M_D5_CH))'+ ... '+ p3md7rdbr1''c * DEL(LOG(TD_B6_S143/TD_P3M_D5_CH))(-1)'+ ... '+ p3md7tcho0''c * DEL(TCHO) '+ ... '+ p3md7vs0''c * DEL(TEMPVS1)'+ ... '+ mup3md7''c * ('+ ... 'LOG(td_p3m_d7_ch(-1)) - p3m_d7_ch_cale(-1)'+ ... '- 1 * LOG(TD_B6_S143(-1)/TD_P3M_D5_CH(-1)) '+... ')'+ ... '+ DEL(p3m_d7_ch_cale),'+ ... +... 'td_p3p_d7_ch : td_p3p_d7_ch = coefp3pd7_ch * td_p3g_d7_ch ,'+ ... + ... 'td_p51s_dhfz7_ch : DEL(LOG(td_p51s_dhfz7_ch)) = -0.002801 '+ ... '+ 0.257006 * (DEL(LOG(td_p51s_dhfz7_ch(-2)))-DEL(p51s_dhfz7_ch_cale(-2)))'+ ... ' - 0.592343 * DEL(LOG(td_p51s_dhfz5_ch/TD_B1_BMNA5_CH))'+ ... '+ 1.363988 * DEL(LOG(td_b1_bmna7_ch))'+ ... '+ 0.002681 * DEL(TUC)'+ ... '- 0.093789 * ('+ ... '+LOG(td_p51s_dhfz7_ch(-1))- LOG(td_b1_bmna7_ch(-1)) - '+... '( -1.854938 -0.018102 * COUT_REEL(-1) ) '+... '- p51s_dhfz7_ch_cale(-1) ) '+... '+ DEL(p51s_dhfz7_ch_cale)') For an economist point of view the last writing makes it much more difficult the understanding of the structure of the equations and I fear that it could make external users reluctant to use my code... Regards, ?ric Le sam. 8 sept. 2018 ? 10:41, ?ric Dubois a ?crit : > Hello > > Can someone explain me why in Scilab 6, you cannot wirte a string on > several lines each line ending by "..."? > > When you have a very long string, you have 2 choices that are not > appealing: > - write this string on a line, which is not very readable; > - define several strings covering different components of the string and > then add them to build your string, which is a time consuming. > > This change makes my productivity when programming in Scilab decline and I > do not see teh drawbacks that the old working entailed. > > Thansk for your answer. > > Regards > > ?ric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Sun Sep 9 14:31:00 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Sun, 9 Sep 2018 14:31:00 +0200 Subject: [Scilab-Dev] strings cannot be cut into several lines In-Reply-To: References:

Message-ID: <0539e047-2248-c13b-1200-5b08649fd863@free.fr> Hello, I agree with you Eric. The example that you provide is rather explicit. I also certainly agree on some simplifications about strings parsing in Scilab 6. For instance, no longer allowing ending a string with the " or ' delimiter that has not been used to start it is a good thing. After 20 years of using Scilab, i discovered this week in a Xcos block function that to include a " or ' in a string, doubling it is not mandatory! Mixed " and ' can be used: --> "ab"'cde" ans = ab'cde --> "ab'"cde" ans = ab"cde Frankly, IMO this kind of dark feature remaining in Scilab 6.0 would deserve being removed. I guess that they do not simplify parsing strings, and occurrences in the existing codes are trivial to detect and convert in the whole code. By the way, this feature may prevent fixing the request 14287 . /So, on one hand we still have this kind of dark complications, and on the other// //one a useful feature as continuing strings is removed...// / Another example showing a not very consistent policy: Scilab 6.0 brings block comments /* this is a multiline comment */ Even if they are poorly still supported, the way is right : they will be really useful. /They implement a new multiline feature, while the multiline strings parsing is removed..// / A last example about very handy multiline processing: It is possible to declare a multiline array using the end-of-line as the ";" line separator. This is also very useful, noticeably because it allows to copy/paste an array in the code as is it displayed in the console: --> A = matrix(1:15,3,5) A = 1. 4. 7. 10. 13. 2. 5. 8. 11. 14. 3. 6. 9. 12. 15. Now in the code to set A in a literal way: A = [ 1. 4. 7. 10. 13. 2. 5. 8. 11. 14. 3. 6. 9. 12. 15. ] No need to append each line with ... or with ; or with ; ... Scilab is handy, and users are happy. They just expect that from it. Nobody would suggest removing this feature. Back to strings: Octave uses "\" as the multiline continuation character. It has this meaning only when it ends a line in an opened string. As it is currently implemented, it unfortunately requires being protected if \ is used inside the string. This is not handy, and would bring many backward incompatibilities in Scilab >> a = " abcd \path\ e" a = abcd pathe <<<< missing \ before p >> a = " abcd \\path\ e" a = abcd \pathe /The way the continuation marks ... worked for strings up to Scilab 5.5.2 was nice.// / We could even wonder that even removing ".." might be syntactically possible: Any string not closed at the end of a line goes on on the next line, and leading blanks are meaningful: text = "This is a unique string defined on several lines" Would it be hard to parse? Anyway, even without improvement, at least restoring the former ".." mark would remove a regression. Antoine, Fortunately, only C?dric and you known that the indeed horrible example you gave was possible :(( But the examples are not inside a string. For my part, i don't understand why preventing such -- possible but unknown -- horrible syntax demands removing a useful feature. Now, i know that defining parsing rules is a very complex thing, and that the parser has been rewritten. Best regards Samuel Le 09/09/2018 ? 11:21, ?ric Dubois a ?crit : > Thanks Antoine for your quick and precised answer. > > I understand the point, but besides "ascending compatibility" (which > as a user I give -quite naturally- more weight than you as a > developper), it makes the writing of long strings rather heavy and I > think that an exception should have been made for strings. In fact, > for long strings the solution you mention (and I mentionned also in ly > previous e-mail) consisting in adding strings seems to mesomehow > artificial, since it amounts to build a variable by splitting it into > several ones. > > As an example of my point, take the Troll code of the macroeconomic > model "Opale", that has been recently realeased by the French Treasury > (https://www.tresor.economie.gouv.fr/Articles/2018/09/05/la-dg-tresor-met-a-la-disposition-du-public-les-codes-sources-des-modeles-mesange-opale-et-saphir). > Since Troll is proprietary and not Opensource software, I have > undertaken (and in fact managed) to translate it into Scilab (which > involves many blocks, sucha s a symbolic derivativefor instance. > > If you take an excerpt of the code that adds some equations to an > existing model, it is written in Troll : > > ADDEQ bottom > td_p3m_d7_ch:DEL(1: LOG(td_p3m_d7_ch)) = p3md7cst'c > + p3md7balpos'c*balpos > + p3md7balneg'c*balneg > + p3md7juppos'c*juppos > + p3md7jupneg'c*jupneg > + p3md7filneg'c*filneg > + p3md7indic1999q3'c*indic1999q3 > + p3md7rdbr0'c*DEL(LOG(TD_B6_S143/TD_P3M_D5_CH)) > + p3md7rdbr1'c*DEL(LOG(TD_B6_S143/TD_P3M_D5_CH))(-1) > + p3md7tcho0'c*DEL(TCHO) > + p3md7vs0'c*DEL(TEMPVS1) > + mup3md7'c*( > LOG(td_p3m_d7_ch(-1)) -p3m_d7_ch_cale(-1) > - 1 * LOG(TD_B6_S143(-1)/TD_P3M_D5_CH(-1)) > ) > + DEL(p3m_d7_ch_cale), > td_p3p_d7_ch : td_p3p_d7_ch = coefp3pd7_ch* td_p3g_d7_ch , > td_p51s_dhfz7_ch : DEL(LOG(td_p51s_dhfz7_ch)) = -0.002801 > + 0.257006*(DEL(LOG(td_p51s_dhfz7_ch(-2)))-DEL(p51s_dhfz7_ch_cale(-2))) > - 0.592343*DEL(LOG(td_p51s_dhfz5_ch/TD_B1_BMNA5_CH)) > + 1.363988 * DEL(LOG(td_b1_bmna7_ch)) > + 0.002681*DEL(TUC) // ?a devrait ?tre > DEL(TUC)(-1) => ? changer > - 0.093789*( > LOG(td_p51s_dhfz7_ch(-1))- LOG(td_b1_bmna7_ch(-1)) - > (-1.854938-0.018102 * COUT_REEL(-1)) > - p51s_dhfz7_ch_cale(-1)) > + DEL(p51s_dhfz7_ch_cale), > > In Scilab 5.5.2 it should be written: > > ADDEQ('bottom','... > td_p3m_d7_ch:DEL(1: LOG(td_p3m_d7_ch)) = p3md7cst''c ... > + p3md7balpos''c*balpos ... > + p3md7balneg''c*balneg ... > + p3md7juppos''c*juppos ... > + p3md7jupneg''c*jupneg ... > + p3md7filneg''c*filneg ... > + p3md7indic1999q3''c*indic1999q3 ... > + p3md7rdbr0''c*DEL(LOG(TD_B6_S143/TD_P3M_D5_CH)) ... > + p3md7rdbr1''c*DEL(LOG(TD_B6_S143/TD_P3M_D5_CH))(-1) ... > + p3md7tcho0''c*DEL(TCHO) ... > + p3md7vs0''c*DEL(TEMPVS1) ... > + mup3md7''c*( ... > LOG(td_p3m_d7_ch(-1)) -p3m_d7_ch_cale(-1) ... > - 1 * LOG(TD_B6_S143(-1)/TD_P3M_D5_CH(-1)) ... > ) ... > + DEL(p3m_d7_ch_cale), ... > ... > td_p3p_d7_ch : td_p3p_d7_ch = coefp3pd7_ch* td_p3g_d7_ch , ... > ... > td_p51s_dhfz7_ch : DEL(LOG(td_p51s_dhfz7_ch)) = -0.002801 ... > + > 0.257006*(DEL(LOG(td_p51s_dhfz7_ch(-2)))-DEL(p51s_dhfz7_ch_cale(-2))) ... > - > 0.592343*DEL(LOG(td_p51s_dhfz5_ch/TD_B1_BMNA5_CH)) ... > + 1.363988 * DEL(LOG(td_b1_bmna7_ch)) ... > + 0.002681*DEL(TUC) ... > - 0.093789*( ... > LOG(td_p51s_dhfz7_ch(-1))- LOG(td_b1_bmna7_ch(-1)) - ... > (-1.854938-0.018102 * COUT_REEL(-1)) ... > - p51s_dhfz7_ch_cale(-1)) ... > + DEL(p51s_dhfz7_ch_cale)') > > And in Scilab 6.0.1: > ADDEQ('bottom','... > td_p3m_d7_ch:DEL(1: LOG(td_p3m_d7_ch)) = p3md7cst''c'+ ... > '+ p3md7balpos''c*balpos'+ ... > '+ p3md7balneg''c*balneg'+ ... > '+ p3md7juppos''c*juppos'+ ... > '+ p3md7jupneg''c*jupneg'+ ... > '+ p3md7filneg''c*filneg'+ ... > '+ p3md7indic1999q3''c*indic1999q3 ... > ' + p3md7rdbr0''c*DEL(LOG(TD_B6_S143/TD_P3M_D5_CH))'+ ... > '+ p3md7rdbr1''c*DEL(LOG(TD_B6_S143/TD_P3M_D5_CH))(-1)'+ ... > '+ p3md7tcho0''c*DEL(TCHO) '+ ... > '+ p3md7vs0''c*DEL(TEMPVS1)'+ ... > '+ mup3md7''c*('+ ... > 'LOG(td_p3m_d7_ch(-1)) -p3m_d7_ch_cale(-1)'+ ... > '- 1 * LOG(TD_B6_S143(-1)/TD_P3M_D5_CH(-1)) '+... > ')'+ ... > '+ DEL(p3m_d7_ch_cale),'+ ... > +... > 'td_p3p_d7_ch : td_p3p_d7_ch = coefp3pd7_ch* td_p3g_d7_ch ,'+ ... > + ... > 'td_p51s_dhfz7_ch : DEL(LOG(td_p51s_dhfz7_ch)) = -0.002801 '+ ... > '+ > 0.257006*(DEL(LOG(td_p51s_dhfz7_ch(-2)))-DEL(p51s_dhfz7_ch_cale(-2)))'+ > ... > ' - > 0.592343*DEL(LOG(td_p51s_dhfz5_ch/TD_B1_BMNA5_CH))'+ ... > '+ 1.363988 * DEL(LOG(td_b1_bmna7_ch))'+ ... > '+ 0.002681*DEL(TUC)'+ ... > '- 0.093789*('+ ... > '+LOG(td_p51s_dhfz7_ch(-1))- LOG(td_b1_bmna7_ch(-1)) - '+... > '(-1.854938-0.018102 * COUT_REEL(-1)) '+... > '- p51s_dhfz7_ch_cale(-1)) '+... > '+ DEL(p51s_dhfz7_ch_cale)') > > For an economist point of view the last writing makes it much more > difficult the understanding of the structure of the equations and I > fear that it could make external users reluctant to use my code... > > Regards, > > ?ric > > Le sam. 8 sept. 2018 ? 10:41, ?ric Dubois > a ?crit : > > Hello > > Can someone explain me why in Scilab 6, you cannot wirte a string > on several lines each line ending by "..."? > > When you have a very long string, you have 2 choices that are not > appealing: > - write this string on a line, which is not very readable; > - define several strings covering different components of the > string and then add them to build your string, which is a time > consuming. > > This change makes my productivity when programming in Scilab > decline and I do not see teh drawbacks that the old working entailed. > > Thansk for your answer. > > Regards > > ?ric > > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Wed Sep 12 17:02:02 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Wed, 12 Sep 2018 17:02:02 +0200 Subject: [Scilab-Dev] type of structs and cells Message-ID: <711c5235-efd8-0860-a51d-19ec9a6e0eed@utc.fr> Hi all, I hope some of you are still reading this list, which has a very low traffic these days... I just discovered, while working on https://codereview.scilab.org/#/c/20491/ https://codereview.scilab.org/#/c/19114/ that cells have the same type number, although a different type string. Hence, when you want to differentiate between structs, cells, lists, mlists, tlists, you cannot rely on typeof(), since for mlists and tlists they return the usertype, neither on type(), since it does not make the difference between cells and structs. I know there exist isstruct() and iscell(), but why do we have the same type number ?? S. -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet From stephane.mottelet at utc.fr Wed Sep 12 17:03:41 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Wed, 12 Sep 2018 17:03:41 +0200 Subject: [Scilab-Dev] type of structs and cells In-Reply-To: <711c5235-efd8-0860-a51d-19ec9a6e0eed@utc.fr> References: <711c5235-efd8-0860-a51d-19ec9a6e0eed@utc.fr> Message-ID: <394ac9e0-ddea-90c0-dcd8-b583407fa950@utc.fr> Le 12/09/2018 ? 17:02, St?phane Mottelet a ?crit?: > Hi all, > > I hope some of you are still reading this list, which has a very low > traffic these days... I just discovered, while working on > > https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/codereview.scilab.org/#/c/20491/ > > > https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/codereview.scilab.org/#/c/19114/ > > > that cells and structs > have the same type number, although a different type string. Hence, > when you want to differentiate between structs, cells, lists, mlists, > tlists, you cannot rely on typeof(), since for mlists and tlists they > return the usertype, neither on type(), since it does not make the > difference between cells and structs. I know there exist isstruct() > and iscell(), but why do we have the same type number ?? > > S. > > > > > -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet From sgougeon at free.fr Wed Sep 12 21:48:51 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 12 Sep 2018 21:48:51 +0200 Subject: [Scilab-Dev] type of structs and cells In-Reply-To: <711c5235-efd8-0860-a51d-19ec9a6e0eed@utc.fr> References: <711c5235-efd8-0860-a51d-19ec9a6e0eed@utc.fr> Message-ID: Hello St?phane, Le 12/09/2018 ? 17:02, St?phane Mottelet a ?crit : > Hi all, > > I hope some of you are still reading this list, which has a very low > traffic these days... I just discovered, while working on > > https://codereview.scilab.org/#/c/20491/ > > https://codereview.scilab.org/#/c/19114/ > > that cells have the same type number, although a different type > string. Hence, when you want to differentiate between structs, cells, > lists, mlists, tlists, you cannot rely on typeof(), I guess you meant that we must use the typeof() instead of type(). Anyway,... > since for mlists and tlists they return the usertype, neither on > type(), since it does not make the difference between cells and > structs. I know there exist isstruct() and iscell(), but why do we > have the same type number ?? I had the same question in mind for 2 years. So thanks for asking it here explicitly! Since in Scilab 6 cells and structs are now native types, it could have been the opportunity and the right moment to ascribe a dedicated type() number to each of them, out of their historical mlist type number 17. We may imagine that this conservatism is to avoid back-compatibility issues. However, when we look for the "*17*" pattern in the whole native *.sci Scilab files, we get only *85 possibly relevant hits in 58 files* (*.sci *.sce *.tst *.dia.ref *.c *.cpp *.java *.xml), over thousands of files. The full list is attached. This is much fewer than for some other features removed from 5.5 for 6.0. By the way, contrarily to a syntactic change like []+n that can't be tracked in the code, parsing any external user code for "*[^.0-9a-zA-Z%_:"'*/+-;]17[^.0-9a-zA-Z%_:"'*/+-;<]*" is very simple, to get on the spots and update relevant occurrences. So, to me, ascribing dedicated and separate type() numbers to cells and structures is still a relevant question, for Scilab 6.1. Scilab 6 aims to be more consistent. Ascribing new type codes to now native cells and structures looks possible at low cost. Best regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Search "[^.0-9a-zA-Z%_:"'*/+-;]17[^.0-9a-zA-Z%_:"'*/+-;<]" (85 hits in 58 files) \scilab\modules\atoms\macros\atoms_internals\atomsCatTree.sci (2 hits) Line 35: if type(tree_in_1) <> 17 then Line 39: if type(tree_in_2) <> 17 then \scilab\modules\atoms\macros\atoms_internals\atomsDepTreeExt.sci (2 hits) Line 160: if type(tree) == 17 then Line 175: if type(tree_out)==17 then \scilab\modules\atoms\macros\atoms_internals\atomsDepTreeFlat.sci (3 hits) Line 69: if (rhs==3) & (type(tree_in) <> 17) then Line 169: if type(tree) == 17 then Line 185: if type(tree_out)==17 then \scilab\modules\atoms\macros\atoms_internals\atomsDESCRIPTIONadd.sci (2 hits) Line 52: if type(tree_in) <> 17 then Line 64: if type(description) <> 17 then \scilab\modules\atoms\macros\atoms_internals\atomsDESCRIPTIONaddField.sci (1 hit) Line 53: if type(tree_in) <> 17 then \scilab\modules\atoms\macros\atoms_internals\atomsDESCRIPTIONcat.sci (7 hits) Line 61: if type(tree_in_1) <> 17 then Line 65: if type(tree_in_2) <> 17 then Line 156: if type(tree_in_1) <> 17 then Line 160: if type(tree_in_2) <> 17 then Line 218: if type(tree_in_1) <> 17 then Line 222: if type(tree_in_2) <> 17 then Line 244: if type(package_versions_struct) <> 17 then \scilab\modules\atoms\macros\atoms_internals\atomsDESCRIPTIONread.sci (1 hit) Line 79: if type(additional) <> 17 then \scilab\modules\atoms\macros\atoms_internals\atomsDESCRIPTIONrm.sci (1 hit) Line 52: if type(tree_in) <> 17 then \scilab\modules\atoms\macros\atoms_internals\atomsDESCRIPTIONwrite.sci (2 hits) Line 51: if type(description_in) <> 17 then Line 81: if type(package_versions_struct) <> 17 then \scilab\modules\atoms\macros\atoms_internals\atomsReadDesc.sci (1 hit) Line 38: if rhs==2 & type(description_in)<>17 then \scilab\modules\atoms\macros\atoms_internals\atomsRmfields.sci (1 hit) Line 30: if type(struct_in) <> 17 then \scilab\modules\atoms\macros\atoms_internals\atomsSaveInstalled.sci (1 hit) Line 29: if type(installed_struct) <> 17 then \scilab\modules\atoms\macros\atoms_internals\atomsSaveInstalleddeps.sci (1 hit) Line 48: if type(child_deps) <> 17 then \scilab\modules\compatibility_functions\macros\mstr2sci.sci (1 hit) Line 20: if type(x)==17 then \scilab\modules\core\macros\whos.sci (1 hit) Line 42: elseif _type == 17 | _type == 16 then \scilab\modules\core\tests\unit_tests\type.dia.ref (6 hits) Line 47: // struct <-> 17 Line 48: if type(struct()) <> 17 then bugmes();quit;end Line 49: // cell <-> 17 Line 50: if type(cell(1,1)) <> 17 then bugmes();quit;end \scilab\modules\core\tests\unit_tests\type.tst (6 hits) Line 65: // struct <-> 17 Line 66: if type(struct()) <> 17 then pause,end Line 68: // cell <-> 17 Line 69: if type(cell(1,1)) <> 17 then pause,end \scilab\modules\data_structures\macros\lstsize.sci (1 hit) Line 27: if type(var) <> 15 & type(var) <> 16 & type(var) <> 17 then \scilab\modules\development_tools\macros\assert\assert_checkequal.sci (2 hits) Line 73: if ( or(type(computed)==[16 17]) ) then Line 78: if ( or(type(expected)==[16 17]) ) then \scilab\modules\development_tools\macros\testexamples.sce (1 hit) Line 261: case 17 then //mlist \scilab\modules\elementary_functions\macros\isempty.sci (1 hit) Line 61: case 17 \scilab\modules\elementary_functions\macros\resize_matrix.sci (1 hit) Line 92: if ~(or(type(mat)~=[15 16 17]) .. \scilab\modules\external_objects_java\src\java\org\scilab\modules\external_objects_java\ScilabJavaObject.java (2 hits) Line 105: unwrappableType.put(short.class, 17); Line 141: unwrappableType.put(Short.class, 17); \scilab\modules\graphics\macros\%h_p.sci (1 hit) Line 1107: elseif or(td==17) then \scilab\modules\gui\macros\tree_show.sci (3 hits) Line 28: if type(x)<>16 & type(x)<>17 & type(x)<>15 & type(x)<>128 then Line 79: if type(x)==17 & v(1)=="st" then Line 89: if type(o)==16 | type(o)==17 | type(o)==128 then \scilab\modules\helptools\macros\xmltoformat.sci (8 hits) Line 1308: if type(desc_in_1) <> 17 then Line 1312: if type(desc_in_2) <> 17 then Line 1353: if type(tree) <> 17 then Line 1498: if type(tree) <> 17 then Line 1616: if type(tree_in_1) <> 17 then Line 1620: if type(tree_in_2) <> 17 then Line 1703: if type(tree) <> 17 then Line 1839: if type(tree) <> 17 then \scilab\modules\io\macros\%_sodload.sci (1 hit) Line 33: if or(type(var) == [15, 16, 17]) then \scilab\modules\linear_algebra\tests\nonreg_tests\bug_5017.dia.ref (1 hit) Line 158: if type(A)==16|type(A)==17 then \scilab\modules\linear_algebra\tests\nonreg_tests\bug_5017.tst (1 hit) Line 167: if type(A)==16|type(A)==17 then \scilab\modules\m2sci\help\en_US\m2scideclare.xml (1 hit) Line 96: Matlab cell (17) \scilab\modules\m2sci\help\fr_FR\m2scideclare.xml (1 hit) Line 101: Cell Matlab (17) \scilab\modules\m2sci\macros\kernel\infer2txt.sci (1 hit) Line 41: elseif tp==17 then \scilab\modules\m2sci\macros\kernel\sci_m2scideclare.sci (1 hit) Line 321: elseif tp==17 then \scilab\modules\m2sci\macros\sci_files\sci_char.sci (1 hit) Line 24: elseif A.vtype==16 | A.vtype==17 then \scilab\modules\overloading\macros\generic_i_h.sci (1 hit) Line 51: if type(index)==15 & and(type(property)<>[15 16 17]) then \scilab\modules\overloading\tests\nonreg_tests\bug_7244.dia.ref (1 hit) Line 21: assert_checkequal(type(foo), 17); \scilab\modules\overloading\tests\nonreg_tests\bug_7244.tst (1 hit) Line 22: assert_checkequal(type(foo), 17); \scilab\modules\scicos\macros\scicos_scicos\setvalue.sci (1 hit) Line 224: if type(%vv)<>15& type(%vv)<>16& type(%vv)<>17 then %noooo=-%kk,break,end \scilab\modules\scicos\macros\scicos_utils\find_scicos_version.sci (1 hit) Line 36: if type(scs_m)==17 || type(scs_m)==128 then \scilab\modules\scicos\macros\scicos_utils\scicos_getvalue.sci (1 hit) Line 269: if type(%vv)<>15& type(%vv)<>16& type(%vv)<>17 then %nok=-%kk,break,end \scilab\modules\scicos\tests\unit_tests\model\Clone_SuperBlock_in_Diagram.dia.ref (32 hits) ../.. \scilab\modules\scicos\tests\unit_tests\model\Deep_cloning.dia.ref (63 hits) ../.. \scilab\modules\scicos\tests\unit_tests\model\Delete_objects.dia.ref (15 hits) ../.. \scilab\modules\scicos\tests\unit_tests\model\Diagram.dia.ref (114 hits) ../.. \scilab\modules\scicos\tests\unit_tests\model\Diagram_cloning.dia.ref (16 hits) ../.. \scilab\modules\scicos\tests\unit_tests\model\from_mlist.dia.ref (42 hits) ../.. \scilab\modules\scicos\tests\unit_tests\model\Insert_in_SuperBlock.dia.ref (16 hits) ../.. \scilab\modules\scicos\tests\unit_tests\model\link_preservation.dia.ref (7 hits) ../.. \scilab\modules\scicos\tests\unit_tests\model\SuperBlock.dia.ref (143 hits) ../.. \scilab\modules\scicos_blocks\macros\Sinks\TOWS_c.sci (2 hits) Line 56: // If varnam already exists, then it must be of type struct (17) with fields "values" and "names". Line 58: execstr("if type("+varnam+") <> 17 | or(fieldnames("+varnam+") <> [""values""; ""time""]) then" + ... \scilab\modules\string\macros\prettyprint.sci (1 hit) Line 195: case 17 then \scilab\modules\string\macros\sci2exp.sci (3 hits) Line 103: case 17 then // cells, struct, mlists Line 737: elseif type(a.userdata) == 17 then Line 820: elseif type(a.userdata) == 17 then \scilab\modules\types\src\java\org\scilab\modules\types\ScilabTypeEnum.java (1 hit) Line 26: sci_mlist(17), \scilab\modules\xcos\tests\unit_tests\scicos_diagram.dia.ref (1 hit) Line 11: assert_checktrue(or(type(scs_m) == [17 128])); \scilab\modules\xcos\tests\unit_tests\scicos_diagram.tst (1 hit) Line 15: assert_checktrue(or(type(scs_m) == [17 128])); \scilab\modules\xcos\tests\unit_tests\xcos_simulate.tst (2 hits) Line 15: assert_checkequal(type(scs_m), 17); Line 26: assert_checkequal(type(scs_m), 17); From stephane.mottelet at utc.fr Wed Sep 12 22:08:25 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Wed, 12 Sep 2018 22:08:25 +0200 Subject: [Scilab-Dev] type of structs and cells In-Reply-To: References: <711c5235-efd8-0860-a51d-19ec9a6e0eed@utc.fr> Message-ID: <7ad98ccb-ae66-18b1-ce6e-e9f62ee67021@utc.fr> Le 12/09/2018 ? 21:48, Samuel Gougeon a ?crit?: > Hello St?phane, > > Le 12/09/2018 ? 17:02, St?phane Mottelet a ?crit?: >> Hi all, >> >> I hope some of you are still reading this list, which has a very low >> traffic these days... I just discovered, while working on >> >> https://codereview.scilab.org/#/c/20491/ >> >> https://codereview.scilab.org/#/c/19114/ >> >> that cells have the same type number, although a different type >> string. Hence, when you want to differentiate between structs, cells, >> lists, mlists, tlists, you cannot rely on typeof(), > > I guess you meant that we must use the typeof() instead of type(). > Anyway,... > >> since for mlists and tlists they return the usertype, neither on >> type(), since it does not make the difference between cells and >> structs. I know there exist isstruct() and iscell(), but why do we >> have the same type number ?? > > I had the same question in mind for 2 years. So thanks for asking it > here explicitly! > > Since in Scilab 6 cells and structs are now native types, it could > have been the opportunity and the right moment to ascribe a dedicated > type() number to each of them, out of their historical mlist type > number 17. > > We may imagine that this conservatism is to avoid back-compatibility > issues. There is more than that. For Scilab 6 structs, for k=1,2 getfield(k,...) returns the same result as Scilab 5.5.2 --> str=struct("a",1,"b",1) ?str? = ? a: [1x1 constant] ? b: [1x1 constant] --> getfield(1,str) ?ans? = !st? dims? a? b? ! --> getfield(2,str) ?ans? = ? 1? 1 as if str, in this example, was still a mlist. This is so artificial, but certainely necessary ! > However, when we look for the "*17*" pattern in the whole native *.sci > Scilab files, we get only *85 possibly relevant hits in 58 files* > (*.sci *.sce *.tst *.dia.ref *.c *.cpp *.java *.xml), over thousands > of files. > The full list is attached. > > This is much fewer than for some other features removed from 5.5 for > 6.0. By the way, contrarily to a syntactic change like []+n that can't > be tracked in the code, parsing any external user code for > "*[^.0-9a-zA-Z%_:"'*/+-;]17[^.0-9a-zA-Z%_:"'*/+-;<]*" is very simple, > to get on the spots and update relevant occurrences. > > So, to me, ascribing dedicated and separate type() numbers to cells > and structures is still a relevant question, for Scilab 6.1. > Scilab 6 aims to be more consistent. Ascribing new type codes to now > native cells and structures looks possible at low cost. > > Best 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 Sep 12 22:21:22 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 12 Sep 2018 22:21:22 +0200 Subject: [Scilab-Dev] type of structs and cells In-Reply-To: <7ad98ccb-ae66-18b1-ce6e-e9f62ee67021@utc.fr> References: <711c5235-efd8-0860-a51d-19ec9a6e0eed@utc.fr> <7ad98ccb-ae66-18b1-ce6e-e9f62ee67021@utc.fr> Message-ID: <2de5c391-b12c-2460-1865-ccabe6ff24a9@free.fr> Le 12/09/2018 ? 22:08, St?phane Mottelet a ?crit : > > Le 12/09/2018 ? 21:48, Samuel Gougeon a ?crit : > >> Hello St?phane, >> >> Le 12/09/2018 ? 17:02, St?phane Mottelet a ?crit : >>> Hi all, >>> >>> I hope some of you are still reading this list, which has a very low >>> traffic these days... I just discovered, while working on >>> >>> https://codereview.scilab.org/#/c/20491/ >>> >>> https://codereview.scilab.org/#/c/19114/ >>> >>> that cells have the same type number, although a different type >>> string. Hence, when you want to differentiate between structs, >>> cells, lists, mlists, tlists, you cannot rely on typeof(), >> >> I guess you meant that we must use the typeof() instead of type(). >> Anyway,... >> >>> since for mlists and tlists they return the usertype, neither on >>> type(), since it does not make the difference between cells and >>> structs. I know there exist isstruct() and iscell(), but why do we >>> have the same type number ?? >> >> I had the same question in mind for 2 years. So thanks for asking it >> here explicitly! >> >> Since in Scilab 6 cells and structs are now native types, it could >> have been the opportunity and the right moment to ascribe a dedicated >> type() number to each of them, out of their historical mlist type >> number 17. >> >> We may imagine that this conservatism is to avoid back-compatibility >> issues. > > There is more than that. For Scilab 6 structs, for k=1,2 > getfield(k,...) returns the same result as Scilab 5.5.2 > > --> str=struct("a",1,"b",1) > str = > > a: [1x1 constant] > b: [1x1 constant] > > > --> getfield(1,str) > ans = > > !st dims a b ! > > > --> getfield(2,str) > ans = > > 1 1 > > as if str, in this example, was still a mlist. This is so artificial, > but certainely necessary ! I must confess that i did not catch how the bug 15034 has been processed. I feel rather concerned about its processing. It looks to create an "hybrid/duplicate" type/typeof for struct(), so killing the announcement they are native type in Scilab 6. To me, AFAIU, this is a confusing and worrying way to fix the bug 15234 . Unless struct are finally not native at all in Scilab 6. If so, the CHANGES file and the documentation should be fixed to cancel the announcement. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Thu Sep 13 00:09:39 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 13 Sep 2018 00:09:39 +0200 Subject: [Scilab-Dev] type of structs and cells In-Reply-To: <7ad98ccb-ae66-18b1-ce6e-e9f62ee67021@utc.fr> References: <711c5235-efd8-0860-a51d-19ec9a6e0eed@utc.fr> <7ad98ccb-ae66-18b1-ce6e-e9f62ee67021@utc.fr> Message-ID: <1e9eaaad-6a12-143d-e072-80392f8bf638@free.fr> Le 12/09/2018 ? 22:08, St?phane Mottelet a ?crit : > > Le 12/09/2018 ? 21:48, Samuel Gougeon a ?crit : > >> Hello St?phane, >> >> Le 12/09/2018 ? 17:02, St?phane Mottelet a ?crit : >>> Hi all, >>> >>> I hope some of you are still reading this list, which has a very low >>> traffic these days... I just discovered, while working on >>> >>> https://codereview.scilab.org/#/c/20491/ >>> >>> https://codereview.scilab.org/#/c/19114/ >>> >>> that cells have the same type number, although a different type >>> string. Hence, when you want to differentiate between structs, >>> cells, lists, mlists, tlists, you cannot rely on typeof(), >> >> I guess you meant that we must use the typeof() instead of type(). >> Anyway,... >> >>> since for mlists and tlists they return the usertype, neither on >>> type(), since it does not make the difference between cells and >>> structs. I know there exist isstruct() and iscell(), but why do we >>> have the same type number ?? >> >> I had the same question in mind for 2 years. So thanks for asking it >> here explicitly! >> >> Since in Scilab 6 cells and structs are now native types, it could >> have been the opportunity and the right moment to ascribe a dedicated >> type() number to each of them, out of their historical mlist type >> number 17. >> >> We may imagine that this conservatism is to avoid back-compatibility >> issues. > > There is more than that. For Scilab 6 structs, for k=1,2 > getfield(k,...) returns the same result as Scilab 5.5.2 > > --> str=struct("a",1,"b",1) > str = > > a: [1x1 constant] > b: [1x1 constant] > > > --> getfield(1,str) > ans = > > !st dims a b ! > > > --> getfield(2,str) > ans = > > 1 1 > > as if str, in this example, was still a mlist. This is so artificial, > but certainely necessary ! I don't see why. In reading mode, it is possible to retrieve all struct information in a more direct and handy way: > --> getfield(1,str) > ans = > !st dims a b ! typeof(str) // returns "st" : OK fieldnames(str) // returns ["a" "b"] : OK > --> getfield(2,str) > ans = > 1 1 size(str) // returns dims values: OK In addition: getfield(3, s) // returns the list of values for the "a" field clear s s.a = %pi s(1,2).a = %i s(1).t = "Hi" s(2).t = "Bonjour" * getfield(3, s)** // But s(:).a returns the same, without using getfield(). // => So getfield() is now useless for struct()** **s(:).a** * --> getfield(3, s) ans = ans(1) 3.1415927 ans(2) i --> // But s(:).a returns the same, without using getfield(). So getfield() is now useless for struct() --> s(:).a ans = ans(1) 3.1415927 ans(2) i So: usage of getfield() with structures could and should now be completely prevented. The main issue with new native structures is that, for an array of structures, it is no longer possible to set the whole set of values of a field , neither with a .field syntax nor with setfield()... But it is hard to see why it could not be implemented, or at least reimplemented with setfield(), without reintroducing struct as mlist(). Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Fri Sep 14 18:20:42 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 14 Sep 2018 18:20:42 +0200 Subject: [Scilab-Dev] algebra conventions with integer types to be discussed Message-ID: <6ca39921-b002-731b-7631-b730254ae8b9@utc.fr> Hello all, Integer types in Scilab are not smoothly implemented and there are still some bugs and real questions to be discussed, specifically on over/underflow, exceptions in divisions such as in int8(1)/int8(0) int8(-128)/int8(-1) type of the result of mixed double/integer operations, such as int8(1) + %pi int8(1)/0.0 and so on. Other software related to Scilab, e.g. Matlab and Julia, have different conventions and currently Scilab currently adopts a mix of them, which does not help to make one's mind. Integers types were a long-waited feature by people who needed it, so I would like to have some? developpers and user testimonies about the way they do algebra with them. Thanks in adavance, S. -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet From stephane.mottelet at utc.fr Mon Sep 17 19:03:11 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Mon, 17 Sep 2018 19:03:11 +0200 Subject: [Scilab-Dev] [Scilab-users] algebra conventions with integer types to be discussed In-Reply-To: <6ca39921-b002-731b-7631-b730254ae8b9@utc.fr> References: <6ca39921-b002-731b-7631-b730254ae8b9@utc.fr> Message-ID: Le 14/09/2018 ? 18:20, St?phane Mottelet a ?crit?: > Hello all, > > Integer types in Scilab are not smoothly implemented and there are > still some bugs and real questions to be discussed, specifically on > over/underflow, exceptions in divisions such as in > > int8(1)/int8(0) > > int8(-128)/int8(-1) > > type of the result of mixed double/integer operations, such as > > int8(1) + %pi > > int8(1)/0.0 > > and so on. Other software related to Scilab, e.g. Matlab and Julia, > have different conventions and currently Scilab currently adopts a mix > of them, which does not help to make one's mind. > > Integers types were a long-waited feature by people who needed it, so > I would like to have some? developpers and user testimonies about the > way they do algebra with them. > > Thanks in adavance, > > S. > Hello all, Do I have to conclude that the implementation is currently so incoherent that *nobody* uses integer types in Scilab (other than Scilab code itself) ? S. -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet From stephane.mottelet at utc.fr Wed Sep 26 17:46:20 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Wed, 26 Sep 2018 17:46:20 +0200 Subject: [Scilab-Dev] ilib_build with C++ and Fortran sources Message-ID: <40a38c88-12a0-6eb4-cebb-59e38d7948c4@utc.fr> Hello, I am trying to build a c++ gateway to a fortran subtroutine, hence I have one .cpp and one .f file. I have tried this : files=["sci_mesh2d.cpp";"deumesh.f"] ilib_build("mesh2d", ["mesh2d" "sci_mesh2d" "cppsci"],files, []) but I got a completely weird error : libtool: compile: unrecognized option `-I/Users/mottelet/scilab/scilab-6.0.1/scilab-6.0.1.app/Contents/MacOS/share/scilab/../../include/scilab/' libtool: compile: Try `libtool --help' for more information. make: *** [deumesh.lo] Error 1 I guess this is the fortran compiler which complains about the -I option (why ?). So I would like to know which compiler/linker flags I have to give to ilib_build. Note: I am able to build other gateways based on c++ sources only without problem. S. -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet From clement.david at scilab-enterprises.com Thu Sep 27 09:00:46 2018 From: clement.david at scilab-enterprises.com (=?utf-8?B?Q2zDqW1lbnQgREFWSUQ=?=) Date: Thu, 27 Sep 2018 07:00:46 +0000 Subject: [Scilab-Dev] ilib_build with C++ and Fortran sources In-Reply-To: <40a38c88-12a0-6eb4-cebb-59e38d7948c4@utc.fr> References: <40a38c88-12a0-6eb4-cebb-59e38d7948c4@utc.fr> Message-ID: Hello Stephane, I strongly suggest you to keep fortran in a separate lib rather than passing all sources files (whatever the language) to be linked together. Passing all of them together imply that the compilers will handle similar command-line arguments which is not the case in your system. Could you send us the config.log file from the toolbox ? Thanks for your work on Metanet, do not hesitate to ask if you need support :p -- Cl?ment -----Original Message----- From: dev On Behalf Of St?phane Mottelet Sent: Wednesday, September 26, 2018 5:46 PM To: List dedicated to development questions Subject: [Scilab-Dev] ilib_build with C++ and Fortran sources Hello, I am trying to build a c++ gateway to a fortran subtroutine, hence I have one .cpp and one .f file. I have tried this : files=["sci_mesh2d.cpp";"deumesh.f"] ilib_build("mesh2d", ["mesh2d" "sci_mesh2d" "cppsci"],files, []) but I got a completely weird error : libtool: compile: unrecognized option `-I/Users/mottelet/scilab/scilab-6.0.1/scilab-6.0.1.app/Contents/MacOS/share/scilab/../../include/scilab/' libtool: compile: Try `libtool --help' for more information. make: *** [deumesh.lo] Error 1 I guess this is the fortran compiler which complains about the -I option (why ?). So I would like to know which compiler/linker flags I have to give to ilib_build. Note: I am able to build other gateways based on c++ sources only without problem. S. -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet _______________________________________________ dev mailing list dev at lists.scilab.org http://lists.scilab.org/mailman/listinfo/dev From stephane.mottelet at utc.fr Fri Sep 28 10:21:17 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 28 Sep 2018 10:21:17 +0200 Subject: [Scilab-Dev] (c++) sparse matrix creation Message-ID: <6d52d08a-0c04-22a0-7c08-b38976fb11b3@utc.fr> Hello all, After searching in sparse.hxx and sparse.cpp I didn' find a method in class Sparse:: allowing to create a matrix of given dimensions with preallocation of memory for an initial number of non-zero terms, i.e. such as Sparse(int rows, int cols, int nnz, bool cplx = false); Does such a mehtod exist ? S. -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet From stephane.mottelet at utc.fr Fri Sep 28 10:27:12 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 28 Sep 2018 10:27:12 +0200 Subject: [Scilab-Dev] (c++) sparse matrix creation In-Reply-To: <6d52d08a-0c04-22a0-7c08-b38976fb11b3@utc.fr> References: <6d52d08a-0c04-22a0-7c08-b38976fb11b3@utc.fr> Message-ID: <82d9aea0-a4d8-e613-48c4-7f5f2d975482@utc.fr> Le 28/09/2018 ? 10:21, St?phane Mottelet a ?crit?: > Hello all, > > After searching in sparse.hxx and sparse.cpp I didn' find a method in > class Sparse:: allowing to create a matrix of given dimensions with > preallocation of memory for an initial number of non-zero terms, i.e. > such as > > Sparse(int rows, int cols, int nnz, bool cplx = false); > > Does such a mehtod exist ? > > S. > maybe types::Sparse* pS : new Sparse(rows, cols) pS->matrixReal->reserve(nnz) ? -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet From stephane.mottelet at utc.fr Fri Sep 28 16:46:10 2018 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 28 Sep 2018 16:46:10 +0200 Subject: [Scilab-Dev] ilib_build with C++ and Fortran sources In-Reply-To: References: <40a38c88-12a0-6eb4-cebb-59e38d7948c4@utc.fr> Message-ID: <405675b9-ddb8-b5e8-6724-30256c747aaf@utc.fr> Hello Cl?ment, I have two kinds of behavior between 6.0.1 and branch-6.0. Under 6.0.1, I am not even able to build toolbox_skeleton, with the same error message (problem when compiling fortran, again) -- Cr?ation de [toolbox_skeletonlib] (Macros) -- genlib : Traitement du fichier : scilab_error.sci genlib : Traitement du fichier : scilab_sum.sci Cr?ation des sources... ?(...) ilib_compile : Une erreur s'est produite lors de la compilation libtool: compile: unrecognized option `-I/Applications/scilab-6.0.1.app/Contents/MacOS/share/scilab/../../include/scilab/' libtool: compile: Try `libtool --help' for more information. make: *** [fsum.lo] Error 1 ilib_compile : La commande ?tait :make? CFLAGS=" -D__SCILAB_TOOLBOX__ -I/Applications/scilab-6.0.1.app/Contents/MacOS/share/scilab/../../include/scilab/ -I/Applications/scilab-6.0.1.app/Contents/MacOS/share/scilab/../../include/ " CXXFLAGS=" -D__SCILAB_TOOLBOX__ -I/Applications/scilab-6.0.1.app/Contents/MacOS/share/scilab/../../include/scilab/ -I/Applications/scilab-6.0.1.app/Contents/MacOS/share/scilab/../../include/ " FFLAGS="-I/Applications/scilab-6.0.1.app/Contents/MacOS/share/scilab/../../include/scilab/ " Under branch-6.0, I can build toolbox_skeleton, The first fortan files are rapidely processed,? but when the first c or c++ files have to be compiled, ilib_gen_make reruns the configure script and it takes almost 5 minutes to complete ! -- Creation of [toolbox_skeletonlib] (Macros) -- Building sources... ?? Generate a loader file ?? Generate a Makefile ?? ilib_gen_Make: Copy compilation files (Makefile*, libtool...) to TMPDIR ?? ilib_gen_Make: Copy fsum.f to TMPDIR ?? ilib_gen_Make: Modification of the Makefile in TMPDIR. ?? Running the Makefile ?? Generate a cleaner file ?? Generate a loader file ?? Generate a Makefile ?? ilib_gen_Make: Copy compilation files (Makefile*, libtool...) to TMPDIR ?? ilib_gen_Make: Copy csum.c to TMPDIR ?? ilib_gen_Make: Copy csub.c to TMPDIR ?? ilib_gen_Make: Copy multiplybypi.c to TMPDIR ?? ilib_gen_Make: configure : Generate Makefile. 5 minutes stuck here. Do you have an idea ? S. Le 27/09/2018 ? 09:00, Cl?ment DAVID a ?crit?: > Hello Stephane, > > I strongly suggest you to keep fortran in a separate lib rather than passing all sources files (whatever the language) to be linked together. Passing all of them together imply that the compilers will handle similar command-line arguments which is not the case in your system. Could you send us the config.log file from the toolbox ? > > Thanks for your work on Metanet, do not hesitate to ask if you need support :p > > -- > Cl?ment > > -----Original Message----- > From: dev On Behalf Of St?phane Mottelet > Sent: Wednesday, September 26, 2018 5:46 PM > To: List dedicated to development questions > Subject: [Scilab-Dev] ilib_build with C++ and Fortran sources > > Hello, > > I am trying to build a c++ gateway to a fortran subtroutine, hence I have one .cpp and one .f file. I have tried this : > > files=["sci_mesh2d.cpp";"deumesh.f"] > ilib_build("mesh2d", ["mesh2d" "sci_mesh2d" "cppsci"],files, []) > > but I got a completely weird error : > > libtool: compile: unrecognized option > `-I/Users/mottelet/scilab/scilab-6.0.1/scilab-6.0.1.app/Contents/MacOS/share/scilab/../../include/scilab/' > libtool: compile: Try `libtool --help' for more information. > make: *** [deumesh.lo] Error 1 > > I guess this is the fortran compiler which complains about the -I option (why ?). So I would like to know which compiler/linker flags I have to give to ilib_build. > > Note: I am able to build other gateways based on c++ sources only without problem. > > S. > > -- > St?phane Mottelet > Ing?nieur de recherche > EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.utc.fr/~mottelet > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev > _______________________________________________ > dev mailing list > dev at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev -- St?phane Mottelet Ing?nieur de recherche EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable D?partement G?nie des Proc?d?s Industriels Sorbonne Universit?s - Universit? de Technologie de Compi?gne CS 60319, 60203 Compi?gne cedex Tel : +33(0)344234688 http://www.utc.fr/~mottelet From sgougeon at free.fr Sat Sep 29 21:34:52 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 29 Sep 2018 21:34:52 +0200 Subject: [Scilab-Dev] [Scilab-users] bug when setting gcbo field in a callback function ? In-Reply-To: References: <3c4c2a81-a832-842c-4ce6-cde22922317f@laas.fr> <07b1519a-328d-947c-5968-ca3d7746df51@utc.fr> <17fd9bd0-d569-48df-5104-51c53c45f06f@free.fr> <85583a4c-6299-a848-dc19-28a851502370@laas.fr> <1E0A4216-7B9A-4CBC-8113-441051DF9B8D@utc.fr> Message-ID: <627b5c0d-d5de-64d8-88e7-237b6a8f63e3@free.fr> This is a follow-up of the users@ thread http://mailinglists.scilab.org/Scilab-users-bug-when-setting-gcbo-field-in-a-callback-function-tp4038615.html Le 29/09/2018 ? 18:16, St?phane Mottelet a ?crit : > Another example of such weirdness: consider (fixed) bug #13359. Its > non-regression test fail (at least on my OSX and Linux machines) > systematicaly when run by > > --> test_run cacsd bug_13359 > > When run interactively by > > --> exec SCI/modules/cacsd/tests/nonreg_tests/bug_13359.tst > > it sometimes succeed and sometimes fail, this completely random. > However, if you insert a sleep line 25 > > (...) > d1 = datatipCreate(pl, 200); > sleep(10) // line inserted > txt_datatip = d1.text; > assert_checkequal(strindex(txt_datatip(2), "-"), 1); > > Then the test, executed by exec SCI/... above, always succeed. > However, even with a bigger duration of sleep, even sleep(1000), then > "test_run cacsd bug_13359" always fail. It is here really another bug, about datatip rendering: when we increase the sleep() time -- say up to 10 s --, we have enough time to see that the datatip is created -- its square anchor is visible -- but stays empty for the whole sleep time (so d1.text==""). Hence, it's not just a matter of delay: something is wrong about datatips rendering when things are done in a Scilab session created inside the current session (this is what test_run does): The test_run environment definitely cancels the rendering of the datatip label. I tried * without the TEST-WITH-GRAPHIC mode, to cancel the -nw option when running the test: same issue * with get(d1,"text") instead of d1.text: as expected, same (upstream) issue * with a drawnow, or gcf().immediate_drawing="on", or gcf().visible="off" // + "on": this does not cancels the bug I also tried in NO-CHECK-REF mode in order to cancel opening a diary, but this is not the case: A diary is opened anyway. But opening a diary in the current session before directly running exec(the_test_file) does not yield the issue. To be more explored... Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Sat Sep 29 21:43:19 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 29 Sep 2018 21:43:19 +0200 Subject: [Scilab-Dev] [Scilab-users] bug when setting gcbo field in a callback function ? In-Reply-To: <627b5c0d-d5de-64d8-88e7-237b6a8f63e3@free.fr> References: <3c4c2a81-a832-842c-4ce6-cde22922317f@laas.fr> <07b1519a-328d-947c-5968-ca3d7746df51@utc.fr> <17fd9bd0-d569-48df-5104-51c53c45f06f@free.fr> <85583a4c-6299-a848-dc19-28a851502370@laas.fr> <1E0A4216-7B9A-4CBC-8113-441051DF9B8D@utc.fr> <627b5c0d-d5de-64d8-88e7-237b6a8f63e3@free.fr> Message-ID: <130a9440-7494-9b21-5e09-7f958f6312e6@free.fr> Le 29/09/2018 ? 21:34, Samuel Gougeon a ?crit : > .../... > Le 29/09/2018 ? 18:16, St?phane Mottelet a ?crit : >> Another example of such weirdness: consider (fixed) bug #13359. Its >> non-regression test fail (at least on my OSX and Linux machines) >> systematicaly when run by >> >> --> test_run cacsd bug_13359 >> >> When run interactively by >> >> --> exec SCI/modules/cacsd/tests/nonreg_tests/bug_13359.tst When running exec directly in -nw mode does not yield the rendering bug From sgougeon at free.fr Sat Sep 29 22:03:34 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 29 Sep 2018 22:03:34 +0200 Subject: [Scilab-Dev] [Scilab-users] bug when setting gcbo field in a callback function ? In-Reply-To: <627b5c0d-d5de-64d8-88e7-237b6a8f63e3@free.fr> References: <3c4c2a81-a832-842c-4ce6-cde22922317f@laas.fr> <07b1519a-328d-947c-5968-ca3d7746df51@utc.fr> <17fd9bd0-d569-48df-5104-51c53c45f06f@free.fr> <85583a4c-6299-a848-dc19-28a851502370@laas.fr> <1E0A4216-7B9A-4CBC-8113-441051DF9B8D@utc.fr> <627b5c0d-d5de-64d8-88e7-237b6a8f63e3@free.fr> Message-ID: Le 29/09/2018 ? 21:34, Samuel Gougeon a ?crit : > This is a follow-up of the users@ thread > http://mailinglists.scilab.org/Scilab-users-bug-when-setting-gcbo-field-in-a-callback-function-tp4038615.html > > Le 29/09/2018 ? 18:16, St?phane Mottelet a ?crit : >> Another example of such weirdness: consider (fixed) bug #13359. Its >> non-regression test fail (at least on my OSX and Linux machines) >> systematicaly when run by >> >> --> test_run cacsd bug_13359 >> >> When run interactively by >> >> --> exec SCI/modules/cacsd/tests/nonreg_tests/bug_13359.tst >> >> it sometimes succeed and sometimes fail, this completely random. >> However, if you insert a sleep line 25 >> >> (...) >> d1 = datatipCreate(pl, 200); >> sleep(10) // line inserted >> txt_datatip = d1.text; >> assert_checkequal(strindex(txt_datatip(2), "-"), 1); >> >> Then the test, executed by exec SCI/... above, always succeed. >> However, even with a bigger duration of sleep, even sleep(1000), then >> "test_run cacsd bug_13359" always fail. > > It is here really another bug, about datatip rendering: when we > increase the sleep() time -- say up to 10 s --, we have enough time to > see that the datatip is created -- its square anchor is visible -- but > stays empty for the whole sleep time (so d1.text==""). > Hence, it's not just a matter of delay: something is wrong about > datatips rendering when things are done in a Scilab session created > inside the current session (this is what test_run does): The test_run > environment definitely cancels the rendering of the datatip label. > I tried > > * without the TEST-WITH-GRAPHIC mode, to cancel the -nw option when > running the test: same issue > * with get(d1,"text") instead of d1.text: as expected, same > (upstream) issue > * with a drawnow, or gcf().immediate_drawing="on", or > gcf().visible="off" // + "on": this does not cancels the bug > > I also tried in NO-CHECK-REF mode in order to cancel opening a diary, > but this is not the case: A diary is opened anyway. > But opening a diary in the current session before directly running > exec(the_test_file) does not yield the issue. > > To be more explored... I've got it: this bug is due to the -quit option used to run the test_run scilab session: removing it uncancels the datatip rendering. Since the -quit option is needed to cancel the test when a syntax error occurs in it, this is still only a first step to fix the issue... -------------- next part -------------- An HTML attachment was scrubbed... URL: