From sgougeon at free.fr Sun Dec 2 20:54:09 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Sun, 2 Dec 2018 20:54:09 +0100 Subject: [Scilab-Dev] SEP advanced function/profiling in Scilab 6 In-Reply-To: References: Message-ID: <49038696-c6a1-24cc-dfd8-f39eb710b812@free.fr> Hello Cl?ment, Glad to see that restoring handy profiling facilities is awake. I am afraid i don't catch all from the SEP. Here is a short list of remarks that still make me wondering: * In 5.5.2, the former functions were about BOTH coverage and timing. Displaying both informations in the 2 first columns was very handy. The current SEP seems to present 2 separated subsets of functions, as if things are planned to become separated. This is quite unclear. * Reforging things should be a major opportunity to suppress the splitting in many functions just vs the action. Hence, the former add_profiling, remove_profiling, reset_profiling were painfull because inventing, maintaining, documenting and using 3 separate functions just because of ONE parameter is changing -- the action -- imo was imo meaningless. This is a low-level kind of design, whereas Scilab is a high-level language, the language should be integrated: I rather expect using *profile(action, target [, options])* with for instance *action = "on"|"off"|"reset"|"disp"|"html"*|*"plot"*... In this way, things are open. If other actions have to be added latter, the prototype won't change, and no need to have a Nth function and Nth documentation page in 5 natural languages. * In the SEP, the fact that restoring a display in text mode in the console is planned does not explicitly appear. Nor the planned order of columns of results. Both aspects are really killing details. When improving the code, i never felt the need of having pleasant colored reports. But, daily, the display in console was my first and almost only usage. * "instrumentation" is some hardly understandable devs jargon. Best regards Samuel Le 30/11/2018 ? 15:02, Cl?ment David a ?crit : > Dear devs, > > I started working on re-introducing profiling functions into Scilab 6.0; > these functions will behave very similarly to the Scilab 5 ones but have > been renamed for consistency and their arguments will slightly differs > (macro value vs macro as string). Thanks to Samuel's mail [2], I wrote a SEP > [1] that might finally fix that miss, please comment and give feedbacks ! > > [1]: https://wiki.scilab.org/SEP%20profiling%20in%20Scilab%206.1 > [2]: > http://mailinglists.scilab.org/New-profiling-module-code-coverage-td4034048. > html > > Thanks, > > -- > Cl?ment > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From Clement.David at esi-group.com Mon Dec 3 16:31:58 2018 From: Clement.David at esi-group.com (=?iso-8859-1?Q?Cl=E9ment_David?=) Date: Mon, 3 Dec 2018 15:31:58 +0000 Subject: [Scilab-Dev] SEP advanced function/profiling in Scilab 6 In-Reply-To: <49038696-c6a1-24cc-dfd8-f39eb710b812@free.fr> References: <49038696-c6a1-24cc-dfd8-f39eb710b812@free.fr> Message-ID: Hello Samuel and thanks for your comments, I updated the SEP with more information clarifying some aspects. These `profile` functions are not supposed to replace the existing `coverage` ones. The underlying execution counters are re-used for the two implementations but the usage might slightly be different: produce a static report for the coverage or display performance information while developing. I reword some aspect to clarify the display and show methods, the ?instrumentation? At first, I want to map the Scilab 5 features before trying to push enhancement or API modification so I used similar names as in Scilab 5. The main issue with switching API is the associated effort to port existing Scilab 5 toolset to the new API. As you propose, a Matlab-like `profile` might be a later extension. Best, -- Cl?ment From: dev On Behalf Of Samuel Gougeon Sent: Sunday, December 2, 2018 8:54 PM To: List dedicated to the development of Scilab Subject: Re: [Scilab-Dev] SEP advanced function/profiling in Scilab 6 Hello Cl?ment, Glad to see that restoring handy profiling facilities is awake. I am afraid i don't catch all from the SEP. Here is a short list of remarks that still make me wondering: * In 5.5.2, the former functions were about BOTH coverage and timing. Displaying both informations in the 2 first columns was very handy. The current SEP seems to present 2 separated subsets of functions, as if things are planned to become separated. This is quite unclear. * Reforging things should be a major opportunity to suppress the splitting in many functions just vs the action. Hence, the former add_profiling, remove_profiling, reset_profiling were painfull because inventing, maintaining, documenting and using 3 separate functions just because of ONE parameter is changing -- the action -- imo was imo meaningless. This is a low-level kind of design, whereas Scilab is a high-level language, the language should be integrated: I rather expect using profile(action, target [, options]) with for instance action = "on"|"off"|"reset"|"disp"|"html"|"plot"... In this way, things are open. If other actions have to be added latter, the prototype won't change, and no need to have a Nth function and Nth documentation page in 5 natural languages. * In the SEP, the fact that restoring a display in text mode in the console is planned does not explicitly appear. Nor the planned order of columns of results. Both aspects are really killing details. When improving the code, i never felt the need of having pleasant colored reports. But, daily, the display in console was my first and almost only usage. * "instrumentation" is some hardly understandable devs jargon. Best regards Samuel Le 30/11/2018 ? 15:02, Cl?ment David a ?crit : Dear devs, I started working on re-introducing profiling functions into Scilab 6.0; these functions will behave very similarly to the Scilab 5 ones but have been renamed for consistency and their arguments will slightly differs (macro value vs macro as string). Thanks to Samuel's mail [2], I wrote a SEP [1] that might finally fix that miss, please comment and give feedbacks ! [1]: https://wiki.scilab.org/SEP%20profiling%20in%20Scilab%206.1 [2]: http://mailinglists.scilab.org/New-profiling-module-code-coverage-td4034048. html Thanks, -- Cl?ment _______________________________________________ dev mailing list dev at lists.scilab.org http://lists.scilab.org/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4425 bytes Desc: not available URL: From sgougeon at free.fr Sun Dec 16 18:50:52 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Sun, 16 Dec 2018 18:50:52 +0100 Subject: [Scilab-Dev] SEP advanced function/profiling in Scilab 6 In-Reply-To: References: <49038696-c6a1-24cc-dfd8-f39eb710b812@free.fr> Message-ID: <0dcb8ce8-37fe-547d-a3da-5f18a714127e@free.fr> Hello Cl?ment, Thanks for this second version, indeed much clearer to me. This one brings new questions and comments. * The planned ability to target a single function, or a whole library, or all loaded libraries goes beyond the portage to Scilab 6. This is already a great improvement. About possible targets, here are some arising open questions (they are not requests, just questions for more information) : => Will it be possible to target a user-defined function out of libraries (defined with deff, function (in console), exec, jdeff..)? * prof = profileGetInfo(): the architecture/hierarchy to access to the results is unclear to me. This is an important point in term of usages. This point is one of major ones hindering the usage of slint(), as reported on bugzilla and on users at . It would be a pity to have the same issue for profiling results. Examples showing how to address most interesting results would be highly welcome. o Example : How to get totalTime for all functions of a given library (as a first step to focus on hot functions). Will it be something like sel = prof.FunctionTable.ModuleName=="myModule"; prof.FunctionTable(sel).FunctionName prof.FunctionTable(sel).TotalTime or like prof.FunctionTable...TotalTime or like prof.FunctionTable..TotalTime prof.FunctionTable..ModuleName o I do not catch why there are 2 distinct 1st level fields FunctionTable and FunctionCoverage, instead of having a tenth field FunctionCoverage directly at the first level. This first level FunctionTable/FunctionCoverage complicates the addressing, and its motivation is unclear. o To me, the most handy first level addressing should be directly through : prof.myFun.TotalTime prof.myFun.Coverage etc. This is much simpler and straightforward than with the syntaxes presented hereabove. o About fields names + "ModuleName" might be abbreviated into Module or Library without loss of meaning and clarity. If the expected value is the name of the library (e.g. corelib), then the field name should be Library instead of Module or ModuleName. Otherwise, ModuleName will refer to core, not to corelib. This would prevent securely addressing information from the library (the name of a module is not clearly defined. Is it the name of its SCI/ directory, or the name of its gateway, or...? + "FirstLine" : is it the "Prototype"? + InstructionsCount, BranchesCount, PathsCount : # these fields would be new results, not available in Scilab 5. For the time being, I do not understand what they represent nor what they can be used to. # Does "executed lines count" stand for only lines that are actually executed, or does it stand for _all_ lines, with a count 0 for not executed ones? * The case of *nested functions* (a function defined in a function, etc) is not presented. There were some issues in Scilab 5 about them. See for instance the bug 12104 or the bug 12105 . * The case of *internal functions defined in the same .sci file *after the main function is not presented. This is a new topic, since the Scilab 6 processing is new with respect to these local dependencies. Will profiling these internal dependencies be possible? * /"//The main issue with switching API is the associated effort to port existing Scilab 5 toolset to the new API. As you propose, a Matlab-like `profile` might be a later extension."/ I am sorry, i do not clearly understand this point. Anyway, the API is changed, since functions are renamed, and the format of results is completely changed. Writting a profile() macro routing to the internal profileEnable() etc would be somehow let's say ~3% of the time, by far the easiest part of the forge, compared to the implementation/rewritting of hard code. But it would ease usages and maintenance and documentation. Skipping it looks like a bit self censorship, self limiting impact of a great work. At least, not splitting the documentation in N separated pages, but building a single help page presenting all profiling functions and usages would be better. Thanks again for all your efforts and work. Best regards Samuel Le 03/12/2018 ? 16:31, Cl?ment David a ?crit : > > Hello Samuel and thanks for your comments, > > I updated the SEP with more information clarifying some aspects. These > `profile` functions are not supposed to replace the existing > `coverage` ones. The underlying execution counters are re-used for the > two implementations but the usage might slightly be different: produce > a static report for the coverage or display performance information > while developing. I reword some aspect to clarify the display and show > methods, the ?instrumentation? > > At first, I want to map the Scilab 5 features before trying to push > enhancement or API modification so I used similar names as in Scilab > 5. The main issue with switching API is the associated effort to port > existing Scilab 5 toolset to the new API. As you propose, a > Matlab-like `profile` might be a later extension. > > Best, > > -- > > Cl?ment > > *From:*dev *On Behalf Of *Samuel Gougeon > *Sent:* Sunday, December 2, _2018_ 8:54 PM > *To:* List dedicated to the development of Scilab > *Subject:* Re: [Scilab-Dev] SEP advanced function/profiling in Scilab 6 > > Hello Cl?ment, > > Glad to see that restoring handy profiling facilities is awake. > I am afraid _i_ don't catch all from the SEP. Here is a short list of > remarks that still make me _wondering_: > > * In 5.5.2, the former functions were about BOTH coverage and > timing. Displaying both _informations_ in the 2 first columns was > very handy. > The current SEP seems to present 2 separated subsets of > _functions,_ as if things are planned to become separated. This is > quite unclear. > * Reforging things should be a major opportunity to suppress the > splitting in many functions just vs the action. > Hence, the former add_profiling, remove_profiling, reset_profiling > were _painfull_ because inventing, maintaining, documenting and > using 3 separate functions just because of ONE parameter is > changing -- the action -- _imo_ was _imo_ meaningless. This is a > low-level kind of design, whereas Scilab is a high-level language, > the language should be integrated: I rather expect using > *profile(action, target [, options])* with for instance *action = > "on"|"off"|"reset"|"disp"|"html"*|*"plot"*... > In this way, things are open. If other actions have to be added > _latter_, the prototype won't change, and no need to have _a Nth_ > function and Nth documentation page in 5 natural languages. > * In the SEP, the fact that restoring a display in text mode in the > console is planned does not explicitly appear. Nor the planned > order of columns of results. Both aspects are really killing > details. When improving the code, i never felt the need of having > pleasant colored reports. But, daily, the display in console was > my first and almost only usage. > * "instrumentation" is some hardly understandable devs jargon. > > Best regards > > Samuel > > > Le 30/11/2018 ? 15:02, Cl?ment David a ?crit : > > Dear devs, > > I started working on re-introducing profiling functions into Scilab 6.0; > > these functions will behave very similarly to the Scilab 5 ones but have > > been renamed for consistency and their arguments will slightly differs > > (macro value vs macro as string). Thanks to Samuel's mail [2], I wrote a SEP > > [1] that might finally fix that miss, please comment and give feedbacks ! > > [1]:https://wiki.scilab.org/SEP%20profiling%20in%20Scilab%206.1 > > [2]: > > http://mailinglists.scilab.org/New-profiling-module-code-coverage-td4034048. > > html > > Thanks, > > -- > > Cl?ment > > > > > _______________________________________________ > > 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 komalbharadiya at gmail.com Fri Dec 21 10:05:07 2018 From: komalbharadiya at gmail.com (Komal Bharadiya) Date: Fri, 21 Dec 2018 14:35:07 +0530 Subject: [Scilab-Dev] Bug #6028 Message-ID: Hey Mentors, I am Komal from Pune, India. I am an 4th year engineering student. I am interested in working for this issue. Since I am totally new to open source, I need your help in this. I want to know how do I go about this. Thanking you in anticipation. Regards, Komal From Clement.David at esi-group.com Fri Dec 21 14:19:15 2018 From: Clement.David at esi-group.com (=?iso-8859-1?Q?Cl=E9ment_David?=) Date: Fri, 21 Dec 2018 13:19:15 +0000 Subject: [Scilab-Dev] SEP add a `%foo_delete` overloading Message-ID: Dear devs, After CNES presentation on Scilab Conference 2018, I would like to propose a solution to the mandatory use of `jremove`. The point is : some Scilab functionalities based on mlist overloading are implemented in C/C++ with manual memory management or in Java with garbage collected memory. How to clean-up the associated resources on Scilab mlist deletion ? I wrote a SEP about adding a "delete" overloading to describe that [1], please comment and give feedbacks ! [1]: https://wiki.scilab.org/SEP%20add%20a%20%25foo_delete%20overloading Thanks, -- Cl?ment From sgougeon at free.fr Fri Dec 21 19:40:12 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 21 Dec 2018 19:40:12 +0100 Subject: [Scilab-Dev] SEP add a `%foo_delete` overloading In-Reply-To: References: Message-ID: <1451fbe9-c1c2-b5df-47c4-6364343dcf5a@free.fr> Hello Cl?ment, Le 21/12/2018 ? 14:19, Cl?ment David a ?crit : > Dear devs, > > After CNES presentation on Scilab Conference 2018, I would like to propose a solution to the mandatory use of `jremove`. The point is : some Scilab functionalities based on mlist overloading are implemented in C/C++ with manual memory management or in Java with garbage collected memory. How to clean-up the associated resources on Scilab mlist deletion ? > > I wrote a SEP about adding a "delete" overloading to describe that [1], please comment and give feedbacks ! > > [1]: https://wiki.scilab.org/SEP%20add%20a%20%25foo_delete%20overloading > > Thanks, Thanks for this proposal. I have a couple of questions about it: In the example that you provide, %foo_delete() is aimed to be called when calling clear(). Using clear looks indeed the most handy and simple. It is the main most known deleting function. AFAIK The naming convention for the overload of any primitive is %_builtinName. So, why naming/calling the overload %foo_delete() instead of %foo_clear()? Are you sure that the bug 10258 is related? I would rather say that the bug 10277 and the bug 13398 are so. By the way, 10258's author actually proposes to call %foo_clear(). So, why going out of this convention and regular naming rule? Best regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Dec 21 19:42:03 2018 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 21 Dec 2018 19:42:03 +0100 Subject: [Scilab-Dev] SEP add a `%foo_delete` overloading In-Reply-To: <1451fbe9-c1c2-b5df-47c4-6364343dcf5a@free.fr> References: <1451fbe9-c1c2-b5df-47c4-6364343dcf5a@free.fr> Message-ID: <17bc4aff-2722-0c9a-783f-062a34056382@free.fr> Le 21/12/2018 ? 19:40, Samuel Gougeon a ?crit : > Hello Cl?ment, > > Le 21/12/2018 ? 14:19, Cl?ment David a ?crit : >> Dear devs, >> >> After CNES presentation on Scilab Conference 2018, I would like to propose a solution to the mandatory use of `jremove`. The point is : some Scilab functionalities based on mlist overloading are implemented in C/C++ with manual memory management or in Java with garbage collected memory. How to clean-up the associated resources on Scilab mlist deletion ? >> >> I wrote a SEP about adding a "delete" overloading to describe that [1], please comment and give feedbacks ! >> >> [1]:https://wiki.scilab.org/SEP%20add%20a%20%25foo_delete%20overloading >> >> Thanks, > > > Thanks for this proposal. I have a couple of questions about it: > In the example that you provide, %foo_delete() is aimed to be called > when calling clear(). > Using clear looks indeed the most handy and simple. It is the main > most known deleting function. > > AFAIK The naming convention for the overload of any primitive is > %_builtinName. > So, why naming/calling the overload %foo_delete() instead of %foo_clear()? > > Are you sure that the bug 10258 is related? > I would rather say that the bug 10277 > and the bug 13398 > are so. > By the way, 10258's author actually proposes to call %foo_clear(). Sorry: ..so, 10277's author... -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostrov65 at yandex.ru Wed Dec 26 15:09:43 2018 From: kostrov65 at yandex.ru (mobile_ghost) Date: Wed, 26 Dec 2018 07:09:43 -0700 (MST) Subject: [Scilab-Dev] Fortran program call in Scilab 6.01: OMP does not work! Message-ID: <1545833383929-0.post@n3.nabble.com> Hello! I wrote a parallel routine in Fortran using OMP (Intel compiler v.17.0.4) and link it to Scilab 6.01. To my surprise the program uses only one CPU core from 8 available. Besides, the same stand-alone code uses 8 cores. *Does anybody know what the bug (if any) in Scialab 6.01 and how to bypass it? * My system is Ubuntu 18.04. Intel compiler (ifort version 17.0.4) command is ifort -fPIC -shared -qopenmp grav3d_omp.f90 -o gravda_omp.so Scilab link and call command are: a29=link('modules/gravda_omp.so','gravda','f'); [mgrdm]=call("gravda",a_cells,1,"d",ipar,2,"i",... xgrd,3,"d",ygrd,4,"d", zgrd,5,"d",... mgrdm,6,"d",indsub,7,"i",... frm3d,8,"d",srf,9,"i",logfiles3d,10,"i",... "out",[nr_mgrdm,nc_mgrdm],6,"d"); I made a standalone version ifort -qopenmp grav3d_omp.f90 -o gravda_omp of the same progam and run it from Scilab 6.01 unix_w("gravda_omp"); with the same result: ONLY ONE CPU CORE is used! BUT, when I run it from a terminal window it works fine. Every CPU core busy 100%. What's the matter? Is there a solution? Thanks in advance. Nick -- Sent from: http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944.html From bygrandao at gmail.com Fri Dec 28 17:42:38 2018 From: bygrandao at gmail.com (Pedro Arthur) Date: Fri, 28 Dec 2018 14:42:38 -0200 Subject: [Scilab-Dev] Fortran program call in Scilab 6.01: OMP does not work! In-Reply-To: <1545833383929-0.post@n3.nabble.com> References: <1545833383929-0.post@n3.nabble.com> Message-ID: Hi, Em qua, 26 de dez de 2018 ?s 12:09, mobile_ghost escreveu: > > Hello! > I wrote a parallel routine in Fortran using OMP (Intel compiler v.17.0.4) > and link it to Scilab 6.01. To my surprise the program uses only one CPU > core from 8 available. Besides, the same stand-alone code uses 8 cores. > *Does anybody know what the bug (if any) in Scialab 6.01 and how to bypass > it? * Did you set the number of threads to use at runtime [1]? if not the application may use whatever default value is set. [1] - https://software.intel.com/en-us/mkl-linux-developer-guide-changing-the-number-of-openmp-threads-at-run-time Best regards, Pedro. > > My system is Ubuntu 18.04. Intel compiler > (ifort version 17.0.4) command is > ifort -fPIC -shared -qopenmp grav3d_omp.f90 -o gravda_omp.so > > Scilab link and call command are: > a29=link('modules/gravda_omp.so','gravda','f'); > [mgrdm]=call("gravda",a_cells,1,"d",ipar,2,"i",... > xgrd,3,"d",ygrd,4,"d", zgrd,5,"d",... > mgrdm,6,"d",indsub,7,"i",... > frm3d,8,"d",srf,9,"i",logfiles3d,10,"i",... > "out",[nr_mgrdm,nc_mgrdm],6,"d"); > > I made a standalone version > ifort -qopenmp grav3d_omp.f90 -o gravda_omp > of the same progam and run it from Scilab 6.01 > unix_w("gravda_omp"); > with the same result: ONLY ONE CPU CORE is used! > BUT, when I run it from a terminal window it works fine. Every CPU core busy > 100%. > What's the matter? Is there a solution? > > Thanks in advance. > > Nick > > > > -- > Sent from: http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944.html > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From kostrov65 at yandex.ru Sat Dec 29 18:46:03 2018 From: kostrov65 at yandex.ru (=?utf-8?B?0J3QuNC60L7Qu9Cw0Lkg0JrQvtGB0YLRgNC+0LI=?=) Date: Sat, 29 Dec 2018 22:46:03 +0500 Subject: [Scilab-Dev] Fortran program call in Scilab 6.01: OMP does not work! In-Reply-To: References: Message-ID: <41618841546105563@iva7-bd007c44f58e.qloud-c.yandex.net> An HTML attachment was scrubbed... URL: