From Clement.David at esi-group.com  Thu Jan  3 17:49:30 2019
From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=)
Date: Thu, 3 Jan 2019 16:49:30 +0000
Subject: [Scilab-Dev] SEP add a `%foo_delete` overloading
In-Reply-To: <17bc4aff-2722-0c9a-783f-062a34056382@free.fr>
References: <AM6PR0502MB370207916FBD937975C04D77B0B80@AM6PR0502MB3702.eurprd05.prod.outlook.com>
 <1451fbe9-c1c2-b5df-47c4-6364343dcf5a@free.fr>
 <17bc4aff-2722-0c9a-783f-062a34056382@free.fr>
Message-ID: <5f143997164d6b5fb0f8889bbd147e644158aae2.camel@esi-group.com>

Hello Samuel,

I fully agree with `%foo_clear` instead of `%foo_delete` this is simpler to understand from a user
perspective. I edited the wiki page (but preserved the wiki URL) to use this convention. I also
added your bug links to the wiki, a bugzilla search did not list me these ones.

Thanks,

--
Cl?ment 

Le vendredi 21 d?cembre 2018 ? 19:42 +0100, Samuel Gougeon a ?crit :
> 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 %<type>_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...
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/dev

From Clement.David at esi-group.com  Fri Jan  4 09:50:53 2019
From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=)
Date: Fri, 4 Jan 2019 08:50:53 +0000
Subject: [Scilab-Dev] SEP advanced function/profiling in Scilab 6
In-Reply-To: <0dcb8ce8-37fe-547d-a3da-5f18a714127e@free.fr>
References: <VI1PR0502MB371099A62147591BD4B75017B0D30@VI1PR0502MB3710.eurprd05.prod.outlook.com>
 <49038696-c6a1-24cc-dfd8-f39eb710b812@free.fr>
 <AM6PR0502MB3702446309FF22C1BD81FF79B0AE0@AM6PR0502MB3702.eurprd05.prod.outlook.com>
 <0dcb8ce8-37fe-547d-a3da-5f18a714127e@free.fr>
Message-ID: <b2d2ae953d276aaf5245ede98dc54585d73cce55.camel@esi-group.com>

Hello Samuel and happy new year,

I will try to answer your question in-line to clarify the current description (and implementation).
I also updated the wiki page with the latest information (mainly a split I will detail below).

 
> => Will it be possible to target a user-defined function out of libraries (defined with deff,
> function (in console), exec, jdeff..)?

Yes of course, from the interpreter point of view, a Scilab function (in whatever way we use to
define it) is a specific value we instrument or retrieve the value from.

> sel = prof.FunctionTable.ModuleName=="myModule";
> prof.FunctionTable(sel).FunctionName
> prof.FunctionTable(sel).TotalTime

Yep, that's almost it :

 sel = prof.FunctionTable.ModuleName == "myModule";
 prof.FunctionCoverage(sel).FunctionName
 prof.FunctionCoverage(sel).TotalTime


> 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.
> 
> To me, the most handy first level addressing should be directly through <functionName>:
> prof.myFun.TotalTime
> prof.myFun.Coverage
> etc. This is much simpler and straightforward than with the syntaxes presented hereabove.

I described a way to store functions descriptions, functions statistics and line coverage in
separate fields as this is really different information. For exemple, to store function description
or statistics I used a struct which is the most easy way to select (as in the above snippet) a
module or a specific function whereas to store line coverage (per function) in a compact way I used
a list containing information for each function and *per line*. So really the final indexing is not
the same for this line coverage.

At the end and after some interaction with our current customer, we ended up with three different
information : static per function (file names, module, etc..), dynamic per function (number of
calls, total time, etc...), dynamic per function per line (time and counter). So a tlist with three
fields : FunctionTable, FunctionCoverage and LineCoverage. 

> 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/<module> directory, or the name of its gateway, or...?

I agree with the "core" vs "corelib" however this value is stored as a string so this is really a
name. I will switch to "LibraryName" to ease understanding and be coherent with the libraryinfo
documentation [1].

[1]: https://help.scilab.org/docs/6.0.1/en_US/libraryinfo.html

> "FirstLine" : is it the "Prototype"?

This field is the first line of the function (the one with the `function` keyword) and is the same
as:
 * used on error (in Scilab 5 or 6)
 * within Scinotes

This is also used to avoid generating header lines on LineCoverage.

> 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?

This is basically counters for coverage, the executed instruction/branches/path and non executed
instruction/branches counts for a specific function are reported. This is not really "lines count"
but expression count (executable statement in the code) thus is more precise than lines based
coverage but harder to visualize.

> 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?

Yes this is handled and was an important remark from our customer. Both the sub function (in the
same macro file) or inner functions (within another function) are handled as independent functions
and could be retrieved by FunctionTable.FileName and a specific FunctionTable.ParentIndex (index to
its parent function).

Inner functions are also reported as non executable lines on the parent function LineCoverage.

> "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.

Well, each Scilab function is supposed to have its own associated help page furthermore having the
full description. However I agree that having a single `profile` page will ease overall
understanding, its usage and its maintenance. 

Thanks for your remarks,

--
Cl?ment

From kostrov65 at yandex.ru  Mon Jan 14 13:43:35 2019
From: kostrov65 at yandex.ru (mobile_ghost)
Date: Mon, 14 Jan 2019 05:43:35 -0700 (MST)
Subject: [Scilab-Dev] Scilab 6.0.1 and OMP
Message-ID: <1547469815478-0.post@n3.nabble.com>

There is a very simple Fortran progmam calculating
gravity, in which I used OMP code ( grav3d_omp.f90
<https://drive.google.com/file/d/1ytver7e3yY6rKGSy7_XFMUc7NlCmTXY5/view?usp=sharing> 
)
Here is a row in .bashrc
export OMP_NUM_THREADS=8

I ran grav3d_omp from a terminal window and
htop shows (Figure  htop_2019-01-14_16-36-52.png
<https://drive.google.com/file/d/1Ab_XeUFN0WdpozxZhP_yNy8smIXpcZ4i/view?usp=sharing> 
) that OMP works OK.

The same program I ran from Scilab 6.0.1 command window

--> unix("bin/grav3d_omp");
and saw that OMP does not work (screen shot 
htop_scilab_2019-01-14_16-41-29.png
<https://drive.google.com/file/d/1Rj8cHwbDy6LHdxLAmOrn9xv2sd5exgYF/view?usp=sharing> 
)


My OS is Ubuntu 16.04
nick@:$ uname -a
Linux ghost7 4.15.0-43-lowlatency #46-Ubuntu SMP PREEMPT Thu Dec 6 17:28:08
UTC
2018 x86_64 x86_64 x86_64 GNU/Linux

nick@:$ ifort -v
ifort version 17.0.4
nick@:$

The same behavior (as shown on figure  htop_scilab_2019-01-14_16-41-29.png
<https://drive.google.com/file/d/1Rj8cHwbDy6LHdxLAmOrn9xv2sd5exgYF/view?usp=sharing> 
)
you can see if you make so-module
ifort -qopenmp -FPIC -shared grav3d_omp.f90 -o grav3d_omp.so
and then
link it to Scilab  and call it
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");

How to make OMP code working from inside Scilab?
A question for the developers. What the reason and how to bypass the problem
?
Maybe I sent the question to the wrong place so I would like to ask someone
to
tell me were should I send it to get an answer or any hint.

The references to grav3d_omp, the program source code and input data to run
it are attached:

Input data to grav3d_omp is in  grav3d_omp.rar
<https://drive.google.com/file/d/16RjHmPVsyTE1FVlxg8-tfDcxJVKwxs-f/view?usp=sharing>   
https://drive.google.com/file/d/16RjHmPVsyTE1FVlxg8-tfDcxJVKwxs-f/view?usp=sharing

grav3d_omp.f90
<https://drive.google.com/file/d/1ytver7e3yY6rKGSy7_XFMUc7NlCmTXY5/view?usp=sharing>  
https://drive.google.com/file/d/1ytver7e3yY6rKGSy7_XFMUc7NlCmTXY5/view?usp=sharing

htop_2019-01-14_16-36-52.png
<https://drive.google.com/file/d/1Ab_XeUFN0WdpozxZhP_yNy8smIXpcZ4i/view?usp=sharing>  
https://drive.google.com/file/d/1Ab_XeUFN0WdpozxZhP_yNy8smIXpcZ4i/view?usp=sharing

htop_scilab_2019-01-14_16-41-29.png
<https://drive.google.com/file/d/1Rj8cHwbDy6LHdxLAmOrn9xv2sd5exgYF/view?usp=sharing>  
https://drive.google.com/file/d/1Rj8cHwbDy6LHdxLAmOrn9xv2sd5exgYF/view?usp=sharing


Thanks in advance.

Nick





--
Sent from: http://mailinglists.scilab.org/Scilab-developers-Mailing-Lists-Archives-f2574944.html


From bygrandao at gmail.com  Mon Jan 14 14:15:12 2019
From: bygrandao at gmail.com (Pedro Arthur)
Date: Mon, 14 Jan 2019 11:15:12 -0200
Subject: [Scilab-Dev] Scilab 6.0.1 and OMP
In-Reply-To: <1547469815478-0.post@n3.nabble.com>
References: <1547469815478-0.post@n3.nabble.com>
Message-ID: <CAKN1MR7TP62HpKpr=cusKoQdT9rNzjsoq2P1Uv2rLsf_UfduVA@mail.gmail.com>

Em seg, 14 de jan de 2019 ?s 10:44, mobile_ghost <kostrov65 at yandex.ru> escreveu:
>
> There is a very simple Fortran progmam calculating
> gravity, in which I used OMP code ( grav3d_omp.f90
> <https://drive.google.com/file/d/1ytver7e3yY6rKGSy7_XFMUc7NlCmTXY5/view?usp=sharing>
> )
> Here is a row in .bashrc
> export OMP_NUM_THREADS=8
>
> I ran grav3d_omp from a terminal window and
> htop shows (Figure  htop_2019-01-14_16-36-52.png
> <https://drive.google.com/file/d/1Ab_XeUFN0WdpozxZhP_yNy8smIXpcZ4i/view?usp=sharing>
> ) that OMP works OK.
>
> The same program I ran from Scilab 6.0.1 command window
>
> --> unix("bin/grav3d_omp");
> and saw that OMP does not work (screen shot
> htop_scilab_2019-01-14_16-41-29.png
> <https://drive.google.com/file/d/1Rj8cHwbDy6LHdxLAmOrn9xv2sd5exgYF/view?usp=sharing>
> )
>
>
> My OS is Ubuntu 16.04
> nick@:$ uname -a
> Linux ghost7 4.15.0-43-lowlatency #46-Ubuntu SMP PREEMPT Thu Dec 6 17:28:08
> UTC
> 2018 x86_64 x86_64 x86_64 GNU/Linux
>
> nick@:$ ifort -v
> ifort version 17.0.4
> nick@:$
>
> The same behavior (as shown on figure  htop_scilab_2019-01-14_16-41-29.png
> <https://drive.google.com/file/d/1Rj8cHwbDy6LHdxLAmOrn9xv2sd5exgYF/view?usp=sharing>
> )
> you can see if you make so-module
> ifort -qopenmp -FPIC -shared grav3d_omp.f90 -o grav3d_omp.so
> and then
> link it to Scilab  and call it
> a29=link('modules/gravda_omp.so','gravda','f');
>  [mgrdm]=call("gravda",a_cells,1,"d",ipar,2,"i",...

There is no function named gravda in the code you provide. I'm
supposing the function name is GRA.
It seems that your OMP directives are in the program (lines 158-160)
and not inside the function. If you want the function to be
parallelized you have to use the directives in a loop inside the
function.


From sgougeon at free.fr  Mon Jan 14 23:22:01 2019
From: sgougeon at free.fr (Samuel Gougeon)
Date: Mon, 14 Jan 2019 23:22:01 +0100
Subject: [Scilab-Dev] varn([]) changed
Message-ID: <0c7c011b-e48a-1a72-1029-db0bacfb0b12@free.fr>

Hello,

I was noting that varn([]) changed from Scilab 5 to Scilab 6:

5.5.2:
-->varn([])
          !--error 246
Function not defined for given argument type(s),
   check arguments or define function %s_varn for overloading.

6.0.1:
--> varn([])
  ans  =
     []

This is hard-coded, not in any %s_varn().

This change is not yet documented. I would like to have confirmation 
that it is intentional.

Thanks
Samuel




From sgougeon at free.fr  Mon Jan 14 23:58:50 2019
From: sgougeon at free.fr (Samuel Gougeon)
Date: Mon, 14 Jan 2019 23:58:50 +0100
Subject: [Scilab-Dev] Are genlib() changes intentional? Documenting them
 makes them official
Message-ID: <e23e1ce4-de9a-7b76-10e1-561a6f935016@free.fr>

Hello devs,

After having done it for lib() (already in a somewhat awkward way), i 
would like to update the documentation for libraries and genlib() pages 
for Scilab 6, as fairly requested there 
<http://bugzilla.scilab.org/show_bug.cgi?id=14098>.
However, there is no indication whether observable changes are 
intentional or should be considered as bugs.
Now, documenting things make them official. Therefore, the status of 
changes should be made clearer by their authors.

 1. In a .sci file, functions that are defined after the main one are
    now private, no longer registered in the library.
    There were some discussions about this new feature, early after the
    first Scilab 6.0.0-alpha and beta releases.
    I think that we can consider this point as a new great official
    feature now.

 2. genlib() no longer allows to build a library including some symbols
    other than functions.
    This change could be a consequence of the first chaneg presented
    here-above.
    A bugzilla report could be posted about this topic, that was
    somewhat presented in this thread
    <http://mailinglists.scilab.org/Scilab-users-Clone-a-function-continued-tp4037723p4037728.html>.
    This point is problematic for some toolboxes.
    IMO, the problem is that there is no workaround.
    One smart way to do the same maybe in an even smarter way would be
    to be able to protect variables one by one.
    Then, doing so would be possible in the .start file of a module.
    Indeed, this genlib feature was interesting mainly -- or even only ?
    -- as a workaround of the unability to protect variables.
    Now, when will it be possible to protect variables on the fly in the
    session with Scilab 6?...

 3. genlib() is no longer able to exclude any *.sci files of the current
    directory to not be compiled. This is reported there
    <http://bugzilla.scilab.org/show_bug.cgi?id=15919>. To me, if this
    change is intentional, it is debatable...

Looking forward to reading you

Samuel

PS: IMO it would be better to document as many Scilab 5 => Scilab 6.0 
changes as possible *before* Scilab 6.1.0

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20190114/59f68de0/attachment.htm>

From sgougeon at free.fr  Tue Jan 15 00:25:27 2019
From: sgougeon at free.fr (Samuel Gougeon)
Date: Tue, 15 Jan 2019 00:25:27 +0100
Subject: [Scilab-Dev] &&, ||, {} as cell-builder not overloadable: official?
Message-ID: <b837759a-3b4e-f013-7303-e9ca389d1ef1@free.fr>

Hello,

Could we have the confirmation that the new Scilab 6 operators &&, ||, 
and {} heterogeneous concatenator are not currently overloadable?
Is this their official stable status (=> creating some first official 
exceptions), or should it be considered as bugs to be reported?

Thanks
Samuel



From antoine.elias at scilab-enterprises.com  Tue Jan 15 09:53:31 2019
From: antoine.elias at scilab-enterprises.com (Antoine ELIAS)
Date: Tue, 15 Jan 2019 09:53:31 +0100
Subject: [Scilab-Dev] varn([]) changed
In-Reply-To: <0c7c011b-e48a-1a72-1029-db0bacfb0b12@free.fr>
References: <0c7c011b-e48a-1a72-1029-db0bacfb0b12@free.fr>
Message-ID: <0511d8b9-7db0-4333-de0f-fba5cf7e5e1c@scilab-enterprises.com>

Hello Samuel,

No, it is not intentional, I will take a look to that today.

Antoine.
Le 14/01/2019 ? 23:22, Samuel Gougeon a ?crit?:
> Hello,
>
> I was noting that varn([]) changed from Scilab 5 to Scilab 6:
>
> 5.5.2:
> -->varn([])
> ???????? !--error 246
> Function not defined for given argument type(s),
> ? check arguments or define function %s_varn for overloading.
>
> 6.0.1:
> --> varn([])
> ?ans? =
> ??? []
>
> This is hard-coded, not in any %s_varn().
>
> This change is not yet documented. I would like to have confirmation 
> that it is intentional.
>
> Thanks
> Samuel
>
>
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/dev


From antoine.elias at scilab-enterprises.com  Tue Jan 15 10:12:40 2019
From: antoine.elias at scilab-enterprises.com (Antoine ELIAS)
Date: Tue, 15 Jan 2019 10:12:40 +0100
Subject: [Scilab-Dev] Are genlib() changes intentional? Documenting them
 makes them official
In-Reply-To: <e23e1ce4-de9a-7b76-10e1-561a6f935016@free.fr>
References: <e23e1ce4-de9a-7b76-10e1-561a6f935016@free.fr>
Message-ID: <dadadfbe-0563-c3a8-48bb-3dacd466e164@scilab-enterprises.com>

Hello Samuel,
1. It's intentional, when a function is private, it must stay private.
2. Need time to read threads and understand the problem.
3.It is a bug ! Someone forgot to read documentation before coding ! ( 
probably me ^^ )

Antoine

Le 14/01/2019 ? 23:58, Samuel Gougeon a ?crit?:

> Hello devs,
>
> After having done it for lib() (already in a somewhat awkward way), i 
> would like to update the documentation for libraries and genlib() 
> pages for Scilab 6, as fairly requested there 
> <http://bugzilla.scilab.org/show_bug.cgi?id=14098>.
> However, there is no indication whether observable changes are 
> intentional or should be considered as bugs.
> Now, documenting things make them official. Therefore, the status of 
> changes should be made clearer by their authors.
>
>  1. In a .sci file, functions that are defined after the main one are
>     now private, no longer registered in the library.
>     There were some discussions about this new feature, early after
>     the first Scilab 6.0.0-alpha and beta releases.
>     I think that we can consider this point as a new great official
>     feature now.
>
>  2. genlib() no longer allows to build a library including some
>     symbols other than functions.
>     This change could be a consequence of the first chaneg presented
>     here-above.
>     A bugzilla report could be posted about this topic, that was
>     somewhat presented in this thread
>     <http://mailinglists.scilab.org/Scilab-users-Clone-a-function-continued-tp4037723p4037728.html>.
>     This point is problematic for some toolboxes.
>     IMO, the problem is that there is no workaround.
>     One smart way to do the same maybe in an even smarter way would be
>     to be able to protect variables one by one.
>     Then, doing so would be possible in the .start file of a module.
>     Indeed, this genlib feature was interesting mainly -- or even only
>     ? -- as a workaround of the unability to protect variables.
>     Now, when will it be possible to protect variables on the fly in
>     the session with Scilab 6?...
>
>  3. genlib() is no longer able to exclude any *.sci files of the
>     current directory to not be compiled. This is reported there
>     <http://bugzilla.scilab.org/show_bug.cgi?id=15919>. To me, if this
>     change is intentional, it is debatable...
>
> Looking forward to reading you
>
> Samuel
>
> PS: IMO it would be better to document as many Scilab 5 => Scilab 6.0 
> changes as possible *before* Scilab 6.1.0
>
>
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20190115/31bc2e3c/attachment.htm>

From sgougeon at free.fr  Tue Jan 15 10:29:49 2019
From: sgougeon at free.fr (Samuel Gougeon)
Date: Tue, 15 Jan 2019 10:29:49 +0100
Subject: [Scilab-Dev] varn([]) changed
In-Reply-To: <0511d8b9-7db0-4333-de0f-fba5cf7e5e1c@scilab-enterprises.com>
References: <0c7c011b-e48a-1a72-1029-db0bacfb0b12@free.fr>
 <0511d8b9-7db0-4333-de0f-fba5cf7e5e1c@scilab-enterprises.com>
Message-ID: <cc1a7715-4d31-0a7e-5682-b1adbc01a74a@free.fr>

Hello Antoine,

Le 15/01/2019 ? 09:53, Antoine ELIAS a ?crit :
> Hello Samuel,
>
> No, it is not intentional, I will take a look to that today.

IMO, this is not necessarilly a bad change. Please also consider that 
remark <http://bugzilla.scilab.org/show_bug.cgi?id=11077#c8> about 
applicability of varn() to empty rlist().

Thanks
Samuel

>
> Antoine.
> Le 14/01/2019 ? 23:22, Samuel Gougeon a ?crit :
>> Hello,
>>
>> I was noting that varn([]) changed from Scilab 5 to Scilab 6:
>>
>> 5.5.2:
>> -->varn([])
>>          !--error 246
>> Function not defined for given argument type(s),
>>   check arguments or define function %s_varn for overloading.
>>
>> 6.0.1:
>> --> varn([])
>>  ans  =
>>     []
>>
>> This is hard-coded, not in any %s_varn().
>>
>> This change is not yet documented. I would like to have confirmation 
>> that it is intentional.
>>
>> Thanks
>> Samuel 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20190115/cd7a704e/attachment.htm>

From antoine.elias at scilab-enterprises.com  Tue Jan 15 10:47:47 2019
From: antoine.elias at scilab-enterprises.com (Antoine ELIAS)
Date: Tue, 15 Jan 2019 10:47:47 +0100
Subject: [Scilab-Dev] &&, ||,
 {} as cell-builder not overloadable: official?
In-Reply-To: <b837759a-3b4e-f013-7303-e9ca389d1ef1@free.fr>
References: <b837759a-3b4e-f013-7303-e9ca389d1ef1@free.fr>
Message-ID: <c861d281-0a81-4b82-2f04-cd7cf39ad17c@scilab-enterprises.com>

Hello Samuel,

You are right, there is no overload for these new operators.
for || and &&, it seems to be OK, we can create new overloads like 
%x_gg_x ( || ) and %_hh_x ( && ) for example.

but for {} it would be difficult, cell creation accepts ALL types so how 
to detect and call overloads ?

Antoine
Le 15/01/2019 ? 00:25, Samuel Gougeon a ?crit?:
> Hello,
>
> Could we have the confirmation that the new Scilab 6 operators &&, ||, 
> and {} heterogeneous concatenator are not currently overloadable?
> Is this their official stable status (=> creating some first official 
> exceptions), or should it be considered as bugs to be reported?
>
> Thanks
> Samuel
>
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/dev


From antoine.elias at scilab-enterprises.com  Tue Jan 15 11:06:32 2019
From: antoine.elias at scilab-enterprises.com (Antoine ELIAS)
Date: Tue, 15 Jan 2019 11:06:32 +0100
Subject: [Scilab-Dev] varn([]) changed
In-Reply-To: <cc1a7715-4d31-0a7e-5682-b1adbc01a74a@free.fr>
References: <0c7c011b-e48a-1a72-1029-db0bacfb0b12@free.fr>
 <0511d8b9-7db0-4333-de0f-fba5cf7e5e1c@scilab-enterprises.com>
 <cc1a7715-4d31-0a7e-5682-b1adbc01a74a@free.fr>
Message-ID: <5a96f936-7450-f8bd-b03f-9307ebac90c7@scilab-enterprises.com>

I'm not sure that empty rlist is properly managed in Scilab

try
a = rlist() //without ;

and overload "%r_varn" tries to access to internal fields that does not 
exist.
I think the trouble comes from rlist function.

Antoine
Le 15/01/2019 ? 10:29, Samuel Gougeon a ?crit?:
> Hello Antoine,
>
> Le 15/01/2019 ? 09:53, Antoine ELIAS a ?crit?:
>> Hello Samuel,
>>
>> No, it is not intentional, I will take a look to that today.
>
> IMO, this is not necessarilly a bad change. Please also consider that 
> remark <http://bugzilla.scilab.org/show_bug.cgi?id=11077#c8> about 
> applicability of varn() to empty rlist().
>
> Thanks
> Samuel
>
>>
>> Antoine.
>> Le 14/01/2019 ? 23:22, Samuel Gougeon a ?crit?:
>>> Hello,
>>>
>>> I was noting that varn([]) changed from Scilab 5 to Scilab 6:
>>>
>>> 5.5.2:
>>> -->varn([])
>>> ???????? !--error 246
>>> Function not defined for given argument type(s),
>>> ? check arguments or define function %s_varn for overloading.
>>>
>>> 6.0.1:
>>> --> varn([])
>>> ?ans? =
>>> ??? []
>>>
>>> This is hard-coded, not in any %s_varn().
>>>
>>> This change is not yet documented. I would like to have confirmation 
>>> that it is intentional.
>>>
>>> Thanks
>>> Samuel 
>
>
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20190115/eefd3ed0/attachment.htm>

From sgougeon at free.fr  Tue Jan 15 11:31:57 2019
From: sgougeon at free.fr (Samuel Gougeon)
Date: Tue, 15 Jan 2019 11:31:57 +0100
Subject: [Scilab-Dev] varn([]) changed
In-Reply-To: <5a96f936-7450-f8bd-b03f-9307ebac90c7@scilab-enterprises.com>
References: <0c7c011b-e48a-1a72-1029-db0bacfb0b12@free.fr>
 <0511d8b9-7db0-4333-de0f-fba5cf7e5e1c@scilab-enterprises.com>
 <cc1a7715-4d31-0a7e-5682-b1adbc01a74a@free.fr>
 <5a96f936-7450-f8bd-b03f-9307ebac90c7@scilab-enterprises.com>
Message-ID: <be3e9183-7caa-7373-3166-5393fafe4fff@free.fr>

Le 15/01/2019 ? 11:06, Antoine ELIAS a ?crit :
> I'm not sure that empty rlist is properly managed in Scilab
>
> try
> a = rlist() //without ;
>
> and overload "%r_varn" tries to access to internal fields that does 
> not exist.
> I think the trouble comes from rlist function.

Yes, this is why forbidding rlist() and setting rlist([],[]) to [] is 
somewhat proposed
@ http://bugzilla.scilab.org/show_bug.cgi?id=11077#c8
Then, in order to avoid useless errors, the new implementation varn([]) 
=> []
is rather handy. I don't see any trap that it could yield.

Other users inputs are welcome.



From sgougeon at free.fr  Tue Jan 15 11:41:21 2019
From: sgougeon at free.fr (Samuel Gougeon)
Date: Tue, 15 Jan 2019 11:41:21 +0100
Subject: [Scilab-Dev] &&, ||,
 {} as cell-builder not overloadable: official?
In-Reply-To: <c861d281-0a81-4b82-2f04-cd7cf39ad17c@scilab-enterprises.com>
References: <b837759a-3b4e-f013-7303-e9ca389d1ef1@free.fr>
 <c861d281-0a81-4b82-2f04-cd7cf39ad17c@scilab-enterprises.com>
Message-ID: <631f51b7-d409-25f5-4fbe-326f88b58391@free.fr>

Le 15/01/2019 ? 10:47, Antoine ELIAS a ?crit :
> Hello Samuel,
>
> You are right, there is no overload for these new operators.
> for || and &&, it seems to be OK, we can create new overloads like 
> %x_gg_x ( || ) and %_hh_x ( && ) for example.
>
> but for {} it would be difficult, cell creation accepts ALL types so 
> how to detect and call overloads ?

You are right. This concatenator can't be overloaded. Let's document it 
in its forthcoming page.

Do you think that overloading for || and && could be ready for Scilab 
6.0.2, to make Scilab 6.0 regular?



From sgougeon at free.fr  Wed Jan 16 00:11:23 2019
From: sgougeon at free.fr (Samuel Gougeon)
Date: Wed, 16 Jan 2019 00:11:23 +0100
Subject: [Scilab-Dev] A && B is considered as A & B for unsupported A types
Message-ID: <2c1383c7-e62b-8dff-f50d-2e6c2e1a444c@free.fr>

Hello,

Another approach to tackle overloading of the new && and || operators:

With Scilab 6.0.2, we currently get:

--> %z && 2
Undefined operation for the given operands.
check or define function %p_h_s for overloading.

--> %z & 2
Undefined operation for the given operands.
check or define function %p_h_s for overloading.

Why both operators address the same _h_ overload of & !?

This is a puzzling behavior.
IMO it would be clearer to display a message about its true status:

--> %z && 2
Undefined operation for the given operands.
&& overloading not supported.

Unless && overloading becomes actually supported.
Otherwise, identifying && to & is a dark feature.

On one hand, Scilab 6 removes the duplicate {} as [].
On the other hand, leaving this && / & partial equivalence would 
introduce a partial conditional duplicate.
This looks not very clean.

Thanks
Samuel



From antoine.elias at scilab-enterprises.com  Wed Jan 16 13:39:29 2019
From: antoine.elias at scilab-enterprises.com (Antoine ELIAS)
Date: Wed, 16 Jan 2019 13:39:29 +0100
Subject: [Scilab-Dev] A && B is considered as A & B for unsupported A
 types
In-Reply-To: <2c1383c7-e62b-8dff-f50d-2e6c2e1a444c@free.fr>
References: <2c1383c7-e62b-8dff-f50d-2e6c2e1a444c@free.fr>
Message-ID: <72122c07-16ae-ad41-bfd0-ff3357e32a30@scilab-enterprises.com>

I'm agree to explicitly show that we do not support overload for && and ||.

But I'm not understand the second part about {} and [].
Can you explain it ?

Antoine
Le 16/01/2019 ? 00:11, Samuel Gougeon a ?crit?:
> Hello,
>
> Another approach to tackle overloading of the new && and || operators:
>
> With Scilab 6.0.2, we currently get:
>
> --> %z && 2
> Undefined operation for the given operands.
> check or define function %p_h_s for overloading.
>
> --> %z & 2
> Undefined operation for the given operands.
> check or define function %p_h_s for overloading.
>
> Why both operators address the same _h_ overload of & !?
>
> This is a puzzling behavior.
> IMO it would be clearer to display a message about its true status:
>
> --> %z && 2
> Undefined operation for the given operands.
> && overloading not supported.
>
> Unless && overloading becomes actually supported.
> Otherwise, identifying && to & is a dark feature.
>
> On one hand, Scilab 6 removes the duplicate {} as [].
> On the other hand, leaving this && / & partial equivalence would 
> introduce a partial conditional duplicate.
> This looks not very clean.
>
> Thanks
> Samuel
>
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/dev



From sgougeon at free.fr  Wed Jan 16 22:36:34 2019
From: sgougeon at free.fr (Samuel Gougeon)
Date: Wed, 16 Jan 2019 22:36:34 +0100
Subject: [Scilab-Dev] A && B is considered as A & B for unsupported A
 types
In-Reply-To: <72122c07-16ae-ad41-bfd0-ff3357e32a30@scilab-enterprises.com>
References: <2c1383c7-e62b-8dff-f50d-2e6c2e1a444c@free.fr>
 <72122c07-16ae-ad41-bfd0-ff3357e32a30@scilab-enterprises.com>
Message-ID: <8314de1d-acd1-df87-e975-3e46b307107c@free.fr>

Le 16/01/2019 ? 13:39, Antoine ELIAS a ?crit :
> I'm agree to explicitly show that we do not support overload for && 
> and ||.
>
> But I'm not understand the second part about {} and [].
> Can you explain it ?

It was just meaning that, after doing a step forward to a clarified 
Scilab 6 by removing a duplicate operator,
it is a pity and like a step backward when introducing an unclear 
overloadability status for the new && and || operators...



From sgougeon at free.fr  Wed Jan 16 22:49:50 2019
From: sgougeon at free.fr (Samuel Gougeon)
Date: Wed, 16 Jan 2019 22:49:50 +0100
Subject: [Scilab-Dev] empty sparse: sparse([]) vs sparse([],[],[0 0])
Message-ID: <557f0345-cde9-8cd3-29f6-4adfc73706c6@free.fr>

Hello,

In Scilab 5.5 and up to Scilab 6.0.1, there was no empty sparse. Trying 
to build it yielded [] :

--> sparse([])
  ans  =
      []
--> sparse([],[],[0 0])
  ans  =
      []

However, in the 6.0 branch, the second statement now creates an empty 
sparse:

--> sparse([],[],[0 0])
  ans  =
(  0,  0) zero sparse matrix

while we still have

--> sparse([])
  ans  =
      []

I am wondering if this change is intentional, because it does not look 
documented.
I am not really able to assess the impact of this change.
I have the feeling that it's rather useful to be able to have an empty 
sparse. This enables the fact that, from a sparse, deletions -- possibly 
down to empty -- and then further insertions can be done without loosing 
the sparse encoding.
However, i think that, if this is kept for Scilab 6.0.2, then still 
getting [] out of sparse([]) instead of getting the empty sparse becomes 
rather inconsistent and should be changed as well.

Looking forward to reading you about this topic

Samuel





From stephane.mottelet at utc.fr  Thu Jan 17 08:37:14 2019
From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=)
Date: Thu, 17 Jan 2019 08:37:14 +0100
Subject: [Scilab-Dev] empty sparse: sparse([]) vs sparse([],[],[0 0])
In-Reply-To: <557f0345-cde9-8cd3-29f6-4adfc73706c6@free.fr>
References: <557f0345-cde9-8cd3-29f6-4adfc73706c6@free.fr>
Message-ID: <244f9d7a-cf97-f654-3513-6684c2efaa62@utc.fr>

Hello Samuel,

I have initially voted for this behavior (sparse([]) == (? 0,? 0) zero 
sparse matrix ) but your remark on numerous occurences of "sparse([])" 
in scilab prevented to do so.

Please see https://codereview.scilab.org/#/c/20492/ and the discussion 
starting at Patch Set 8.

S.

Le 16/01/2019 ? 22:49, Samuel Gougeon a ?crit?:
> Hello,
>
> In Scilab 5.5 and up to Scilab 6.0.1, there was no empty sparse. 
> Trying to build it yielded [] :
>
> --> sparse([])
> ?ans? =
> ???? []
> --> sparse([],[],[0 0])
> ?ans? =
> ???? []
>
> However, in the 6.0 branch, the second statement now creates an empty 
> sparse:
>
> --> sparse([],[],[0 0])
> ?ans? =
> (? 0,? 0) zero sparse matrix
>
> while we still have
>
> --> sparse([])
> ?ans? =
> ???? []
>
> I am wondering if this change is intentional, because it does not look 
> documented.
> I am not really able to assess the impact of this change.
> I have the feeling that it's rather useful to be able to have an empty 
> sparse. This enables the fact that, from a sparse, deletions -- 
> possibly down to empty -- and then further insertions can be done 
> without loosing the sparse encoding.
> However, i think that, if this is kept for Scilab 6.0.2, then still 
> getting [] out of sparse([]) instead of getting the empty sparse 
> becomes rather inconsistent and should be changed as well.
>
> Looking forward to reading you about this topic
>
> Samuel
>
>
>
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev 
>


From sgougeon at free.fr  Tue Jan 22 16:25:10 2019
From: sgougeon at free.fr (Samuel Gougeon)
Date: Tue, 22 Jan 2019 16:25:10 +0100
Subject: [Scilab-Dev] empty sparse: sparse([]) vs sparse([],[],[0 0])
In-Reply-To: <244f9d7a-cf97-f654-3513-6684c2efaa62@utc.fr>
References: <557f0345-cde9-8cd3-29f6-4adfc73706c6@free.fr>
 <244f9d7a-cf97-f654-3513-6684c2efaa62@utc.fr>
Message-ID: <922fed48-f7af-2d09-e468-e198310ba0af@free.fr>

Hello St?phane,

Le 17/01/2019 ? 08:37, St?phane Mottelet a ?crit :
> Hello Samuel,
>
> I have initially voted for this behavior (sparse([]) == (  0,  0) zero 
> sparse matrix ) but your remark on numerous occurences of "sparse([])" 
> in scilab prevented to do so.

Why? My remark aimed to bring the attention to existing occurrences and 
to prevent merging the commit without updating them, not to prevent 
updating them.
Then these occurrences changed your opinion and vote, not mine.

Best regards
Samuel

>
> Please see https://codereview.scilab.org/#/c/20492/ and the discussion 
> starting at Patch Set 8.
>
> S. 



From stephane.mottelet at utc.fr  Tue Jan 22 16:34:52 2019
From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=)
Date: Tue, 22 Jan 2019 16:34:52 +0100
Subject: [Scilab-Dev] empty sparse: sparse([]) vs sparse([],[],[0 0])
In-Reply-To: <922fed48-f7af-2d09-e468-e198310ba0af@free.fr>
References: <557f0345-cde9-8cd3-29f6-4adfc73706c6@free.fr>
 <244f9d7a-cf97-f654-3513-6684c2efaa62@utc.fr>
 <922fed48-f7af-2d09-e468-e198310ba0af@free.fr>
Message-ID: <9bfed43f-66ed-a93f-61cf-d2922fa0cd24@utc.fr>

Le 22/01/2019 ? 16:25, Samuel Gougeon a ?crit?:
> Hello St?phane,
>
> Le 17/01/2019 ? 08:37, St?phane Mottelet a ?crit :
>> Hello Samuel,
>>
>> I have initially voted for this behavior (sparse([]) == (? 0, 0) zero 
>> sparse matrix ) but your remark on numerous occurences of 
>> "sparse([])" in scilab prevented to do so.
>
> Why? My remark aimed to bring the attention to existing occurrences 
> and to prevent merging the commit without updating them, not to 
> prevent updating them.
> Then these occurrences changed your opinion and vote, not mine.
>
> Best regards
> Samuel

Please see comment #8:

Anyway, *as bug #15758 is not related to sparse([]) being not sparse*, 
and considered the numerous side effects, I will restore sparse([]) == 
double empty matrix. *If you find necessary to have sparse([]) == sparse 
empty matrix, please file a bug/whish on BZ.*

S.

>
>>
>> Please see 
>> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/codereview.scilab.org/#/c/20492/ 
>> and the discussion starting at Patch Set 8.
>>
>> S. 
>
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev 
>


-- 
St?phane Mottelet
Ing?nieur de recherche
EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable
D?partement G?nie des Proc?d?s Industriels
Sorbonne Universit?s - Universit? de Technologie de Compi?gne
CS 60319, 60203 Compi?gne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20190122/e27cc911/attachment.htm>

From sgougeon at free.fr  Tue Jan 22 17:06:00 2019
From: sgougeon at free.fr (Samuel Gougeon)
Date: Tue, 22 Jan 2019 17:06:00 +0100
Subject: [Scilab-Dev] empty sparse: sparse([]) vs sparse([],[],[0 0])
In-Reply-To: <9bfed43f-66ed-a93f-61cf-d2922fa0cd24@utc.fr>
References: <557f0345-cde9-8cd3-29f6-4adfc73706c6@free.fr>
 <244f9d7a-cf97-f654-3513-6684c2efaa62@utc.fr>
 <922fed48-f7af-2d09-e468-e198310ba0af@free.fr>
 <9bfed43f-66ed-a93f-61cf-d2922fa0cd24@utc.fr>
Message-ID: <8492f083-f5d0-c80f-ea79-1dd9d78baecd@free.fr>

Le 22/01/2019 ? 16:34, St?phane Mottelet a ?crit :
> Le 22/01/2019 ? 16:25, Samuel Gougeon a ?crit :
>> Hello St?phane,
>>
>> Le 17/01/2019 ? 08:37, St?phane Mottelet a ?crit :
>>> Hello Samuel,
>>>
>>> I have initially voted for this behavior (sparse([]) == (  0, 0) 
>>> zero sparse matrix ) but your remark on numerous occurences of 
>>> "sparse([])" in scilab prevented to do so.
>>
>> Why? My remark aimed to bring the attention to existing occurrences 
>> and to prevent merging the commit without updating them, not to 
>> prevent updating them.
>> Then these occurrences changed your opinion and vote, not mine.
>>
>> Best regards
>> Samuel
>
> Please see comment #8:
>
> Anyway, *as bug #15758 is not related to sparse([]) being not sparse*, 
> and considered the numerous side effects, I will restore sparse([]) == 
> double empty matrix. *If you find necessary to have sparse([]) == 
> sparse empty matrix, please file a bug/whish on BZ.*
>

Yes, and neither you -- that voted for it -- nor me did it.
And finally we agree: keeping sparse([])==[] was your decision.
Changing this could be done later if it proves to be better.
For the time being, the situation is the following:

*Scilab 6.0.1*:
--> sparse([])
  ans  =
     []

--> sparse([],[])
  ans  =
(  0,  0) zero sparse matrix

--> sparse([],[],[0,2])
  ans  =
     []

*Scilab 6.0.2-* after https://codereview.scilab.org/20492 :
--> sparse([])      // unchanged
  ans  =
     []

--> sparse([],[])   // unchanged
  ans  =
(  0,  0) zero sparse matrix

--> sparse([],[],[0,2])  // *CHANGED*
  ans  =
(  0,  0) zero sparse matrix

while i don't think that this last change is intentional.
This is what Antoine is pointing to, in https://codereview.scilab.org/20612.

Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20190122/d20d3df6/attachment.htm>

From stephane.mottelet at utc.fr  Tue Jan 22 17:40:34 2019
From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=)
Date: Tue, 22 Jan 2019 17:40:34 +0100
Subject: [Scilab-Dev] empty sparse: sparse([]) vs sparse([],[],[0 0])
In-Reply-To: <8492f083-f5d0-c80f-ea79-1dd9d78baecd@free.fr>
References: <557f0345-cde9-8cd3-29f6-4adfc73706c6@free.fr>
 <244f9d7a-cf97-f654-3513-6684c2efaa62@utc.fr>
 <922fed48-f7af-2d09-e468-e198310ba0af@free.fr>
 <9bfed43f-66ed-a93f-61cf-d2922fa0cd24@utc.fr>
 <8492f083-f5d0-c80f-ea79-1dd9d78baecd@free.fr>
Message-ID: <e1000819-ebb2-fd9a-eff3-156a6ebf3e43@utc.fr>

Le 22/01/2019 ? 17:06, Samuel Gougeon a ?crit?:
> Le 22/01/2019 ? 16:34, St?phane Mottelet a ?crit?:
>> Le 22/01/2019 ? 16:25, Samuel Gougeon a ?crit?:
>>> Hello St?phane,
>>>
>>> Le 17/01/2019 ? 08:37, St?phane Mottelet a ?crit :
>>>> Hello Samuel,
>>>>
>>>> I have initially voted for this behavior (sparse([]) == ( 0,? 0) 
>>>> zero sparse matrix ) but your remark on numerous occurences of 
>>>> "sparse([])" in scilab prevented to do so.
>>>
>>> Why? My remark aimed to bring the attention to existing occurrences 
>>> and to prevent merging the commit without updating them, not to 
>>> prevent updating them.
>>> Then these occurrences changed your opinion and vote, not mine.
>>>
>>> Best regards
>>> Samuel
>>
>> Please see comment #8:
>>
>> Anyway, *as bug #15758 is not related to sparse([]) being not 
>> sparse*, and considered the numerous side effects, I will restore 
>> sparse([]) == double empty matrix. *If you find necessary to have 
>> sparse([]) == sparse empty matrix, please file a bug/whish on BZ.*
>>
>
> Yes, and neither you -- that voted for it -- nor me did it.
> And finally we agree: keeping sparse([])==[] was your decision.
> Changing this could be done later if it proves to be better.
> For the time being, the situation is the following:
>
> *Scilab 6.0.1*:
> --> sparse([])
> ?ans? =
> ??? []
>
> --> sparse([],[])
> ?ans? =
> (? 0,? 0) zero sparse matrix
>
> --> sparse([],[],[0,2])
> ?ans? =
> ??? []
>
> *Scilab 6.0.2-* after https://codereview.scilab.org/20492 :
> --> sparse([])????? // unchanged
> ?ans? =
> ??? []
>
> --> sparse([],[])?? // unchanged
> ?ans? =
> (? 0,? 0) zero sparse matrix
>
> --> sparse([],[],[0,2])? // *CHANGED*
> ?ans? =
> (? 0,? 0) zero sparse matrix
>
> while i don't think that this last change is intentional.

it is. To me,

sparse([],[]) <=> sparse([],[],[0,0]) by getting dims implicitely 
defined in first two arguments (ij,v), so explicit size definition in 
sparse([],[],[2,0]) should give the same output (2x0 == empty matrix);

S.

> This is what Antoine is pointing to, in 
> https://codereview.scilab.org/20612.
>
> Samuel
>
>
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev


-- 
St?phane Mottelet
Ing?nieur de recherche
EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable
D?partement G?nie des Proc?d?s Industriels
Sorbonne Universit?s - Universit? de Technologie de Compi?gne
CS 60319, 60203 Compi?gne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20190122/c94d4dd4/attachment.htm>

From sgougeon at free.fr  Tue Jan 22 17:56:47 2019
From: sgougeon at free.fr (Samuel Gougeon)
Date: Tue, 22 Jan 2019 17:56:47 +0100
Subject: [Scilab-Dev] empty sparse: sparse([]) vs sparse([],[],[0 0])
In-Reply-To: <e1000819-ebb2-fd9a-eff3-156a6ebf3e43@utc.fr>
References: <557f0345-cde9-8cd3-29f6-4adfc73706c6@free.fr>
 <244f9d7a-cf97-f654-3513-6684c2efaa62@utc.fr>
 <922fed48-f7af-2d09-e468-e198310ba0af@free.fr>
 <9bfed43f-66ed-a93f-61cf-d2922fa0cd24@utc.fr>
 <8492f083-f5d0-c80f-ea79-1dd9d78baecd@free.fr>
 <e1000819-ebb2-fd9a-eff3-156a6ebf3e43@utc.fr>
Message-ID: <a05f47e0-447d-30f5-d676-06053b369ae8@free.fr>

Le 22/01/2019 ? 17:40, St?phane Mottelet a ?crit :
> Le 22/01/2019 ? 17:06, Samuel Gougeon a ?crit :
>> Le 22/01/2019 ? 16:34, St?phane Mottelet a ?crit :
>>> Le 22/01/2019 ? 16:25, Samuel Gougeon a ?crit :
>>>> Hello St?phane,
>>>>
>>>> Le 17/01/2019 ? 08:37, St?phane Mottelet a ?crit :
>>>>> Hello Samuel,
>>>>>
>>>>> I have initially voted for this behavior (sparse([]) == ( 0,  0) 
>>>>> zero sparse matrix ) but your remark on numerous occurences of 
>>>>> "sparse([])" in scilab prevented to do so.
>>>>
>>>> Why? My remark aimed to bring the attention to existing occurrences 
>>>> and to prevent merging the commit without updating them, not to 
>>>> prevent updating them.
>>>> Then these occurrences changed your opinion and vote, not mine.
>>>>
>>>> Best regards
>>>> Samuel
>>>
>>> Please see comment #8:
>>>
>>> Anyway, *as bug #15758 is not related to sparse([]) being not 
>>> sparse*, and considered the numerous side effects, I will restore 
>>> sparse([]) == double empty matrix. *If you find necessary to have 
>>> sparse([]) == sparse empty matrix, please file a bug/whish on BZ.*
>>>
>>
>> Yes, and neither you -- that voted for it -- nor me did it.
>> And finally we agree: keeping sparse([])==[] was your decision.
>> Changing this could be done later if it proves to be better.
>> For the time being, the situation is the following:
>>
>> *Scilab 6.0.1*:
>> --> sparse([])
>>  ans  =
>>     []
>>
>> --> sparse([],[])
>>  ans  =
>> (  0,  0) zero sparse matrix
>>
>> --> sparse([],[],[0,2])
>>  ans  =
>>     []
>>
>> *Scilab 6.0.2-* after https://codereview.scilab.org/20492 :
>> --> sparse([])      // unchanged
>>  ans  =
>>     []
>>
>> --> sparse([],[])   // unchanged
>>  ans  =
>> (  0,  0) zero sparse matrix
>>
>> --> sparse([],[],[0,2])  // *CHANGED*
>>  ans  =
>> (  0,  0) zero sparse matrix
>>
>> while i don't think that this last change is intentional.
>
> it is. To me,
>
> sparse([],[]) <=> sparse([],[],[0,0]) by getting dims implicitely 
> defined in first two arguments (ij,v), so explicit size definition in 
> sparse([],[],[2,0]) should give the same output
>

Yes

> (2x0 == empty matrix);
>

No. Since both other syntaxes yielded [], [] should be returned. What 
would make a consistent answer for *all* empty inputs.

Samuel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20190122/a9491641/attachment.htm>

From sgougeon at free.fr  Tue Jan 22 17:58:57 2019
From: sgougeon at free.fr (Samuel Gougeon)
Date: Tue, 22 Jan 2019 17:58:57 +0100
Subject: [Scilab-Dev] empty sparse: sparse([]) vs sparse([],[],[0 0])
In-Reply-To: <a05f47e0-447d-30f5-d676-06053b369ae8@free.fr>
References: <557f0345-cde9-8cd3-29f6-4adfc73706c6@free.fr>
 <244f9d7a-cf97-f654-3513-6684c2efaa62@utc.fr>
 <922fed48-f7af-2d09-e468-e198310ba0af@free.fr>
 <9bfed43f-66ed-a93f-61cf-d2922fa0cd24@utc.fr>
 <8492f083-f5d0-c80f-ea79-1dd9d78baecd@free.fr>
 <e1000819-ebb2-fd9a-eff3-156a6ebf3e43@utc.fr>
 <a05f47e0-447d-30f5-d676-06053b369ae8@free.fr>
Message-ID: <c02f5673-ed38-9dec-b3f6-b14366d4e23b@free.fr>

Le 22/01/2019 ? 17:56, Samuel Gougeon a ?crit :
> Le 22/01/2019 ? 17:40, St?phane Mottelet a ?crit :
>> Le 22/01/2019 ? 17:06, Samuel Gougeon a ?crit :
>>> Le 22/01/2019 ? 16:34, St?phane Mottelet a ?crit :
>>>> Le 22/01/2019 ? 16:25, Samuel Gougeon a ?crit :
>>>>> Hello St?phane,
>>>>>
>>>>> Le 17/01/2019 ? 08:37, St?phane Mottelet a ?crit :
>>>>>> Hello Samuel,
>>>>>>
>>>>>> I have initially voted for this behavior (sparse([]) == (  0,  0) 
>>>>>> zero sparse matrix ) but your remark on numerous occurences of 
>>>>>> "sparse([])" in scilab prevented to do so.
>>>>>
>>>>> Why? My remark aimed to bring the attention to existing 
>>>>> occurrences and to prevent merging the commit without updating 
>>>>> them, not to prevent updating them.
>>>>> Then these occurrences changed your opinion and vote, not mine.
>>>>>
>>>>> Best regards
>>>>> Samuel
>>>>
>>>> Please see comment #8:
>>>>
>>>> Anyway, *as bug #15758 is not related to sparse([]) being not 
>>>> sparse*, and considered the numerous side effects, I will restore 
>>>> sparse([]) == double empty matrix. *If you find necessary to have 
>>>> sparse([]) == sparse empty matrix, please file a bug/whish on BZ.*
>>>>
>>>
>>> Yes, and neither you -- that voted for it -- nor me did it.
>>> And finally we agree: keeping sparse([])==[] was your decision.
>>> Changing this could be done later if it proves to be better.
>>> For the time being, the situation is the following:
>>>
>>> *Scilab 6.0.1*:
>>> --> sparse([])
>>>  ans  =
>>>     []
>>>
>>> --> sparse([],[])
>>>  ans  =
>>> (  0,  0) zero sparse matrix
>>>
>>> --> sparse([],[],[0,2])
>>>  ans  =
>>>     []
>>>
>>> *Scilab 6.0.2-* after https://codereview.scilab.org/20492 :
>>> --> sparse([])      // unchanged
>>>  ans  =
>>>     []
>>>
>>> --> sparse([],[])   // unchanged
>>>  ans  =
>>> (  0,  0) zero sparse matrix
>>>
>>> --> sparse([],[],[0,2])  // *CHANGED*
>>>  ans  =
>>> (  0,  0) zero sparse matrix
>>>
>>> while i don't think that this last change is intentional.
>>
>> it is. To me,
>>
>> sparse([],[]) <=> sparse([],[],[0,0]) by getting dims implicitely 
>> defined in first two arguments (ij,v), so explicit size definition in 
>> sparse([],[],[2,0]) should give the same output
>>
>
> Yes
>
>> (2x0 == empty matrix);
>>
>
> No. Since both other syntaxes yielded [], [] should be returned. What 
> would make a consistent answer for *all* empty inputs.

I mean: Changing

--> sparse([],[])
  ans  =
(  0,  0) zero sparse matrix

into

--> sparse([],[])
  ans  =
    []

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20190122/4ca8e5be/attachment.htm>

From stephane.mottelet at utc.fr  Tue Jan 22 18:06:12 2019
From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=)
Date: Tue, 22 Jan 2019 18:06:12 +0100
Subject: [Scilab-Dev] empty sparse: sparse([]) vs sparse([],[],[0 0])
In-Reply-To: <c02f5673-ed38-9dec-b3f6-b14366d4e23b@free.fr>
References: <557f0345-cde9-8cd3-29f6-4adfc73706c6@free.fr>
 <244f9d7a-cf97-f654-3513-6684c2efaa62@utc.fr>
 <922fed48-f7af-2d09-e468-e198310ba0af@free.fr>
 <9bfed43f-66ed-a93f-61cf-d2922fa0cd24@utc.fr>
 <8492f083-f5d0-c80f-ea79-1dd9d78baecd@free.fr>
 <e1000819-ebb2-fd9a-eff3-156a6ebf3e43@utc.fr>
 <a05f47e0-447d-30f5-d676-06053b369ae8@free.fr>
 <c02f5673-ed38-9dec-b3f6-b14366d4e23b@free.fr>
Message-ID: <7c116f7c-b003-7279-fc13-318cd6642a63@utc.fr>

Le 22/01/2019 ? 17:58, Samuel Gougeon a ?crit?:
> Le 22/01/2019 ? 17:56, Samuel Gougeon a ?crit?:
>> Le 22/01/2019 ? 17:40, St?phane Mottelet a ?crit?:
>>> Le 22/01/2019 ? 17:06, Samuel Gougeon a ?crit?:
>>>> Le 22/01/2019 ? 16:34, St?phane Mottelet a ?crit?:
>>>>> Le 22/01/2019 ? 16:25, Samuel Gougeon a ?crit?:
>>>>>> Hello St?phane,
>>>>>>
>>>>>> Le 17/01/2019 ? 08:37, St?phane Mottelet a ?crit :
>>>>>>> Hello Samuel,
>>>>>>>
>>>>>>> I have initially voted for this behavior (sparse([]) == (? 0,? 
>>>>>>> 0) zero sparse matrix ) but your remark on numerous occurences 
>>>>>>> of "sparse([])" in scilab prevented to do so.
>>>>>>
>>>>>> Why? My remark aimed to bring the attention to existing 
>>>>>> occurrences and to prevent merging the commit without updating 
>>>>>> them, not to prevent updating them.
>>>>>> Then these occurrences changed your opinion and vote, not mine.
>>>>>>
>>>>>> Best regards
>>>>>> Samuel
>>>>>
>>>>> Please see comment #8:
>>>>>
>>>>> Anyway, *as bug #15758 is not related to sparse([]) being not 
>>>>> sparse*, and considered the numerous side effects, I will restore 
>>>>> sparse([]) == double empty matrix. *If you find necessary to have 
>>>>> sparse([]) == sparse empty matrix, please file a bug/whish on BZ.*
>>>>>
>>>>
>>>> Yes, and neither you -- that voted for it -- nor me did it.
>>>> And finally we agree: keeping sparse([])==[] was your decision.
>>>> Changing this could be done later if it proves to be better.
>>>> For the time being, the situation is the following:
>>>>
>>>> *Scilab 6.0.1*:
>>>> --> sparse([])
>>>> ?ans? =
>>>> ??? []
>>>>
>>>> --> sparse([],[])
>>>> ?ans? =
>>>> (? 0,? 0) zero sparse matrix
>>>>
>>>> --> sparse([],[],[0,2])
>>>> ?ans? =
>>>> ??? []
>>>>
>>>> *Scilab 6.0.2-* after https://codereview.scilab.org/20492 :
>>>> --> sparse([])????? // unchanged
>>>> ?ans? =
>>>> ??? []
>>>>
>>>> --> sparse([],[])?? // unchanged
>>>> ?ans? =
>>>> (? 0,? 0) zero sparse matrix
>>>>
>>>> --> sparse([],[],[0,2])? // *CHANGED*
>>>> ?ans? =
>>>> (? 0,? 0) zero sparse matrix
>>>>
>>>> while i don't think that this last change is intentional.
>>>
>>> it is. To me,
>>>
>>> sparse([],[]) <=> sparse([],[],[0,0]) by getting dims implicitely 
>>> defined in first two arguments (ij,v), so explicit size definition 
>>> in sparse([],[],[2,0]) should give the same output
>>>
>>
>> Yes
>>
>>> (2x0 == empty matrix);
>>>
>>
>> No. Since both other syntaxes yielded [], [] should be returned. What 
>> would make a consistent answer for *all* empty inputs.
>
> I mean: Changing
>
> --> sparse([],[])
> ?ans? =
> (? 0,? 0) zero sparse matrix
>
> into
>
> --> sparse([],[])
> ?ans? =
> ?? []

I do not agree. I will prepare a patch with sparse([]) == (0,0) zero 
sparse matrix for master and this time I will track all possible 
glitches. Every output of sparse(...), whatever the arguments, should be 
sparse, even if empty.

S.


>
>
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev


-- 
St?phane Mottelet
Ing?nieur de recherche
EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable
D?partement G?nie des Proc?d?s Industriels
Sorbonne Universit?s - Universit? de Technologie de Compi?gne
CS 60319, 60203 Compi?gne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20190122/ae3d29cb/attachment.htm>

From sgougeon at free.fr  Tue Jan 22 18:11:23 2019
From: sgougeon at free.fr (Samuel Gougeon)
Date: Tue, 22 Jan 2019 18:11:23 +0100
Subject: [Scilab-Dev] empty sparse: sparse([]) vs sparse([],[],[0 0])
In-Reply-To: <7c116f7c-b003-7279-fc13-318cd6642a63@utc.fr>
References: <557f0345-cde9-8cd3-29f6-4adfc73706c6@free.fr>
 <244f9d7a-cf97-f654-3513-6684c2efaa62@utc.fr>
 <922fed48-f7af-2d09-e468-e198310ba0af@free.fr>
 <9bfed43f-66ed-a93f-61cf-d2922fa0cd24@utc.fr>
 <8492f083-f5d0-c80f-ea79-1dd9d78baecd@free.fr>
 <e1000819-ebb2-fd9a-eff3-156a6ebf3e43@utc.fr>
 <a05f47e0-447d-30f5-d676-06053b369ae8@free.fr>
 <c02f5673-ed38-9dec-b3f6-b14366d4e23b@free.fr>
 <7c116f7c-b003-7279-fc13-318cd6642a63@utc.fr>
Message-ID: <ea075151-5439-3760-b23b-9a095a2207ab@free.fr>

Le 22/01/2019 ? 18:06, St?phane Mottelet a ?crit :
> Le 22/01/2019 ? 17:58, Samuel Gougeon a ?crit :
>> Le 22/01/2019 ? 17:56, Samuel Gougeon a ?crit :
>>> Le 22/01/2019 ? 17:40, St?phane Mottelet a ?crit :
>>>> Le 22/01/2019 ? 17:06, Samuel Gougeon a ?crit :
>>>>> Le 22/01/2019 ? 16:34, St?phane Mottelet a ?crit :
>>>>>> Le 22/01/2019 ? 16:25, Samuel Gougeon a ?crit :
>>>>>>> Hello St?phane,
>>>>>>>
>>>>>>> Le 17/01/2019 ? 08:37, St?phane Mottelet a ?crit :
>>>>>>>> Hello Samuel,
>>>>>>>>
>>>>>>>> I have initially voted for this behavior (sparse([]) == (  0,  
>>>>>>>> 0) zero sparse matrix ) but your remark on numerous occurences 
>>>>>>>> of "sparse([])" in scilab prevented to do so.
>>>>>>>
>>>>>>> Why? My remark aimed to bring the attention to existing 
>>>>>>> occurrences and to prevent merging the commit without updating 
>>>>>>> them, not to prevent updating them.
>>>>>>> Then these occurrences changed your opinion and vote, not mine.
>>>>>>>
>>>>>>> Best regards
>>>>>>> Samuel
>>>>>>
>>>>>> Please see comment #8:
>>>>>>
>>>>>> Anyway, *as bug #15758 is not related to sparse([]) being not 
>>>>>> sparse*, and considered the numerous side effects, I will restore 
>>>>>> sparse([]) == double empty matrix. *If you find necessary to have 
>>>>>> sparse([]) == sparse empty matrix, please file a bug/whish on BZ.*
>>>>>>
>>>>>
>>>>> Yes, and neither you -- that voted for it -- nor me did it.
>>>>> And finally we agree: keeping sparse([])==[] was your decision.
>>>>> Changing this could be done later if it proves to be better.
>>>>> For the time being, the situation is the following:
>>>>>
>>>>> *Scilab 6.0.1*:
>>>>> --> sparse([])
>>>>>  ans  =
>>>>>     []
>>>>>
>>>>> --> sparse([],[])
>>>>>  ans  =
>>>>> (  0,  0) zero sparse matrix
>>>>>
>>>>> --> sparse([],[],[0,2])
>>>>>  ans  =
>>>>>     []
>>>>>
>>>>> *Scilab 6.0.2-* after https://codereview.scilab.org/20492 :
>>>>> --> sparse([])      // unchanged
>>>>>  ans  =
>>>>>     []
>>>>>
>>>>> --> sparse([],[])   // unchanged
>>>>>  ans  =
>>>>> (  0,  0) zero sparse matrix
>>>>>
>>>>> --> sparse([],[],[0,2])  // *CHANGED*
>>>>>  ans  =
>>>>> (  0,  0) zero sparse matrix
>>>>>
>>>>> while i don't think that this last change is intentional.
>>>>
>>>> it is. To me,
>>>>
>>>> sparse([],[]) <=> sparse([],[],[0,0]) by getting dims implicitely 
>>>> defined in first two arguments (ij,v), so explicit size definition 
>>>> in sparse([],[],[2,0]) should give the same output
>>>>
>>>
>>> Yes
>>>
>>>> (2x0 == empty matrix);
>>>>
>>>
>>> No. Since both other syntaxes yielded [], [] should be returned. 
>>> What would make a consistent answer for *all* empty inputs.
>>
>> I mean: Changing
>>
>> --> sparse([],[])
>>  ans  =
>> (  0,  0) zero sparse matrix
>>
>> into
>>
>> --> sparse([],[])
>>  ans  =
>>    []
>
> I do not agree. I will prepare a patch with sparse([]) == (0,0) zero 
> sparse matrix for master and this time I will track all possible 
> glitches. Every output of sparse(...), whatever the arguments, should 
> be sparse, even if empty.
>

This was the missing intention.
Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20190122/760c57ac/attachment.htm>

From sgougeon at free.fr  Tue Jan 22 19:12:28 2019
From: sgougeon at free.fr (Samuel Gougeon)
Date: Tue, 22 Jan 2019 19:12:28 +0100
Subject: [Scilab-Dev] &&, ||,
 {} as cell-builder not overloadable: official?
In-Reply-To: <631f51b7-d409-25f5-4fbe-326f88b58391@free.fr>
References: <b837759a-3b4e-f013-7303-e9ca389d1ef1@free.fr>
 <c861d281-0a81-4b82-2f04-cd7cf39ad17c@scilab-enterprises.com>
 <631f51b7-d409-25f5-4fbe-326f88b58391@free.fr>
Message-ID: <79005fcb-fa3d-2fd3-ad85-5540a1384d74@free.fr>

Le 15/01/2019 ? 11:41, Samuel Gougeon a ?crit :
> Le 15/01/2019 ? 10:47, Antoine ELIAS a ?crit :
>> Hello Samuel,
>>
>> You are right, there is no overload for these new operators.
>> for || and &&, it seems to be OK, we can create new overloads like 
>> %x_gg_x ( || ) and %_hh_x ( && ) for example.
>>
>> but for {} it would be difficult, cell creation accepts ALL types so 
>> how to detect and call overloads ?
>
> You are right. This concatenator can't be overloaded. Let's document 
> it in its forthcoming page.
>
> Do you think that overloading for || and && could be ready for Scilab 
> 6.0.2, to make Scilab 6.0 regular?

Antoine,

After our discussion in private mails continuing this thread, i would 
like to go on about this topic.
For the short term, that's to say Scilab 6.0.2,  clarifying the 
not-overloadable status of && and ||
is a good thing. This is proposed here: https://codereview.scilab.org/20703

To abstract our private discussion:
My initial public question was about making these symbols overloadable 
as all other ones,
without any specific meaning or processing.
However, your were thinking about overloading them by keeping their 
"shortcircuit" property.
Finally, you told me that if this is not possible, and that just adding 
&& and || to the list of
overloadable symbols is not interesting and should not be done.

I don't really agree with this last point. Even if such a regularization 
is rather not a high priority,
it would be interesting anyway. Scilab 6.0 aimed to make Scilab more 
regular than Scilab<6.
I hope that this will hold as well for next 6.x releases, avoiding 
exceptions.

Keeping the "short-circuit" property for the overloads of && and || is 
not possible for two reasons:

  * As you noted, after a && b, the overload will need to receive b
    anyway. This requires that b is evaluated anyway before calling the
    overload.
  * The even stronger reason is that the criterion deciding if b must be
    evaluated  or not /is necessarily part of the overload/. So *a* must
    be sent to the overload, and since the overload won't be called
    another time to send b, b must be sent -- and so evaluated -- from
    the beginning, at the first call, even before deciding whether b is
    useful.

Not making the criterion about *a* part of the overload would mean that 
*a* is necessarily boolean. Then, the overload would stand only on b, 
and would be always named %b_hh_<btype>(a,b).
To me, this would be a too poor restricted implementation.

*The intention to keep the "shortcircuit" property should be abandoned*.
However, the overloading of both operators could be implemented in a 
special way, in order to diversify overloading possibilities.
How?
The overloading of all other binary operators is called according to the 
type of *both* left and right operands.
But for some custom operations, being able to call an overload for a op 
b _only according to the type of *a*_ would be interesting.
When developing in Scilab language, it is possible to meet situations 
where some very similar code is able to process *a op b* for various 
types of *b*.
Presently, the only way to do so is to replicate the code of say 
%ta_op_s in %ta_op_i, %ta_op_sp, %ta_op_i,  etc, or at least define them 
and route to the same %ta_op_s().
This is not very smart.

So, the special implementation that we could imagine would be to *call 
%typea_hh(a,b) only according to a's type*.

This would make && and || of fractional multiplicity 1.5.
This would not be a shortcircuit, but this is currently the best thing i 
may propose to you and users about this topic.
; -)

Hoping to read other contributions,

Regards
Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20190122/5e2b57c0/attachment.htm>

From sgougeon at free.fr  Tue Jan 22 19:24:40 2019
From: sgougeon at free.fr (Samuel Gougeon)
Date: Tue, 22 Jan 2019 19:24:40 +0100
Subject: [Scilab-Dev] &&, ||,
 {} as cell-builder not overloadable: official?
In-Reply-To: <79005fcb-fa3d-2fd3-ad85-5540a1384d74@free.fr>
References: <b837759a-3b4e-f013-7303-e9ca389d1ef1@free.fr>
 <c861d281-0a81-4b82-2f04-cd7cf39ad17c@scilab-enterprises.com>
 <631f51b7-d409-25f5-4fbe-326f88b58391@free.fr>
 <79005fcb-fa3d-2fd3-ad85-5540a1384d74@free.fr>
Message-ID: <d2f6fd35-1c37-f27b-e6b8-b5beebdd3629@free.fr>

Le 22/01/2019 ? 19:12, Samuel Gougeon a ?crit :
> Le 15/01/2019 ? 11:41, Samuel Gougeon a ?crit :
>> Le 15/01/2019 ? 10:47, Antoine ELIAS a ?crit :
>>> Hello Samuel,
>>>
>>> You are right, there is no overload for these new operators.
>>> for || and &&, it seems to be OK, we can create new overloads like 
>>> %x_gg_x ( || ) and %_hh_x ( && ) for example.
>>>
>>> but for {} it would be difficult, cell creation accepts ALL types so 
>>> how to detect and call overloads ?
>>
>> You are right. This concatenator can't be overloaded. Let's document 
>> it in its forthcoming page.
>>
>> Do you think that overloading for || and && could be ready for Scilab 
>> 6.0.2, to make Scilab 6.0 regular?
>
> Antoine,
>
> After our discussion in private mails continuing this thread, i would 
> like to go on about this topic.
> For the short term, that's to say Scilab 6.0.2,  clarifying the 
> not-overloadable status of && and ||
> is a good thing. This is proposed here: 
> https://codereview.scilab.org/20703
>
> To abstract our private discussion:
> My initial public question was about making these symbols overloadable 
> as all other ones,
> without any specific meaning or processing.
> However, your were thinking about overloading them by keeping their 
> "shortcircuit" property.
> Finally, you told me that if this is not possible, and that just 
> adding && and || to the list of
> overloadable symbols is not interesting and should not be done.
>
> I don't really agree with this last point. Even if such a 
> regularization is rather not a high priority,
> it would be interesting anyway. Scilab 6.0 aimed to make Scilab more 
> regular than Scilab<6.
> I hope that this will hold as well for next 6.x releases, avoiding 
> exceptions.
>
> Keeping the "short-circuit" property for the overloads of && and || is 
> not possible for two reasons:
>
>   * As you noted, after a && b, the overload will need to receive b
>     anyway. This requires that b is evaluated anyway before calling
>     the overload.
>   * The even stronger reason is that the criterion deciding if b must
>     be evaluated  or not /is necessarily part of the overload/. So *a*
>     must be sent to the overload, and since the overload won't be
>     called another time to send b, b must be sent -- and so evaluated
>     -- from the beginning, at the first call, even before deciding
>     whether b is useful.
>
> Not making the criterion about *a* part of the overload would mean 
> that *a* is necessarily boolean. Then, the overload would stand only 
> on b, and would be always named %b_hh_<btype>(a,b).
> To me, this would be a too poor restricted implementation.
>
> *The intention to keep the "shortcircuit" property should be abandoned*.
> However, the overloading of both operators could be implemented in a 
> special way, in order to diversify overloading possibilities.
> How?
> The overloading of all other binary operators is called according to 
> the type of *both* left and right operands.
> But for some custom operations, being able to call an overload for a 
> op b _only according to the type of *a*_ would be interesting.
> When developing in Scilab language, it is possible to meet situations 
> where some very similar code is able to process *a op b* for various 
> types of *b*.
> Presently, the only way to do so is to replicate the code of say 
> %ta_op_s in %ta_op_i, %ta_op_sp, %ta_op_i,  etc, or at least define 
> them and route to the same %ta_op_s().
> This is not very smart.
>
> So, the special implementation that we could imagine would be to *call 
> %typea_hh(a,b) only according to a's type*.
>
> This would make && and || of fractional multiplicity 1.5.
> This would not be a shortcircuit, but this is currently the best thing 
> i may propose to you and users about this topic.

To illustrate on a case that many of us have likely already met:
When a custom operator supports 5 distinct data types for both operands,
only 5 overloads/files would then have to be defined, instead of 5x5  = 
25 files...
The added value would be clear.

By the way, this kind of implementation could become generic, even for 
native operators:
if %typea_op_typeb() is not defined => test whether %typea_op(a,b) is 
defined, and call it if it's the case.

Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20190122/34a82d60/attachment.htm>

From antoine.elias at scilab-enterprises.com  Wed Jan 23 12:09:54 2019
From: antoine.elias at scilab-enterprises.com (Antoine ELIAS)
Date: Wed, 23 Jan 2019 12:09:54 +0100
Subject: [Scilab-Dev] &&, ||,
 {} as cell-builder not overloadable: official?
In-Reply-To: <79005fcb-fa3d-2fd3-ad85-5540a1384d74@free.fr>
References: <b837759a-3b4e-f013-7303-e9ca389d1ef1@free.fr>
 <c861d281-0a81-4b82-2f04-cd7cf39ad17c@scilab-enterprises.com>
 <631f51b7-d409-25f5-4fbe-326f88b58391@free.fr>
 <79005fcb-fa3d-2fd3-ad85-5540a1384d74@free.fr>
Message-ID: <ab7ee817-abf4-5eb1-9d50-3073ae08aae2@scilab-enterprises.com>

Hello Samuel,

You know my point of view:
 > *The intention to keep the "shortcircuit" property should be abandoned*.
Sorry I cannot be agree with that. *b* can be a non-idempotent 
code/function or a failing code ( isfield(st, "foo") && st.foo == x )
&& is often used to evaluate/execute or not "b".

*"b" should not be evaluated until we know the result of "a".
*If you don't care about short-circuit, use & or | instead of && or ||.


About generic version of overload %x_op(a, b), I guess that can be a 
good idea (in 6.1.0 ^^ ) but full version %t_op_t(a,b) must stay 
priority if exists.
That could reduce number of overloads that only reroute to 
%t_op_generic(a, b) for example.

Hoping to read other contributions too,
Antoine
Le 22/01/2019 ? 19:12, Samuel Gougeon a ?crit?:
> Le 15/01/2019 ? 11:41, Samuel Gougeon a ?crit?:
>> Le 15/01/2019 ? 10:47, Antoine ELIAS a ?crit :
>>> Hello Samuel,
>>>
>>> You are right, there is no overload for these new operators.
>>> for || and &&, it seems to be OK, we can create new overloads like 
>>> %x_gg_x ( || ) and %_hh_x ( && ) for example.
>>>
>>> but for {} it would be difficult, cell creation accepts ALL types so 
>>> how to detect and call overloads ?
>>
>> You are right. This concatenator can't be overloaded. Let's document 
>> it in its forthcoming page.
>>
>> Do you think that overloading for || and && could be ready for Scilab 
>> 6.0.2, to make Scilab 6.0 regular?
>
> Antoine,
>
> After our discussion in private mails continuing this thread, i would 
> like to go on about this topic.
> For the short term, that's to say Scilab 6.0.2,? clarifying the 
> not-overloadable status of && and ||
> is a good thing. This is proposed here: 
> https://codereview.scilab.org/20703
>
> To abstract our private discussion:
> My initial public question was about making these symbols overloadable 
> as all other ones,
> without any specific meaning or processing.
> However, your were thinking about overloading them by keeping their 
> "shortcircuit" property.
> Finally, you told me that if this is not possible, and that just 
> adding && and || to the list of
> overloadable symbols is not interesting and should not be done.
>
> I don't really agree with this last point. Even if such a 
> regularization is rather not a high priority,
> it would be interesting anyway. Scilab 6.0 aimed to make Scilab more 
> regular than Scilab<6.
> I hope that this will hold as well for next 6.x releases, avoiding 
> exceptions.
>
> Keeping the "short-circuit" property for the overloads of && and || is 
> not possible for two reasons:
>
>   * As you noted, after a && b, the overload will need to receive b
>     anyway. This requires that b is evaluated anyway before calling
>     the overload.
>   * The even stronger reason is that the criterion deciding if b must
>     be evaluated? or not /is necessarily part of the overload/. So *a*
>     must be sent to the overload, and since the overload won't be
>     called another time to send b, b must be sent -- and so evaluated
>     -- from the beginning, at the first call, even before deciding
>     whether b is useful.
>
> Not making the criterion about *a* part of the overload would mean 
> that *a* is necessarily boolean. Then, the overload would stand only 
> on b, and would be always named %b_hh_<btype>(a,b).
> To me, this would be a too poor restricted implementation.
>
> *The intention to keep the "shortcircuit" property should be abandoned*.
> However, the overloading of both operators could be implemented in a 
> special way, in order to diversify overloading possibilities.
> How?
> The overloading of all other binary operators is called according to 
> the type of *both* left and right operands.
> But for some custom operations, being able to call an overload for a 
> op b _only according to the type of *a*_ would be interesting.
> When developing in Scilab language, it is possible to meet situations 
> where some very similar code is able to process *a op b* for various 
> types of *b*.
> Presently, the only way to do so is to replicate the code of say 
> %ta_op_s in %ta_op_i, %ta_op_sp, %ta_op_i,? etc, or at least define 
> them and route to the same %ta_op_s().
> This is not very smart.
>
> So, the special implementation that we could imagine would be to *call 
> %typea_hh(a,b) only according to a's type*.
>
> This would make && and || of fractional multiplicity 1.5.
> This would not be a shortcircuit, but this is currently the best thing 
> i may propose to you and users about this topic.
> ; -)
>
> Hoping to read other contributions,
>
> Regards
> Samuel
>
>
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20190123/1c67cfa9/attachment.htm>

From sgougeon at free.fr  Fri Jan 25 15:50:08 2019
From: sgougeon at free.fr (Samuel Gougeon)
Date: Fri, 25 Jan 2019 15:50:08 +0100
Subject: [Scilab-Dev] test_run and crashes: how to avoid the modal "Close
 the program" window
Message-ID: <a07e50aa-b88d-b99d-10f9-48e48ecc1f4c@free.fr>

Hello,

While running test_run on a module, when a test makes the internal 
session crashing, sometimes a modal windows appears and asks to the user 
whether the program must be closed, or other options.

The issue is that this modal window stops the tests until the 
user/interactively/ answers.

This makes mandatory to stay around and monitor running tests.

Is there a way to avoid this modal window?

I guess that it is rather a Windows7-OS question, but any hint would be 
appreciated.

Thanks
Samuel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20190125/7725924f/attachment.htm>