From clement.david at scilab-enterprises.com Fri Mar 4 12:48:24 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Fri, 04 Mar 2016 12:48:24 +0100 Subject: [Scilab-Dev] : non-standard scilab implementation for the documentation <= Re: Update of the online documentation In-Reply-To: <56CCBEBC.6020108@free.fr> References: <1287504863.3270.5863.camel@losinj.inria.fr> <1287561295.4839.21.camel@pinarellu.inria.fr> <1287564734.766.769.camel@Calixte-Dell> <56CCBEBC.6020108@free.fr> Message-ID: <1457092104.2345.29.camel@scilab-enterprises.com> Hi Samuel, Le mardi 23 f?vrier 2016 ? 21:19 +0100, Samuel Gougeon a ?crit?: >? > So, just to remember: just use like the tag, with providing a reference that is > internal to the page, instead of the reference to an external page : > Option wb > ... > "wb" > > will show a link Option wb that when ones click on it will go to the section of the page where the > term "wb" appears. > That's all. Yep I confirm th is behavior and posted [bug #14444]. This feature will alos let us improve the current documentation by using this feature on all pages that cross-reference related features (eg. almost every page through the "See also" section). [bug #14444]:?http://bugzilla.scilab.org/show_bug.cgi?id=14444 -- Cl?ment From inacio.guilherme at gmail.com Mon Mar 7 23:45:32 2016 From: inacio.guilherme at gmail.com (=?UTF-8?Q?Guilherme_Gon=C3=A7alves?=) Date: Mon, 07 Mar 2016 22:45:32 +0000 Subject: [Scilab-Dev] Bug #14416 fixed Message-ID: Hello, i'm new in Scilab community. My name is Guilherme Inacio Gon?alves, brazilian, finishing my degree in Computer Engineering. I used scilab throughout my course an i was inspired to start contributing to the open source community by my good friend Marcos Cardinot, a Scilab developer too. My desire is to participate in GSoC 2016, motivated by the great experience of working with major developers. So I started my activity fixing bugs. Attached to fix the Bug#14416. http://bugzilla.scilab.org/show_bug.cgi?id=14416 Thanks for the opportunity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clement.david at scilab-enterprises.com Tue Mar 8 11:07:52 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Tue, 08 Mar 2016 11:07:52 +0100 Subject: [Scilab-Dev] Bug #14416 fixed In-Reply-To: References: Message-ID: <1457431672.2474.35.camel@scilab-enterprises.com> Hello Guilherme and welcome, You patch has been accepted and push to the codereview by Paul. I merged it so you are now an official Scilab contributor :) . For the GSoC, we use a dedicated mailing-list : gsoc at lists.scilab.org?so feel free to ask any question (even dummy one) to GSoC-ers. Please also select your subject on the wiki to ease your code knowledge on a specific topic (Java for instance). Regards, -- Cl?ment Le lundi 07 mars 2016 ? 22:45 +0000, Guilherme Gon?alves a ?crit?: > Hello, i'm new in Scilab community. My name is Guilherme Inacio Gon?alves, brazilian,?finishing my > degree in Computer Engineering.?I used scilab throughout my course?an i?was inspired to start > contributing to the open source community by my good friend Marcos Cardinot, a Scilab?developer > too. > My desire is to participate in GSoC 2016,?motivated by the great experience of working with major > developers.?So I started my activity fixing bugs. > > Attached to fix the Bug#14416. > http://bugzilla.scilab.org/show_bug.cgi?id=14416 > > Thanks for the opportunity. > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From sgougeon at free.fr Wed Mar 9 00:21:59 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 9 Mar 2016 00:21:59 +0100 Subject: [Scilab-Dev] Doc: and considerations. Missing resolved page_id#item_id addresses In-Reply-To: <1457092104.2345.29.camel@scilab-enterprises.com> References: <1287504863.3270.5863.camel@losinj.inria.fr> <1287561295.4839.21.camel@pinarellu.inria.fr> <1287564734.766.769.camel@Calixte-Dell> <56CCBEBC.6020108@free.fr> <1457092104.2345.29.camel@scilab-enterprises.com> Message-ID: <56DF5E97.8060502@free.fr> Hi Cl?ment, Le 04/03/2016 12:48, Cl?ment David a ?crit : > Hi Samuel, > > Le mardi 23 f?vrier 2016 ? 21:19 +0100, Samuel Gougeon a ?crit : >> >> So, just to remember: just use like the tag, with providing a reference that is >> internal to the page, instead of the reference to an external page : >> Option wb >> ... >> "wb" >> >> will show a link Option wb that when ones click on it will go to the section of the page where the >> term "wb" appears. >> That's all. > Yep I confirm this behavior and posted [bug #14444]. This feature will alos let us improve > the current documentation by using this feature on all pages that cross-reference related features > (eg. almost every page through the "See also" section). > > [bug #14444]: http://bugzilla.scilab.org/show_bug.cgi?id=14444 Humm, i am not sure to understand what you mean about the expected behavior / purpose of the tag. By the way, i am nor sure to clearly understand differences between and , and the initial answer from Calixte at the beginning of this thread does not clarifies them. Even this is not clear in the Docbook user manual. The tag may as well have an /endterm/ attribute, getting in the target the content to be displayed as the link, turning the tag as an autoclosed one: So, the only difference that i can see -- according to Docbook -- is that is /always/ an autoclosed tag that can't be written .... But in Scilab, it is implemented exactly as a needing a . So, *my first question is: Do you intend to make and different? And if yes, in which aspect?* I was initially looking for a way to target a section of a page, rather than the page (its top) itself. I tried the html syntax with an id in the target and #id in the link, but this does not work. Then i found this tag, and its non-standard implementation equal to the standard one. Further tests show that, with the current implementation, if in a "See also" section or wherever else one uses item OR item AND * a) "the_id" is an xml:id of a page, OR * b) "the_id" is the id of an element of the same page, OR * c) "the_id" is the id of an element of another page, then the top of the page (a), or the element of the same or other page (b) and c)) are already well targeted, in the helpbrowser as well as in HTML files. Hence, i do not see anything specific to that should be implemented about cross-referencing. The problems that i see are the following: * the xml:id of a page and ids in pages are equally considered. This may set some "unresolved" conflicts between ids. It would be better to have two distinct levels of targeting, as in HTML, i.e. to be able to use a 2-level address id_page#id_element for linkend/href values. * In the "See also" section or in any other part of a page of an external module, succeeds linking to a Scilab page/in the help browser/, but fails to link to the online HTML Scilab page in its HTML version. This is already reported, and should be quite easy to fix, since some Scilab online pages exist and can be targeted. * In the "See also" section of an external module, pointing to Scilab pages are not followed by short descriptions of the related pages. This is another reported bug. So, my last questions are : * *Do you intend to implement resolved addresses such as page_id#item_id ? * * *Do you intend to implement the endterm attribute for ? * * Don't you think that the tag is useless and should be removed ? Best regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Mar 9 00:48:41 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 9 Mar 2016 00:48:41 +0100 Subject: [Scilab-Dev] strcat([],"")~=[]+"" ? <= Re: A+[] In-Reply-To: <56C6E232.70901@scilab-enterprises.com> References: <4BB0758D.9090208@scilab.org> <56C60351.7080908@free.fr> <56C6DB9B.8070508@inria.fr> <56C6E232.70901@scilab-enterprises.com> Message-ID: <56DF64D9.4030508@free.fr> Hello, Le 19/02/2016 10:36, Pierre-Aim? Agnel a ?crit : > Hello, > > A flag has been introduced to tackle the A+[] operation > help("oldEmptyBehaviour") > oldEmptyBehaviour("on") > 1 + [] > > oldEmptyBehaviour("off") > 1+[] > > > oldEmptyBehaviour("query") > > > We kept the warning for both behaviours if users want to migrate "softly". > This is also done to protect the scripts. Up to Scilab 5.5.2, we had strcat([],"anything") == "" // as well as [] + "anything" == "" The fact that both expressions give the same result is correct, since they mean exactly the same operation. But with the new behavior of +[], both results become distinct: strcat([], "anything") // still returns "" (scilab 6.0-b1) , while []+"anything" // now returns [] This is why *we **could prefer from strcat([]) or strcat([], "anything") now to return [] instead of ""*. What's your opinion about this? Moreover, most of string functions processing [] *already* return [] : *convstr([]) => [], string([]) => [], etc*. If the behavior of strcat([]) is changed, this should not depend on the oldEmptyBehaviour flag. Best regards Alain Lamy and Samuel Gougeon -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Mar 9 01:18:22 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 9 Mar 2016 01:18:22 +0100 Subject: [Scilab-Dev] SEP #40: Cell Arrays In-Reply-To: References: <4BB0758D.9090208@scilab.org> <56C60351.7080908@free.fr> Message-ID: <56DF6BCE.8000008@free.fr> Hello, Le 18/02/2016 20:41, Eric Dubois a ?crit : > Hello > > I am inclined to share Samuel point of view: this is a compliocation > than could be avoided. > > But I cannot resist noting that the annoucement is 6 years older than > the announcement of the weapon of mass destruction that consist in > changing the behaviour of the addition of a matrix with a null matrix. > > Sorry for insisting, but I will again call for the removal from the > final Scilab 6.0 release of this planned change. > > First, I am not convinced at all by the argument put forward that it > will make Scilab more consistent with other language such as Matlab, > Octave, Julia.. : after all, every language has its indiosycrasies; a > Matlab user will yet have to adapt herslef to this change, bu along > many other ones; and I,do not think that changing this behavour will > convice any Matlab user to switch to Scilab nor prevent anyone > thinking about switching to give up because of this beahviour. > > Second The argument that it enhances Scilab internal consistency is a > little bit more compelling, but not much: after all, addition and > subtraction are different operations from multiplication and division, > such one can justify different behaviour. And there are cases when it > make tho code more compact. > > Adnd lastly both arguments are anyway swept away by the simple fact > that the change should make all previous code unreliable: you cannot > be sure in advance that the working of your program has not been > affected by the change (and the warning that is designed to alert to > the user is not sufficient: a warning can easily be missed, especially > for second hand users not so famaliar with Scilab and if it is hidden > among many other warnings). I have the same feeling, and i agree mostly with your last remark. We could stress on some "pitfalls" set by the oldEmptyBehaviour flag or by the "warning stop" behavior: * oldEmptyBehaviour flag:We may guess that this flag is a /global/ one. Isn't it? So, if we set it at the beginning of a script or of a macro, then it applies to the whole Scilab session (i haven't checked that), even after leaving the script or the macro. If so, then if in a session we process some recent up-to-date scripts or macros, and some other ones that are not up-to-date, what will occur, whatever is the flag's value? This is not really clear. * warning("stop"): i agree that, in order to update all contents and to be sure that results are reliable and not polluted by unpredictable "[]+-" side effects, this warning mode will have to be always activated for a very long period, may be up to Scilab 7. Then, the problem is that this stopping mode does not resolve the cause: if an up-to-date package intentionally uses warnings for anything else than []+, it will be stopped as well. This warning mode should accept an additional parameter identifying the type of event (or a series/vector of events) for which stopping must occur. Shouln't it? BR Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Mar 9 01:31:11 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 9 Mar 2016 01:31:11 +0100 Subject: [Scilab-Dev] oldEmptyBehaviour and warning("stop") on []+- In-Reply-To: <56DF6BCE.8000008@free.fr> References: <4BB0758D.9090208@scilab.org> <56C60351.7080908@free.fr> <56DF6BCE.8000008@free.fr> Message-ID: <56DF6ECF.6000905@free.fr> Sorry for the badly unretitled previous message. May i end it with a suggestion: Le 09/03/2016 01:18, Samuel Gougeon a ?crit : > Hello, > > Le 18/02/2016 20:41, Eric Dubois a ?crit : >> Hello >> >> I am inclined to share Samuel point of view: this is a compliocation >> than could be avoided. >> >> But I cannot resist noting that the annoucement is 6 years older than >> the announcement of the weapon of mass destruction that consist in >> changing the behaviour of the addition of a matrix with a null matrix. >> >> Sorry for insisting, but I will again call for the removal from the >> final Scilab 6.0 release of this planned change. >> >> First, I am not convinced at all by the argument put forward that it >> will make Scilab more consistent with other language such as Matlab, >> Octave, Julia.. : after all, every language has its indiosycrasies; a >> Matlab user will yet have to adapt herslef to this change, bu along >> many other ones; and I,do not think that changing this behavour will >> convice any Matlab user to switch to Scilab nor prevent anyone >> thinking about switching to give up because of this beahviour. >> >> Second The argument that it enhances Scilab internal consistency is a >> little bit more compelling, but not much: after all, addition and >> subtraction are different operations from multiplication and >> division, such one can justify different behaviour. And there are >> cases when it make tho code more compact. >> >> Adnd lastly both arguments are anyway swept away by the simple fact >> that the change should make all previous code unreliable: you cannot >> be sure in advance that the working of your program has not been >> affected by the change (and the warning that is designed to alert to >> the user is not sufficient: a warning can easily be missed, >> especially for second hand users not so famaliar with Scilab and if >> it is hidden among many other warnings). > > I have the same feeling, and i agree mostly with your last remark. We > could stress on some "pitfalls" set by the oldEmptyBehaviour flag or > by the "warning stop" behavior: > > * oldEmptyBehaviour flag:We may guess that this flag is a /global/ > one. Isn't it? So, if we set it at the beginning of a script or of > a macro, then it applies to the whole Scilab session (i haven't > checked that), even after leaving the script or the macro. If so, > then if in a session we process some recent up-to-date scripts or > macros, and some other ones that are not up-to-date, what will > occur, whatever is the flag's value? This is not really clear. > > * warning("stop"): i agree that, in order to update all contents and > to be sure that results are reliable and not polluted by > unpredictable "[]+-" side effects, this warning mode will have to > be always activated for a very long period, may be up to Scilab 7. > Then, the problem is that this stopping mode does not resolve the > cause: if an up-to-date package intentionally uses warnings for > anything else than []+, it will be stopped as well. > This warning mode should accept an additional parameter > identifying the type of event (or a series/vector of events) for > which stopping must occur. Shouln't it? > For both of these reasons, introducing this oldEmptyBehaviour flag in Scilab 6 is questionable. It might be preferable to only improve the warning("stop", event) mode, and to leave Scilab 5.5.2 available on the download page for a long time. It will then always be possible to run old packages with Scilab 5. SG -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcardinot at gmail.com Wed Mar 9 11:58:11 2016 From: mcardinot at gmail.com (Marcos Cardinot) Date: Wed, 9 Mar 2016 10:58:11 +0000 Subject: [Scilab-Dev] [Gsoc] [GSoC] Network module In-Reply-To: <1251578042.4294513.1457504690909.JavaMail.yahoo@mail.yahoo.com> References: <1251578042.4294513.1457504690909.JavaMail.yahoo@mail.yahoo.com> Message-ID: Hi Rishubh, Have you cloned the svn repo into your scilab directory? Best regards, Marcos On Wed, Mar 9, 2016 at 6:24 AM, Rishubh Jain wrote: > Hi, > > If you have solved the error I would like to know how you solved it, I had > the same issue, I installed it on the home folder but that didnt solve the > issue. > > Thanking You > RIshubh > > > On Monday, 7 March 2016 5:48 AM, Marcos Cardinot > wrote: > > > Hi, > > You should try installing it in your home dir. > Also, make sure you have all thirdparties there [1] (clone the svn repo > into scilab dir) > > [1]: svn:// > svn.scilab.org/scilab/trunk/Dev-Tools/SE/Prerequirements/linux_x64/ > or > [1]: svn://svn.scilab.org/scilab/trunk/Dev-Tools/SE/Prerequirements/linux/ > > username: anonymous > password: Scilab > > Cheers, > Marcos > > On Sun, Mar 6, 2016 at 10:24 PM, Bitiquinho > wrote: > > Oops, too soon. Got an error trying to launch it (installed in > /opt/scilab): > > $ ./bin/scilab > Ocorreram alguns problemas durante o carregamento das bibliotecas Java. > (Problems loading Java libraries) > Isto pode levar a comportamentos inconsistentes. (This can lead to > inconsistent behaviour) > Por favor, verifique o arquivo SCI/etc/classpath.xml. (Please, verify the > file SCI/etc/classpath.xml) > N?o foi poss?vel acessar a classe principal do Scilab: (Not possible to > access main Scilab class) > Exception in thread "main" java.lang.NoClassDefFoundError: > org/scilab/modules/core/Scilab > Caused by: java.lang.ClassNotFoundException: org.scilab.modules.core.Scilab > at java.net.URLClassLoader$1.run(URLClassLoader.java:366) > at java.net.URLClassLoader$1.run(URLClassLoader.java:355) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:354) > at java.lang.ClassLoader.loadClass(ClassLoader.java:425) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) > at java.lang.ClassLoader.loadClass(ClassLoader.java:358) > > Scilab n?o pode criar Scilab Java Main-Class (n?o conseguimos encontrar a > classe principal do Scilab. Verifique se o Scilab e pacotes de terceiros > est?o dispon?veis). > (Scilab cant create Java main class. Check is Scilab and thirdparty > packages > are available) > > > > -- > View this message in context: > http://mailinglists.scilab.org/GSoC-Network-module-tp4033589p4033639.html > Sent from the Scilab / GSOC - Mailing Lists Archives mailing list archive > at Nabble.com. > _______________________________________________ > gsoc mailing list > gsoc at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/gsoc > > > > _______________________________________________ > gsoc mailing list > gsoc at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/gsoc > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Mar 9 17:23:26 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 9 Mar 2016 17:23:26 +0100 Subject: [Scilab-Dev] warning("stop") or warning("trace") ? In-Reply-To: <56DF6BCE.8000008@free.fr> References: <4BB0758D.9090208@scilab.org> <56C60351.7080908@free.fr> <56DF6BCE.8000008@free.fr> Message-ID: <56E04DFE.30304@free.fr> Hi, Le 09/03/2016 01:18, Samuel Gougeon a ?crit : > > * warning("stop"): i agree that, in order to update all contents and > to be sure that results are reliable and not polluted by > unpredictable "[]+-" side effects, this warning mode will have to > be always activated for a very long period, may be up to Scilab 7. > Then, the problem is that this stopping mode does not resolve the > cause: if an up-to-date package intentionally uses warnings for > anything else than []+, it will be stopped as well. > This warning mode should accept an additional parameter > identifying the type of event (or a series/vector of events) for > which stopping must occur. Shouln't it? > An other solution could be to implement and use a new *warning("trace") *mode, instead of the rough warning("stop").warning("trace") would display a warning + the where() or whereami() trace locating where the warning occurs, /without stopping the execution of the script/. This has been proposed while CodeReviewing the implementation of warning("stop"), but has not been retained. Don't know why. If the intention of warning("stop") (instead of "only warning("trace")) is to urge and compel users to update their codes, then the oldEmptyBehaviour flag should not be proposed in the other hand. BR Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From grocer.toolbox at gmail.com Wed Mar 9 17:50:41 2016 From: grocer.toolbox at gmail.com (Eric Dubois) Date: Wed, 9 Mar 2016 17:50:41 +0100 Subject: [Scilab-Dev] warning("stop") or warning("trace") ? In-Reply-To: <56E04DFE.30304@free.fr> References: <4BB0758D.9090208@scilab.org> <56C60351.7080908@free.fr> <56DF6BCE.8000008@free.fr> <56E04DFE.30304@free.fr> Message-ID: Hello Samuel I think my concerns have not been fully understood: the problem is not-or not only- to allow users to adapt their code, for which the warning(s'top') or warning('trace') whatever is implemented is useful. The problem is also that you will have many difficulties to detect all cases when your programs will be at risk of making an addition of an empty matrix and a non empty one and not crash but produce a wrong result. And the problem is -again- worse for toolboxes: you may expect the developper of a toolbox to be aware of the diffculties that this change of behaviour entail, but this is much less the case for users (such as some of the ones that use some of the capabilities of my toolbox not because they are written in Scilab, but because they find adapted to the problem they want to deal with), who won't necessary be aware of this risk. I think that if such error happens and is discovered, it will do much harm to Scilab image. Beyond the problems it causes to me (already 5 full days of hard work to test and adapt my programs and I have only discovered the most obvious problems), I think this is a reason why the change should absolutely not be made. Unfortunately, I have the impression that I won't be heard and I feal a little bit discouraged not to have any answer from Scilab team to much of these concerns. The fact that some toolboxes are no more packaged under Atoms is another source of concern, which make me wonder if Scilab entreprises is still paying attention to the community... ?ric. 2016-03-09 17:23 GMT+01:00 Samuel Gougeon : > Hi, > > Le 09/03/2016 01:18, Samuel Gougeon a ?crit : > > > - warning("stop"): i agree that, in order to update all contents and > to be sure that results are reliable and not polluted by unpredictable > "[]+-" side effects, this warning mode will have to be always activated for > a very long period, may be up to Scilab 7. Then, the problem is that this > stopping mode does not resolve the cause: if an up-to-date package > intentionally uses warnings for anything else than []+, it will be stopped > as well. > This warning mode should accept an additional parameter identifying > the type of event (or a series/vector of events) for which stopping must > occur. Shouln't it? > > > An other solution could be to implement and use a new *warning("trace") *mode, > instead of the rough warning("stop"). warning("trace") would display a > warning + the where() or whereami() trace locating where the warning > occurs, *without stopping the execution of the script*. > This has been proposed while CodeReviewing the implementation of > warning("stop"), but has not been retained. Don't know why. > > If the intention of warning("stop") (instead of "only warning("trace")) is > to urge and compel users to update their codes, then the oldEmptyBehaviour > flag should not be proposed in the other hand. > > BR > 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 Serge.Steer at inria.fr Wed Mar 9 20:18:03 2016 From: Serge.Steer at inria.fr (Serge Steer) Date: Wed, 09 Mar 2016 20:18:03 +0100 Subject: [Scilab-Dev] strcat([],"")~=[]+"" ? <= Re: A+[] In-Reply-To: <56DF64D9.4030508@free.fr> References: <4BB0758D.9090208@scilab.org> <56C60351.7080908@free.fr> <56C6DB9B.8070508@inria.fr> <56C6E232.70901@scilab-enterprises.com> <56DF64D9.4030508@free.fr> Message-ID: <56E076EB.2000607@inria.fr> Le 09/03/2016 00:48, Samuel Gougeon a ?crit : > Hello, > > Le 19/02/2016 10:36, Pierre-Aim? Agnel a ?crit : >> Hello, >> >> A flag has been introduced to tackle the A+[] operation >> help("oldEmptyBehaviour") >> oldEmptyBehaviour("on") >> 1 + [] >> >> oldEmptyBehaviour("off") >> 1+[] >> >> >> oldEmptyBehaviour("query") >> >> >> We kept the warning for both behaviours if users want to migrate >> "softly". >> This is also done to protect the scripts. > > Up to Scilab 5.5.2, we had > strcat([],"anything") == "" // as well as > [] + "anything" == "" > The fact that both expressions give the same result is correct, since > they mean exactly the same operation. Not exactly the same meaning strcat(strarray,"anything") adds "anything" between each element of strarray strcat("foo","blabla") ->"foo" and not "fooblabla" So it is ok that strcat([], "anything") returns [] as there is no elements. Serge > > But with the new behavior of +[], both results become distinct: > strcat([], "anything") // still returns "" (scilab 6.0-b1) , while > []+"anything" // now returns [] > > This is why *we **could prefer from strcat([]) or strcat([], > "anything") now to return [] instead of ""*. > What's your opinion about this? I do not agree for the reason explained above > Moreover, most of string functions processing [] *already* return [] : > *convstr([]) => [], string([]) => [], etc*. > > If the behavior of strcat([]) is changed, this should not depend on > the oldEmptyBehaviour flag. > > Best regards > > Alain Lamy and Samuel Gougeon > > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Mar 9 20:35:43 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 9 Mar 2016 20:35:43 +0100 Subject: [Scilab-Dev] strcat([],"")~=[]+"" ? <= Re: A+[] In-Reply-To: <56E076EB.2000607@inria.fr> References: <4BB0758D.9090208@scilab.org> <56C60351.7080908@free.fr> <56C6DB9B.8070508@inria.fr> <56C6E232.70901@scilab-enterprises.com> <56DF64D9.4030508@free.fr> <56E076EB.2000607@inria.fr> Message-ID: <56E07B0F.3060007@free.fr> Le 09/03/2016 20:18, Serge Steer a ?crit : > Up to Scilab 5.5.2, we had >> strcat([],"anything") == "" // as well as >> [] + "anything" == "" >> The fact that both expressions give the same result is correct, since >> they mean exactly the same operation. > Not exactly the same meaning strcat(strarray,"anything") adds > "anything" between each element of > strarray strcat("foo","blabla") ->"foo" and not "fooblabla" > So it is ok that strcat([], "anything") returns [] as there is no > elements. Thank you Serge for your confirmation. You are right: both expressions do not mean exactly the same thing, and even without respect to the []+ "trick", the current behavior of strcat([],"")=>"" is not consistent. => reported there: http://bugzilla.scilab.org/14453 Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rishubhjain at ymail.com Thu Mar 10 17:59:28 2016 From: rishubhjain at ymail.com (Rishubh Jain) Date: Thu, 10 Mar 2016 16:59:28 +0000 (UTC) Subject: [Scilab-Dev] [Gsoc] [GSoC] Network module In-Reply-To: <2062212381.4434842.1457521163815.JavaMail.yahoo@mail.yahoo.com> References: <2062212381.4434842.1457521163815.JavaMail.yahoo@mail.yahoo.com> Message-ID: <124943353.5023408.1457629168480.JavaMail.yahoo@mail.yahoo.com> hi, Yes I have done that but was unable to solve the issue. Rishubh -------------- next part -------------- An HTML attachment was scrubbed... URL: From inacio.guilherme at gmail.com Thu Mar 10 19:46:04 2016 From: inacio.guilherme at gmail.com (=?UTF-8?Q?Guilherme_Gon=C3=A7alves?=) Date: Thu, 10 Mar 2016 18:46:04 +0000 Subject: [Scilab-Dev] Bug #14402 and #14458 fixed Message-ID: Hello, I fixed two more bugs. I have no permission to add it on codereview, so I'll send the links. http://bugzilla.scilab.org/show_bug.cgi?id=14402 http://bugzilla.scilab.org/show_bug.cgi?id=14458 I think you need merge the #14402 patch first, cause i found a new bug in same file and created a #14458 and fix it. Thanks so much. Guilherme Gon?alves -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Mar 11 21:24:12 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 11 Mar 2016 21:24:12 +0100 Subject: [Scilab-Dev] Tuning CodeReview email notifications ? Message-ID: <56E3296C.5030705@free.fr> Hello Scilab Team, Is there a way for a registered user of the Scilab Gerrit CodeReview to tune the content of notifications received by email? I tried through my Preferences, but they do not propose any option about this topic. For my part, * i am not sure that getting the full list of reviewers in each message is really useful. * i would like to have the link to the review on the top. * the link to unsubscribe, at the bottom * the line Gerrit-project and branch look useless to me: they are already in the message subject and may be other simplifications / tunings. Thanks for your attention. Best regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Mar 11 21:35:37 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 11 Mar 2016 21:35:37 +0100 Subject: [Scilab-Dev] Tuning CodeReview email notifications ? In-Reply-To: <56E3296C.5030705@free.fr> References: <56E3296C.5030705@free.fr> Message-ID: <56E32C19.5020803@free.fr> And in the same way: to get the Subject more compact and informative . For instance: Currently: subject: Change in scilab[master]: Bug Fix #14429 fixed - Patched Simplifications of rationals ... Wished: something like subject: [master] 17886, PSet 8 : Bug Fix #14429 fixed - Patched Simplifications of rationals ... This would really highlight the notified operation. Samuel Le 11/03/2016 21:24, Samuel Gougeon a ?crit : > Hello Scilab Team, > > Is there a way for a registered user of the Scilab Gerrit CodeReview > to tune the content of notifications received by email? > I tried through my Preferences, but they do not propose any option > about this topic. > > For my part, > > * i am not sure that getting the full list of reviewers in each > message is really useful. > * i would like to have the link to the review on the top. > * the link to unsubscribe, at the bottom > * the line Gerrit-project and branch look useless to me: they are > already in the message subject > > and may be other simplifications / tunings. > > Thanks for your attention. > Best regards > > Samuel > > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Mar 11 23:42:23 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 11 Mar 2016 23:42:23 +0100 Subject: [Scilab-Dev] Graphics: curve edition: identifying the curve with set()/gce() ? Message-ID: <56E349CF.6040609@free.fr> Hello Scilab Team, Curve edition is a quite new feature: clicking on a curve allows to select it before either interactively editing its points (move, delete, insert), or moving the whole curve. But from outside, * is it possible to know which curve is currently/has been lastly interactively selected? * is there a way with a Scilab instruction to set the curve we want to edit data? For moving it, ged(..) can be used: OK For turning on data edition, the internal private useeditor(nFig,%t) can be used: OK But how is it possible to set or identify the edited object, instead of priorly clicking on it? I have checked that there is no relationship between the current object as returned by gce() or set by set("hdl",handle) and the current object as clicked-on before data edition. So, how to process? Why not using set("hdl",handle) to preset the curve to edit, and using gce() to identify the last curve edited? Looking forward to read you, Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Mar 11 23:51:14 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 11 Mar 2016 23:51:14 +0100 Subject: [Scilab-Dev] Graphics: curve edition: identifying the curve with set()/gce() ? In-Reply-To: <56E349CF.6040609@free.fr> References: <56E349CF.6040609@free.fr> Message-ID: <56E34BE2.1000702@free.fr> Le 11/03/2016 23:42, Samuel Gougeon a ?crit : > .../... > is it possible to know which curve is currently/has been lastly > interactively selected? > > * is there a way with a Scilab instruction to set the curve we want > to edit data? > > For moving it, ged(..) can be used: OK > . Actually, the situation is not better with ged(#,nFig): As with useeditor(), it is only possible to target a figure, not a component in it. It's a pity. SG -------------- next part -------------- An HTML attachment was scrubbed... URL: From clement.david at scilab-enterprises.com Mon Mar 14 11:03:38 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Mon, 14 Mar 2016 11:03:38 +0100 Subject: [Scilab-Dev] Tuning CodeReview email notifications ? In-Reply-To: <56E32C19.5020803@free.fr> References: <56E3296C.5030705@free.fr> <56E32C19.5020803@free.fr> Message-ID: <1457949818.2472.36.camel@scilab-enterprises.com> Hello Samuel, All your settings can be configured as?https://codereview.scilab.org/#/settings?but, as you wrote, there is nothing to tune the content of the mail. It seems to be possible [1], but only on the server side (so for all users). On this topic, I prefer avoiding any extra configuration that will take some time to maintain. We use also use the codereview for other project than "scilab" (web services for instance) and other branches (the next 6.0 for instance) so that's a need for us.? [1]:?https://codereview.scilab.org/Documentation/config-mail.html -- Cl?ment Le vendredi 11 mars 2016 ? 21:35 +0100, Samuel Gougeon a ?crit?: > And in the same way: to get the Subject more compact and informative . For instance: > Currently: > subject: Change in scilab[master]: Bug Fix #14429 fixed - Patched Simplifications of rationals ... > Wished: something like > subject: [master] 17886, PSet 8 : Bug Fix #14429 fixed - Patched Simplifications of rationals ... > > This would really highlight the notified operation. > > Samuel > > Le 11/03/2016 21:24, Samuel Gougeon a ?crit?: > > Hello Scilab Team, > > > > Is there a way for a registered user of the Scilab Gerrit CodeReview to tune the content of > > notifications received by email? > > I tried through my Preferences, but they do not propose any option about this topic. > > > > For my part,?? > > i am not sure that getting the full list of reviewers in each message is really useful. > > i would like to have the link to the review on the top. > > the link to unsubscribe, at the bottom > > the line Gerrit-project and branch look useless to me: they are already in the message subject > > and may be other simplifications / tunings. > > Thanks for your attention. > > Best regards > > Samuel > > > > > > > > _______________________________________________ > > dev mailing list > > dev at lists.scilab.org > > http://lists.scilab.org/mailman/listinfo/dev > ? > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From clement.david at scilab-enterprises.com Mon Mar 14 11:10:24 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Mon, 14 Mar 2016 11:10:24 +0100 Subject: [Scilab-Dev] Graphics: curve edition: identifying the curve with set()/gce() ? In-Reply-To: <56E349CF.6040609@free.fr> References: <56E349CF.6040609@free.fr> Message-ID: <1457950224.2472.39.camel@scilab-enterprises.com> Hello Samuel, If I understand correctly, it might be sufficient to set `gce` on when a graphical object is selected (not edited but just selected), no ? Regards, -- Cl?ment Le vendredi 11 mars 2016 ? 23:42 +0100, Samuel Gougeon a ?crit?: > Hello Scilab Team, > > Curve edition is a quite new feature: clicking on a curve allows to select it before either > interactively editing its points (move, delete, insert), or moving the whole curve. > But from outside,? > is it possible to know which curve is currently/has been lastly interactively selected? > is there a way with a Scilab instruction to set the curve we want to edit data? > For moving it, ged(..) can be used: OK > For turning on data edition, the internal private useeditor(nFig,%t) can be used: OK > But how is it possible to set or identify the edited object, instead of priorly clicking on it? > I have checked that there is no relationship between the current object as returned? > by gce() or set by set("hdl",handle) and the current object as clicked-on before data edition. > So, how to process?? > Why not using set("hdl",handle) to preset the curve to edit, and using gce() to identify? > the last curve edited? > Looking forward to read you, > Regards > Samuel > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From sgougeon at free.fr Mon Mar 14 15:59:38 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Mon, 14 Mar 2016 15:59:38 +0100 Subject: [Scilab-Dev] Graphics: curve edition: identifying the curve with set()/gce() ? In-Reply-To: <1457950224.2472.39.camel@scilab-enterprises.com> References: <56E349CF.6040609@free.fr> <1457950224.2472.39.camel@scilab-enterprises.com> Message-ID: <56E6D1DA.7030803@free.fr> Hello Cl?ment, Le 14/03/2016 11:10, Cl?ment David a ?crit : > Hello Samuel, > > If I understand correctly, it might be sufficient to set `gce` on when a graphical object is > selected (not edited but just selected), no ? * Driving the focus for the data curve editor of a given figure: If its data curve editor in "on", AND o if gce() is a polyline in the considered figure, then, indeed, the default edited curve could be set to gce(). This would allow to set the "java focus" with a command line. o If gce() is not a polyline or is a polyline in another figure (whose curve editor is off, or that has not the "java focus"?), then the editor of the considered figure may stand behaving has it presently does (i have no proposal to clarify this). * Setting gce() from the editor : o if the editing mode is off and we select a curve (turning grey) : no, gce() shall not be set to the selected (greyed) curve. This would trigger major back-compatibility issues. o if the editing mode is on : + if the interactive selection is done in gca() : yes, synchronizing gce() to the currently edited curve would answer to the issue. This synchronization would be more intuitive than the current behavior that has 2 distinct focus : Scilab's one (with gce()), and java one (with interactions). + otherwise : no, because this would compel as well to set gca() to the java focus. This would bring major BC issues. I don't know whether the editor is able to edit other types of objects than polylines. If so, the proposed behavior could be extended to them. I hope that this analysis is clear enough (sorry for the length). However, it may still miss important things... Any confirmation would be welcome. Regards Samuel > Le vendredi 11 mars 2016 ? 23:42 +0100, Samuel Gougeon a ?crit : >> Hello Scilab Team, >> >> Curve edition is a quite new feature: clicking on a curve allows to select it before either >> interactively editing its points (move, delete, insert), or moving the whole curve. >> But from outside, >> is it possible to know which curve is currently/has been lastly interactively selected? >> is there a way with a Scilab instruction to set the curve we want to edit data? >> For moving it, ged(..) can be used: OK >> For turning on data edition, the internal private useeditor(nFig,%t) can be used: OK >> But how is it possible to set or identify the edited object, instead of priorly clicking on it? >> I have checked that there is no relationship between the current object as returned >> by gce() or set by set("hdl",handle) and the current object as clicked-on before data edition. >> So, how to process? >> Why not using set("hdl",handle) to preset the curve to edit, and using gce() to identify >> the last curve edited? >> Looking forward to read you, >> Regards >> Samuel >> >> _______________________________________________ >> dev mailing list >> dev at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/dev > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Mon Mar 14 16:13:48 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Mon, 14 Mar 2016 16:13:48 +0100 Subject: [Scilab-Dev] Graphics: curve edition: identifying the curve with set()/gce() ? In-Reply-To: <56E6D1DA.7030803@free.fr> References: <56E349CF.6040609@free.fr> <1457950224.2472.39.camel@scilab-enterprises.com> <56E6D1DA.7030803@free.fr> Message-ID: <56E6D52C.5010703@free.fr> Le 14/03/2016 15:59, Samuel Gougeon a ?crit : > Hello Cl?ment, > > Le 14/03/2016 11:10, Cl?ment David a ?crit : >> Hello Samuel, >> >> If I understand correctly, it might be sufficient to set `gce` on when a graphical object is >> selected (not edited but just selected), no ? > > * Driving the focus for the data curve editor of a given figure: If > its data curve editor in "on", AND > o if gce() is a polyline in the considered figure, then, indeed, > the default edited curve could be set to gce(). This would > allow to set the "java focus" with a command line. > o If gce() is not a polyline or is a polyline in another figure > (whose curve editor is off, or that has not the "java > focus"?), then the editor of the considered figure may stand > behaving has it presently does (i have no proposal to clarify > this). > > * Setting gce() from the editor : > o if the editing mode is off and we select a curve (turning > grey) : no, gce() shall not be set to the selected (greyed) > curve. This would trigger major back-compatibility issues. > o if the editing mode is on : > + if the interactive selection is done in gca() : yes, > synchronizing gce() to the currently edited curve would > answer to the issue. This synchronization would be more > intuitive than the current behavior that has 2 distinct > focus : Scilab's one (with gce()), and java one (with > interactions). > + otherwise : no, because this would compel as well to set > gca() to the java focus. This would bring major BC issues. > > I don't know whether the editor is able to edit other types of objects > than polylines. If so, the proposed behavior could be extended to them. > > I hope that this analysis is clear enough (sorry for the length). > However, it may still miss important things... Any confirmation would > be welcome. > > Regards > Samuel > As often, other ideas/considerations come with a delay ;) : * If we interact (selection or even edition) with a curve in a figure that is not gcf(), then, when we will scf() to it, the default gce() should become the last edited curve. I am not sure that it is already the case (too many tests done forget first ones...;) Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.baudin at contrib.scilab.org Wed Mar 16 21:48:11 2016 From: michael.baudin at contrib.scilab.org (michael.baudin at contrib.scilab.org) Date: Wed, 16 Mar 2016 21:48:11 +0100 Subject: [Scilab-Dev] Atoms modules maintenance In-Reply-To: <126cab484c44895081f39281f6afd482@contrib.scilab.org> References: <126cab484c44895081f39281f6afd482@contrib.scilab.org> Message-ID: <4857b1827b41e0c95af9b0d43b810377@contrib.scilab.org> Hi, I am still interested by a potential reply, if anyone has any idea on this topic... By the way, i noticed that there are other modules unpackaged : https://atoms.scilab.org/toolboxes/swt https://atoms.scilab.org/toolboxes/regtools Is atoms down ? Best regards, Micha?l Le 2016-02-25 14:46, michael.baudin at contrib.scilab.org a ?crit?: > Hi, > > I develop and maintain two atoms modules : > > https://atoms.scilab.org/toolboxes/distfun/1.0 (released Nov. 2015) > https://atoms.scilab.org/toolboxes/stixbox/2.4 (released Feb. 2016) > > These two modules were not compiled by the atoms system, which is a > problem for me. > > I have three specific questions on this : > * Since the modules were not compiled, I tried to compiled them by > myself. Unfortunately, I got the following message after uploading the > .zip : > > [send_mail_create] [send] 5.1.1 : Recipient address rejected: User > unknown in virtual mailbox table > > Any idea ? > > * Should I create a specific bug report on bugzilla or should I > contact the atoms maintainer (and who is it ?) ? > > * Up to what point is the creation of atoms binaries automatic ? At > what step are humans involved in the task ? Should the build of module > be shared with external contributors and is it technically possible ? > > Best regards, > > Micha?l > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From siddheshwani.iitb at gmail.com Sun Mar 20 19:55:16 2016 From: siddheshwani.iitb at gmail.com (Siddhesh) Date: Sun, 20 Mar 2016 11:55:16 -0700 (MST) Subject: [Scilab-Dev] Unable to clone svn repo Message-ID: <1458500116902-4033782.post@n3.nabble.com> Hi all, I am trying to build Scilab from source following instructions given here . I am able to clone git repo but not able clone svn repo (prerequisites). It gives me error as 'svn: E000110: Unable to connect to a repository at URL svn://svn.scilab.org/scilab/trunk/Dev-Tools/SE/Prerequirements/linux/bin' svn: E000110: Can't connect to host 'svn.scilab.org': Connection timed out' I am accessing internet through proxy. So, I thought it might be because of proxy. But I am able clone other svn repo (apache repo). Can somebody help me? -- View this message in context: http://mailinglists.scilab.org/Unable-to-clone-svn-repo-tp4033782.html Sent from the Scilab developers - Mailing Lists Archives mailing list archive at Nabble.com. From rishubhjain at ymail.com Sun Mar 20 20:02:01 2016 From: rishubhjain at ymail.com (Rishubh Jain) Date: Sun, 20 Mar 2016 19:02:01 +0000 (UTC) Subject: [Scilab-Dev] Unable to clone svn repo In-Reply-To: <1458500116902-4033782.post@n3.nabble.com> References: <1458500116902-4033782.post@n3.nabble.com> Message-ID: <1921913148.1247681.1458500521842.JavaMail.yahoo@mail.yahoo.com> Hi, If you check?http://forge.scilab.org/index.php/p/linux-prerequisites-sources/source/tree/40/trunk/Dev-Tools/SE/Prerequirements/linux? you will see that there is no bin folder and your link is searching for bin folder CheersRishubh On Monday, 21 March 2016 12:26 AM, Siddhesh wrote: Hi all, I am trying to build Scilab from source following instructions given? here ? . I am able to clone git repo but not able clone svn repo (prerequisites). It gives me error as 'svn: E000110: Unable to connect to a repository at URL svn://svn.scilab.org/scilab/trunk/Dev-Tools/SE/Prerequirements/linux/bin' svn: E000110: Can't connect to host 'svn.scilab.org': Connection timed out' I am accessing internet through proxy. So, I thought it might be because of proxy. But I am able clone other svn repo (apache repo). Can somebody help me? -- View this message in context: http://mailinglists.scilab.org/Unable-to-clone-svn-repo-tp4033782.html Sent from the Scilab developers - Mailing Lists Archives mailing list archive at Nabble.com. _______________________________________________ dev mailing list dev at lists.scilab.org http://lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From siddheshwani.iitb at gmail.com Sun Mar 20 20:12:42 2016 From: siddheshwani.iitb at gmail.com (Siddhesh) Date: Sun, 20 Mar 2016 12:12:42 -0700 (MST) Subject: [Scilab-Dev] Unable to clone svn repo In-Reply-To: <1921913148.1247681.1458500521842.JavaMail.yahoo@mail.yahoo.com> References: <1458500116902-4033782.post@n3.nabble.com> <1921913148.1247681.1458500521842.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1458501162055-4033784.post@n3.nabble.com> Hi Rishubh, Thanks for prompt response. '/bin' was my mistake. I don't remember when did I put it there. Even without '/bin' it was not working either. But now I am able to download from 'svn.forge.scilab.org'. Thanks again. -- View this message in context: http://mailinglists.scilab.org/Unable-to-clone-svn-repo-tp4033782p4033784.html Sent from the Scilab developers - Mailing Lists Archives mailing list archive at Nabble.com. From stephane.mottelet at utc.fr Sun Mar 20 22:31:55 2016 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Sun, 20 Mar 2016 22:31:55 +0100 Subject: [Scilab-Dev] problem with svn.forge.scilab.org access rights In-Reply-To: <1458500116902-4033782.post@n3.nabble.com> References: <1458500116902-4033782.post@n3.nabble.com> Message-ID: <56EF16CB.1060804@utc.fr> Hello, I have a project "Sysmetab" on the forge and although the source tree has been set as visible only for the owner and members of the project, it is visible from anywhere (and anybody) by typing direct urls like http://svn.forge.scilab.org/sysmetab/ I think that all the parameters are correctly set on my side. Can something be fixed on the forge admin side ? Thanks in advance, S. From clement.david at scilab-enterprises.com Mon Mar 21 11:44:14 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Mon, 21 Mar 2016 11:44:14 +0100 Subject: [Scilab-Dev] problem with svn.forge.scilab.org access rights In-Reply-To: <56EF16CB.1060804@utc.fr> References: <1458500116902-4033782.post@n3.nabble.com> <56EF16CB.1060804@utc.fr> Message-ID: <1458557054.2420.12.camel@scilab-enterprises.com> Hello St?phane, I checked and after setting the project as "Private project" the HTTP server prompt me for a login when accessing a URL. Is it what you expect ? AFAIK a project is either open or close ; advanced user rights are not taken in account when accessing the source code directly. -- Cl?ment Le dimanche 20 mars 2016 ? 22:31 +0100, St?phane Mottelet a ?crit?: > Hello, > > I have a project "Sysmetab" on the forge and although the source tree?? > has been set as visible only for the owner and members of the project,? > it is visible from anywhere (and anybody) by typing direct urls like > > http://svn.forge.scilab.org/sysmetab/ > > I think that all the parameters are correctly set on my side. Can? > something be fixed on the forge admin side ? > > Thanks in advance, > > S. > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From stephane.mottelet at utc.fr Mon Mar 21 12:07:07 2016 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Mon, 21 Mar 2016 12:07:07 +0100 Subject: [Scilab-Dev] problem with svn.forge.scilab.org access rights In-Reply-To: <1458557054.2420.12.camel@scilab-enterprises.com> References: <1458500116902-4033782.post@n3.nabble.com> <56EF16CB.1060804@utc.fr> <1458557054.2420.12.camel@scilab-enterprises.com> Message-ID: <56EFD5DB.8050904@utc.fr> Hello, Le 21/03/2016 11:44, Cl?ment David a ?crit : > Hello St?phane, > > I checked and after setting the project as "Private project" the HTTP server prompt me for a login > when accessing a URL. Is it what you expect ? no. I reported the problem because I saw that since a few days Google is indexing the whole svn tree of my project, although the source (not the whole project itself) is set as "closed" in the forge parameters... This is quite confusing ! > > AFAIK a project is either open or close ; advanced user rights are not taken in account when > accessing the source code directly. OK, so you mean that user rights only concern writing rights ? This is not coherent because when the source is set as "closed' it is not acessible from the project page, but completely visible from the internet via the http://svn.forge.scilab.org/ url. S. > > -- > Cl?ment > > Le dimanche 20 mars 2016 ? 22:31 +0100, St?phane Mottelet a ?crit : >> Hello, >> >> I have a project "Sysmetab" on the forge and although the source tree >> has been set as visible only for the owner and members of the project, >> it is visible from anywhere (and anybody) by typing direct urls like >> >> http://svn.forge.scilab.org/sysmetab/ >> >> I think that all the parameters are correctly set on my side. Can >> something be fixed on the forge admin side ? >> >> Thanks in advance, >> >> S. >> _______________________________________________ >> dev mailing list >> dev at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/dev > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -- D?partement de G?nie Informatique EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable Universit? de Technologie de Compi?gne - CS 60319 60203 Compi?gne cedex From adhitya07 at gmail.com Mon Mar 21 12:28:26 2016 From: adhitya07 at gmail.com (adhitya) Date: Mon, 21 Mar 2016 04:28:26 -0700 (MST) Subject: [Scilab-Dev] Documentation for Xcos In-Reply-To: References: <1454135487845-4033357.post@n3.nabble.com> <1454311906.2921.9.camel@scilab-enterprises.com> <1455886529.2660.41.camel@scilab-enterprises.com>

Message-ID: <1458559706603-4033790.post@n3.nabble.com> Hi, Could you please point me to the file (or the String) that has the XML representation of the JGraphX front-end, just before the play button is pressed? Thanks, Adhitya -- View this message in context: http://mailinglists.scilab.org/Documentation-for-Xcos-tp4033357p4033790.html Sent from the Scilab developers - Mailing Lists Archives mailing list archive at Nabble.com. From normand at linux.vnet.ibm.com Mon Mar 21 13:13:49 2016 From: normand at linux.vnet.ibm.com (michel normand) Date: Mon, 21 Mar 2016 05:13:49 -0700 (MST) Subject: [Scilab-Dev] [Scilab-users] Issue when compiling Scilab: "Cannot allocate this quantity of memory" In-Reply-To: <1425374669.2419.9.camel@scilab-enterprises.com> References: <1425374669.2419.9.camel@scilab-enterprises.com> Message-ID: <1458562429946-4033791.post@n3.nabble.com> I assume this thread is related to the still open bug http://bugzilla.scilab.org/show_bug.cgi?id=13826 about "Stacksize can't be allocated" -- View this message in context: http://mailinglists.scilab.org/Re-Scilab-users-Issue-when-compiling-Scilab-Cannot-allocate-this-quantity-of-memory-tp4031773p4033791.html Sent from the Scilab developers - Mailing Lists Archives mailing list archive at Nabble.com. From clement.david at scilab-enterprises.com Tue Mar 22 11:27:14 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Tue, 22 Mar 2016 11:27:14 +0100 Subject: [Scilab-Dev] Documentation for Xcos In-Reply-To: <1458559706603-4033790.post@n3.nabble.com> References: <1454135487845-4033357.post@n3.nabble.com> <1454311906.2921.9.camel@scilab-enterprises.com> <1455886529.2660.41.camel@scilab-enterprises.com>

<1458559706603-4033790.post@n3.nabble.com> Message-ID: <1458642434.11844.32.camel@scilab-enterprises.com> Hi, Just save the file to the xcos format. This is the XML format that we support. The JGraphX internal representation might differ but you might probably get enough information. The zcos file format is (similarly to the ODT format) a ZIP file containing a file called content.xml with similar content. Regards, -- Cl?ment Le lundi 21 mars 2016 ? 04:28 -0700, adhitya a ?crit?: > Hi, > > Could you please point me to the file (or the String) that has the XML > representation of the JGraphX front-end, just before the play button is > pressed? > > Thanks, > > Adhitya > > > > > -- > View this message in context: http://mailinglists.scilab.org/Documentation-for-Xcos-tp4033357p4033 > 790.html > Sent from the Scilab developers - Mailing Lists Archives mailing list archive at Nabble.com. > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From adhitya07 at gmail.com Tue Mar 22 12:24:41 2016 From: adhitya07 at gmail.com (adhitya) Date: Tue, 22 Mar 2016 04:24:41 -0700 (MST) Subject: [Scilab-Dev] Documentation for Xcos In-Reply-To: <1458642434.11844.32.camel@scilab-enterprises.com> References: <1454135487845-4033357.post@n3.nabble.com> <1454311906.2921.9.camel@scilab-enterprises.com> <1455886529.2660.41.camel@scilab-enterprises.com>

<1458559706603-4033790.post@n3.nabble.com> <1458642434.11844.32.camel@scilab-enterprises.com> Message-ID: Hi, As you might know, we are porting Xcos on to the Web. The front end of XCos is done using JGraphX - correct? Since the JavaScript version of JGraphX - mxGraph is not Open Source, we are doing the porting using Draw2D. We want to convert Draw2D XML to JGraphX XML. Could you please point the Line number where we can get that JGraphX XML String? Adhitya On Tue, Mar 22, 2016 at 3:59 PM, Cl?ment David-2 [via Scilab / Xcos - Mailing Lists Archives] wrote: > Hi, > > Just save the file to the xcos format. This is the XML format that we > support. The JGraphX internal > representation might differ but you might probably get enough information. > > The zcos file format is (similarly to the ODT format) a ZIP file > containing a file called > content.xml with similar content. > > Regards, > > -- > Cl?ment > > Le lundi 21 mars 2016 ? 04:28 -0700, adhitya a ?crit : > > > Hi, > > > > Could you please point me to the file (or the String) that has the XML > > representation of the JGraphX front-end, just before the play button is > > pressed? > > > > Thanks, > > > > Adhitya > > > > > > > > > > -- > > View this message in context: > http://mailinglists.scilab.org/Documentation-for-Xcos-tp4033357p4033 > > 790.html > > Sent from the Scilab developers - Mailing Lists Archives mailing list > archive at Nabble.com. > > _______________________________________________ > > dev mailing list > > [hidden email] > > http://lists.scilab.org/mailman/listinfo/dev > _______________________________________________ > dev mailing list > [hidden email] > http://lists.scilab.org/mailman/listinfo/dev > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://mailinglists.scilab.org/Documentation-for-Xcos-tp4033357p4033813.html > To unsubscribe from Documentation for Xcos, click here > > . > NAML > > -- View this message in context: http://mailinglists.scilab.org/Documentation-for-Xcos-tp4033357p4033817.html Sent from the Scilab developers - Mailing Lists Archives mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Wed Mar 23 09:04:49 2016 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Wed, 23 Mar 2016 09:04:49 +0100 Subject: [Scilab-Dev] Matrix indexing is not coherent with MATLAB convention (bug #14487) Message-ID: <56F24E21.10808@utc.fr> Hello, Matrix indexing is not coherent with Matlab (or Octave, Julia,...) conventions. For example, when x is a vector and A a matrix of indices of x, x(A) should be a matrix with the same size as A : MATLAB: >> x=[1 2 3]; A=[1 2;3 3]; x(A) ans = 1 2 3 3 Julia: julia> x=[1 2 3]; A=[1 2;3 3]; x[A] 2x2 Array{Int64,2}: 1 2 3 3 Scilab: --> x=[1 2 3]; A=[1 2;3 3]; x(A) ans = 1. 3. 2. 3. This is really annoying and is a problem for portability. I know that matrix(x(A),size(A)) gives the correct answer, but having to use such a construct is not admissible. http://bugzilla.scilab.org/show_bug.cgi?id=14487 S. -- D?partement de G?nie Informatique EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable Universit? de Technologie de Compi?gne - CS 60319 60203 Compi?gne cedex From stephane.mottelet at utc.fr Wed Mar 23 10:05:13 2016 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Wed, 23 Mar 2016 10:05:13 +0100 Subject: [Scilab-Dev] Scilab index type should be generalized Message-ID: <56F25C49.5060305@utc.fr> Hello, Most of you should have noticed that the expression 1:$ has the index type: --> type(1:$) ans = 129. which means that when you write something like --> a=rand(10,1); a(1:$) then 1:$ is passed as an index to the interpreter, and not as a vector. The two constructs a(1:$) a(1:10) should be treated the same way by the interpreter, but this is not the case as the 1:10 has not the index type --> type(1:10) ans = 1. This means that Scilab handles 1:10 as any other vector of scrambled/duplicate indices without seeing that all the components are contiguous in memory. In fact, this behavior is a major bottleneck, as illustrated in the following (Scilab 5.5.2 timings on a Xeon E5-2660 v2 (2.20 GHz) ) --> n=200000;a=rand(n,1); --> timer();for i=1:1000;sum(a(10:100000));end;disp(timer()) 1.51426 --> timer();for i=1:1000;sum(a($-n+10:$-n+100000));end;disp(timer()) 0.588478 almost three times faster... But the problem is that we have been all get used to mistake indices for vectors. That's why Julia, for example, uses brackets to make the difference : 1:10 is an index set and [1:10] is the vector [1,2,3,...,10]. I know that introducing this in Scilab is almost impossible as it would break a lot of things, but maybe a solution could be found at the interpreter level, as the trick of replacing a(10:100000) by a($-n+10:$-n+100000) is really boosting the indexing mechanism. S. -- D?partement de G?nie Informatique EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable Universit? de Technologie de Compi?gne - CS 60319 60203 Compi?gne cedex -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Wed Mar 23 11:59:28 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 23 Mar 2016 11:59:28 +0100 Subject: [Scilab-Dev] Scilab index type should be generalized In-Reply-To: <56F25C49.5060305@utc.fr> References: <56F25C49.5060305@utc.fr> Message-ID: <56F27710.80407@free.fr> Hello St?phane, Le 23/03/2016 10:05, St?phane Mottelet a ?crit : > .../... > This means that Scilab handles 1:10 as any other vector of > scrambled/duplicate indices without seeing that all the components are > contiguous in memory. In fact, this behavior is a major bottleneck, as > illustrated in the following (Scilab 5.5.2 timings on a Xeon E5-2660 > v2 (2.20 GHz) ) > > --> n=200000;a=rand(n,1); > > --> timer();for i=1:1000;sum(a(10:100000));end;disp(timer()) > > 1.51426 > > --> timer();for i=1:1000;sum(a($-n+10:$-n+100000));end;disp(timer()) > > 0.588478 > > almost three times faster... On my PC, i get with Scilab 6.0b1 / win7_x64, in a ~reproducible way (for the ratio) : --> timer();for i=1:1000;sum(a(10:100000));end;disp(timer()) 2.1996141 --> timer();for i=1:1000;sum(a($-n+10:$-n+100000));end;disp(timer()) 1.5756101 Scilab 5.5.2 is slightly faster and the ratio is a bit more balanced: --> timer();for i=1:1000;sum(a(10:100000));end;disp(timer()) 1.716011 -->timer();for i=1:1000;sum(a($-n+10:$-n+100000));end;disp(timer()) 1.4196091 Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Wed Mar 23 12:20:45 2016 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Wed, 23 Mar 2016 12:20:45 +0100 Subject: [Scilab-Dev] Scilab index type should be generalized In-Reply-To: <56F27710.80407@free.fr> References: <56F25C49.5060305@utc.fr> <56F27710.80407@free.fr> Message-ID: <56F27C0D.2050805@utc.fr> Le 23/03/2016 11:59, Samuel Gougeon a ?crit : > Hello St?phane, > > Le 23/03/2016 10:05, St?phane Mottelet a ?crit : >> .../... >> This means that Scilab handles 1:10 as any other vector of >> scrambled/duplicate indices without seeing that all the components >> are contiguous in memory. In fact, this behavior is a major >> bottleneck, as illustrated in the following (Scilab 5.5.2 timings on >> a Xeon E5-2660 v2 (2.20 GHz) ) >> >> --> n=200000;a=rand(n,1); >> >> --> timer();for i=1:1000;sum(a(10:100000));end;disp(timer()) >> >> 1.51426 >> >> --> timer();for i=1:1000;sum(a($-n+10:$-n+100000));end;disp(timer()) >> >> 0.588478 >> >> almost three times faster... > > On my PC, i get with Scilab 6.0b1 / win7_x64, in a ~reproducible way > (for the ratio) : > --> timer();for i=1:1000;sum(a(10:100000));end;disp(timer()) > 2.1996141 > > --> timer();for i=1:1000;sum(a($-n+10:$-n+100000));end;disp(timer()) > 1.5756101 > > Scilab 5.5.2 is slightly faster and the ratio is a bit more balanced: > --> timer();for i=1:1000;sum(a(10:100000));end;disp(timer()) > 1.716011 > > -->timer();for i=1:1000;sum(a($-n+10:$-n+100000));end;disp(timer()) > 1.4196091 > > > Samuel on my MacPro mid 2010 (2,8 GHz Quad-Core Intel Xeon) , with Scilab 5.5.2: -->timer();for i=1:1000;sum(a(10:100000));end;disp(timer()) 1.176976 --> timer();for i=1:1000;sum(a($-n+10:$-n+100000));end;disp(timer()) 0.565811 and with Scilab 6.0b1: --> timer();for i=1:1000;sum(a(10:100000));end;disp(timer()) 1.22783 --> timer();for i=1:1000;sum(a($-n+10:$-n+100000));end;disp(timer()) 0.728778 The different ratios for different platforms are somehow understandable (different os, memory management, ...) but anyway disturbing ! S. > > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -- D?partement de G?nie Informatique EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable Universit? de Technologie de Compi?gne - CS 60319 60203 Compi?gne cedex -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine.monmayrant at laas.fr Wed Mar 23 12:39:28 2016 From: antoine.monmayrant at laas.fr (Antoine Monmayrant) Date: Wed, 23 Mar 2016 12:39:28 +0100 Subject: [Scilab-Dev] Scilab index type should be generalized In-Reply-To: <56F27C0D.2050805@utc.fr> References: <56F25C49.5060305@utc.fr> <56F27710.80407@free.fr> <56F27C0D.2050805@utc.fr> Message-ID: <56F28070.8050304@laas.fr> Le 03/23/2016 12:20 PM, St?phane Mottelet a ?crit : > timer();for i=1:1000;sum(a($-n+10:$-n+100000));end;disp(timer()) On a 10-year old pc under linux (ubuntu 14.04): 5.5.2 n=200000;a=rand(n,1); timer();for i=1:1000;sum(a(10:100000));end;disp(timer());timer();for i=1:1000;sum(a($-n+10:$-n+100000));end;disp(timer()) 2.202731 0.94785 6.0.0 n=200000;a=rand(n,1); timer();for i=1:1000;sum(a(10:100000));end;disp(timer());timer();for i=1:1000;sum(a($-n+10:$-n+100000));end;disp(timer()) 2.303838 1.430211 -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ Antoine Monmayrant LAAS - CNRS 7 avenue du Colonel Roche BP 54200 31031 TOULOUSE Cedex 4 FRANCE Tel:+33 5 61 33 64 59 email : antoine.monmayrant at laas.fr permanent email : antoine.monmayrant at polytechnique.org +++++++++++++++++++++++++++++++++++++++++++++++++++++++ From stephane.mottelet at utc.fr Wed Mar 23 16:15:49 2016 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Wed, 23 Mar 2016 16:15:49 +0100 Subject: [Scilab-Dev] Erratic behavior of "Recent files" Scinotes menu item under OSX Message-ID: <56F2B325.8080909@utc.fr> Hello, The "Recent files" Scinotes feature is (almost all the time) not working. For example, I see filenames concerning very old stuff I was working with one year ago, but recent files never appear. Am I the only person having this problem (OSX specific ?) ? BTW, where is located the file storing the file opening history ? S. -- D?partement de G?nie Informatique EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable Universit? de Technologie de Compi?gne - CS 60319 60203 Compi?gne cedex From stephane.mottelet at utc.fr Wed Mar 23 16:25:02 2016 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Wed, 23 Mar 2016 16:25:02 +0100 Subject: [Scilab-Dev] Erratic behavior of "Recent files" Scinotes menu item under OSX In-Reply-To: <56F2B325.8080909@utc.fr> References: <56F2B325.8080909@utc.fr> Message-ID: <56F2B54E.6020800@utc.fr> Le 23/03/2016 16:15, St?phane Mottelet a ?crit : > Hello, > > The "Recent files" Scinotes feature is (almost all the time) not > working. For example, I see filenames concerning very old stuff I was > working with one year ago, but recent files never appear. Am I the > only person having this problem (OSX specific ?) ? BTW, where is > located the file storing the file opening history ? > > S. > It seems to be a regression of http://bugzilla.scilab.org/show_bug.cgi?id=7277 Because in my scinotesConfiguration.xml the files names are here, but the elements are not correctly ordered, as the top ones are the older ones... Maybe reopening the above bug would be adequate ? S. -- D?partement de G?nie Informatique EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable Universit? de Technologie de Compi?gne - CS 60319 60203 Compi?gne cedex From jicarrerom at unal.edu.co Wed Mar 23 17:19:44 2016 From: jicarrerom at unal.edu.co (javier ignacio carrero mantilla) Date: Wed, 23 Mar 2016 11:19:44 -0500 Subject: [Scilab-Dev] Erratic behavior of "Recent files" Scinotes menu item under OSX In-Reply-To: <56F2B54E.6020800@utc.fr> References: <56F2B325.8080909@utc.fr> <56F2B54E.6020800@utc.fr> Message-ID: I have noticed the same bug on windows 7 - 64bit with Scilab 5.5.0 and 5.5.2. Please reopen the 7277 thread in bugzilla 2016-03-23 10:25 GMT-05:00 St?phane Mottelet : > Le 23/03/2016 16:15, St?phane Mottelet a ?crit : > >> Hello, >> >> The "Recent files" Scinotes feature is (almost all the time) not working. >> For example, I see filenames concerning very old stuff I was working with >> one year ago, but recent files never appear. Am I the only person having >> this problem (OSX specific ?) ? BTW, where is located the file storing the >> file opening history ? >> >> S. >> >> It seems to be a regression of > > http://bugzilla.scilab.org/show_bug.cgi?id=7277 > > Because in my scinotesConfiguration.xml the files names are here, but the > elements are not correctly ordered, as the top ones are the > older ones... Maybe reopening the above bug would be adequate ? > > > S. > > -- > D?partement de G?nie Informatique > EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable > Universit? de Technologie de Compi?gne - CS 60319 > 60203 Compi?gne cedex > > _______________________________________________ > 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 Mar 23 17:49:55 2016 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Wed, 23 Mar 2016 17:49:55 +0100 Subject: [Scilab-Dev] Erratic behavior of "Recent files" Scinotes menu item under OSX In-Reply-To: References: <56F2B325.8080909@utc.fr> <56F2B54E.6020800@utc.fr> Message-ID: <56F2C933.4070805@utc.fr> bug 7277 has been reopen. S. Le 23/03/2016 17:19, javier ignacio carrero mantilla a ?crit : > I have noticed the same bug on windows 7 - 64bit with Scilab 5.5.0 and > 5.5.2. Please reopen the 7277 thread in bugzilla > > 2016-03-23 10:25 GMT-05:00 St?phane Mottelet >: > > Le 23/03/2016 16:15, St?phane Mottelet a ?crit : > > Hello, > > The "Recent files" Scinotes feature is (almost all the time) > not working. For example, I see filenames concerning very old > stuff I was working with one year ago, but recent files never > appear. Am I the only person having this problem (OSX specific > ?) ? BTW, where is located the file storing the file opening > history ? > > S. > > It seems to be a regression of > > http://bugzilla.scilab.org/show_bug.cgi?id=7277 > > Because in my scinotesConfiguration.xml the files names are here, > but the elements are not correctly ordered, as the top > ones are the older ones... Maybe reopening the above bug would be > adequate ? > > > S. > > -- > D?partement de G?nie Informatique > EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable > Universit? de Technologie de Compi?gne - CS 60319 > 60203 Compi?gne cedex > > _______________________________________________ > 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 -- D?partement de G?nie Informatique EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable Universit? de Technologie de Compi?gne - CS 60319 60203 Compi?gne cedex -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Thu Mar 24 21:53:43 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 24 Mar 2016 21:53:43 +0100 Subject: [Scilab-Dev] ui tables: a review of helpful features Message-ID: <56F453D7.5030700@free.fr> Hello, ui.table as an uicontrol interactive graphical component was added to Scilab in 2010. However, users cases have shown that this release was hardly an alpha version. Several bugs or missing features were reported on Bugzilla about it. This interactive component remains much needed, beyond the current alpha version that cannot really be used. A review of features that would be useful is now reported on the Scilab wiki: https://wiki.scilab.org/Contributor%20-%20uicontrol:%20interactive%20table The list of features is quite long, and some priorities are suggested. Indeed, this ui.component is a "2D" one and is more complex than basic uicontrol styles. It may have also many distinct applications. As decided by Scilab's team, the upgrade of this component has a high priority for the GSOC2016. Comments, suggestions and discussions are welcome on this mailing list, as well as on the discussion page opened with the wiki page. Best regards Samuel Gougeon https://help.scilab.org/docs/5.5.2/en_US/uicontrol.html -------------- next part -------------- An HTML attachment was scrubbed... URL: