From Clement.David at esi-group.com  Mon Jul  8 14:00:21 2019
From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=)
Date: Mon, 8 Jul 2019 12:00:21 +0000
Subject: [Scilab-Dev] Recursive extraction on a function's identifier
In-Reply-To: <38efbad5-9532-9aeb-7df8-2d15115f6750@free.fr>
References: <38efbad5-9532-9aeb-7df8-2d15115f6750@free.fr>
Message-ID: <DBBPR09MB31742BD35FDE3C64EE578F23B0F60@DBBPR09MB3174.eurprd09.prod.outlook.com>

Hello Samuel,

IMHO the function call without parenthesis `myfun` instead of `myfun()` notation is a function call helper handy for some functions and while playing with the REPL *but* using it inside macros or as real code is not a good idea for readability.

As a rationale, I always describe the `foo an argument` syntax is a handy way for listing files and is really a corner-case rewritten to `foo("an_argument")` before execution. Similarly I describe the dot operator as rewritten to a string extraction. 

Thanks,

--
Cl?ment

> -----Original Message-----
> From: dev <dev-bounces at lists.scilab.org> On Behalf Of Samuel Gougeon
> Sent: Tuesday, June 25, 2019 1:38 PM
> To: List dedicated to development questions <dev at lists.scilab.org>
> Subject: [Scilab-Dev] Recursive extraction on a function's identifier
> 
> Hello,
> 
> Let
> function s = myfun()
>    clear s
>    s.a = %pi
>    s.b = %z
> endfunction
> 
> 
> Presently, we get
> 
> 
> --> myfun.a
> Attempt to reference field of non-structure array.
> 
> --> myfun().a
>  ans  =
>    3.1415927
> 
> The type of the symbol myfun as a function is known when calling myfun.a, isn't
> it?
> 
> 
> So, is there a technical or a usage reason to not understand implicitly myfun.a as
> myfun().a ?
> As well, couldn't we expect an error message routing the user to defining
> %function_e() (unless Scilab provides a default definition) ?
> 
> 
> Thanks
> Samuel
> 
> 


From sylvain.corlay at gmail.com  Wed Jul 17 11:47:39 2019
From: sylvain.corlay at gmail.com (Sylvain Corlay)
Date: Wed, 17 Jul 2019 11:47:39 +0200
Subject: [Scilab-Dev] Summary of issues (and solutions) that occured while
 packaging Scilab for conda
Message-ID: <CAK=Phk7krRjT_-LWNP7_94fo7L1KW74p4tbCTnO7ShVVEPMHNQ@mail.gmail.com>

Hello Everyone,

I figured it may be useful to make a summary of the issues that I
encountered as I made a conda package for Scilab. The information already
exists in a couple of other threads but is scattered accross many messages.
Hopefully, the core team will be able to resolve some of these for the next
version of scilab.

*1) *Only scilab-cli was included in the conda package, and not the
graphical interface.

The reason is that scilab does not build with *openjdk* 11, and requires an
older version that has not been packaged for conda.

*2) *scilab does not build on OS X when using the *--without-matio* option.

The build ends with the following error:

ar: no archive members specified
usage:  ar -d [-TLsv] archive file ...
    ar -m [-TLsv] archive file ...
    ar -m [-abiTLsv] position archive file ...
    ar -p [-TLsv] archive [file ...]
    ar -q [-cTLsv] archive file ...
    ar -r [-cuTLsv] archive file ...
    ar -r [-abciuTLsv] position archive file ...
    ar -t [-TLsv] archive [file ...]
    ar -x [-ouTLsv] archive [file ...]
make[1]: *** [libscimatio-algo.la] Error 1


Fortunately, we were able to package matio for conda-forge as well, so this
error does not impact us anymore. However, I do think that we should be
able to use that option.

*3)* We cannot build headless scilab on OS X

It seems that we cannot build scilab with the *--without-gui *option on OS
X. The build fails over the symbol *_initMacOSXEnv* not being found.

Stephane Mottelet proposed to apply a patch to the generated makefile after
the configure stage to overcome that issue.

macmottelet-cr-0:scilab mottelet$ diff -Naur Makefile.orig Makefile
--- Makefile.orig    2019-04-01 11:55:47.000000000 +0200
+++ Makefile    2019-04-01 11:56:12.000000000 +0200
@@ -109,7 +109,7 @@
 POST_UNINSTALL = :
 build_triplet = x86_64-apple-darwin17.7.0
 host_triplet = x86_64-apple-darwin17.7.0
-bin_PROGRAMS = scilab-bin$(EXEEXT) scilab-cli-bin$(EXEEXT)
+bin_PROGRAMS = scilab-cli-bin$(EXEEXT)
 am__append_1 = bin/checkmacosx.applescript



This patch allows scilab-cli to build completely on OS X, but then scilab
fails to start at runtime (the conda recipe has a sanity check that we can
run the executable)

+_CONDA_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_x86_64_apple_darwin13_4_0
+ scilab-cli -version
dyld: Symbol not found: __ZN14CoverageModule4LoadEv

St?phane advised to use the *--enable-code-coverage=no* option which does
not solve the issue unfortunately.

Hopefuly, this summary will be useful for others.

Best,

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20190717/2a82e4bf/attachment.htm>

From sylvain.corlay at gmail.com  Wed Jul 17 11:51:44 2019
From: sylvain.corlay at gmail.com (Sylvain Corlay)
Date: Wed, 17 Jul 2019 11:51:44 +0200
Subject: [Scilab-Dev] setScilabOutputMethod - output vs error streams
In-Reply-To: <2288bb2d-f473-2928-a8a7-ea9e70190743@utc.fr>
References: <CAK=Phk4=KENv=3xgG6AbdZ7onyMg-hZjePY_Y=YdsN1jOv93gg@mail.gmail.com>
 <2288bb2d-f473-2928-a8a7-ea9e70190743@utc.fr>
Message-ID: <CAK=Phk5Q7cObCeCdc_HQLCTeQTfA4oE1Kz2EqWRkwmSA_uUKGQ@mail.gmail.com>

Hello Everyone,

I am following up on this.

Would you guys be open to a PR making that change?

On Fri, Mar 29, 2019 at 6:56 PM St?phane Mottelet <stephane.mottelet at utc.fr>
wrote:

> Le 29/03/2019 ? 18:28, Sylvain Corlay a ?crit :
>
> Hello, world!
>
> The Jupyter kernel protocol expect stdout and stderr streams to be both
> redirected to the frontend, however, it makes a distinction between error
> and output messages in the `stream` message type:
>
> content = {
>     # The name of the stream is one of 'stdout', 'stderr'
>     'name' : str,
>
>     # The text is an arbitrary string to be written to that stream
>     'text' : str,}
>
>
> This is reflected graphically in web frontend. See the following
> screenshot for example, with the C++ Jupyter kernel:
>
> [image: Screenshot from 2019-03-29 18-11-44.png]
>
> I am writing a scilab Jupyter kernel
>
> Glad to hear that, this is a great initiative !
>
> with the Xeus C++ implementation of the protocol, and the redirection to
> the frontend is achieved through the setScilabOutputMethod function which
> results in both errors and outputs to be redirected in the same way.
>
> It would be great if there was a means to specify to different functions
> with e.g. setScilabErrorStreamMethod and setScilabOutputStreamMethod, and
> keeping setScilabOutputMethod as a means to set both at once for backward
> compatibility.
>
> I would love to hear your thoughts on that.
>
> Maybe Antoine could answer ?
>
>
> Cheers,
>
> Sylvain
>
> _______________________________________________
> dev mailing listdev at lists.scilab.orghttps://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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: <https://lists.scilab.org/pipermail/dev/attachments/20190717/3514b4b4/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2019-03-29 18-11-44.png
Type: image/png
Size: 68953 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/dev/attachments/20190717/3514b4b4/attachment.png>

From antoine.elias at scilab-enterprises.com  Wed Jul 17 18:14:08 2019
From: antoine.elias at scilab-enterprises.com (Antoine ELIAS)
Date: Wed, 17 Jul 2019 18:14:08 +0200
Subject: [Scilab-Dev] setScilabOutputMethod - output vs error streams
In-Reply-To: <CAK=Phk5Q7cObCeCdc_HQLCTeQTfA4oE1Kz2EqWRkwmSA_uUKGQ@mail.gmail.com>
References: <CAK=Phk4=KENv=3xgG6AbdZ7onyMg-hZjePY_Y=YdsN1jOv93gg@mail.gmail.com>
 <2288bb2d-f473-2928-a8a7-ea9e70190743@utc.fr>
 <CAK=Phk5Q7cObCeCdc_HQLCTeQTfA4oE1Kz2EqWRkwmSA_uUKGQ@mail.gmail.com>
Message-ID: <74759206-897b-9b5e-e0b1-735ea8b73a02@scilab-enterprises.com>

Hello Sylvain,

I made changes on master branch. You can update your repo ( Cl?ment has 
merged the PR )
Now you have 3 functions:
void setScilabOutputMethod(SCILAB_OUTPUT_METHOD writer);
void setScilabErrorStreamMethod(SCILAB_OUTPUT_METHOD writer);
void setScilabOutputStreamMethod(SCILAB_OUTPUT_METHOD writer);

First for compatibility that set the same handler for outputs and errors
Second for errors and third for outputs.

I hope that help you.

Antoine
Le 17/07/2019 ? 11:51, Sylvain Corlay a ?crit?:
> Hello Everyone,
>
> I am following up on this.
>
> Would you guys be open to a PR making that change?
>
> On Fri, Mar 29, 2019 at 6:56 PM St?phane Mottelet 
> <stephane.mottelet at utc.fr <mailto:stephane.mottelet at utc.fr>> wrote:
>
>     Le 29/03/2019 ? 18:28, Sylvain Corlay a ?crit?:
>
>>     Hello, world!
>>
>>     The Jupyter kernel protocol expect stdout and stderr streams to
>>     be both redirected to the frontend, however, it makes a
>>     distinction between error and output messages in the `stream`
>>     message type:
>>     content  =  {
>>          # The name of the stream is one of 'stdout', 'stderr'
>>          'name'  :  str,
>>
>>          # The text is an arbitrary string to be written to that stream
>>          'text'  :  str,
>>     }
>>
>>     This is reflected graphically in web frontend. See the following
>>     screenshot for example, with the C++ Jupyter kernel:
>>
>>     Screenshot from 2019-03-29 18-11-44.png
>>
>>     I am writing a scilab Jupyter kernel
>     Glad to hear that, this is a great initiative !
>>     with the Xeus C++ implementation of the protocol, and the
>>     redirection to the frontend is achieved through the
>>     setScilabOutputMethod function which results in both errors and
>>     outputs to be redirected in the same way.
>>
>>     It would be great if there was a means to specify to different
>>     functions with e.g. setScilabErrorStreamMethod?and
>>     setScilabOutputStreamMethod, and keeping setScilabOutputMethod as
>>     a means to set both at once for backward compatibility.
>>
>>     I would love to hear your thoughts on that.
>     Maybe Antoine could answer ?
>>
>>     Cheers,
>>
>>     Sylvain
>>
>>     _______________________________________________
>>     dev mailing list
>>     dev at lists.scilab.org  <mailto:dev at lists.scilab.org>
>>     https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev
>     _______________________________________________
>     dev mailing list
>     dev at lists.scilab.org <mailto: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: <https://lists.scilab.org/pipermail/dev/attachments/20190717/a7810517/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2019-03-29 18-11-44.png
Type: image/png
Size: 68953 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/dev/attachments/20190717/a7810517/attachment.png>

From sgougeon at free.fr  Sun Jul 21 22:27:52 2019
From: sgougeon at free.fr (Samuel Gougeon)
Date: Sun, 21 Jul 2019 22:27:52 +0200
Subject: [Scilab-Dev] jimport error on calling environment: blocking scope
	issue
Message-ID: <79e8fb6e-12db-d454-cc03-8d8910b85bf5@free.fr>

Hello,

I am facing some very? serious issue. It is so trivial and surprising 
that i am wondering if this blocking behavior is intentional, and if yes 
why and how to by-pass it if possible:

--> clear File, clearglobal File
--> function test(), jimport java.io.File, disp(File), endfunction
--> test() // OK
class java.io.File
--> File
Undefined variable: File // So the File class is local. It is not 
returned to the caller, from the Scilab point of view.
--> File = 1;
--> test()
at line???? 1 of function test
jimport: An error occurred: A variable with this name is already existing
!!!!

So jimport refuses to create a local Scilab mlist (class) on the reason 
that there is a Scilab variable with the same name in the */calling/* 
environment !

Since it's impossible to ensure that no /File/ variable is defined by 
some process in the (nested) callers up to the console level,/*jimport 
is definitely fragile*/.

Is this a bug, and is there any work-around?

Thanks
Samuel


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