From arjun.2131 at gmail.com Tue Jul 3 20:58:46 2018 From: arjun.2131 at gmail.com (iraj21) Date: Tue, 3 Jul 2018 11:58:46 -0700 (MST) Subject: [Scilab-Dev] Looking for projects Message-ID: <1530644326377-0.post@n3.nabble.com> Hi, Im an absolute beginner and would like to contribute to Scilab. Can anybody find me something that a beginner can do. Thanking you Arjun Raj -- Sent from: http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944.html From stephane.mottelet at utc.fr Tue Jul 3 22:03:41 2018 From: stephane.mottelet at utc.fr (=?utf-8?Q?St=C3=A9phane_Mottelet?=) Date: Tue, 3 Jul 2018 22:03:41 +0200 Subject: [Scilab-Dev] Looking for projects In-Reply-To: <1530644326377-0.post@n3.nabble.com> References: <1530644326377-0.post@n3.nabble.com> Message-ID: Fix bugs ! S. > Le 3 juil. 2018 ? 20:58, iraj21 a ?crit : > > Hi, > Im an absolute beginner and would like to contribute to Scilab. Can anybody > find me something that a beginner can do. > > Thanking you > Arjun Raj > > > > -- > Sent from: https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944.html > _______________________________________________ > dev mailing list > dev at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev From caioc2bolado at gmail.com Wed Jul 4 18:13:19 2018 From: caioc2bolado at gmail.com (Caio Souza) Date: Wed, 4 Jul 2018 13:13:19 -0300 Subject: [Scilab-Dev] Looking for projects In-Reply-To: References: <1530644326377-0.post@n3.nabble.com> Message-ID: Two helpful links: setup scilab repo scilab bug tracker For the bug tracker search for something you have interest or is more used to work with. On Tue, Jul 3, 2018 at 5:03 PM, St?phane Mottelet wrote: > Fix bugs ! > > S. > > > Le 3 juil. 2018 ? 20:58, iraj21 a ?crit : > > > > Hi, > > Im an absolute beginner and would like to contribute to Scilab. Can > anybody > > find me something that a beginner can do. > > > > Thanking you > > Arjun Raj > > > > > > > > -- > > Sent from: https://antispam.utc.fr/proxy/1/ > c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/mailinglists.scilab.org/ > Scilab-developers-Mailing-Lists-Archives-f2574944.html > > _______________________________________________ > > dev mailing list > > dev at lists.scilab.org > > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLm > Zy/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 arjun.2131 at gmail.com Thu Jul 5 10:36:16 2018 From: arjun.2131 at gmail.com (iraj21) Date: Thu, 5 Jul 2018 01:36:16 -0700 (MST) Subject: [Scilab-Dev] Looking for projects In-Reply-To: References: <1530644326377-0.post@n3.nabble.com> Message-ID: <1530779776983-0.post@n3.nabble.com> Can anyone help me in starting off on how to fix bugs -- Sent from: http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944.html From caioc2bolado at gmail.com Thu Jul 5 17:13:10 2018 From: caioc2bolado at gmail.com (Caio Souza) Date: Thu, 5 Jul 2018 12:13:10 -0300 Subject: [Scilab-Dev] Looking for projects In-Reply-To: <1530779776983-0.post@n3.nabble.com> References: <1530644326377-0.post@n3.nabble.com> <1530779776983-0.post@n3.nabble.com> Message-ID: Hi, Its hard to help when you are not clear on what exactly you need. Did you tried to setup your repository? Thats the first thing you should do. If you nave troubles setting it up, then tell exactly whats going wrong and people may try to help. If you have troubles chosing a bug to fix, you can start with coverity issues. On qui, 5 de jul de 2018 05:36 iraj21 wrote: > Can anyone help me in starting off on how to fix bugs > > > > -- > Sent from: > http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944.html > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Jul 20 13:58:32 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 20 Jul 2018 13:58:32 +0200 Subject: [Scilab-Dev] untrackable recent gdf() changes? Message-ID: Dear devs, On the period [2018-02-15 (6.0.1 release), 2018-06-21 (my 6.0-branch session)], something was changed since at the session startup, *gdf().figure_name* returns * *"Figure n?%d"* with 6.0.1 official * *"Graphic window number %d" * with 6.0-branch of 2018-06-21 This impacts and was detecting while running the test *test_run graphics clf show_error* that now fails due to this change.* * The only code file where *"Graphic window number %d"* is set is scilab/modules/graphics/src/c/InitObjects.c (1 hit) Line 116: setGraphicObjectProperty(iFiguremdlUID, __GO_NAME__, _("Graphic window number %d"), jni_string, 1); and http://gitweb.scilab.org/?p=scilab.git;a=history;f=... tells that its latest change was on *2016-05* The only code file where *"Figure %d"* is set is C:\Users\Samuel\Desktop\DOSSIERS\Scilab\scripts\dev\_netbeans\Scilab\scilab\modules\graphics\sci_gateway\cpp\sci_xset.cpp (1 hit) Line 357: setGraphicObjectProperty(iFigureUID, __GO_NAME__, _("Figure n?%d"), jni_string, 1); and http://gitweb.scilab.org/?p=scilab.git;a=history;f=... tells that its latest change was on *2017-02* So, the cause of the issue looks not direct. Any idea about the underlaying change causing the trouble? Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Jul 20 20:24:23 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 20 Jul 2018 20:24:23 +0200 Subject: [Scilab-Dev] legacy 5.x syntax deserves to be abandonned In-Reply-To: <1026695b-3657-3c2c-5d13-4c7c0d206c9a@utc.fr> References: <1026695b-3657-3c2c-5d13-4c7c0d206c9a@utc.fr> Message-ID: Le 22/06/2018 ? 10:28, St?phane Mottelet a ?crit : > Hello, > > While fixing > > http://bugzilla.scilab.org/show_bug.cgi?id=15623 > http://bugzilla.scilab.org/show_bug.cgi?id=15624 > > I discovered that gross syntax errors such as > > max(,), max(1,) mean(,)... > > are not trapped by the parser. As a consequence, tokens of type > internalType:ScilabVoid are given to the gateway in the input arguments. > > There are a lot of scilab functions which do not correctly handle > this. For example, > > max(1,) and atan(1,) crash Scilab > > max(,), gives a message about a missing overloading function for > ScilabVoid type. > > Why such an dumb syntax has been kept as valid in Scilab 6 ? Does even > somebody remember if there exist some legacy code needing this ? > > There is a potentially huge number of gateways to be fixed because of > this too permissive syntax. If you consider the very close syntaxes like myfun(a, , c) or myfun(, b, c) also as too permissive and to be forbidden, then we would definitely disagree: To me, they are to most handy way to skip an argument (obviously provided that myfun() handles it correctly). Does your proposed patch also prevent them? Samuel From stephane.mottelet at utc.fr Fri Jul 20 20:30:46 2018 From: stephane.mottelet at utc.fr (=?utf-8?Q?St=C3=A9phane_Mottelet?=) Date: Fri, 20 Jul 2018 20:30:46 +0200 Subject: [Scilab-Dev] legacy 5.x syntax deserves to be abandonned In-Reply-To: References: <1026695b-3657-3c2c-5d13-4c7c0d206c9a@utc.fr> Message-ID: <38FAA535-BF33-48CE-A33C-37E65664FB3E@utc.fr> > Le 20 juil. 2018 ? 20:24, Samuel Gougeon a ?crit : > >> Le 22/06/2018 ? 10:28, St?phane Mottelet a ?crit : >> Hello, >> >> While fixing >> >> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=15623 >> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=15624 >> >> I discovered that gross syntax errors such as >> >> max(,), max(1,) mean(,)... >> >> are not trapped by the parser. As a consequence, tokens of type internalType:ScilabVoid are given to the gateway in the input arguments. >> >> There are a lot of scilab functions which do not correctly handle this. For example, >> >> max(1,) and atan(1,) crash Scilab >> >> max(,), gives a message about a missing overloading function for ScilabVoid type. >> >> Why such an dumb syntax has been kept as valid in Scilab 6 ? Does even somebody remember if there exist some legacy code needing this ? >> >> There is a potentially huge number of gateways to be fixed because of this too permissive syntax. > > > If you consider the very close syntaxes like > myfun(a, , c) > or > myfun(, b, c) > also as too permissive and to be forbidden, then we would definitely disagree: > > To me, they are to most handy way to skip an argument (obviously provided that myfun() handles it correctly). The problem is that the number of functions that actually *do not* handle it is unknown/unbounded.... S. > > Does your proposed patch also prevent them? > > Samuel > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev From sgougeon at free.fr Fri Jul 20 20:49:40 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 20 Jul 2018 20:49:40 +0200 Subject: [Scilab-Dev] legacy 5.x syntax deserves to be abandonned In-Reply-To: <38FAA535-BF33-48CE-A33C-37E65664FB3E@utc.fr> References: <1026695b-3657-3c2c-5d13-4c7c0d206c9a@utc.fr> <38FAA535-BF33-48CE-A33C-37E65664FB3E@utc.fr> Message-ID: <2277d51d-d604-6272-8867-6210c0b2bcf7@free.fr> Le 20/07/2018 ? 20:30, St?phane Mottelet a ?crit : > >> Le 20 juil. 2018 ? 20:24, Samuel Gougeon a ?crit : >> >>> Le 22/06/2018 ? 10:28, St?phane Mottelet a ?crit : >>> Hello, >>> >>> While fixing >>> >>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=15623 >>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=15624 >>> >>> I discovered that gross syntax errors such as >>> >>> max(,), max(1,) mean(,)... >>> >>> are not trapped by the parser. As a consequence, tokens of type internalType:ScilabVoid are given to the gateway in the input arguments. >>> >>> There are a lot of scilab functions which do not correctly handle this. For example, >>> >>> max(1,) and atan(1,) crash Scilab >>> >>> max(,), gives a message about a missing overloading function for ScilabVoid type. >>> >>> Why such an dumb syntax has been kept as valid in Scilab 6 ? Does even somebody remember if there exist some legacy code needing this ? >>> >>> There is a potentially huge number of gateways to be fixed because of this too permissive syntax. >> >> If you consider the very close syntaxes like >> myfun(a, , c) >> or >> myfun(, b, c) >> also as too permissive and to be forbidden, then we would definitely disagree: >> >> To me, they are to most handy way to skip an argument (obviously provided that myfun() handles it correctly). > The problem is that the number of functions that actually *do not* handle it is unknown/unbounded.... Why is it a problem? The same question can hold about the unknown number of functions that expect [] to skip an argument, or that expect "" instead, etc. This is just a matter of documentation. If being able to handle myfun(,b,c) or myfun(a,,c) becomes impossible, this would really be an issue, not a documentation one. Just skipping arguments values at kept positions to set the default values is more and more my way to write my macros. It is more robust than using named arguments, and simpler than each time asking to oneself which value must be entered to set the default one. Scilab 6 is a bit better than Scilab 5 about "void" types. Their relevant usage must not be prevented by any parser modification. myfun(a,) is not relevant, indeed, since it is equivalent but less simple than myfun(a). And the bug http://bugzilla.scilab.org/10279 is just about this ending comma case, nothing more. >> Does your proposed patch also prevent them? Shall we understand "yes"? Samuel From sgougeon at free.fr Sun Jul 22 16:38:16 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Sun, 22 Jul 2018 16:38:16 +0200 Subject: [Scilab-Dev] git push on forges Message-ID: <9b8a214a-18a0-ceb0-7bbe-396334fb34d4@free.fr> Hello, After having released the module scidoe 0.4.1, i am trying to update with git the source files of scidoe on its forge. It's the first time that i use the forge as administrator of a project. * cloning the project with git is OK * updating local files according to the 0.4.1 version is OK * committing the list of changed files is OK, with o git add * o git status => ok, i get the right green list o git commit -m "version 0.4.1" But then, the commit must be pushed. The page https://forge.scilab.org/index.php/p/scidoe/source/help/ indicates the command $ git push origin master After validation, i always get.. nothing: the git session is just waiting... without error, and without doing anything. I have well set my public key on my forges profile (it starts with ssh-rsaand ends with Mylogin at my-computer-name). I did not do anything else on my git, since i use the same key as for the Scilab CodeReview. What's wrong or missing in this protocol? Any help would be appreciated, here or in private. Thanks in advance. Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Clement.David at esi-group.com Wed Jul 25 08:33:21 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Wed, 25 Jul 2018 06:33:21 +0000 Subject: [Scilab-Dev] git push on forges In-Reply-To: <9b8a214a-18a0-ceb0-7bbe-396334fb34d4@free.fr> References: <9b8a214a-18a0-ceb0-7bbe-396334fb34d4@free.fr> Message-ID: <418c2024b11b54288e909ef4d9c0e17751f09df0.camel@esi-group.com> Hello Samuel, `git push origin master` will push your local branch master to the matching remote branch ; to be more explicit you could also use `git push origin master:master`. If this command still fail, could you send us the .git/config file from the scidoe directory ? It is also possible that behind a strict firewall the ssh port are closed (the codereview use an explicit non ssh port), could you try from home (or through mobile phone tethering) ? Thanks, -- Cl?ment Le dimanche 22 juillet 2018 ? 16:38 +0200, Samuel Gougeon a ?crit : > Hello, > After having released the module scidoe 0.4.1, i am trying to update with git the source files of > scidoe on its forge. > It's the first time that i use the forge as administrator of a project. > cloning the project with git is OK > updating local files according to the 0.4.1 version is OK > committing the list of changed files is OK, with > git add * > git status => ok, i get the right green list > git commit -m "version 0.4.1" > But then, the commit must be pushed. The page https://forge.scilab.org/index.php/p/scidoe/source/h > elp/ indicates the command > $ git push origin master > After validation, i always get.. nothing: the git session is just waiting... without error, and > without doing anything. > I have well set my public key on my forges profile (it starts with ssh-rsa and ends with Mylogin at m > y-computer-name). I did not do anything else on my git, since i use the same key as for the Scilab > CodeReview. > > What's wrong or missing in this protocol? > > Any help would be appreciated, here or in private. > > Thanks in advance. > Samuel > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From johanwesselink23 at gmail.com Thu Jul 26 03:09:48 2018 From: johanwesselink23 at gmail.com (Johan Wesselink) Date: Wed, 25 Jul 2018 22:09:48 -0300 Subject: [Scilab-Dev] JOGL java OpenGL library Message-ID: I build scilab from the scilab branch master under lubuntu. This went well except for the JOGL2 library. I noticed that almost all modern distros come with its own version of this library. The library is currently redistributed. However, there is a library problem in which a dynamic library doesn't return the correct string. If I remember correctly this is the latest MesagGL library. The redistributed version is no longer compatible with the latest mesa library. This is a well known problem and all distributions package scilab using the new version. They are aware that search path for the library in Java is modfied from javax.opengl to com.jogamp. Every distribution uses a patch which patches a set of java files and adapts the configure.ac I am very curious if there is an incentive to integrate this modification into the current master branch and link to a new version of JOGL2. This will make it much easier to compile scilab from scratch. I do this because I am interested on working on XCOS.. This is a very cool tool which still needs a lot of work. Sincerely Johan Wesselink -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim_monte at live.com Sat Jul 28 06:02:48 2018 From: jim_monte at live.com (Jim Monte) Date: Fri, 27 Jul 2018 21:02:48 -0700 (MST) Subject: [Scilab-Dev] Change URLs in Scilab documentation Message-ID: <1532750568789-0.post@n3.nabble.com> Hi All, I was looking for a place to put this suggestion and hopefully have found one that is not too far off. When I search for a Scilab topic, I almost invariably find that the top links are to outdated documentation. For example, instead of getting a link to https://help.scilab.org/docs/6.0.1/en_US/fscanfMat.html, Google's top links are to versions 5.3.0 and 6.0.0 when searching for fscanfMat. To help the search engines out, why not put something like "current" where 6.0.1 is in the above URL, https://help.scilab.org/docs/current/en_US/fscanfMat.html? Then when a new version is released, rename the link to https://help.scilab.org/docs/6.0.1/en_US/fscanfMat.html and have the latest documentation for fscanfMat always at https://help.scilab.org/docs/current/en_US/fscanfMat.html. Jim Monte -- Sent from: http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944.html From sgougeon at free.fr Sat Jul 28 11:27:45 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 28 Jul 2018 11:27:45 +0200 Subject: [Scilab-Dev] Change URLs in Scilab documentation In-Reply-To: <1532750568789-0.post@n3.nabble.com> References: <1532750568789-0.post@n3.nabble.com> Message-ID: <6768d494-c4b7-9856-2395-b03e1cf55fe1@free.fr> Hello Jim, Le 28/07/2018 ? 06:02, Jim Monte a ?crit : > Hi All, > > I was looking for a place to put this suggestion and hopefully have found > one that is not too far off. When I search for a Scilab topic, I almost > invariably find that the top links are to outdated documentation. For > example, instead of getting a link to > https://help.scilab.org/docs/6.0.1/en_US/fscanfMat.html, Google's top links > are to versions 5.3.0 and 6.0.0 when searching for fscanfMat. To help the > search engines out, why not put something like "current" where 6.0.1 is in > the above URL, https://help.scilab.org/docs/current/en_US/fscanfMat.html? > Then when a new version is released, rename the link to > https://help.scilab.org/docs/6.0.1/en_US/fscanfMat.html > and have the latest documentation for fscanfMat always at > https://help.scilab.org/docs/current/en_US/fscanfMat.html. You may also use uman() (from https://atoms.scilab.org/toolboxes/uman) with its w option: Then you will always target the online help version of your current Scilab version, without external search engine, which by the way is an energy-saving solution. A version of uman() making it able to display the local HTML help pages in the web browser is in preparation. But of course, anyway, for it, Scilab needs to be running. Best regards Samuel From sgougeon at free.fr Sat Jul 28 16:47:27 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 28 Jul 2018 16:47:27 +0200 Subject: [Scilab-Dev] XMLDoc==XMLDoc definition Message-ID: <11a9c4e8-2101-8974-3f04-9b20d2be29f6@free.fr> Hello, Before posting any report on Bugzilla, i would like to understand why we get [%t %t] instead of %t when we compare 2 XMLDoc objects. Is it a bug, or is it intentional?: --> doc = xmlReadStr("Hello") doc = XML Document url: Undefined root: XML Element --> doc2 = doc; --> doc==doc2 ans = T T <<<<<<<<<<<<<<<<<<<<<< Here --> xmlDelete(doc), clear doc doc2 Since XMLDoc objects are of type 17, i was naively searching for a %XMLDoc_o_XMLDoc() overload. But the XML module does not have such a macro overload. I also searched in the XML src and gateway source directories, without success. XML overloads are not documented. The only overload having a unit test is for size(). Any clue where the XMLDoc==XMLDoc comparison is defined? If XMLDoc objects are not regular mlists, why a specific type code distinct from 17 has not been ascribed to them? Thanks Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Sat Jul 28 17:00:45 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 28 Jul 2018 17:00:45 +0200 Subject: [Scilab-Dev] Display of invalid XMLDoc identifier changed in Scilab 6 Message-ID: <388d3ecd-989c-4d6d-182c-890977c6c268@free.fr> Hi, In Scilab 5.5, after -->doc = xmlReadStr("Hello"); -->xmlDelete(doc) we had -->doc doc = !--error 999 %XMLDoc_p: XML object does not exist. while in Scilab 6.0.1 we have now: --> doc doc = Is this change intentional? Yielding an error while displaying the invalid object was rather questionable. So, IMHO removing the error is rather nice. However, the new display looks a bit suspect... Doesn't it? Cheers Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine.elias at scilab-enterprises.com Sat Jul 28 18:28:14 2018 From: antoine.elias at scilab-enterprises.com (Antoine ELIAS) Date: Sat, 28 Jul 2018 18:28:14 +0200 Subject: [Scilab-Dev] XMLDoc==XMLDoc definition In-Reply-To: <11a9c4e8-2101-8974-3f04-9b20d2be29f6@free.fr> References: <11a9c4e8-2101-8974-3f04-9b20d2be29f6@free.fr> Message-ID: <11d2b515-27ed-e35f-231a-54ee2da0e4f0@scilab-enterprises.com> Hello Samuel, Example outside of xml "object" (lot of overloads) a = mlist(["toto", "id"], 1); b = mlist(["toto", "id"], 1); a == b -> [%t %t] For mlist we compare the type ("toto") and fields? ("id" in this case) Regards, Antoine Le 28/07/2018 ? 16:47, Samuel Gougeon a ?crit?: > Hello, > > Before posting any report on Bugzilla, i would like to understand why > we get [%t %t] instead of %t when we compare 2 XMLDoc objects. Is it a > bug, or is it intentional?: > --> doc = xmlReadStr(" rib=""bar"">Hello") > ?doc? = > XML Document > url: Undefined > root: XML Element > > --> doc2 = doc; > --> doc==doc2 > ?ans? = > ? T T <<<<<<<<<<<<<<<<<<<<<< Here > --> xmlDelete(doc), clear doc doc2 > > Since XMLDoc objects are of type 17, i was naively searching for a > %XMLDoc_o_XMLDoc() overload. > But the XML module does not have such a macro overload. > I also searched in the XML src and gateway source directories, without > success. > XML overloads are not documented. The only overload having a unit test > is for size(). > > Any clue where the XMLDoc==XMLDoc comparison is defined? > > If XMLDoc objects are not regular mlists, why a specific type code > distinct from 17 has not been ascribed to them? > > Thanks > 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 Sat Jul 28 18:54:51 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 28 Jul 2018 18:54:51 +0200 Subject: [Scilab-Dev] XMLDoc==XMLDoc definition In-Reply-To: <11d2b515-27ed-e35f-231a-54ee2da0e4f0@scilab-enterprises.com> References: <11a9c4e8-2101-8974-3f04-9b20d2be29f6@free.fr> <11d2b515-27ed-e35f-231a-54ee2da0e4f0@scilab-enterprises.com> Message-ID: <8b6a0d3c-c59f-c5f4-6410-ccb5427f82a4@free.fr> Hello Antoine, Thanks for your quick answer: Le 28/07/2018 ? 18:28, Antoine ELIAS a ?crit : > Hello Samuel, > > Example outside of xml "object" (lot of overloads) > a = mlist(["toto", "id"], 1); > b = mlist(["toto", "id"], 1); > a == b -> [%t %t] > > For mlist we compare the type ("toto") and fields ("id" in this case) and --> a = mlist(["aBcD", "id" "id2"], 1, 2); --> a==a ans = T T T OK: so a) there is actually a default equality definition b) it is actually type+fields-wise c) it looks not documented: none of the list, mlist, tlist, overloading, comparison, and equal pages indicate it. d) it is overloadable: function r= %aBcD_o_aBcD(a, b) r = typeof(a)==typeof(b); af = fieldnames(a); r = r & and(af==fieldnames(b)); for f = af' r = r & and(a(f)==b(f)) end endfunction --> a==a ans = T Thanks Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Sat Jul 28 18:57:27 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 28 Jul 2018 18:57:27 +0200 Subject: [Scilab-Dev] XMLDoc==XMLDoc definition In-Reply-To: <8b6a0d3c-c59f-c5f4-6410-ccb5427f82a4@free.fr> References: <11a9c4e8-2101-8974-3f04-9b20d2be29f6@free.fr> <11d2b515-27ed-e35f-231a-54ee2da0e4f0@scilab-enterprises.com> <8b6a0d3c-c59f-c5f4-6410-ccb5427f82a4@free.fr> Message-ID: Le 28/07/2018 ? 18:54, Samuel Gougeon a ?crit : > Hello Antoine, > > Thanks for your quick answer: > > Le 28/07/2018 ? 18:28, Antoine ELIAS a ?crit : >> Hello Samuel, >> >> Example outside of xml "object" (lot of overloads) >> a = mlist(["toto", "id"], 1); >> b = mlist(["toto", "id"], 1); >> a == b -> [%t %t] >> >> For mlist we compare the type ("toto") and fields ("id" in this case) > > and > --> a = mlist(["aBcD", "id" "id2"], 1, 2); > --> a==a > ans = > T T T > > OK: so > a) there is actually a default equality definition > b) it is actually type+fields-wise > c) it looks not documented: none of the list, mlist, tlist, > overloading, comparison, and equal pages indicate it. > d) it is overloadable: > function r= %aBcD_o_aBcD(a, b) > r = typeof(a)==typeof(b); > af = fieldnames(a); > r = r & and(af==fieldnames(b)); > for f = af' > r = r & and(a(f)==b(f)) > end > endfunction > --> a==a > ans = > T For a overall lists comparison, we may also use directly --> isequal(a,a) ans = T -------------- next part -------------- An HTML attachment was scrubbed... URL: From Clement.David at esi-group.com Mon Jul 30 14:41:51 2018 From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=) Date: Mon, 30 Jul 2018 12:41:51 +0000 Subject: [Scilab-Dev] JOGL java OpenGL library In-Reply-To: References: Message-ID: <6500024b52564f6f0df20ea3b73ada6962d1942d.camel@esi-group.com> Hello Johan, Yep the patch is already in review [1] however we should rebuild jogl2 to ship it within our thirdparties. Currently to build Scilab for yourself with the latest jogl2 version from your distribution, apply it before building. [1]: https://codereview.scilab.org/#/c/17530/ Thanks, -- Cl?ment Le mercredi 25 juillet 2018 ? 22:09 -0300, Johan Wesselink a ?crit : > I build scilab from the scilab branch master under lubuntu. > This went well except for the JOGL2 library. > > I noticed that almost all modern distros come with its own version of this library. > The library is currently redistributed. However, there is a library problem in which > a dynamic library doesn't return the correct string. If I remember correctly this is the latest > MesagGL library. The redistributed version is no longer compatible with the latest mesa library. > > This is a well known problem and all distributions package scilab using the > new version. > They are aware that search path for the library in Java is modfied from > javax.opengl to com.jogamp. > Every distribution uses a patch which patches a set of java files and adapts the configure.ac > > I am very curious if there is an incentive to integrate this modification into the current > master branch and link to a new version of JOGL2. This will make it much easier to > compile scilab from scratch. > > I do this because I am interested on working on XCOS.. This is a very cool tool > which still needs a lot of work. > > Sincerely > Johan Wesselink > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From johanwesselink23 at gmail.com Mon Jul 30 15:01:59 2018 From: johanwesselink23 at gmail.com (Johan Wesselink) Date: Mon, 30 Jul 2018 10:01:59 -0300 Subject: [Scilab-Dev] JOGL java OpenGL library In-Reply-To: <6500024b52564f6f0df20ea3b73ada6962d1942d.camel@esi-group.com> References: <6500024b52564f6f0df20ea3b73ada6962d1942d.camel@esi-group.com> Message-ID: Thanks Cl?ment, I made the modifications by hand in the different files. Not that many files! Had a quick look at the patch set it does exactly the same as mine as far as I can see. I can now compile an working Scilab from the master branch.However, I noticed that there is still a selection bug in the plot window. The red markers are correct. However, the rubber box is drawn upside down. I don't know if this is also fixed in this patch set. But it is a really old bug which is not any longer present in Scilab 6.0.1 So at one moment in time it was fixed. I am curious if I introduced this bug myself because I linked against an external version of JOGL2 which may or may not contain this bug. In other words is this bug fixed JOGL2 library you are using? Thanks, Johan 2018-07-30 9:41 GMT-03:00 Cl?ment David : > Hello Johan, > > Yep the patch is already in review [1] however we should rebuild jogl2 to > ship it within our > thirdparties. Currently to build Scilab for yourself with the latest jogl2 > version from your > distribution, apply it before building. > > [1]: https://codereview.scilab.org/#/c/17530/ > > Thanks, > > -- > Cl?ment > > Le mercredi 25 juillet 2018 ? 22:09 -0300, Johan Wesselink a ?crit : > > I build scilab from the scilab branch master under lubuntu. > > This went well except for the JOGL2 library. > > > > I noticed that almost all modern distros come with its own version of > this library. > > The library is currently redistributed. However, there is a library > problem in which > > a dynamic library doesn't return the correct string. If I remember > correctly this is the latest > > MesagGL library. The redistributed version is no longer compatible with > the latest mesa library. > > > > This is a well known problem and all distributions package scilab using > the > > new version. > > They are aware that search path for the library in Java is modfied from > > javax.opengl to com.jogamp. > > Every distribution uses a patch which patches a set of java files and > adapts the configure.ac > > > > I am very curious if there is an incentive to integrate this > modification into the current > > master branch and link to a new version of JOGL2. This will make it much > easier to > > compile scilab from scratch. > > > > I do this because I am interested on working on XCOS.. This is a very > cool tool > > which still needs a lot of work. > > > > Sincerely > > Johan Wesselink > > _______________________________________________ > > 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: