From clement.david at scilab-enterprises.com Mon Feb 1 08:31:46 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Mon, 01 Feb 2016 08:31:46 +0100 Subject: [Scilab-Dev] Documentation for Xcos In-Reply-To: <1454135487845-4033357.post@n3.nabble.com> References: <1454135487845-4033357.post@n3.nabble.com> Message-ID: <1454311906.2921.9.camel@scilab-enterprises.com> Hi?Adhitya, The code is *the* reference but for more internal views I suggest you to read these documents : * R. NIKOUKHAH AND S. STEER , Scicos a dynamic system builder and simulator, IEEE INTERNATIONAL CONFERENCE ON CACSD, DEARBORN , MICHIGAN , 1996. * S. STEER , R. NIKOUKHAH , Scicos: a hybrid system formalism, ESS?99, E RLANGEN , GERMANY , 1999. * Masoud NAJAFI thesis , The Numerical Solver for the Simulation of the Hybrid Dynamical Systems ,?2005 . And for understanding what's behind each block, take a look at the Scilab documentation, and ScilabTec presentations. Regards, -- Cl?ment Le vendredi 29 janvier 2016 ? 23:31 -0700, adhitya a ?crit?: > Hi, > > My name is Adhitya Kamakshidasan and I'm an Intern at FOSSEE, IIT Bombay.? > > We are trying to develop a standalone version of Xcos, that is completely > web-based. > > I would like to know if there is any documentation with respect to how Xcos > has been written - Flowcharts, Main methods, PDF's, etc. > > Currently, I'm trying to reverse-engineer the code, by slowly moving through > the code, and removing the parts that are not related to Xcos. However, this > is taking a lot of time. > > We would like your support in this regard. > > Thanks, > > Adhitya Kamakshidasan > > > > -- > View this message in context: http://mailinglists.scilab.org/Documentation-for-Xcos-tp4033357.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 Fri Feb 12 18:11:40 2016 From: adhitya07 at gmail.com (adhitya) Date: Fri, 12 Feb 2016 10:11:40 -0700 (MST) Subject: [Scilab-Dev] Documentation for Xcos In-Reply-To: <1454311906.2921.9.camel@scilab-enterprises.com> References: <1454135487845-4033357.post@n3.nabble.com> <1454311906.2921.9.camel@scilab-enterprises.com> Message-ID: Hi, Thank you for your response. I will definitely go through the links that you have provided for a better understanding. ---- 1 ---- As a part of my reverse engineering process, I have started from the point where Xcos application is invoked, when the button is pressed in the MenuBar. The flow of files that I have gone through, after the button has been pressed, is the following: - main_menubar.xml - MenuBarBuilder.java - GraphicController.java - GraphicObject.java - CallBack.java - CommonCallBack.java - ScilabCallBack.java - InterpreterManagement.java - InterpreterManagementJNI.java - StoreCommand.cpp - ThreadManagement.cpp In the file named StoreCommand.cpp, the following function is invoked - ( https://github.com/opencollab/scilab/blob/9cc3c2b45eec49626d82b496a80117b048745836/scilab/modules/core/src/cpp/storeCommand.cpp#L76 ) int StoreCommand(char *command) { ThreadManagement::LockStoreCommand(); commandQueue.emplace_back(os_strdup(command), /*is prioritary*/ 0, /* is interruptible*/ 1, /* cmd origin */ NONE); ThreadManagement::UnlockStoreCommand(); // Awake Scilab to execute a new command ThreadManagement::SendCommandStoredSignal(); return 0; } In this function calls are further made to - https://github.com/opencollab/scilab/blob/9cc3c2b45eec49626d82b496a80117b048745836/scilab/modules/ast/src/cpp/system_env/threadmanagement.cpp#L110 void ThreadManagement::LockStoreCommand(void) { #ifdef DEBUG_THREAD PrintDebug("LockStoreCommand"); #endif // DEBUG_THREAD __Lock(&m_StoreCommandLock); } void ThreadManagement::UnlockStoreCommand(void) { #ifdef DEBUG_THREAD PrintDebug("UnlockStoreCommand"); #endif // DEBUG_THREAD __UnLock(&m_StoreCommandLock); } I'm unable to understand the Lock and Unlock mechanisms that are used in this function. What happens before/during/after Lock and Unlock? Would you have any documentation for this part? If possible, could you explain the StoreCommand() function? I see that all incoming commands are en-queued in the commandQueue, to be processed one by one. But where in the code, is the command getting de-queued for parsing? ---- 2 ---- The command that is given in /etc/main_menubar.xml for opening Xcos is if with_mode ('xcos') then xcos(); else disp(gettext('Please install xcos module')) Would it be possible for you to point where xcos() is invoked after interpretation and parsing? Hypothetically for instance, if I were to create a new method in Java, so that I can see the Block Diagram Editor, like this - public static void main (String args[]){ Xcos xcos = new Xcos(); //Assuming I can write something like this } If this is possible, I would like to know, which is that particular 'XCos' Class that can allow me to do this? Do let me know, if any of my questions are vague or unclear. Thanks, Adhitya On Mon, Feb 1, 2016 at 1:02 PM, Cl?ment David-2 [via Scilab / Xcos - Mailing Lists Archives] wrote: > Hi Adhitya, > > The code is *the* reference but for more internal views I suggest you to > read these documents : > > * R. NIKOUKHAH AND S. STEER , Scicos a dynamic system builder and > simulator, IEEE INTERNATIONAL > CONFERENCE ON CACSD, DEARBORN , MICHIGAN , 1996. > * S. STEER , R. NIKOUKHAH , Scicos: a hybrid system formalism, ESS?99, E > RLANGEN , GERMANY , 1999. > * Masoud NAJAFI thesis , The Numerical Solver for the Simulation of the > Hybrid Dynamical Systems > , 2005 . > > And for understanding what's behind each block, take a look at the Scilab > documentation, and > ScilabTec presentations. > > Regards, > > -- > Cl?ment > > > Le vendredi 29 janvier 2016 ? 23:31 -0700, adhitya a ?crit : > > > Hi, > > > > My name is Adhitya Kamakshidasan and I'm an Intern at FOSSEE, IIT > Bombay. > > > > We are trying to develop a standalone version of Xcos, that is > completely > > web-based. > > > > I would like to know if there is any documentation with respect to how > Xcos > > has been written - Flowcharts, Main methods, PDF's, etc. > > > > Currently, I'm trying to reverse-engineer the code, by slowly moving > through > > the code, and removing the parts that are not related to Xcos. However, > this > > is taking a lot of time. > > > > We would like your support in this regard. > > > > Thanks, > > > > Adhitya Kamakshidasan > > > > > > > > -- > > View this message in context: > http://mailinglists.scilab.org/Documentation-for-Xcos-tp4033357.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-tp4033357p4033359.html > To unsubscribe from Documentation for Xcos, click here > > . > NAML > > -- View this message in context: http://mailinglists.scilab.org/Documentation-for-Xcos-tp4033357p4033448.html Sent from the Scilab developers - Mailing Lists Archives mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurent.berger at univ-lemans.fr Mon Feb 15 12:27:39 2016 From: laurent.berger at univ-lemans.fr (Laurent Berger) Date: Mon, 15 Feb 2016 12:27:39 +0100 Subject: [Scilab-Dev] Scilab 6.0 In-Reply-To: <1451979804.3828.2.camel@scilab-enterprises.com> References: <567BE4FF.4080702@univ-lemans.fr> <1451979804.3828.2.camel@scilab-enterprises.com> Message-ID: <56C1B62B.7000508@univ-lemans.fr> Hi, Is it a message from Scilab Enterprise? " Le 05/01/2016 08:43, Cl?ment David a ?crit : > Hi Laurent, > > The call function is not implemented yet but will be for the stable release. Note that your toolbox > does not use the toolbox skeleton and thus might be harder to maintain in the future. > > -- > Cl?ment > > Le jeudi 24 d?cembre 2015 ? 13:28 +0100, Laurent Berger a ?crit : >> Hi, >> >> I'm trying to use Scilab 6.0 alpha2.0 with my contrib. After some error >> like some ; missing I have got an error : >> >> Undefined variable: call >> >> at line 2 of function FermerPortAudio ( >> C:\PROGRA~1\SCILAB~1.0-A\contrib\AnaSpec\loader.sce line 65 ) >> >> I don't understand call is stil in doc so If somebody can help me... >> >> Thanks in advance >> >> Source code is here >> https://github.com/LaurentBerger/Traitement_du_signal_avec_Scilab >> _______________________________________________ >> 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 embedded message was scrubbed... From: Yann Debray - Team Scilab Subject: [PUB]Scilab News: Scilab 6 Beta, VISA Toolbox, Embedded World 2016 Date: Mon, 15 Feb 2016 11:09:32 +0000 Size: 55544 URL: From laurent.berger at univ-lemans.fr Mon Feb 15 12:34:33 2016 From: laurent.berger at univ-lemans.fr (Laurent Berger) Date: Mon, 15 Feb 2016 12:34:33 +0100 Subject: [Scilab-Dev] Scilab 6.0 In-Reply-To: <56C1B62B.7000508@univ-lemans.fr> References: <567BE4FF.4080702@univ-lemans.fr> <1451979804.3828.2.camel@scilab-enterprises.com> <56C1B62B.7000508@univ-lemans.fr> Message-ID: <56C1B7C9.5090005@univ-lemans.fr> Le 15/02/2016 12:27, Laurent Berger a ?crit : Hi, Is it a message from Scilab Enterprise? Just arrived : Yann Debray - Team Scilab Reply-To: communication at scilab-enterprises.com To: Subject: [PUB]Scilab News: Scilab 6 Beta, VISA Toolbox, Embedded World 2016 PS sorry for empty message From adhitya07 at gmail.com Thu Feb 18 13:43:28 2016 From: adhitya07 at gmail.com (Adhitya Kamakshidasan) Date: Thu, 18 Feb 2016 18:13:28 +0530 Subject: [Scilab-Dev] Documentation for Xcos In-Reply-To: References: <1454135487845-4033357.post@n3.nabble.com> <1454311906.2921.9.camel@scilab-enterprises.com> Message-ID: Hi all, It's been a while, since I posted my previous query on the forum. However, I have not yet received any response to it. I'm quite stuck with this for the past week or so. Could you please help me out? Adhitya On Fri, Feb 12, 2016 at 10:41 PM, adhitya wrote: > Hi, > > Thank you for your response. I will definitely go through the links that > you have provided for a better understanding. > > ---- 1 ---- > > As a part of my reverse engineering process, I have started from the point > where Xcos application is invoked, when the button is pressed in the > MenuBar. > > The flow of files that I have gone through, after the button has been > pressed, is the following: > > - main_menubar.xml > - MenuBarBuilder.java > - GraphicController.java > - GraphicObject.java > - CallBack.java > - CommonCallBack.java > - ScilabCallBack.java > - InterpreterManagement.java > - InterpreterManagementJNI.java > - StoreCommand.cpp > - ThreadManagement.cpp > > > In the file named StoreCommand.cpp, the following function is invoked - ( > https://github.com/opencollab/scilab/blob/9cc3c2b45eec49626d82b496a80117b048745836/scilab/modules/core/src/cpp/storeCommand.cpp#L76 > ) > > int StoreCommand(char *command) > { > ThreadManagement::LockStoreCommand(); > commandQueue.emplace_back(os_strdup(command), > /*is prioritary*/ 0, > /* is interruptible*/ 1, > /* cmd origin */ NONE); > > ThreadManagement::UnlockStoreCommand(); > // Awake Scilab to execute a new command > ThreadManagement::SendCommandStoredSignal(); > > return 0; > } > > In this function calls are further made to - > https://github.com/opencollab/scilab/blob/9cc3c2b45eec49626d82b496a80117b048745836/scilab/modules/ast/src/cpp/system_env/threadmanagement.cpp#L110 > > void ThreadManagement::LockStoreCommand(void) > { > #ifdef DEBUG_THREAD > PrintDebug("LockStoreCommand"); > #endif // DEBUG_THREAD > __Lock(&m_StoreCommandLock); > } > > void ThreadManagement::UnlockStoreCommand(void) > { > #ifdef DEBUG_THREAD > PrintDebug("UnlockStoreCommand"); > #endif // DEBUG_THREAD > __UnLock(&m_StoreCommandLock); > } > > I'm unable to understand the Lock and Unlock mechanisms that are used in > this function. What happens before/during/after Lock and Unlock? Would you > have any documentation for this part? > > If possible, could you explain the StoreCommand() function? I see that all > incoming commands are en-queued in the commandQueue, to be processed one by > one. But where in the code, is the command getting de-queued for parsing? > > ---- 2 ---- > > The command that is given in /etc/main_menubar.xml for opening Xcos is > > if with_mode ('xcos') then xcos(); > else disp(gettext('Please install xcos module')) > > Would it be possible for you to point where xcos() is invoked after > interpretation and parsing? > > Hypothetically for instance, if I were to create a new method in Java, so > that I can see the Block Diagram Editor, like this - > > public static void main (String args[]){ > Xcos xcos = new Xcos(); //Assuming I can write something like this > } > > If this is possible, I would like to know, which is that particular 'XCos' > Class that can allow me to do this? > > Do let me know, if any of my questions are vague or unclear. > > Thanks, > > Adhitya > > On Mon, Feb 1, 2016 at 1:02 PM, Cl?ment David-2 [via Scilab / Xcos - > Mailing Lists Archives] <[hidden email] > > wrote: > >> Hi Adhitya, >> >> The code is *the* reference but for more internal views I suggest you to >> read these documents : >> >> * R. NIKOUKHAH AND S. STEER , Scicos a dynamic system builder and >> simulator, IEEE INTERNATIONAL >> CONFERENCE ON CACSD, DEARBORN , MICHIGAN , 1996. >> * S. STEER , R. NIKOUKHAH , Scicos: a hybrid system formalism, ESS?99, E >> RLANGEN , GERMANY , 1999. >> * Masoud NAJAFI thesis , The Numerical Solver for the Simulation of the >> Hybrid Dynamical Systems >> , 2005 . >> >> And for understanding what's behind each block, take a look at the Scilab >> documentation, and >> ScilabTec presentations. >> >> Regards, >> >> -- >> Cl?ment >> >> >> Le vendredi 29 janvier 2016 ? 23:31 -0700, adhitya a ?crit : >> >> > Hi, >> > >> > My name is Adhitya Kamakshidasan and I'm an Intern at FOSSEE, IIT >> Bombay. >> > >> > We are trying to develop a standalone version of Xcos, that is >> completely >> > web-based. >> > >> > I would like to know if there is any documentation with respect to how >> Xcos >> > has been written - Flowcharts, Main methods, PDF's, etc. >> > >> > Currently, I'm trying to reverse-engineer the code, by slowly moving >> through >> > the code, and removing the parts that are not related to Xcos. However, >> this >> > is taking a lot of time. >> > >> > We would like your support in this regard. >> > >> > Thanks, >> > >> > Adhitya Kamakshidasan >> > >> > >> > >> > -- >> > View this message in context: >> http://mailinglists.scilab.org/Documentation-for-Xcos-tp4033357.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-tp4033357p4033359.html >> To unsubscribe from Documentation for Xcos, click here. >> NAML >> >> > > > ------------------------------ > View this message in context: Re: Documentation for Xcos > > > 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 sgougeon at free.fr Thu Feb 18 18:45:53 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 18 Feb 2016 18:45:53 +0100 Subject: [Scilab-Dev] SEP #40: Cell Arrays In-Reply-To: <4BB0758D.9090208@scilab.org> References: <4BB0758D.9090208@scilab.org> Message-ID: <56C60351.7080908@free.fr> Hello, Le 29/03/2010 11:40, Bruno JOFRET a ?crit : > Hi, > > Please find attached SEP #40 talking about Cell Arrays. > This SEP is targeting Scilab 6.0 as we will introduce a new syntax for > cells. > > Any feedbacks are welcome. 6 years after, it is very (very) late to comment or make any suggestion. Yet, Scilab 6.0 is not yet released, so i hope that this won't be too late for the essential: Indexation (extraction and insertion) with {} should really not be introduced. This message comes after first comments and rational recently posted there: http://mailinglists.scilab.org/Scilab-users-a-i-j-specific-extraction-syntax-with-should-not-be-introduced-tp4033484.html As another way to explain why {} extractors and inserters must not be introduced, we may follow the pages of the current version of the SEP available here: http://gitweb.scilab.org/?p=scilab.git;a=blob;f=SEP/SEP_040_cell_arrays.odt * After a cell array *c = { %pi %i %t ; %z "abc" list(1,%s)}* has been (very friendly) built with the new {} heterogeneous concatenator: o the *extraction of the content of any single cell component* should be direct: + with Scilab < 6 : c(5).entries or c(1,3).entries + with Scilab >=6: c(5) or c(1,3) + with Scilab < 6 : c(5) or c(1,3) + with Scilab >=6: {c(5)} or {c(1,3)} Whenever any wrapped-in-cell answer would be needed, it still can be obtain by packaging the answer, instead of implementing a "dereferencing" way to address a content through a very specific {} extractors and inserters when unwrapped values are required. o As well, *the insertion into a single component must be direct, and any type of data should be accepted*: + Scilab < 6: c(5).entries = ["Hi" "Hello"] or c(1,3).entries = ["Hi" "Hello"] + Scilab >=6: c(5) = ["Hi" "Hello"] or c(1,3) = ["Hi" "Hello"] So, page 4: # c = cell([4,3,2]); for i = 1:24, c*{i}* = i, end becomes # c = cell([4,3,2]); for i = 1:24, c*(i)* = i, end o Is there any reason to not address cells components simply as we do for matrix components, directly with (i,j,..)? I do not find any. The .entries addressing was needed due to the encoding of cells as mlists. But what could motivate keeping any intermediate level to access to the values of data, for extraction as well as for insertion? I do not see a single reason. As noted here-above, from the fact that the LHS object is a cell array, any data type can be accepted and inserted, without any prior packaging of the RHS as a cell array. The wrapping in cell must be done internally by the insertion process. o Then, Scilab 6: c(5) = {"abcd"} will insert a true elementary cell as the c(1,3) c's component, not the string "abcd". This is a straightforward and very clear syntax. What is in RHS parameter is just values that are inserted in the array, *as is*. * *The SEP does not present **_insertion and extraction of multiple components_ in a once*. After still *c = { %pi %i %t ; %z "abc" list(1,%s)}, *the current implementation is the following: o *multiple insertion*: *a) of corresponding multiple components*: + c(:,1) = { %e "zz" } assigns %e to c(1,1) and "zz" to c(2,1) /in a distributive way/! 1. This kind of distributive assignment is a very great new feature!! 2. The assignment is transparently done using /linearized indices/. unmatching sizes/formats of the recipient and of the source is smoothly handled. Here, a row of cells feeds a column of cells. This is nice as is! This behavior could also be implemented with other types of RHS containers, at least for a list. So + c(:,1) = list(%e, "zz") should do the same. But it does not: --> c(:,1) = list(%e, "zz") Wrong insertion: A Cell expected: use {...} instead of (...). This feature might be implemented later. This is not so urgent as removing the {} addressing. If this feature is implemented, how will it be possible to insert a list in a single component? # c(3) = list(list(%t)) // will do it. Or if the size of the list is not 1, even # c(3) = list(%t, %z) // mismatch could be handled softly in a comprehensive way + c([1 2]) = { %e "zz" } does the same using a vector of linearized indices. Great! o *multiple insertion*: *b) of a single component to be replicated*: + c([1 4]) = {"abc"} inserts the same "abc" string at the 1st and 4th positions in c. This is great! The only thing is that the syntax should become simply c([1 4]) = "abc" In the final implementation that we suggest and hope, c([1 4]) = {"abc"} will be as well possible but will insert the cell {"abc"} instead of the string "abc" at the desired positions. o *multiple extraction:* + c(1,:) returns{%pi %i %t}: this is great! By default, this can't be anything else than a cell array. No c{1,:} syntax is required + c(:,3) returns {%t ; list(1,%s)}: still great and expected! No c{3,:} syntax is required + c(1:2,[1 3]) returns {%pi %t ; %z list(1,%s)} as expected. No c{1:2,[1 3]} syntax is required + with a linearized index: c([2 5 3]) returns {%z ; %t ; %i} column cell, as with matrices addressed with a linearized index a column is returned: Great! No c{[2 5 3]} syntax is required * Finally, *what about conversions between a cell array and a list? *We think that this kind of conversion between these 2 types of containers should be available in Scilab. o *list => cell* : + If it becomes possible to feed a cell array (or subarray) with a list as discussed above, then this kind of conversion won't need anything else. We will just have to do: c = cell(2,3); c(:) = list(%pi, %z, %i, "abc", %t, list(1,%s)) + Otherwise: *makecell() *should be kept and renamed *list2cell()*, instead of being removed. It already works as expected : L = list(%pi, %z, %i, "abc", %t, list(1,%s)); --> makecell([2 3], L(:)) ans = [1x1 constant] [1x1 polynomial] [1x1 constant] [1x1 string ] [1x1 boolean ] [ list ] o *cell => list:* + The present special extraction with {:} does it, but this syntax must be removed. Keeping it only for that is meaningless: --> typeof(c{:}) ans = list + A new *cell2list()* converter should rather be implemented. Hoping that this will convince you to remove the {} complicated addressing and the related data wrapping, Best regards Samuel Gougeon -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Thu Feb 18 19:21:38 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 18 Feb 2016 19:21:38 +0100 Subject: [Scilab-Dev] SEP #40: Cell Arrays In-Reply-To: <56C60351.7080908@free.fr> References: <4BB0758D.9090208@scilab.org> <56C60351.7080908@free.fr> Message-ID: <56C60BB2.9010001@free.fr> Le 18/02/2016 18:45, Samuel Gougeon a ?crit : > > o Then, Scilab 6: c(5) = {"abcd"} will insert a true elementary > cell as the c(1,3) c's component, not the string "abcd". This > is a straightforward and very clear syntax. What is in RHS > parameter is just values that are inserted in the array, *as is*. > > .../... > > + c([1 4]) = {"abc"} inserts the same "abc" string at the > 1st and 4th positions in c. This is great! The only thing > is that the syntax should become simply > c([1 4]) = "abc" > In the final implementation that we suggest and hope, c([1 > 4]) = {"abc"} will be as well possible but will insert the > cell {"abc"} instead of the string "abc" at the desired > positions. > If we do not want to make exceptions about the meaning of = { .. }, i.e. if we want to use it always and only as a container feeding recipients and from which components to be inserted must be picked up, even if there is only one component in the container, then, inserting an elementary cell in one or several recipients might be done simply with c(5) = {{"abcd"}} c([1 4]) = {{"abcd"}} while c(5) = {"abcd"} will be exactly equivalent to c(5) = "abcd" In c([1 4]) = {{"abcd"}}, external {} are the container, and internal {} belong to the value to be inserted, as it will be in c([1 4]) = {{"abcd"} %z } SG -------------- next part -------------- An HTML attachment was scrubbed... URL: From grocer.toolbox at gmail.com Thu Feb 18 20:41:40 2016 From: grocer.toolbox at gmail.com (Eric Dubois) Date: Thu, 18 Feb 2016 20:41:40 +0100 Subject: [Scilab-Dev] SEP #40: Cell Arrays In-Reply-To: <56C60351.7080908@free.fr> References: <4BB0758D.9090208@scilab.org> <56C60351.7080908@free.fr> Message-ID: 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 hope that the Scilab will come to its senses and give up making this change. Regards. ?ric. 2016-02-18 18:45 GMT+01:00 Samuel Gougeon : > Hello, > > Le 29/03/2010 11:40, Bruno JOFRET a ?crit : > > Hi, > > Please find attached SEP #40 talking about Cell Arrays. > This SEP is targeting Scilab 6.0 as we will introduce a new syntax for > cells. > > Any feedbacks are welcome. > > > 6 years after, it is very (very) late to comment or make any suggestion. > Yet, Scilab 6.0 is not yet released, so i hope that this won't be too late > for the essential: > Indexation (extraction and insertion) with {} should really not be > introduced. > > This message comes after first comments and rational recently posted there: > > http://mailinglists.scilab.org/Scilab-users-a-i-j-specific-extraction-syntax-with-should-not-be-introduced-tp4033484.html > > As another way to explain why {} extractors and inserters must not be > introduced, > we may follow the pages of the current version of the SEP available here: > http://gitweb.scilab.org/?p=scilab.git;a=blob;f=SEP/SEP_040_cell_arrays.odt > > - After a cell array *c = { %pi %i %t ; %z "abc" list(1,%s)}* has been > (very friendly) built with the new {} heterogeneous concatenator: > > - the *extraction of the content of any single cell component* should > be direct: > - with Scilab < 6 : c(5).entries or c(1,3).entries > - with Scilab >=6: c(5) or c(1,3) > > - with Scilab < 6 : c(5) or c(1,3) > - with Scilab >=6: {c(5)} or {c(1,3)} > Whenever any wrapped-in-cell answer would be needed, it still > can be obtain by packaging the answer, instead of implementing a > "dereferencing" way to address a content through a very specific {} > extractors and inserters when unwrapped values are required. > > - As well, *the insertion into a single component must be > direct, and any type of data should be accepted*: > - Scilab < 6: c(5).entries = ["Hi" "Hello"] or c(1,3).entries = > ["Hi" "Hello"] > - Scilab >=6: c(5) = ["Hi" "Hello"] or c(1,3) = ["Hi" "Hello"] > So, page 4: > - c = cell([4,3,2]); for i = 1:24, c*{i}* = i, end > becomes > - c = cell([4,3,2]); for i = 1:24, c*(i)* = i, end > > - Is there any reason to not address cells components simply > as we do for matrix components, directly with (i,j,..)? I do not find any. > The .entries addressing was needed due to the encoding of cells as > mlists. But what could motivate keeping any intermediate level to access to > the values of data, for extraction as well as for insertion? I do not see a > single reason. > As noted here-above, from the fact that the LHS object is a cell > array, any data type can be accepted and inserted, without any prior > packaging of the RHS as a cell array. The wrapping in cell must be done > internally by the insertion process. > - Then, Scilab 6: c(5) = {"abcd"} will insert a true elementary > cell as the c(1,3) c's component, not the string "abcd". This is a > straightforward and very clear syntax. What is in RHS parameter is just > values that are inserted in the array, *as is*. > > - *The SEP does not present **insertion and extraction of multiple > components in a once*. > After still *c = { %pi %i %t ; %z "abc" list(1,%s)}, *the current > implementation is the following: > > - *multiple insertion*: *a) of corresponding multiple components*: > - c(:,1) = { %e "zz" } > assigns %e to c(1,1) and "zz" to c(2,1) *in a distributive way*! > 1. This kind of distributive assignment is a very great new > feature!! > 2. The assignment is transparently done using *linearized > indices*. unmatching sizes/formats of the recipient and of > the source is smoothly handled. Here, a row of cells feeds a column of > cells. This is nice as is! This behavior could also be implemented with > other types of RHS containers, at least for a list. So > > - c(:,1) = list(%e, "zz") > should do the same. But it does not: > --> c(:,1) = list(%e, "zz") > Wrong insertion: A Cell expected: use {...} instead of (...). > This feature might be implemented later. This is not so urgent > as removing the {} addressing. > > If this feature is implemented, how will it be possible to > insert a list in a single component? > - c(3) = list(list(%t)) // will do it. Or if the size of the > list is not 1, even > - c(3) = list(%t, %z) // mismatch could be handled softly > in a comprehensive way > > - c([1 2]) = { %e "zz" } does the same using a vector of > linearized indices. Great! > > - *multiple insertion*: *b) of a single component to be > replicated*: > - c([1 4]) = {"abc"} inserts the same "abc" string at the 1st and > 4th positions in c. This is great! The only thing is that the syntax should > become simply > c([1 4]) = "abc" > In the final implementation that we suggest and hope, c([1 4]) = > {"abc"} will be as well possible but will insert the cell {"abc"} instead > of the string "abc" at the desired positions. > > - *multiple extraction:* > - c(1,:) returns {%pi %i %t}: this is great! By default, this > can't be anything else than a cell array. > No c{1,:} syntax is required > - c(:,3) returns {%t ; list(1,%s)}: still great and expected! > No c{3,:} syntax is required > - c(1:2,[1 3]) returns {%pi %t ; %z list(1,%s)} as expected. > No c{1:2,[1 3]} syntax is required > - with a linearized index: c([2 5 3]) returns {%z ; %t ; %i} > column cell, as with matrices addressed with a linearized index a column is > returned: Great! > No c{[2 5 3]} syntax is required > > - Finally, *what about conversions between a cell array and a > list? *We think that this kind of conversion between these 2 types of > containers should be available in Scilab. > - *list => cell* : > - If it becomes possible to feed a cell array (or subarray) with a > list as discussed above, then this kind of conversion won't need anything > else. We will just have to do: > c = cell(2,3); c(:) = list(%pi, %z, %i, "abc", %t, list(1,%s)) > > - Otherwise: *makecell() *should be kept and renamed > *list2cell()*, instead of being removed. It already works as > expected : > L = list(%pi, %z, %i, "abc", %t, list(1,%s)); > --> makecell([2 3], L(:)) > ans = > [1x1 constant] [1x1 polynomial] [1x1 constant] > [1x1 string ] [1x1 boolean ] [ list ] > > - *cell => list:* > - The present special extraction with {:} does it, but this syntax > must be removed. Keeping it only for that is meaningless: > --> typeof(c{:}) > ans = > list > - A new *cell2list()* converter should rather be implemented. > > Hoping that this will convince you to remove the {} complicated addressing > and the related data wrapping, > > Best regards > 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 Serge.Steer at inria.fr Fri Feb 19 10:08:43 2016 From: Serge.Steer at inria.fr (Serge Steer) Date: Fri, 19 Feb 2016 10:08:43 +0100 Subject: [Scilab-Dev] A+[] In-Reply-To: References: <4BB0758D.9090208@scilab.org> <56C60351.7080908@free.fr> Message-ID: <56C6DB9B.8070508@inria.fr> In Scilab 5 the function mtlb_mode allows to change the meaning of a+[] according to Scilab or matlab semantics. This function has been removed in Scilab6. It can be a solution redefine it as oldscilab_mode that can be used for old codes Serge 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 hope that the Scilab will come to its senses and give up making this > change. > > Regards. > > ?ric. > > 2016-02-18 18:45 GMT+01:00 Samuel Gougeon >: > > Hello, > > Le 29/03/2010 11:40, Bruno JOFRET a ?crit : >> Hi, >> >> Please find attached SEP #40 talking about Cell Arrays. >> This SEP is targeting Scilab 6.0 as we will introduce a new >> syntax for cells. >> >> Any feedbacks are welcome. > > 6 years after, it is very (very) late to comment or make any > suggestion. > Yet, Scilab 6.0 is not yet released, so i hope that this won't be > too late for the essential: > Indexation (extraction and insertion) with {} should really not be > introduced. > > This message comes after first comments and rational recently > posted there: > http://mailinglists.scilab.org/Scilab-users-a-i-j-specific-extraction-syntax-with-should-not-be-introduced-tp4033484.html > > As another way to explain why {} extractors and inserters must not > be introduced, > we may follow the pages of the current version of the SEP > available here: > http://gitweb.scilab.org/?p=scilab.git;a=blob;f=SEP/SEP_040_cell_arrays.odt > > > * After a cell array *c = { %pi %i %t ; %z "abc" list(1,%s)}* > has been (very friendly) built with the new {} heterogeneous > concatenator: > > o the *extraction of the content of any single cell > component* should be direct: > + with Scilab < 6 : c(5).entries or c(1,3).entries > + with Scilab >=6: c(5) or c(1,3) > > + with Scilab < 6 : c(5) or c(1,3) > + with Scilab >=6: {c(5)} or {c(1,3)} > Whenever any wrapped-in-cell answer would be needed, > it still can be obtain by packaging the answer, > instead of implementing a "dereferencing" way to > address a content through a very specific {} > extractors and inserters when unwrapped values are > required. > > o As well, *the insertion into a single component must be > direct, and any type of data should be accepted*: > + Scilab < 6: c(5).entries = ["Hi" "Hello"] or > c(1,3).entries = ["Hi" "Hello"] > + Scilab >=6: c(5) = ["Hi" "Hello"] or c(1,3) = ["Hi" > "Hello"] > So, page 4: > # c = cell([4,3,2]); for i = 1:24, c*{i}* = i, end > becomes > # c = cell([4,3,2]); for i = 1:24, c*(i)* = i, end > > o Is there any reason to not address cells components simply > as we do for matrix components, directly with (i,j,..)? I > do not find any. > The .entries addressing was needed due to the encoding of > cells as mlists. But what could motivate keeping any > intermediate level to access to the values of data, for > extraction as well as for insertion? I do not see a single > reason. > As noted here-above, from the fact that the LHS object is > a cell array, any data type can be accepted and inserted, > without any prior packaging of the RHS as a cell array. > The wrapping in cell must be done internally by the > insertion process. > o Then, Scilab 6: c(5) = {"abcd"} will insert a true > elementary cell as the c(1,3) c's component, not the > string "abcd". This is a straightforward and very clear > syntax. What is in RHS parameter is just values that are > inserted in the array, *as is*. > > * *The SEP does not present **_insertion and extraction of > multiple components_ in a once*. > After still *c = { %pi %i %t ; %z "abc" list(1,%s)}, *the > current implementation is the following: > > o *multiple insertion*: *a) of corresponding multiple > components*: > + c(:,1) = { %e "zz" } > assigns %e to c(1,1) and "zz" to c(2,1) /in a > distributive way/! > 1. This kind of distributive assignment is a very > great new feature!! > 2. The assignment is transparently done using > /linearized indices/. unmatching sizes/formats of > the recipient and of the source is smoothly > handled. Here, a row of cells feeds a column of > cells. This is nice as is! This behavior could > also be implemented with other types of RHS > containers, at least for a list. So > > + c(:,1) = list(%e, "zz") > should do the same. But it does not: > --> c(:,1) = list(%e, "zz") > Wrong insertion: A Cell expected: use {...} instead of > (...). > This feature might be implemented later. This is not > so urgent as removing the {} addressing. > > If this feature is implemented, how will it be > possible to insert a list in a single component? > # c(3) = list(list(%t)) // will do it. Or if the > size of the list is not 1, even > # c(3) = list(%t, %z) // mismatch could be > handled softly in a comprehensive way > > + c([1 2]) = { %e "zz" } does the same using a vector of > linearized indices. Great! > > o *multiple insertion*: *b) of a single component to be > replicated*: > + c([1 4]) = {"abc"} inserts the same "abc" string at > the 1st and 4th positions in c. This is great! The > only thing is that the syntax should become simply > c([1 4]) = "abc" > In the final implementation that we suggest and hope, > c([1 4]) = {"abc"} will be as well possible but will > insert the cell {"abc"} instead of the string "abc" at > the desired positions. > > o *multiple extraction:* > + c(1,:) returns{%pi %i %t}: this is great! By > default, this can't be anything else than a cell array. > No c{1,:} syntax is required > + c(:,3) returns {%t ; list(1,%s)}: still great and > expected! > No c{3,:} syntax is required > + c(1:2,[1 3]) returns {%pi %t ; %z list(1,%s)} as > expected. > No c{1:2,[1 3]} syntax is required > + with a linearized index: c([2 5 3]) returns {%z ; %t ; > %i} column cell, as with matrices addressed with a > linearized index a column is returned: Great! > No c{[2 5 3]} syntax is required > > * Finally, *what about conversions between a cell array and a > list? *We think that this kind of conversion between these 2 > types of containers should be available in Scilab. > o *list => cell* : > + If it becomes possible to feed a cell array (or > subarray) with a list as discussed above, then this > kind of conversion won't need anything else. We will > just have to do: > c = cell(2,3); c(:) = list(%pi, %z, %i, "abc", %t, > list(1,%s)) > > + Otherwise: *makecell() *should be kept and renamed > *list2cell()*, instead of being removed. It already > works as expected : > L = list(%pi, %z, %i, "abc", %t, list(1,%s)); > --> makecell([2 3], L(:)) > ans = > [1x1 constant] [1x1 polynomial] [1x1 constant] > [1x1 string ] [1x1 boolean ] [ list ] > > o *cell => list:* > + The present special extraction with {:} does it, but > this syntax must be removed. Keeping it only for that > is meaningless: > --> typeof(c{:}) > ans = > list > + A new *cell2list()* converter should rather be > implemented. > > Hoping that this will convince you to remove the {} complicated > addressing and the related data wrapping, > > Best regards > Samuel Gougeon > > > _______________________________________________ > 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 pierre-aime.agnel at scilab-enterprises.com Fri Feb 19 10:36:50 2016 From: pierre-aime.agnel at scilab-enterprises.com (=?UTF-8?Q?Pierre-Aim=c3=a9_Agnel?=) Date: Fri, 19 Feb 2016 10:36:50 +0100 Subject: [Scilab-Dev] A+[] In-Reply-To: <56C6DB9B.8070508@inria.fr> References: <4BB0758D.9090208@scilab.org> <56C60351.7080908@free.fr> <56C6DB9B.8070508@inria.fr> Message-ID: <56C6E232.70901@scilab-enterprises.com> 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. Le 19/02/2016 10:08, Serge Steer a ?crit : > In Scilab 5 the function mtlb_mode allows to change the meaning of > a+[] according to Scilab or matlab semantics. This function has been > removed in Scilab6. > It can be a solution redefine it as oldscilab_mode that can be used > for old codes > Serge > 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 hope that the Scilab will come to its senses and give up making >> this change. >> >> Regards. >> >> ?ric. >> >> 2016-02-18 18:45 GMT+01:00 Samuel Gougeon > >: >> >> Hello, >> >> Le 29/03/2010 11:40, Bruno JOFRET a ?crit : >>> Hi, >>> >>> Please find attached SEP #40 talking about Cell Arrays. >>> This SEP is targeting Scilab 6.0 as we will introduce a new >>> syntax for cells. >>> >>> Any feedbacks are welcome. >> >> 6 years after, it is very (very) late to comment or make any >> suggestion. >> Yet, Scilab 6.0 is not yet released, so i hope that this won't be >> too late for the essential: >> Indexation (extraction and insertion) with {} should really not >> be introduced. >> >> This message comes after first comments and rational recently >> posted there: >> http://mailinglists.scilab.org/Scilab-users-a-i-j-specific-extraction-syntax-with-should-not-be-introduced-tp4033484.html >> >> As another way to explain why {} extractors and inserters must >> not be introduced, >> we may follow the pages of the current version of the SEP >> available here: >> http://gitweb.scilab.org/?p=scilab.git;a=blob;f=SEP/SEP_040_cell_arrays.odt >> >> >> * After a cell array *c = { %pi %i %t ; %z "abc" list(1,%s)}* >> has been (very friendly) built with the new {} heterogeneous >> concatenator: >> >> o the *extraction of the content of any single cell >> component* should be direct: >> + with Scilab < 6 : c(5).entries or c(1,3).entries >> + with Scilab >=6: c(5) or c(1,3) >> >> + with Scilab < 6 : c(5) or c(1,3) >> + with Scilab >=6: {c(5)} or {c(1,3)} >> Whenever any wrapped-in-cell answer would be needed, >> it still can be obtain by packaging the answer, >> instead of implementing a "dereferencing" way to >> address a content through a very specific {} >> extractors and inserters when unwrapped values are >> required. >> >> o As well, *the insertion into a single component must be >> direct, and any type of data should be accepted*: >> + Scilab < 6: c(5).entries = ["Hi" "Hello"] or >> c(1,3).entries = ["Hi" "Hello"] >> + Scilab >=6: c(5) = ["Hi" "Hello"] or c(1,3) = ["Hi" >> "Hello"] >> So, page 4: >> # c = cell([4,3,2]); for i = 1:24, c*{i}* = i, end >> becomes >> # c = cell([4,3,2]); for i = 1:24, c*(i)* = i, end >> >> o Is there any reason to not address cells components >> simply as we do for matrix components, directly with >> (i,j,..)? I do not find any. >> The .entries addressing was needed due to the encoding of >> cells as mlists. But what could motivate keeping any >> intermediate level to access to the values of data, for >> extraction as well as for insertion? I do not see a >> single reason. >> As noted here-above, from the fact that the LHS object is >> a cell array, any data type can be accepted and inserted, >> without any prior packaging of the RHS as a cell array. >> The wrapping in cell must be done internally by the >> insertion process. >> o Then, Scilab 6: c(5) = {"abcd"} will insert a true >> elementary cell as the c(1,3) c's component, not the >> string "abcd". This is a straightforward and very clear >> syntax. What is in RHS parameter is just values that are >> inserted in the array, *as is*. >> >> * *The SEP does not present **_insertion and extraction of >> multiple components_ in a once*. >> After still *c = { %pi %i %t ; %z "abc" list(1,%s)}, *the >> current implementation is the following: >> >> o *multiple insertion*: *a) of corresponding multiple >> components*: >> + c(:,1) = { %e "zz" } >> assigns %e to c(1,1) and "zz" to c(2,1) /in a >> distributive way/! >> 1. This kind of distributive assignment is a very >> great new feature!! >> 2. The assignment is transparently done using >> /linearized indices/. unmatching sizes/formats of >> the recipient and of the source is smoothly >> handled. Here, a row of cells feeds a column of >> cells. This is nice as is! This behavior could >> also be implemented with other types of RHS >> containers, at least for a list. So >> >> + c(:,1) = list(%e, "zz") >> should do the same. But it does not: >> --> c(:,1) = list(%e, "zz") >> Wrong insertion: A Cell expected: use {...} instead >> of (...). >> This feature might be implemented later. This is not >> so urgent as removing the {} addressing. >> >> If this feature is implemented, how will it be >> possible to insert a list in a single component? >> # c(3) = list(list(%t)) // will do it. Or if the >> size of the list is not 1, even >> # c(3) = list(%t, %z) // mismatch could be >> handled softly in a comprehensive way >> >> + c([1 2]) = { %e "zz" } does the same using a vector >> of linearized indices. Great! >> >> o *multiple insertion*: *b) of a single component to be >> replicated*: >> + c([1 4]) = {"abc"} inserts the same "abc" string at >> the 1st and 4th positions in c. This is great! The >> only thing is that the syntax should become simply >> c([1 4]) = "abc" >> In the final implementation that we suggest and hope, >> c([1 4]) = {"abc"} will be as well possible but will >> insert the cell {"abc"} instead of the string "abc" >> at the desired positions. >> >> o *multiple extraction:* >> + c(1,:) returns{%pi %i %t}: this is great! By >> default, this can't be anything else than a cell array. >> No c{1,:} syntax is required >> + c(:,3) returns {%t ; list(1,%s)}: still great and >> expected! >> No c{3,:} syntax is required >> + c(1:2,[1 3]) returns {%pi %t ; %z list(1,%s)} as >> expected. >> No c{1:2,[1 3]} syntax is required >> + with a linearized index: c([2 5 3]) returns {%z ; %t >> ; %i} column cell, as with matrices addressed with a >> linearized index a column is returned: Great! >> No c{[2 5 3]} syntax is required >> >> * Finally, *what about conversions between a cell array and a >> list? *We think that this kind of conversion between these 2 >> types of containers should be available in Scilab. >> o *list => cell* : >> + If it becomes possible to feed a cell array (or >> subarray) with a list as discussed above, then this >> kind of conversion won't need anything else. We will >> just have to do: >> c = cell(2,3); c(:) = list(%pi, %z, %i, "abc", %t, >> list(1,%s)) >> >> + Otherwise: *makecell() *should be kept and renamed >> *list2cell()*, instead of being removed. It already >> works as expected : >> L = list(%pi, %z, %i, "abc", %t, list(1,%s)); >> --> makecell([2 3], L(:)) >> ans = >> [1x1 constant] [1x1 polynomial] [1x1 constant] >> [1x1 string ] [1x1 boolean ] [ list ] >> >> o *cell => list:* >> + The present special extraction with {:} does it, but >> this syntax must be removed. Keeping it only for that >> is meaningless: >> --> typeof(c{:}) >> ans = >> list >> + A new *cell2list()* converter should rather be >> implemented. >> >> Hoping that this will convince you to remove the {} complicated >> addressing and the related data wrapping, >> >> Best regards >> Samuel Gougeon >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev Pierre-Aim? Agnel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Feb 19 11:26:31 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 19 Feb 2016 11:26:31 +0100 Subject: [Scilab-Dev] SEP #40: Cell Arrays In-Reply-To: <56C60351.7080908@free.fr> References: <4BB0758D.9090208@scilab.org> <56C60351.7080908@free.fr> Message-ID: <56C6EDD7.9030700@free.fr> Le 18/02/2016 18:45, Samuel Gougeon a ?crit : > *.../... > The SEP does not present **_insertion and extraction of multiple > components_ in a once*. > > * After still *c = { %pi %i %t ; %z "abc" list(1,%s)}, *the current > implementation is the following: > > o *multiple insertion*: *a) of corresponding multiple components*: > + c(:,1) = { %e "zz" } > assigns %e to c(1,1) and "zz" to c(2,1) /in a distributive > way/! > 1. .../... > > + c(:,1) = list(%e, "zz") > should do the same. But it does not: > --> c(:,1) = list(%e, "zz") > Wrong insertion: A Cell expected: use {...} instead of (...). > This feature might be implemented later. This is not so > urgent as removing the {} addressing. > By the way, a workaround already exists to do that: L = list(%e, "zz") // any list to be used as the source of data to be inserted c(:,1) = makecell([1 size(L)], L(:)) // does it. > + > > > If this feature is implemented, how will it be possible to > insert a list in a single component? > # c(3) = list(list(%t)) // will do it. Or if the size of > the list is not 1, even > c(3) = { list(%t) } // would even be simpler > > # c(3) = list(%t, %z) // mismatch could be handled > softly in a comprehensive way > Humm, better to avoid such an exception. => should yield an error instead. SG -------------- next part -------------- An HTML attachment was scrubbed... URL: From clement.david at scilab-enterprises.com Fri Feb 19 13:55:29 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Fri, 19 Feb 2016 13:55:29 +0100 Subject: [Scilab-Dev] Documentation for Xcos In-Reply-To: References: <1454135487845-4033357.post@n3.nabble.com> <1454311906.2921.9.camel@scilab-enterprises.com> Message-ID: <1455886529.2660.41.camel@scilab-enterprises.com> Hi, > ---- 1 ---- > > As a part of my reverse engineering process, I have started from the point where Xcos application > is invoked, when the button is pressed in the MenuBar. >? > If possible, could you explain the StoreCommand() function? I see that all incoming commands are > en-queued in the commandQueue, to be processed one by one. But where in the code, is the command > getting de-queued for parsing? In fact, the commandQueue is the way to communicate to the Scilab interpreter engine. When you request an execution, the command is stored on the queue and latter the engine pick the command and execute it. When hitting the "Play" button on xcos, we push the diagram to the Scilab workspace and put an 'xcos_simulate' call to be executed. > ---- 2 ---- > > The command that is given in /etc/main_menubar.xml for opening Xcos is > > if with_mode ('xcos') then xcos(); > else disp(gettext('Please install xcos module')) > > Would it be possible for you to point where xcos() is invoked after interpretation and parsing? > > Hypothetically for instance, if I were to create a new method in Java, so that I can see the Block > Diagram Editor, like this -? > > public static void main (String args[]){ > ? ? Xcos xcos = new Xcos(); //Assuming I can write something like this > } > > If this is possible, I would like to know, which is that particular 'XCos' Class that can allow me > to do this? On the xcos module, there is an 'Xcos.java' file that contains some annotated methods exported to C. For instance you can take a look at the Xcos#xcos() method. -- Cl?ment > On Mon, Feb 1, 2016 at 1:02 PM, Cl?ment David-2 [via Scilab / Xcos - Mailing Lists Archives] > <[hidden email]> wrote: > > ?Hi?Adhitya,? > > > > The code is *the* reference but for more internal views I suggest you to read these documents :? > > > > * R. NIKOUKHAH AND S. STEER , Scicos a dynamic system builder and simulator, IEEE INTERNATIONAL? > > CONFERENCE ON CACSD, DEARBORN , MICHIGAN , 1996.? > > * S. STEER , R. NIKOUKHAH , Scicos: a hybrid system formalism, ESS?99, E RLANGEN , GERMANY , > > 1999.? > > * Masoud NAJAFI thesis , The Numerical Solver for the Simulation of the Hybrid Dynamical > > Systems? > > ,?2005 .? > > > > And for understanding what's behind each block, take a look at the Scilab documentation, and? > > ScilabTec presentations.? > > > > Regards,? > > > > --? > > Cl?ment? > > > > > > Le vendredi 29 janvier 2016 ? 23:31 -0700, adhitya a ?crit?: > > > > > Hi,? > > >? > > > My name is Adhitya Kamakshidasan and I'm an Intern at FOSSEE, IIT Bombay.?? > > >? > > > We are trying to develop a standalone version of Xcos, that is completely? > > > web-based.? > > >? > > > I would like to know if there is any documentation with respect to how Xcos? > > > has been written - Flowcharts, Main methods, PDF's, etc.? > > >? > > > Currently, I'm trying to reverse-engineer the code, by slowly moving through? > > > the code, and removing the parts that are not related to Xcos. However, this? > > > is taking a lot of time.? > > >? > > > We would like your support in this regard.? > > >? > > > Thanks,? > > >? > > > Adhitya Kamakshidasan? > > >? > > >? > > >? > > > --? > > > View this message in context: http://mailinglists.scilab.org/Documentation-for-Xcos-tp4033357. > > 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-tp4033357p4033359.html > > To unsubscribe from Documentation for Xcos, click here. > > NAML > > > > View this message in context: Re: Documentation for Xcos > 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 grocer.toolbox at gmail.com Sat Feb 20 08:37:05 2016 From: grocer.toolbox at gmail.com (Eric Dubois) Date: Sat, 20 Feb 2016 08:37:05 +0100 Subject: [Scilab-Dev] 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: Thank you for the information 1) do you plan to maintain this feature forever? If not (as I suspect, maybe mistakenly), then for me it does not solve the main problem which is the daunting ask of adapting old code (especially if it is emboddied in a toolbox) and the risk of missing something. If yes, then: 2) for functions in toolboxes, the answer should rather be something like that : function [...] if evstr(part(getversion(),8:10)) >= 6 then function [...] if evstr(part(getversion(),8:10)) >= 6 then oldEmptyBehaviour("on") end [...] if evstr(part(getversion(),8:10)) >= 6 then oldEmptyBehaviour("off") end endfunction This is because there will remain users that will continue loading toolboxes (in particular through Atoms) under old Scilab versions and I think important that the toolboxes go on working for these users. The result is not very elegant, but I can survive with it. But please do not change the working of the getversion function! And more importantly, please do not remove anytime the oldEmptyBehaviour function. Regards ?ric. 2016-02-19 10:36 GMT+01:00 Pierre-Aim? Agnel < pierre-aime.agnel at scilab-enterprises.com>: > 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. > > > Le 19/02/2016 10:08, Serge Steer a ?crit : > > In Scilab 5 the function mtlb_mode allows to change the meaning of a+[] > according to Scilab or matlab semantics. This function has been removed in > Scilab6. > It can be a solution redefine it as oldscilab_mode that can be used for > old codes > Serge > 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 hope that the Scilab will come to its senses and give up making this > change. > > Regards. > > ?ric. > > 2016-02-18 18:45 GMT+01:00 Samuel Gougeon : > >> Hello, >> >> Le 29/03/2010 11:40, Bruno JOFRET a ?crit : >> >> Hi, >> >> Please find attached SEP #40 talking about Cell Arrays. >> This SEP is targeting Scilab 6.0 as we will introduce a new syntax for >> cells. >> >> Any feedbacks are welcome. >> >> >> 6 years after, it is very (very) late to comment or make any suggestion. >> Yet, Scilab 6.0 is not yet released, so i hope that this won't be too >> late for the essential: >> Indexation (extraction and insertion) with {} should really not be >> introduced. >> >> This message comes after first comments and rational recently posted >> there: >> >> http://mailinglists.scilab.org/Scilab-users-a-i-j-specific-extraction-syntax-with-should-not-be-introduced-tp4033484.html >> >> As another way to explain why {} extractors and inserters must not be >> introduced, >> we may follow the pages of the current version of the SEP available here: >> >> http://gitweb.scilab.org/?p=scilab.git;a=blob;f=SEP/SEP_040_cell_arrays.odt >> >> - After a cell array *c = { %pi %i %t ; %z "abc" list(1,%s)}* has >> been (very friendly) built with the new {} heterogeneous concatenator: >> >> - the *extraction of the content of any single cell component* should >> be direct: >> - with Scilab < 6 : c(5).entries or c(1,3).entries >> - with Scilab >=6: c(5) or c(1,3) >> >> - with Scilab < 6 : c(5) or c(1,3) >> - with Scilab >=6: {c(5)} or {c(1,3)} >> Whenever any wrapped-in-cell answer would be needed, it still >> can be obtain by packaging the answer, instead of implementing a >> "dereferencing" way to address a content through a very specific {} >> extractors and inserters when unwrapped values are required. >> >> - As well, *the insertion into a single component must be >> direct, and any type of data should be accepted*: >> - Scilab < 6: c(5).entries = ["Hi" "Hello"] or c(1,3).entries >> = ["Hi" "Hello"] >> - Scilab >=6: c(5) = ["Hi" "Hello"] or c(1,3) = ["Hi" >> "Hello"] >> So, page 4: >> - c = cell([4,3,2]); for i = 1:24, c*{i}* = i, end >> becomes >> - c = cell([4,3,2]); for i = 1:24, c*(i)* = i, end >> >> - Is there any reason to not address cells components simply >> as we do for matrix components, directly with (i,j,..)? I do not find any. >> The .entries addressing was needed due to the encoding of cells as >> mlists. But what could motivate keeping any intermediate level to access to >> the values of data, for extraction as well as for insertion? I do not see a >> single reason. >> As noted here-above, from the fact that the LHS object is a cell >> array, any data type can be accepted and inserted, without any prior >> packaging of the RHS as a cell array. The wrapping in cell must be done >> internally by the insertion process. >> - Then, Scilab 6: c(5) = {"abcd"} will insert a true elementary >> cell as the c(1,3) c's component, not the string "abcd". This is a >> straightforward and very clear syntax. What is in RHS parameter is just >> values that are inserted in the array, *as is*. >> >> - *The SEP does not present **insertion and extraction of multiple >> components in a once*. >> After still *c = { %pi %i %t ; %z "abc" list(1,%s)}, *the current >> implementation is the following: >> >> - *multiple insertion*: *a) of corresponding multiple components*: >> - c(:,1) = { %e "zz" } >> assigns %e to c(1,1) and "zz" to c(2,1) *in a distributive way*! >> >> 1. This kind of distributive assignment is a very great new >> feature!! >> 2. The assignment is transparently done using *linearized >> indices*. unmatching sizes/formats of the recipient and of >> the source is smoothly handled. Here, a row of cells feeds a column of >> cells. This is nice as is! This behavior could also be implemented with >> other types of RHS containers, at least for a list. So >> >> - c(:,1) = list(%e, "zz") >> should do the same. But it does not: >> --> c(:,1) = list(%e, "zz") >> Wrong insertion: A Cell expected: use {...} instead of (...). >> This feature might be implemented later. This is not so urgent >> as removing the {} addressing. >> >> If this feature is implemented, how will it be possible to >> insert a list in a single component? >> - c(3) = list(list(%t)) // will do it. Or if the size of the >> list is not 1, even >> - c(3) = list(%t, %z) // mismatch could be handled softly >> in a comprehensive way >> >> - c([1 2]) = { %e "zz" } does the same using a vector of >> linearized indices. Great! >> >> - *multiple insertion*: *b) of a single component to be >> replicated*: >> - c([1 4]) = {"abc"} inserts the same "abc" string at the 1st and >> 4th positions in c. This is great! The only thing is that the syntax should >> become simply >> c([1 4]) = "abc" >> In the final implementation that we suggest and hope, c([1 4]) >> = {"abc"} will be as well possible but will insert the cell {"abc"} instead >> of the string "abc" at the desired positions. >> >> - *multiple extraction:* >> - c(1,:) returns {%pi %i %t}: this is great! By default, this >> can't be anything else than a cell array. >> No c{1,:} syntax is required >> - c(:,3) returns {%t ; list(1,%s)}: still great and expected! >> No c{3,:} syntax is required >> - c(1:2,[1 3]) returns {%pi %t ; %z list(1,%s)} as expected. >> No c{1:2,[1 3]} syntax is required >> - with a linearized index: c([2 5 3]) returns {%z ; %t ; %i} >> column cell, as with matrices addressed with a linearized index a column is >> returned: Great! >> No c{[2 5 3]} syntax is required >> >> - Finally, *what about conversions between a cell array and a >> list? *We think that this kind of conversion between these 2 types of >> containers should be available in Scilab. >> - *list => cell* : >> - If it becomes possible to feed a cell array (or subarray) with a >> list as discussed above, then this kind of conversion won't need anything >> else. We will just have to do: >> c = cell(2,3); c(:) = list(%pi, %z, %i, "abc", %t, list(1,%s)) >> >> - Otherwise: *makecell() *should be kept and renamed >> *list2cell()*, instead of being removed. It already works as >> expected : >> L = list(%pi, %z, %i, "abc", %t, list(1,%s)); >> --> makecell([2 3], L(:)) >> ans = >> [1x1 constant] [1x1 polynomial] [1x1 constant] >> [1x1 string ] [1x1 boolean ] [ list ] >> >> - *cell => list:* >> - The present special extraction with {:} does it, but this syntax >> must be removed. Keeping it only for that is meaningless: >> --> typeof(c{:}) >> ans = >> list >> - A new *cell2list()* converter should rather be implemented. >> >> Hoping that this will convince you to remove the {} complicated >> addressing and the related data wrapping, >> >> Best regards >> Samuel Gougeon >> >> >> _______________________________________________ >> dev mailing list >> dev at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/dev >> >> > > > _______________________________________________ > dev mailing listdev at lists.scilab.orghttp://lists.scilab.org/mailman/listinfo/dev > > > > > _______________________________________________ > dev mailing listdev at lists.scilab.orghttp://lists.scilab.org/mailman/listinfo/dev > > > Pierre-Aim? Agnel > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Tue Feb 23 21:19:08 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Tue, 23 Feb 2016 21:19:08 +0100 Subject: [Scilab-Dev] : non-standard scilab implementation for the documentation <= Re: Update of the online documentation In-Reply-To: <1287564734.766.769.camel@Calixte-Dell> References: <1287504863.3270.5863.camel@losinj.inria.fr> <1287561295.4839.21.camel@pinarellu.inria.fr> <1287564734.766.769.camel@Calixte-Dell> Message-ID: <56CCBEBC.6020108@free.fr> Hello, Le 20/10/2010 10:52, Calixte Denizet a ?crit : > .../.. > > I fixed the bug on the forge: > http://forge.scilab.org/index.php/p/scidoc/source/commit/cb432547a66e60f1fd96561ac121e5e957e85c81/ > > And I fixed a bug in MATEIG.xml (link instead of xref) : > http://codereview.scilab.org/#change,2319 I fought more than 1 hour, trying to use the docbook tag to build a /Table of Contents/ with local cross-references (in a long page), and i failed. I have finally found this message, and going to the codereview, i discovered that *the Scilab implementation of the docbook tag is not standard*. This is why i lost my time. Indeed, according to the http://docbook.org/tdg/en/html/xref.html reference technical page, is normally an empty tag: the visible clickable text is normally grabbed from the target, not provided by itself. Normally, The text to click is not meant to work, like ... does. But Scilab's works like a , and does not work according to the docbook specification: Tried: ... Option wb should build and display a link The option wb where is located, where the xreflabel attribute provides the visible text to be clicked. But does not do that. Another standard way to use would be: ... Option wb building Option wb still where is located, the text to click being equal to the text embraced by the targeted tag (here _____) But the Scilab doc compiler does nor do that. 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. HTH Samuel Gougeon -------------- next part -------------- An HTML attachment was scrubbed... URL: From adhitya07 at gmail.com Wed Feb 24 08:09:59 2016 From: adhitya07 at gmail.com (adhitya) Date: Wed, 24 Feb 2016 00:09:59 -0700 (MST) Subject: [Scilab-Dev] Documentation for Xcos In-Reply-To: <1455886529.2660.41.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> Message-ID: Thanks for your reply, I used the function that you mentioned and created the following class. package org.scilab.modules.xcos; public class TestingXcos { public static void main(String args[]){ Xcos.xcos(null, 0); } } However, I get a runtime exception, with the following message. Exception in thread "main" java.lang.ExceptionInInitializerError at org.scilab.modules.core.Scilab.(Scilab.java:65) at org.scilab.modules.xcos.Xcos.(Xcos.java:116) at org.scilab.modules.xcos.TestingXcos.main(TestingXcos.java:5) Caused by: java.lang.RuntimeException: XPathFactory#newInstance() failed to create an XPathFactory for the default object model: http://java.sun.com/jaxp/xpath/dom with the XPathFactoryConfigurationException: javax.xml.xpath.XPathFactoryConfigurationException: java.util.ServiceConfigurationError: javax.xml.xpath.XPathFactory: jar:file:/C:/Users/Adhitya/Documents/GitHub/scilab/Windows/thirdparty/saxon9he.jar!/META-INF/services/javax.xml.xpath.XPathFactory:2: Illegal configuration-file syntax at javax.xml.xpath.XPathFactory.newInstance(XPathFactory.java:102) at org.scilab.modules.commons.xml.ScilabXPathFactory.newInstance(ScilabXPathFactory.java:56) at org.scilab.modules.commons.xml.XConfiguration.(XConfiguration.java:86) ... 3 more I've seen that there has been a similar issue in the past: http://bugzilla.scilab.org/show_bug.cgi?id=13854 I also saw this bug related to saxon9he.jar over here: https://sourceforge.net/p/saxon/mailman/message/33221102/ After that, I downgraded from Java 8 to Java 7 with the hopes of getting it to work. Still I get the same message. Am I missing something? Could you please help me out? Thanks, Adhitya On Fri, Feb 19, 2016 at 6:26 PM, Cl?ment David-2 [via Scilab / Xcos - Mailing Lists Archives] wrote: > Hi, > > > ---- 1 ---- > > > > As a part of my reverse engineering process, I have started from the > point where Xcos application > > is invoked, when the button is pressed in the MenuBar. > > > > If possible, could you explain the StoreCommand() function? I see that > all incoming commands are > > en-queued in the commandQueue, to be processed one by one. But where in > the code, is the command > > getting de-queued for parsing? > > In fact, the commandQueue is the way to communicate to the Scilab > interpreter engine. When you > request an execution, the command is stored on the queue and latter the > engine pick the command and > execute it. > > When hitting the "Play" button on xcos, we push the diagram to the Scilab > workspace and put an > 'xcos_simulate' call to be executed. > > > > ---- 2 ---- > > > > The command that is given in /etc/main_menubar.xml for opening Xcos is > > > > if with_mode ('xcos') then xcos(); > > else disp(gettext('Please install xcos module')) > > > > Would it be possible for you to point where xcos() is invoked after > interpretation and parsing? > > > > Hypothetically for instance, if I were to create a new method in Java, > so that I can see the Block > > Diagram Editor, like this - > > > > public static void main (String args[]){ > > Xcos xcos = new Xcos(); //Assuming I can write something like this > > } > > > > If this is possible, I would like to know, which is that particular > 'XCos' Class that can allow me > > to do this? > > On the xcos module, there is an 'Xcos.java' file that contains some > annotated methods exported to C. > For instance you can take a look at the Xcos#xcos() method. > > -- > Cl?ment > > > On Mon, Feb 1, 2016 at 1:02 PM, Cl?ment David-2 [via Scilab / Xcos - > Mailing Lists Archives] > > <[hidden email]> wrote: > > > Hi Adhitya, > > > > > > The code is *the* reference but for more internal views I suggest you > to read these documents : > > > > > > * R. NIKOUKHAH AND S. STEER , Scicos a dynamic system builder and > simulator, IEEE INTERNATIONAL > > > CONFERENCE ON CACSD, DEARBORN , MICHIGAN , 1996. > > > * S. STEER , R. NIKOUKHAH , Scicos: a hybrid system formalism, ESS?99, > E RLANGEN , GERMANY , > > > 1999. > > > * Masoud NAJAFI thesis , The Numerical Solver for the Simulation of > the Hybrid Dynamical > > > Systems > > > , 2005 . > > > > > > And for understanding what's behind each block, take a look at the > Scilab documentation, and > > > ScilabTec presentations. > > > > > > Regards, > > > > > > -- > > > Cl?ment > > > > > > > > > Le vendredi 29 janvier 2016 ? 23:31 -0700, adhitya a ?crit : > > > > > > > Hi, > > > > > > > > My name is Adhitya Kamakshidasan and I'm an Intern at FOSSEE, IIT > Bombay. > > > > > > > > We are trying to develop a standalone version of Xcos, that is > completely > > > > web-based. > > > > > > > > I would like to know if there is any documentation with respect to > how Xcos > > > > has been written - Flowcharts, Main methods, PDF's, etc. > > > > > > > > Currently, I'm trying to reverse-engineer the code, by slowly moving > through > > > > the code, and removing the parts that are not related to Xcos. > However, this > > > > is taking a lot of time. > > > > > > > > We would like your support in this regard. > > > > > > > > Thanks, > > > > > > > > Adhitya Kamakshidasan > > > > > > > > > > > > > > > > -- > > > > View this message in context: > http://mailinglists.scilab.org/Documentation-for-Xcos-tp4033357. > > > 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-tp4033357p4033359.html > > > To unsubscribe from Documentation for Xcos, click here. > > > NAML > > > > > > > View this message in context: Re: Documentation for Xcos > > 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-tp4033357p4033513.html > To unsubscribe from Documentation for Xcos, click here > > . > NAML > > -- View this message in context: http://mailinglists.scilab.org/Documentation-for-Xcos-tp4033357p4033553.html Sent from the Scilab developers - Mailing Lists Archives mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adhitya07 at gmail.com Thu Feb 25 10:27:56 2016 From: adhitya07 at gmail.com (adhitya) Date: Thu, 25 Feb 2016 02:27:56 -0700 (MST) Subject: [Scilab-Dev] Documentation for Xcos In-Reply-To: <1455886529.2660.41.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> Message-ID: Hi, I'm doing this on Windows 10 with Java 7. I followed the instructions over here, https://wiki.scilab.org/ScilabWithinEclipse I'm currently using the Remote debugging option, to go through the files. Cheers, Adhitya On 25-Feb-2016 2:48 pm, "monika sharma" wrote: > Dear Adhitya, > Can you provide us your system specification and the steps you are > following for scilab compilation. I've provided a link > here > . > Please go through the documents and let us know if you are following > anything apart from this. > > Regards, > Monika > > On Wed, Feb 24, 2016 at 12:39 PM, Adhitya Kamakshidasan < > adhitya07 at gmail.com> wrote: > >> Thanks for your reply, >> >> I used the function that you mentioned and created the following class. >> >> package org.scilab.modules.xcos; >> >> public class TestingXcos { >> public static void main(String args[]){ >> Xcos.xcos(null, 0); >> } >> } >> >> However, I get a runtime exception, with the following message. >> >> Exception in thread "main" java.lang.ExceptionInInitializerError >> at org.scilab.modules.core.Scilab.(Scilab.java:65) >> at org.scilab.modules.xcos.Xcos.(Xcos.java:116) >> at org.scilab.modules.xcos.TestingXcos.main(TestingXcos.java:5) >> Caused by: java.lang.RuntimeException: XPathFactory#newInstance() failed >> to create an XPathFactory for the default object model: >> http://java.sun.com/jaxp/xpath/dom with the >> XPathFactoryConfigurationException: >> javax.xml.xpath.XPathFactoryConfigurationException: >> java.util.ServiceConfigurationError: javax.xml.xpath.XPathFactory: >> jar:file:/C:/Users/Adhitya/Documents/GitHub/scilab/Windows/thirdparty/saxon9he.jar!/META-INF/services/javax.xml.xpath.XPathFactory:2: >> Illegal configuration-file syntax >> at javax.xml.xpath.XPathFactory.newInstance(XPathFactory.java:102) >> at >> org.scilab.modules.commons.xml.ScilabXPathFactory.newInstance(ScilabXPathFactory.java:56) >> at >> org.scilab.modules.commons.xml.XConfiguration.(XConfiguration.java:86) >> ... 3 more >> >> >> I've seen that there has been a similar issue in the past: >> http://bugzilla.scilab.org/show_bug.cgi?id=13854 >> >> I also saw this bug related to saxon9he.jar over here: >> https://sourceforge.net/p/saxon/mailman/message/33221102/ >> >> After that, I downgraded from Java 8 to Java 7 with the hopes of getting >> it to work. Still I get the same message. >> >> Am I missing something? Could you please help me out? >> >> Thanks, >> >> Adhitya >> >> >> On Fri, Feb 19, 2016 at 6:26 PM, Cl?ment David-2 [via Scilab / Xcos - >> Mailing Lists Archives] wrote: >> >>> Hi, >>> >>> > ---- 1 ---- >>> > >>> > As a part of my reverse engineering process, I have started from the >>> point where Xcos application >>> > is invoked, when the button is pressed in the MenuBar. >>> > >>> > If possible, could you explain the StoreCommand() function? I see that >>> all incoming commands are >>> > en-queued in the commandQueue, to be processed one by one. But where >>> in the code, is the command >>> > getting de-queued for parsing? >>> >>> In fact, the commandQueue is the way to communicate to the Scilab >>> interpreter engine. When you >>> request an execution, the command is stored on the queue and latter the >>> engine pick the command and >>> execute it. >>> >>> When hitting the "Play" button on xcos, we push the diagram to the >>> Scilab workspace and put an >>> 'xcos_simulate' call to be executed. >>> >>> >>> > ---- 2 ---- >>> > >>> > The command that is given in /etc/main_menubar.xml for opening Xcos is >>> > >>> > if with_mode ('xcos') then xcos(); >>> > else disp(gettext('Please install xcos module')) >>> > >>> > Would it be possible for you to point where xcos() is invoked after >>> interpretation and parsing? >>> > >>> > Hypothetically for instance, if I were to create a new method in Java, >>> so that I can see the Block >>> > Diagram Editor, like this - >>> > >>> > public static void main (String args[]){ >>> > Xcos xcos = new Xcos(); //Assuming I can write something like this >>> > } >>> > >>> > If this is possible, I would like to know, which is that particular >>> 'XCos' Class that can allow me >>> > to do this? >>> >>> On the xcos module, there is an 'Xcos.java' file that contains some >>> annotated methods exported to C. >>> For instance you can take a look at the Xcos#xcos() method. >>> >>> -- >>> Cl?ment >>> >>> > On Mon, Feb 1, 2016 at 1:02 PM, Cl?ment David-2 [via Scilab / Xcos - >>> Mailing Lists Archives] >>> > <[hidden email]> wrote: >>> > > Hi Adhitya, >>> > > >>> > > The code is *the* reference but for more internal views I suggest >>> you to read these documents : >>> > > >>> > > * R. NIKOUKHAH AND S. STEER , Scicos a dynamic system builder and >>> simulator, IEEE INTERNATIONAL >>> > > CONFERENCE ON CACSD, DEARBORN , MICHIGAN , 1996. >>> > > * S. STEER , R. NIKOUKHAH , Scicos: a hybrid system formalism, >>> ESS?99, E RLANGEN , GERMANY , >>> > > 1999. >>> > > * Masoud NAJAFI thesis , The Numerical Solver for the Simulation of >>> the Hybrid Dynamical >>> > > Systems >>> > > , 2005 . >>> > > >>> > > And for understanding what's behind each block, take a look at the >>> Scilab documentation, and >>> > > ScilabTec presentations. >>> > > >>> > > Regards, >>> > > >>> > > -- >>> > > Cl?ment >>> > > >>> > > >>> > > Le vendredi 29 janvier 2016 ? 23:31 -0700, adhitya a ?crit : >>> > > >>> > > > Hi, >>> > > > >>> > > > My name is Adhitya Kamakshidasan and I'm an Intern at FOSSEE, IIT >>> Bombay. >>> > > > >>> > > > We are trying to develop a standalone version of Xcos, that is >>> completely >>> > > > web-based. >>> > > > >>> > > > I would like to know if there is any documentation with respect to >>> how Xcos >>> > > > has been written - Flowcharts, Main methods, PDF's, etc. >>> > > > >>> > > > Currently, I'm trying to reverse-engineer the code, by slowly >>> moving through >>> > > > the code, and removing the parts that are not related to Xcos. >>> However, this >>> > > > is taking a lot of time. >>> > > > >>> > > > We would like your support in this regard. >>> > > > >>> > > > Thanks, >>> > > > >>> > > > Adhitya Kamakshidasan >>> > > > >>> > > > >>> > > > >>> > > > -- >>> > > > View this message in context: >>> http://mailinglists.scilab.org/Documentation-for-Xcos-tp4033357. >>> > > 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-tp4033357p4033359.html >>> > > To unsubscribe from Documentation for Xcos, click here. >>> > > NAML >>> > > >>> > >>> > View this message in context: Re: Documentation for Xcos >>> > 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-tp4033357p4033513.html >>> To unsubscribe from Documentation for Xcos, click here >>> >>> . >>> NAML >>> >>> >> >> > -- View this message in context: http://mailinglists.scilab.org/Documentation-for-Xcos-tp4033357p4033566.html Sent from the Scilab developers - Mailing Lists Archives mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adhitya07 at gmail.com Thu Feb 25 10:31:00 2016 From: adhitya07 at gmail.com (Adhitya Kamakshidasan) Date: Thu, 25 Feb 2016 15:01:00 +0530 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: I've also filed a big report over here. http://bugzilla.scilab.org/show_bug.cgi?id=14418 On 25-Feb-2016 2:58 pm, "adhitya" wrote: > Hi, > > I'm doing this on Windows 10 with Java 7. > > I followed the instructions over here, > https://wiki.scilab.org/ScilabWithinEclipse > > I'm currently using the Remote debugging option, to go through the files. > > Cheers, > > Adhitya > On 25-Feb-2016 2:48 pm, "monika sharma" <[hidden email] > > wrote: > >> Dear Adhitya, >> Can you provide us your system specification and the steps you are >> following for scilab compilation. I've provided a link >> here >> . >> Please go through the documents and let us know if you are following >> anything apart from this. >> >> Regards, >> Monika >> >> On Wed, Feb 24, 2016 at 12:39 PM, Adhitya Kamakshidasan <[hidden email] >> > wrote: >> >>> Thanks for your reply, >>> >>> I used the function that you mentioned and created the following class. >>> >>> package org.scilab.modules.xcos; >>> >>> public class TestingXcos { >>> public static void main(String args[]){ >>> Xcos.xcos(null, 0); >>> } >>> } >>> >>> However, I get a runtime exception, with the following message. >>> >>> Exception in thread "main" java.lang.ExceptionInInitializerError >>> at org.scilab.modules.core.Scilab.(Scilab.java:65) >>> at org.scilab.modules.xcos.Xcos.(Xcos.java:116) >>> at org.scilab.modules.xcos.TestingXcos.main(TestingXcos.java:5) >>> Caused by: java.lang.RuntimeException: XPathFactory#newInstance() failed >>> to create an XPathFactory for the default object model: >>> http://java.sun.com/jaxp/xpath/dom with the >>> XPathFactoryConfigurationException: >>> javax.xml.xpath.XPathFactoryConfigurationException: >>> java.util.ServiceConfigurationError: javax.xml.xpath.XPathFactory: >>> jar:file:/C:/Users/Adhitya/Documents/GitHub/scilab/Windows/thirdparty/saxon9he.jar!/META-INF/services/javax.xml.xpath.XPathFactory:2: >>> Illegal configuration-file syntax >>> at javax.xml.xpath.XPathFactory.newInstance(XPathFactory.java:102) >>> at >>> org.scilab.modules.commons.xml.ScilabXPathFactory.newInstance(ScilabXPathFactory.java:56) >>> at >>> org.scilab.modules.commons.xml.XConfiguration.(XConfiguration.java:86) >>> ... 3 more >>> >>> >>> I've seen that there has been a similar issue in the past: >>> http://bugzilla.scilab.org/show_bug.cgi?id=13854 >>> >>> I also saw this bug related to saxon9he.jar over here: >>> https://sourceforge.net/p/saxon/mailman/message/33221102/ >>> >>> After that, I downgraded from Java 8 to Java 7 with the hopes of getting >>> it to work. Still I get the same message. >>> >>> Am I missing something? Could you please help me out? >>> >>> Thanks, >>> >>> Adhitya >>> >>> >>> On Fri, Feb 19, 2016 at 6:26 PM, Cl?ment David-2 [via Scilab / Xcos - >>> Mailing Lists Archives] <[hidden email] >>> > wrote: >>> >>>> Hi, >>>> >>>> > ---- 1 ---- >>>> > >>>> > As a part of my reverse engineering process, I have started from the >>>> point where Xcos application >>>> > is invoked, when the button is pressed in the MenuBar. >>>> > >>>> > If possible, could you explain the StoreCommand() function? I see >>>> that all incoming commands are >>>> > en-queued in the commandQueue, to be processed one by one. But where >>>> in the code, is the command >>>> > getting de-queued for parsing? >>>> >>>> In fact, the commandQueue is the way to communicate to the Scilab >>>> interpreter engine. When you >>>> request an execution, the command is stored on the queue and latter the >>>> engine pick the command and >>>> execute it. >>>> >>>> When hitting the "Play" button on xcos, we push the diagram to the >>>> Scilab workspace and put an >>>> 'xcos_simulate' call to be executed. >>>> >>>> >>>> > ---- 2 ---- >>>> > >>>> > The command that is given in /etc/main_menubar.xml for opening Xcos >>>> is >>>> > >>>> > if with_mode ('xcos') then xcos(); >>>> > else disp(gettext('Please install xcos module')) >>>> > >>>> > Would it be possible for you to point where xcos() is invoked after >>>> interpretation and parsing? >>>> > >>>> > Hypothetically for instance, if I were to create a new method in >>>> Java, so that I can see the Block >>>> > Diagram Editor, like this - >>>> > >>>> > public static void main (String args[]){ >>>> > Xcos xcos = new Xcos(); //Assuming I can write something like >>>> this >>>> > } >>>> > >>>> > If this is possible, I would like to know, which is that particular >>>> 'XCos' Class that can allow me >>>> > to do this? >>>> On the xcos module, there is an 'Xcos.java' file that contains some >>>> annotated methods exported to C. >>>> For instance you can take a look at the Xcos#xcos() method. >>>> >>>> -- >>>> Cl?ment >>>> >>>> > On Mon, Feb 1, 2016 at 1:02 PM, Cl?ment David-2 [via Scilab / Xcos - >>>> Mailing Lists Archives] >>>> > <[hidden email]> wrote: >>>> >>>> > > Hi Adhitya, >>>> > > >>>> > > The code is *the* reference but for more internal views I suggest >>>> you to read these documents : >>>> > > >>>> > > * R. NIKOUKHAH AND S. STEER , Scicos a dynamic system builder and >>>> simulator, IEEE INTERNATIONAL >>>> > > CONFERENCE ON CACSD, DEARBORN , MICHIGAN , 1996. >>>> > > * S. STEER , R. NIKOUKHAH , Scicos: a hybrid system formalism, >>>> ESS?99, E RLANGEN , GERMANY , >>>> > > 1999. >>>> > > * Masoud NAJAFI thesis , The Numerical Solver for the Simulation of >>>> the Hybrid Dynamical >>>> > > Systems >>>> > > , 2005 . >>>> > > >>>> > > And for understanding what's behind each block, take a look at the >>>> Scilab documentation, and >>>> > > ScilabTec presentations. >>>> > > >>>> > > Regards, >>>> > > >>>> > > -- >>>> > > Cl?ment >>>> > > >>>> > > >>>> > > Le vendredi 29 janvier 2016 ? 23:31 -0700, adhitya a ?crit : >>>> > > >>>> > > > Hi, >>>> > > > >>>> > > > My name is Adhitya Kamakshidasan and I'm an Intern at FOSSEE, IIT >>>> Bombay. >>>> > > > >>>> > > > We are trying to develop a standalone version of Xcos, that is >>>> completely >>>> > > > web-based. >>>> > > > >>>> > > > I would like to know if there is any documentation with respect >>>> to how Xcos >>>> > > > has been written - Flowcharts, Main methods, PDF's, etc. >>>> > > > >>>> > > > Currently, I'm trying to reverse-engineer the code, by slowly >>>> moving through >>>> > > > the code, and removing the parts that are not related to Xcos. >>>> However, this >>>> > > > is taking a lot of time. >>>> > > > >>>> > > > We would like your support in this regard. >>>> > > > >>>> > > > Thanks, >>>> > > > >>>> > > > Adhitya Kamakshidasan >>>> > > > >>>> > > > >>>> > > > >>>> > > > -- >>>> > > > View this message in context: >>>> http://mailinglists.scilab.org/Documentation-for-Xcos-tp4033357. >>>> > > 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-tp4033357p4033359.html >>>> > > To unsubscribe from Documentation for Xcos, click here. >>>> > > NAML >>>> > > >>>> > >>>> > View this message in context: Re: Documentation for Xcos >>>> > 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-tp4033357p4033513.html >>>> To unsubscribe from Documentation for Xcos, click here. >>>> NAML >>>> >>>> >>> >>> >> > ------------------------------ > View this message in context: Re: Documentation for Xcos > > 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 michael.baudin at contrib.scilab.org Thu Feb 25 14:46:20 2016 From: michael.baudin at contrib.scilab.org (michael.baudin at contrib.scilab.org) Date: Thu, 25 Feb 2016 14:46:20 +0100 Subject: [Scilab-Dev] Atoms modules maintenance Message-ID: <126cab484c44895081f39281f6afd482@contrib.scilab.org> 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 From sgougeon at free.fr Sun Feb 28 20:24:51 2016 From: sgougeon at free.fr (Samuel Gougeon) Date: Sun, 28 Feb 2016 20:24:51 +0100 Subject: [Scilab-Dev] Coverage ? <= Re: Release Scilab 6.0.0 alpha 2 In-Reply-To: <5395ECC5-F84B-4773-AD21-B8E9EBD313DF@scilab-enterprises.com> References: <565D750D.1060701@laas.fr> <5395ECC5-F84B-4773-AD21-B8E9EBD313DF@scilab-enterprises.com> Message-ID: <56D34983.2080503@free.fr> Hello, Le 01/12/2015 12:11, francois.granade a ?crit : > Good catch, the release notes are not very clear :) > > There *is* some basic documentation, however, in the change log > (accessible from "edit SCI/CHANGES_6.0.X" for example). Pasting them: > > New Features > ============ > > * Scilab now includes a full-featured debugger, with ability to run > Scilab scripts or functions step-by-step, to put (conditional) > breakpoint, in particular break only when an exception is set. Run > "help debug" for more information. > > * A new profiler and coverage tool has been added. > It replaces the "profile" function (which is still there but not > working, and will be removed in the final release)*.* > It produces HTML report for the time spent (profile) on each line. > Example of use: > > covStart(isempty) // instruments the "isempty" macro; instrumenting > a whole library can be done with: covStart("elementary_functions") > for i=1:1e5; isempty(i); end // execute some code - this will be > profiled > covWrite("html", "TMPDIR/coverage") // write the profiling/coverage > report as "report.html" in the folder specified as second parameter > covStop(); // stop the profiling > > A function to merge multiple profiler/coverage is provided too: > covMerge([ list_of_files_to_merge], file_to_merge_to)*.* > The API will change before the release; the current API is mostly to > get feedback from the community. > > * A "lint"-like command, slint, has been added, for code static > analysis: it detects unclear, risky or suspicious code. > Usage: slint("")*.* It is not documented yet. > > > We didn't want to advertise it too much, as we may changes these > functions before the release... Here we are on the dev@ list. If even on the dev@ it is not possible to openly discuss about features /in development/, then where? This part of the release notes is very surprising, because it only and hardly starts what could be a proper Scilab Enhancement Proposal. No SEP was published. This means, that, no, you don't really need our feedback, since SEP are mostly designed for that. For the moment, "coverage" does not look at all as a new functional feature. Among the 3 proposed syntaxes, the first one is (now?) bugged: covStart(isempty) // yielded an error the first time i ran it. And when i tried covStart("isempty") // it did not complain. After that, i tried again, from another fresh session, or a running one, covStart(isempty) // and it did no longer complain. May be it will complain again later, who knows. Mixing input types between strings (name of functions or here library) and functions pointers (covStart(isempty), but covStart("mylibrary")) were already misleading within the former set of profiling functions. This has been reported on bugzilla. The first announcement of the new set shows that we learn almost nothing about former design/usage complications. Then i tried with covStart("strsubst") // that is a builtin. Are built-in profilable? I know that the former profiling applied "only" on Scilab macros, but since this is a new profiler, i do not assume anything about any possible restriction. I do not really expect any answer here. A SEP is the right place to define what does a function, with which kind of parameters, according to which parameters format (string or function or primitive), the naming, etc. A SEP is also a very good start to build the related documentation. Whatever "strsubst" is an acceptable entry or not, no error is produced. After running "uman" that uses a lot of strsubst(), covWrite(..) produces an empty report (attached). Same thing with covStart(strsubst) Same thing with covStart(uman) or covStart("uman") // that is a macro Nothing. I get nothing with the beta-1. Unfortunately, i have uninstalled the alpha-2 for which these "coverage" functions have been first announced. The announcement has not changed for the beta-1. The former profiling functions had an output in console, as well as in argout to enable post-processing (as for the running upgrade of bench_run(), >10 (?) years after its first release) , or in an interactive plot. The few that is announced for the new profiling features looks much less than what was formerly available. So, as somewhat Antoine told it, and after your answer, what i understand is that S/E needs to tell that it needs our feedback. I guess that we are expected to believe it. For the moment nothing really tell us that it needs more than telling it. But this can change. Thanks, and regards. Samuel Gougeon One of your 100000 industrial downloaders/month -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From clement.david at scilab-enterprises.com Mon Feb 29 08:16:41 2016 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Mon, 29 Feb 2016 08:16:41 +0100 Subject: [Scilab-Dev] Coverage ? <= Re: Release Scilab 6.0.0 alpha 2 In-Reply-To: <56D34983.2080503@free.fr> References: <565D750D.1060701@laas.fr> <5395ECC5-F84B-4773-AD21-B8E9EBD313DF@scilab-enterprises.com> <56D34983.2080503@free.fr> Message-ID: <1456730201.2803.11.camel@scilab-enterprises.com> Hi Samuel, Le dimanche 28 f?vrier 2016 ? 20:24 +0100, Samuel Gougeon a ?crit?: > Hello, >? > > * A new profiler and coverage tool has been added. > > ? It replaces the "profile" function (which is still there but not working, and will be removed > > in the final release). > > ? It produces HTML report for the time spent (profile) on each line. Example of use: > > > > ?? ? covStart(isempty) // instruments the "isempty" macro; instrumenting a whole library can be > > done with: covStart("elementary_functions") > > ?? ? for i=1:1e5; isempty(i); end // execute some code - this will be profiled > > ?? ? covWrite("html", "TMPDIR/coverage") // write the profiling/coverage report as "report.html" > > in the folder specified as second parameter > > ?? ? covStop(); // stop the profiling > > > > ? A function to merge multiple profiler/coverage is provided too: covMerge([ > > list_of_files_to_merge], file_to_merge_to). > > ? The API will change before the release; the current API is mostly to get feedback from the > > community. > >? > > We didn't want to advertise it too much, as we may changes these functions before the release... > Here we are on the dev@ list. If even on the dev@ it is not possible to openly discuss about > features in development, then where? The dev@ ML is in fact the right place to discuss new features or how to improve things. On the "coverage" feature especially it has been mainly developed by calixte as a tool to validate its analysis pass (not as a well as a designed from scratch new feature). On the team we asked ourself if we should integrate it or not as it was not in the roadmap for 6.0.0 but is useful enough to be present. We decided to provide it (as an incomplete dev) ! > This part of the release notes is very surprising, because it only and hardly starts what could be > a proper Scilab Enhancement Proposal.? > No SEP was published. This means, that, no, you don't really need our feedback, since SEP are > mostly designed for that. > For the moment, "coverage" does not look at all as a new functional feature. > Among the 3 proposed syntaxes, the first one is (now?) bugged: > covStart(isempty)??? // yielded an error the first time i ran it. And when i tried > covStart("isempty") // it did not complain. After that, i tried again, from another fresh session, > or a running one,? > covStart(isempty)??? // and it did no longer complain. May be it will complain again later, who > knows. > > Mixing input types between strings (name of functions or here library) and functions pointers > (covStart(isempty), but covStart("mylibrary")) were already misleading within the former set of > profiling functions. This has been reported on bugzilla. The first announcement of the new set > shows that we learn almost nothing about former design/usage complications. > ?? > Then i tried with covStart("strsubst") // that is a builtin. Are built-in profilable? I know that > the former profiling applied "only" on Scilab macros, but since this is a new profiler, i do not > assume anything about any possible restriction. I do not really expect any answer here. A SEP is > the right place to define what does a function, with which kind of parameters, according to which > parameters format (string or function or primitive), the naming, etc.? A SEP is also a very good > start to build the related documentation. > > Whatever "strsubst" is an acceptable entry or not, no error is produced. > > After running "uman" that uses a lot of strsubst(), covWrite(..) produces an empty report > (attached). > Same thing with covStart(strsubst) > Same thing with covStart(uman) or covStart("uman") // that is a macro > Nothing. I get nothing with the beta-1. Unfortunately, i have uninstalled the alpha-2 for which > these "coverage" functions have been first announced. The announcement has not changed for the > beta-1. > > The former profiling functions had an output in console, as well as in argout to enable post- > processing (as for the running upgrade of bench_run(), >10 (?) years after its first release) , or > in an interactive plot. > The few that is announced for the new profiling features looks much less than what was formerly > available. > ? > So, as somewhat Antoine told it, and after your answer, what i understand is that S/E needs to > tell that it needs our feedback. I guess that we are expected to believe it. For the moment > nothing really tell us that it needs more than telling it. But this can change. > > Thanks, and regards. > > Samuel Gougeon > One of your 100000 industrial downloaders/month Thanks for this reports, I added some documentation [1] and will try to have a scilab backend (to provide information back to scilab is a similar way as before). Do not hesitate to post bugs about arguments management, there might as (as written before) this was just an internal tool initially. [1]:?http://cgit.scilab.org/scilab/commit/?id=5af4b83932053c80634254cdd3b2d1a312d5e338 Regards, -- Cl?ment From stephane.mottelet at utc.fr Mon Feb 29 20:56:26 2016 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Mon, 29 Feb 2016 20:56:26 +0100 Subject: [Scilab-Dev] is the forge down ? In-Reply-To: <1456730201.2803.11.camel@scilab-enterprises.com> References: <565D750D.1060701@laas.fr> <5395ECC5-F84B-4773-AD21-B8E9EBD313DF@scilab-enterprises.com> <56D34983.2080503@free.fr> <1456730201.2803.11.camel@scilab-enterprises.com> Message-ID: <56D4A26A.6070305@utc.fr> Hello, The scilab forge seems to be down : The server encountered an unexpected condition which prevented it from fulfilling your request. An email has been sent to the administrators, we will correct this error as soon as possible. Thank you for your comprehension. 500 - Internal Server Error S. -------------- next part -------------- An HTML attachment was scrubbed... URL: