From sgougeon at free.fr  Wed Oct  3 13:01:06 2018
From: sgougeon at free.fr (Samuel Gougeon)
Date: Wed, 3 Oct 2018 13:01:06 +0200
Subject: [Scilab-Dev] [Scilab-users] bug when setting gcbo field in a
 callback function ?
In-Reply-To: <fd89ced4-62ed-e6ad-f7db-a983f5b76b58@free.fr>
References: <3c4c2a81-a832-842c-4ce6-cde22922317f@laas.fr>
 <07b1519a-328d-947c-5968-ca3d7746df51@utc.fr>
 <a10777d0-b5e2-c75e-a2e8-e82ee5e48748@laas.fr>
 <17fd9bd0-d569-48df-5104-51c53c45f06f@free.fr>
 <85583a4c-6299-a848-dc19-28a851502370@laas.fr>
 <1E0A4216-7B9A-4CBC-8113-441051DF9B8D@utc.fr>
 <f36a0e26-3c28-7b67-9fda-84379d82c806@utc.fr>
 <627b5c0d-d5de-64d8-88e7-237b6a8f63e3@free.fr>
 <fd89ced4-62ed-e6ad-f7db-a983f5b76b58@free.fr>
Message-ID: <41ec1e53-8a0e-9af6-648c-effd7d02378f@free.fr>

Le 29/09/2018 ? 22:03, Samuel Gougeon a ?crit :
> Le 29/09/2018 ? 21:34, Samuel Gougeon a ?crit :
>> This is a follow-up of the users@ thread
>> http://mailinglists.scilab.org/Scilab-users-bug-when-setting-gcbo-field-in-a-callback-function-tp4038615.html
>>
>> To be more explored...
>
> I've got it: this bug is due to the -quit option used to run the 
> test_run scilab session: removing it uncancels the datatip rendering.
>
> Since the -quit option is needed to cancel the test when  a syntax 
> error occurs in it, this is still only a first step to fix the issue...

Moreover, the bug occurs only when the polyline.display_function is set 
(to explicitly set the datatips labels, instead of using the default 
labels style).
This is the case after calling nyquist(), but not after plot2d().

This bug is now reported @ http://bugzilla.scilab.org/15790



From stephane.mottelet at utc.fr  Tue Oct  9 13:31:19 2018
From: stephane.mottelet at utc.fr (stephane.mottelet at utc.fr)
Date: Tue, 09 Oct 2018 13:31:19 +0200
Subject: [Scilab-Dev] Problem configuring scilab-branch-6.0 after Ubuntu
	18.04 update
Message-ID: <20181009133119.Horde.RjvFG_htqP8VALWuExdSaec@webmail.utc.fr>

Hello,

I just updated my Linux to Ubuntu 18.04 an, although java-headless is  
installed (javah is /usr/bin/javah)

mottelet at mottelet-HP-ProDesk-600-G1-TWR:~/git/scilab/scilab$ javah
Usage:
? javah [options] <classes>
where [options] include:
? -o <file>??????????????? Output file (only one of -d or -o may be used)
? -d <dir>???????????????? Output directory
? -v? -verbose???????????? Enable verbose output
? -h? --help? -??????????? Print this message
? -version???????????????? Print version information
? -jni???????????????????? Generate JNI-style header file (default)
? -force?????????????????? Always write output files
? -classpath <path>??????? Path from which to load classes
? -cp <path>?????????????? Path from which to load classes
? -bootclasspath <path>??? Path from which to load bootstrap classes
<classes> are specified with their fully qualified names
(for example, java.lang.Object).

the configure script cannot find javah:

checking JAVA_HOME variable... not defined
checking for javac... /usr/lib/jvm/default-java/bin//javac
checking for zip or jar files to include on CLASSPATH...
checking to see if the java compiler works... yes
Using JAVAC=/usr/lib/jvm/default-java/bin//javac
Java found in /usr/lib/jvm/default-java
checking type of jvm... jdk
checking java API version... 1.9
Using the following JNI include flags  
-I/usr/lib/jvm/default-java/include  
-I/usr/lib/jvm/default-java/include/linux
checking if jni.h can be included... yes
Looking for JNI libs with x86_64 as machine hardware name
Looking for /usr/lib/jvm/default-java/lib/libjava.so
Found /usr/lib/jvm/default-java/lib/libjava.so
Using the following JNI library flags -L/usr/lib/jvm/default-java/lib  
-ljava -lverify -L/usr/lib/jvm/default-java/lib/server -ljvm
Using the following runtime library path  
/usr/lib/jvm/default-java/lib:/usr/lib/jvm/default-java/lib/server
checking to see if we can link a JNI application... yes
checking for zip or jar files to include on CLASSPATH...
checking for java... /usr/lib/jvm/default-java/bin/java
checking for java_g... no
checking for javah... no
configure: error: Cannot find javah

How can I solve this problem ?

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

From johanwesselink23 at gmail.com  Tue Oct  9 16:02:34 2018
From: johanwesselink23 at gmail.com (Johan Wesselink)
Date: Tue, 9 Oct 2018 11:02:34 -0300
Subject: [Scilab-Dev] Problem configuring scilab-branch-6.0 after Ubuntu
 18.04 update
In-Reply-To: <20181009133119.Horde.RjvFG_htqP8VALWuExdSaec@webmail.utc.fr>
References: <20181009133119.Horde.RjvFG_htqP8VALWuExdSaec@webmail.utc.fr>
Message-ID: <CAOZ7c1YVSoD1fWAJ0rsTbdQZWabDGKDNhb5jy1kSHhb+N96E_w@mail.gmail.com>

I installed JDK 8 and used the java configuration tool to point to this
version. Ubuntu 18.04 comes with JAVA 11.
Your best bet is to remove the current java version and install the JDK8
version.
Also I had a JDK_HOME variable pointing to the wrong location.

Op di 9 okt. 2018 om 10:59 schreef <stephane.mottelet at utc.fr>:

> Hello,
>
> I just updated my Linux to Ubuntu 18.04 an, although java-headless is
> installed (javah is /usr/bin/javah)
>
>
> mottelet at mottelet-HP-ProDesk-600-G1-TWR:~/git/scilab/scilab$ javah
> Usage:
>   javah [options] <classes>
> where [options] include:
>   -o <file>                Output file (only one of -d or -o may be used)
>   -d <dir>                 Output directory
>   -v  -verbose             Enable verbose output
>   -h  --help  -?           Print this message
>   -version                 Print version information
>   -jni                     Generate JNI-style header file (default)
>   -force                   Always write output files
>   -classpath <path>        Path from which to load classes
>   -cp <path>               Path from which to load classes
>   -bootclasspath <path>    Path from which to load bootstrap classes
> <classes> are specified with their fully qualified names
> (for example, java.lang.Object).
>
>
> the configure script cannot find javah:
>
> checking JAVA_HOME variable... not defined
> checking for javac... /usr/lib/jvm/default-java/bin//javac
> checking for zip or jar files to include on CLASSPATH...
> checking to see if the java compiler works... yes
> Using JAVAC=/usr/lib/jvm/default-java/bin//javac
> Java found in /usr/lib/jvm/default-java
> checking type of jvm... jdk
> checking java API version... 1.9
> Using the following JNI include flags -I/usr/lib/jvm/default-java/include
> -I/usr/lib/jvm/default-java/include/linux
> checking if jni.h can be included... yes
> Looking for JNI libs with x86_64 as machine hardware name
> Looking for /usr/lib/jvm/default-java/lib/libjava.so
> Found /usr/lib/jvm/default-java/lib/libjava.so
> Using the following JNI library flags -L/usr/lib/jvm/default-java/lib
> -ljava -lverify -L/usr/lib/jvm/default-java/lib/server -ljvm
> Using the following runtime library path
> /usr/lib/jvm/default-java/lib:/usr/lib/jvm/default-java/lib/server
> checking to see if we can link a JNI application... yes
> checking for zip or jar files to include on CLASSPATH...
> checking for java... /usr/lib/jvm/default-java/bin/java
> checking for java_g... no
> checking for javah... no
> configure: error: Cannot find javah
>
> How can I solve this problem ?
>
> S.
> _______________________________________________
> 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/20181009/1c0a871e/attachment.htm>

From antoine.monmayrant+scilab at laas.fr  Tue Oct  9 11:02:20 2018
From: antoine.monmayrant+scilab at laas.fr (antoine.monmayrant+scilab at laas.fr)
Date: Tue, 9 Oct 2018 11:02:20 +0200
Subject: [Scilab-Dev] fftshift and ifftshift are way too different
Message-ID: <dcfc9d32-9749-51b5-3c15-0ea52a68b27a@laas.fr>

Hello all,

 From what I understand of fast Fourier transforms, fftshift and 
ifftshift should be almost identical.
The only difference is when there are an odd number of elements in the 
dimension along which the shift is performed (ie 
fftshift([1:4])==ifftshift([1:4]) but fftshift([1:5])!=ifftshift([1:5])).
However, it seems that in scilab6.x fftshift and ifftshift are based on 
completely different codes and do not accept the same arguments.
In particular, with fftshift, one can specify the dimension along which 
to perform the shift, while it is not the case for ifftshift.
I think some update of ifftshift would be welcome.
I propose to use the code below (myifftshift), where I just changed 
"ceil" by "floor" in the definition if fftshift.
What do you think, does it look right to you?

Cheers,

Antoine

function x = myifftshift(x,job)
     if argn(2)<2 then job="all",end
     deff("sel=fun(sk)","c=floor(sk/2);sel=[c+1:sk,1:c]")
     if job=="r" then job=1,elseif job=="c" then job=2,end
     ind=list()
     if job=="all" then
         for sk=size(x),ind($+1)=fun(sk),end
     else
         for sk=size(x),ind($+1)=:,end;
         ind(job)=fun(size(x,job))
     end
     x=x(ind(:))
endfunction



From n.strelkov at gmail.com  Thu Oct 11 10:10:11 2018
From: n.strelkov at gmail.com (Nikolay Strelkov)
Date: Thu, 11 Oct 2018 11:10:11 +0300
Subject: [Scilab-Dev] [Scilab-users] Unable to update ATOMS packages -
	Scilab 6.0.1
In-Reply-To: <CAJKcLoUmNUcXTJrMxMH0+jJ+7XU03vGdX2PUtwjifke0cocsug@mail.gmail.com>
References: <1539011463988-0.post@n3.nabble.com>
 <1539207428446-0.post@n3.nabble.com>
 <CAJKcLoUmNUcXTJrMxMH0+jJ+7XU03vGdX2PUtwjifke0cocsug@mail.gmail.com>
Message-ID: <CADK7Jf=+jVT=C1bBZdOPFSrM0P3Y6cT_Pz7rHRCCkciXEMva-A@mail.gmail.com>

Dear all!

It is known bug https://bugs.launchpad.net/bugs/1765503 .

The solution is to use binary version of Scilab 6 as described in this
AskUbuntu answer ( https://askubuntu.com/a/1029164/66509 ).

Official reaction from Scilab developers and/or Debian/Ubuntu maintainers
is highly needed and will be appreciated.
Otherwise Scilab 6 from deb-packages is useless waste of disk resources.
So please take all needed measures on distro-level.

--

*With best regards,Ph.D., *


*associate professor at MPEI
<http://mpei.ru/lang/en/Pages/default.aspx>,IEEE member,maintainer of
Mathieu functions toolbox for Scilab
<http://atoms.scilab.org/toolboxes/Mathieu/>,Nikolay Strelkov.*


??, 11 ???. 2018 ?. ? 9:12, Samuel Enibe <samuel.enibe at unn.edu.ng>:

> I have a similar problem with SCILAB on Ubuntu 1804.
>
> A solution to this problem from the developers of SCILAB or the Ubuntu
> maintainers will be most appreciated.
>
> Samuel Ogbonna Enibe
> University of Nigeria, Nsukka, Nigeria
>
>
> On Wed, Oct 10, 2018 at 10:37 PM Pndsc <chrisp at poundsc.org> wrote:
>
>> So to update my own inquiry - as far as I can make out theres no solution
>> to
>> this problem. Or at least, I havent been able to fix it.
>>
>> I'm not the only person with this problem - theres an  Ubuntu
>> stackexchange
>> thread with a suggested fix here
>> <
>> https://askubuntu.com/questions/1029163/how-to-get-scilab-6-0-1-working-on-ubuntu-18-04-lts/1029164>
>>
>> by N0rbert which might prove useful for other people with issues of simply
>> getting Scilab to work, but does not solve my issue of ATOMS not updating
>> or
>> displaying an up to date package list.
>>
>> The HDF5 thing is a known issue and is on the bugtracker here thanks to
>> N0rbert:
>>
>> https://bugs.launchpad.net/ubuntu/+source/scilab/+bug/1765503
>>
>> I have to admit I have a hard time with believing that this issue has been
>> allowed to persist for so long with the current most widespread linux
>> distribution out there.
>>
>> Running an atomsInstall command doesnt work either:
>>
>> --> atomsInstall("coselica")
>> Scanning repository http://atoms.scilab.org/6.0 ... Done
>>
>> at line   265 of function atomsDESCRIPTIONget (
>>
>> /usr/share/scilab/modules/atoms/macros/atoms_internals/atomsDESCRIPTIONget.sci
>> line 284 )
>> at line    31 of function atomsIsPackage      (
>> /usr/share/scilab/modules/atoms/macros/atoms_internals/atomsIsPackage.sci
>> line 47 )
>> at line    69 of function atomsInstallList    (
>>
>> /usr/share/scilab/modules/atoms/macros/atoms_internals/atomsInstallList.sci
>> line 108 )
>> at line   233 of function atomsInstall        (
>> /usr/share/scilab/modules/atoms/macros/atomsInstall.sci line 249 )
>>
>> atomsDESCRIPTIONget: save
>> ('/home/chris/.Scilab/scilab-6.0.1/.atoms/packages') has failed.
>>
>> I dont know if its significant or not, but in
>> /usr/share/scilab/modules/atoms/etc/ , in the "repositories" text file,
>> the
>> url for the atoms repository for 6.0 (https://atoms.scilab.org/6.0/)
>> returns
>> a 443 forbidden error.
>>
>> Its late here but the next thing on my list to do tomorrow is to download
>> the package zips manually and installing via atomsInstall('pathtozip').
>>
>>
>>
>> --
>> Sent from:
>> http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html
>> _______________________________________________
>> users mailing list
>> users at lists.scilab.org
>> http://lists.scilab.org/mailman/listinfo/users
>>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20181011/e5b00ed6/attachment.htm>

From stephane.mottelet at utc.fr  Fri Oct 12 13:24:30 2018
From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=)
Date: Fri, 12 Oct 2018 13:24:30 +0200
Subject: [Scilab-Dev] Closing bugs
Message-ID: <80598fbd-ee6c-ec01-b7a2-a61ac95d4505@utc.fr>

Hello all,

In Bugzilla, can we close as "RESOVED/WONTFIX" bugs which occured for 
previous version but not for current version (6.0.1) ?

S.


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



From stephane.mottelet at utc.fr  Fri Oct 12 13:27:09 2018
From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=)
Date: Fri, 12 Oct 2018 13:27:09 +0200
Subject: [Scilab-Dev] Closing bugs
In-Reply-To: <80598fbd-ee6c-ec01-b7a2-a61ac95d4505@utc.fr>
References: <80598fbd-ee6c-ec01-b7a2-a61ac95d4505@utc.fr>
Message-ID: <b381b9bf-823c-ca4a-76c5-18f479735233@utc.fr>

Le 12/10/2018 ? 13:24, St?phane Mottelet a ?crit?:
> Hello all,
>
> In Bugzilla, can we close as "RESOVED/WONTFIX" bugs which occured for 
> previous version but not for current version (6.0.1) ?
Since "RESOLVED/WORKSFORME" is irrelevant, as it works for a 
*subsequent* version.
>
> S.
>
>

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



From sgougeon at free.fr  Fri Oct 12 15:16:56 2018
From: sgougeon at free.fr (sgougeon at free.fr)
Date: Fri, 12 Oct 2018 15:16:56 +0200 (CEST)
Subject: [Scilab-Dev] =?utf-8?q?Re=C2=A0=3A_Re=3A__Closing_bugs?=
In-Reply-To: <b381b9bf-823c-ca4a-76c5-18f479735233@utc.fr>
Message-ID: <1706967729.1029538527.1539350216429.JavaMail.root@zimbra75-e12.priv.proxad.net>

Hello St?phane

>De: St?phane Mottelet <stephane.mottelet at utc.fr>
>>Le 12/10/2018 ? 13:24, St?phane Mottelet a ?crit :
>> Hello all,
>>
>> In Bugzilla, can we close as "RESOVED/WONTFIX" bugs which occured for 
>> previous version but not for current version (6.0.1) ?
>Since "RESOLVED/WORKSFORME" is irrelevant, as it works for a 
>*subsequent* version.

IMO, "RESOLVED" => "FIXED" shall be used.

Bug-reporting-fixing is a flow.

"RESOLVED" => "WONTFIX" shall be used when the bug won't reasonably never be fixed, or when is was an actual one but is no longer relevant (for instance an unfixed bug about a removed feature).

"RESOLVED" => "WORKSFORME" shall be used when no one was able to reproduce the bug on any platform with the given Scilab version/family, despite the poster has posted some relevant information to reproduce it, and a quite long period elapsed since the report was posted (some bugs are hardware-dependent, and other users that have the same hardware can confirm the bug, if the report is not closed too early).

My two cents
Samuel

----- Mail d'origine -----
De: St?phane Mottelet <stephane.mottelet at utc.fr>
?: List dedicated to development questions <dev at lists.scilab.org>
Envoy?: Fri, 12 Oct 2018 13:27:09 +0200 (CEST)
Objet: Re: [Scilab-Dev] Closing bugs

Le 12/10/2018 ? 13:24, St?phane Mottelet a ?crit?:
> Hello all,
>
> In Bugzilla, can we close as "RESOVED/WONTFIX" bugs which occured for 
> previous version but not for current version (6.0.1) ?
Since "RESOLVED/WORKSFORME" is irrelevant, as it works for a 
*subsequent* version.
>
> S.
>
>

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

_______________________________________________
dev mailing list
dev at lists.scilab.org
http://lists.scilab.org/mailman/listinfo/dev



From stephane.mottelet at utc.fr  Fri Oct 12 23:30:45 2018
From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=)
Date: Fri, 12 Oct 2018 23:30:45 +0200
Subject: [Scilab-Dev] datatip contextual menu to copy [x,y]
Message-ID: <44c14d0e-3eb9-d6da-2c7b-59d862ce7b7f@utc.fr>

Hello all,

After navigating into the numerous files used for the datatip stuff, 
which are in at least two different modules (graphic_object and gui), I 
still didn't found the right place to define a MouseListener that could 
allow popping a menu when right-clicking on the datatip text, giving the 
possibility to copy the coordinates.

I guess this has to be done at the renderer level, since datatips are 
part of the polyline itself ?

Not that easy...

Thanks for help

S.




From sgougeon at free.fr  Sat Oct 13 13:28:09 2018
From: sgougeon at free.fr (Samuel Gougeon)
Date: Sat, 13 Oct 2018 13:28:09 +0200
Subject: [Scilab-Dev] datatip contextual menu to copy [x,y]
In-Reply-To: <44c14d0e-3eb9-d6da-2c7b-59d862ce7b7f@utc.fr>
References: <44c14d0e-3eb9-d6da-2c7b-59d862ce7b7f@utc.fr>
Message-ID: <e85e7740-ae0a-f56e-45e7-c81bd4cc2d73@free.fr>

Hello St?phane,

Le 12/10/2018 ? 23:30, St?phane Mottelet a ?crit :
> Hello all,
>
> After navigating into the numerous files used for the datatip stuff, 
> which are in at least two different modules (graphic_object and gui), 
> I still didn't found the right place to define a MouseListener that 
> could allow popping a menu when right-clicking on the datatip text, 
> giving the possibility to copy the coordinates.
>
> I guess this has to be done at the renderer level, since datatips are 
> part of the polyline itself ?
>
> Not that easy...
>
> Thanks for help

About the area to click to get the coordinates: imho, it would be better 
to click on the datatip anchor rather than on the label. Indeed, the 
label may be hidden (in 
polyline.datatip_display_mode="mouseclick"|"mouseover"), while the 
anchor is always displayed.
About the tool to do that: to me, there are at least 2 possibilities:

  *   activate the datatip mode + create a contextual menu dedicated
    only to datatips (that was the case in Scilab 5.4.0, before
    refactoring datatips)
  * Out of the datatip mode (which requires a first click to activate
    it), in the general interactive editor : left-clicking on an anchor
    selects the whole curve instead of only the datatip. Then
    right-clicking opens the contextual menu, with actions for the axes
    or the curve:

    It would be interesting to resolve the clicked object: if the click
    position is around an anchor, then in the contextual menu the "copy
    to clipboard" action could be about the only datatip (its coordinates)
    (By the way, in the existing menu, the difference between "Copy" and
    "Copy to clipboard" looks unclear to me).

In practical, i would start

  * either from the datatipmanagermode()
    gateway:/org//.//scilab//.//modules//.//gui//.//datatip//.//DatatipManager//.//start/
  * or from the useeditor()
    one:/org//.//scilab//.//modules//.//gui//.//editor//.//EditorManager//.//start/

HTH
Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20181013/80515c0c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dolihgfkgfnefnof.png
Type: image/png
Size: 15857 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/dev/attachments/20181013/80515c0c/attachment.png>

From sgougeon at free.fr  Sat Oct 13 13:59:24 2018
From: sgougeon at free.fr (Samuel Gougeon)
Date: Sat, 13 Oct 2018 13:59:24 +0200
Subject: [Scilab-Dev] datatip contextual menu to copy [x,y]
In-Reply-To: <e85e7740-ae0a-f56e-45e7-c81bd4cc2d73@free.fr>
References: <44c14d0e-3eb9-d6da-2c7b-59d862ce7b7f@utc.fr>
 <e85e7740-ae0a-f56e-45e7-c81bd4cc2d73@free.fr>
Message-ID: <95f93dcc-61fe-cb41-bf34-355d2a3ad26e@free.fr>

Le 13/10/2018 ? 13:28, Samuel Gougeon a ?crit :
> .../...
>
>   * Out of the datatip mode (which requires a first click to activate
>     it), in the general interactive editor : left-clicking on an
>     anchor selects the whole curve instead of only the datatip. Then
>     right-clicking opens the contextual menu, with actions for the
>     axes or the curve:
>
>     It would be interesting to resolve the clicked object: if the
>     click position is around an anchor, then in the contextual menu
>     the "copy to clipboard" action could be about the only datatip
>     (its coordinates)
>     (By the way, in the existing menu, the difference between "Copy"
>     and "Copy to clipboard" looks unclear to me).
>

About this last point: The issue that makes things rather puzzling is 
that, presently, the contextual menu mixes items related to different 
objects: Axes, and curves, ...

  * The default object when entering the editor is the current axes. OK
    (but the figure's level is not reachable).
  * After selecting a curve, the menu opened when right-clicking is
    the/Axes contextual menu + newly activated items/, instead of being
    dedicated only to actions /on curves/. Then, it's unclear on what
    some "general actions" like copy, delete, clear... are done: the
    axes, the curve, (then the datatip ?) ...
  * For datatips, imho  it would be more handy to resolve the left
    selecting click without having to activate the datatipManagerMode,
    and then display a contextual menu with actions only on the selected
    datatip, like copying its coordinates.

Regards
Samuel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20181013/ff8d818f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 15857 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/dev/attachments/20181013/ff8d818f/attachment.png>

From clement.david at scilab-enterprises.com  Mon Oct 15 09:07:22 2018
From: clement.david at scilab-enterprises.com (=?utf-8?B?Q2zDqW1lbnQgREFWSUQ=?=)
Date: Mon, 15 Oct 2018 07:07:22 +0000
Subject: [Scilab-Dev] =?utf-8?q?Re=C2=A0=3A_Re=3A__Closing_bugs?=
In-Reply-To: <1706967729.1029538527.1539350216429.JavaMail.root@zimbra75-e12.priv.proxad.net>
References: <b381b9bf-823c-ca4a-76c5-18f479735233@utc.fr>
 <1706967729.1029538527.1539350216429.JavaMail.root@zimbra75-e12.priv.proxad.net>
Message-ID: <AM6PR0502MB37020797E149FED23C053FB1B0FD0@AM6PR0502MB3702.eurprd05.prod.outlook.com>

Hello,

I agree with Samuel, "WONTFIX" should only be used when this is not related anymore (or never was). For example, I close as WONTIFX bugs related to custom packaging of Scilab (for Linux distribution, specific builds, etc..) or bug related to user very-specific needs that will break general behavior (for example specific shortcuts that will break on other platforms).

Cheers,

--
Cl?ment

-----Original Message-----
From: dev <dev-bounces at lists.scilab.org> On Behalf Of sgougeon at free.fr
Sent: Friday, October 12, 2018 3:17 PM
To: List dedicated to the development of Scilab <dev at lists.scilab.org>
Subject: [Scilab-Dev] Re?: Re: Closing bugs

Hello St?phane

>De: St?phane Mottelet <stephane.mottelet at utc.fr>
>>Le 12/10/2018 ? 13:24, St?phane Mottelet a ?crit :
>> Hello all,
>>
>> In Bugzilla, can we close as "RESOVED/WONTFIX" bugs which occured for 
>> previous version but not for current version (6.0.1) ?
>Since "RESOLVED/WORKSFORME" is irrelevant, as it works for a
>*subsequent* version.

IMO, "RESOLVED" => "FIXED" shall be used.

Bug-reporting-fixing is a flow.

"RESOLVED" => "WONTFIX" shall be used when the bug won't reasonably never be fixed, or when is was an actual one but is no longer relevant (for instance an unfixed bug about a removed feature).

"RESOLVED" => "WORKSFORME" shall be used when no one was able to reproduce the bug on any platform with the given Scilab version/family, despite the poster has posted some relevant information to reproduce it, and a quite long period elapsed since the report was posted (some bugs are hardware-dependent, and other users that have the same hardware can confirm the bug, if the report is not closed too early).

My two cents
Samuel

----- Mail d'origine -----
De: St?phane Mottelet <stephane.mottelet at utc.fr>
?: List dedicated to development questions <dev at lists.scilab.org>
Envoy?: Fri, 12 Oct 2018 13:27:09 +0200 (CEST)
Objet: Re: [Scilab-Dev] Closing bugs

Le 12/10/2018 ? 13:24, St?phane Mottelet a ?crit?:
> Hello all,
>
> In Bugzilla, can we close as "RESOVED/WONTFIX" bugs which occured for 
> previous version but not for current version (6.0.1) ?
Since "RESOLVED/WORKSFORME" is irrelevant, as it works for a
*subsequent* version.
>
> S.
>
>

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

_______________________________________________
dev mailing list
dev at lists.scilab.org
http://lists.scilab.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev at lists.scilab.org
http://lists.scilab.org/mailman/listinfo/dev

From stephane.mottelet at utc.fr  Mon Oct 15 10:25:48 2018
From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=)
Date: Mon, 15 Oct 2018 10:25:48 +0200
Subject: [Scilab-Dev] datatip contextual menu to copy [x,y]
In-Reply-To: <95f93dcc-61fe-cb41-bf34-355d2a3ad26e@free.fr>
References: <44c14d0e-3eb9-d6da-2c7b-59d862ce7b7f@utc.fr>
 <e85e7740-ae0a-f56e-45e7-c81bd4cc2d73@free.fr>
 <95f93dcc-61fe-cb41-bf34-355d2a3ad26e@free.fr>
Message-ID: <f9eb9626-8585-ea95-ac75-4fdc831a5000@utc.fr>

Hello,

Here is a proposition, to be discussed/improved, of course (patch+demo 
video):

https://codereview.scilab.org/#/c/20550/

S.

Le 13/10/2018 ? 13:59, Samuel Gougeon a ?crit?:
> Le 13/10/2018 ? 13:28, Samuel Gougeon a ?crit?:
>> .../...
>>
>>   * Out of the datatip mode (which requires a first click to activate
>>     it), in the general interactive editor : left-clicking on an
>>     anchor selects the whole curve instead of only the datatip. Then
>>     right-clicking opens the contextual menu, with actions for the
>>     axes or the curve:
>>
>>     It would be interesting to resolve the clicked object: if the
>>     click position is around an anchor, then in the contextual menu
>>     the "copy to clipboard" action could be about the only datatip
>>     (its coordinates)
>>     (By the way, in the existing menu, the difference between "Copy"
>>     and "Copy to clipboard" looks unclear to me).
>>
>
> About this last point: The issue that makes things rather puzzling is 
> that, presently, the contextual menu mixes items related to different 
> objects: Axes, and curves, ...
>
>   * The default object when entering the editor is the current axes.
>     OK (but the figure's level is not reachable).
>   * After selecting a curve, the menu opened when right-clicking is
>     the/Axes contextual menu + newly activated items/, instead of
>     being dedicated only to actions /on curves/. Then, it's unclear on
>     what some "general actions" like copy, delete, clear... are done:
>     the axes, the curve, (then the datatip ?) ...
>   * For datatips, imho? it would be more handy to resolve the left
>     selecting click without having to activate the datatipManagerMode,
>     and then display a contextual menu with actions only on the
>     selected datatip, like copying its coordinates.
>
> Regards
> 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/20181015/4fa0c2db/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gkfaehbmkefaicfl.png
Type: image/png
Size: 15857 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/dev/attachments/20181015/4fa0c2db/attachment.png>

From stephane.mottelet at utc.fr  Fri Oct 19 00:10:59 2018
From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=)
Date: Fri, 19 Oct 2018 00:10:59 +0200
Subject: [Scilab-Dev] conversion types::*int* -> types::Double in gateway
Message-ID: <1a1eb7bf-e8cc-2892-cc83-bf0f3caf6a2e@utc.fr>

Hello all,

Is there a simple way to convert a types::*int* to a types::Double 
without having to write a switch/case for all cases ?

S.



From sgougeon at free.fr  Sat Oct 27 01:06:44 2018
From: sgougeon at free.fr (Samuel Gougeon)
Date: Sat, 27 Oct 2018 01:06:44 +0200
Subject: [Scilab-Dev] Big literal integers for int64() and uint64()
Message-ID: <def34a2e-5f00-cbd6-bb89-1f9d12dd9bea@free.fr>

Hello,

Here is an awkward case. I am afraid that it won't be possible to 
improve the situation, but let's see it:

--> int64(461168601842738791)

  ans  =
   461168601842738816   <<< ..38816 =/= ..38791

I know that this comes from the fact that the literal 461168601842738791 
is /by default /parsed as the decimal number 461168601842738791., and 
since 1/461168601842738791 < %eps, there is a round-off error, after 
what the "truncated" decimal number is converted into an int64.

So, the question is: in the specific cases of int64() and uint64(), 
would it be possible to parse literals input arguments assuming that 
they are not decimal?

Before parsing the literal, could the parser be aware that the calling 
function is int64() or uint64()?

Another solution -- may be easier to implement -- to provide literal 
numbers to int64() and uint64() without rounding them could be to 
support string inputs, as for instance hex2dec() does it. It is 
presently not the case, and the overloading is not enabled:

--> int64("461168601842738791")
int64: Wrong type for input argument #1: integer, boolean or double 
expected.

Samuel


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

From antoine.elias at scilab-enterprises.com  Sat Oct 27 14:00:46 2018
From: antoine.elias at scilab-enterprises.com (Antoine ELIAS)
Date: Sat, 27 Oct 2018 14:00:46 +0200
Subject: [Scilab-Dev] Big literal integers for int64() and uint64()
In-Reply-To: <def34a2e-5f00-cbd6-bb89-1f9d12dd9bea@free.fr>
References: <def34a2e-5f00-cbd6-bb89-1f9d12dd9bea@free.fr>
Message-ID: <2c5d75e4-5bed-fc9e-47d8-91f92471c281@scilab-enterprises.com>

Hello Samuel,

Currently, parser ... lexer, in fact, try to read "number" and convert 
it to floating point number, at this moment, we have no idea what the 
final goal of this number.
After that, the parser try to understand what to do with this number 
(already a double).
So I think the first case is not possible with the current management of 
numbers.

For string argument, I think it cannot be done easily in an overload 
macro for the same reason.
But it can be done in (u)int builtin .

Regards,
Antoine
Le 27/10/2018 ? 01:06, Samuel Gougeon a ?crit?:
>
> Hello,
>
> Here is an awkward case. I am afraid that it won't be possible to 
> improve the situation, but let's see it:
>
> --> int64(461168601842738791)
>
> ?ans? =
> ? 461168601842738816?? <<< ..38816 =/= ..38791
>
> I know that this comes from the fact that the literal 
> 461168601842738791 is /by default /parsed as the decimal number 
> 461168601842738791., and since 1/461168601842738791 < %eps, there is a 
> round-off error, after what the "truncated" decimal number is 
> converted into an int64.
>
> So, the question is: in the specific cases of int64() and uint64(), 
> would it be possible to parse literals input arguments assuming that 
> they are not decimal?
>
> Before parsing the literal, could the parser be aware that the calling 
> function is int64() or uint64()?
>
> Another solution -- may be easier to implement -- to provide literal 
> numbers to int64() and uint64() without rounding them could be to 
> support string inputs, as for instance hex2dec() does it. It is 
> presently not the case, and the overloading is not enabled:
>
> --> int64("461168601842738791")
> int64: Wrong type for input argument #1: integer, boolean or double 
> expected.
>
> 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/20181027/64fe2ddc/attachment.htm>

From sgougeon at free.fr  Sat Oct 27 17:34:51 2018
From: sgougeon at free.fr (Samuel Gougeon)
Date: Sat, 27 Oct 2018 17:34:51 +0200
Subject: [Scilab-Dev] Big literal integers for int64() and uint64()
In-Reply-To: <2c5d75e4-5bed-fc9e-47d8-91f92471c281@scilab-enterprises.com>
References: <def34a2e-5f00-cbd6-bb89-1f9d12dd9bea@free.fr>
 <2c5d75e4-5bed-fc9e-47d8-91f92471c281@scilab-enterprises.com>
Message-ID: <9de6a4ab-c0ef-af8b-91c1-dd875d8a524a@free.fr>

Hello Antoine,

Thanks for your answer.
I have opened a bug report #15837 
<http://bugzilla.scilab.org/show_bug.cgi?id=15837> about this topic.

About the overload:

Le 27/10/2018 ? 14:00, Antoine ELIAS a ?crit :
> Hello Samuel,
>
> Currently, parser ... lexer, in fact, try to read "number" and convert 
> it to floating point number, at this moment, we have no idea what the 
> final goal of this number.
> After that, the parser try to understand what to do with this number 
> (already a double).
> So I think the first case is not possible with the current management 
> of numbers.
>
> For string argument, I think it cannot be done easily in an overload 
> macro for the same reason.

In the report, i have posted a proposal for a working 11-rows-long 
%c_uint64() overload (without the error messages ;)
With it, we get for instance

--> %c_uint64("9000000000000001000") + [ 1 -1001 ; 4 7]
  ans  =
   9000000000000001001  8999999999999999999
   9000000000000001004  9000000000000001007

whereas
--> uint64(9000000000000001000) + [ 1 -1001 ; 4 7]
  ans  =
   9000000000000001025  9000000000000000023
   9000000000000001028  9000000000000001031

It can process any relevant input array of any number of dimensions.

Best regards
Samuel

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

From antoine.elias at scilab-enterprises.com  Sat Oct 27 20:28:50 2018
From: antoine.elias at scilab-enterprises.com (Antoine ELIAS)
Date: Sat, 27 Oct 2018 20:28:50 +0200
Subject: [Scilab-Dev] Big literal integers for int64() and uint64()
In-Reply-To: <9de6a4ab-c0ef-af8b-91c1-dd875d8a524a@free.fr>
References: <def34a2e-5f00-cbd6-bb89-1f9d12dd9bea@free.fr>
 <2c5d75e4-5bed-fc9e-47d8-91f92471c281@scilab-enterprises.com>
 <9de6a4ab-c0ef-af8b-91c1-dd875d8a524a@free.fr>
Message-ID: <c2b4b019-edcd-113e-d71b-5ff200078e9a@scilab-enterprises.com>

Hello again,
I worked on it ( challenge accepted ! )

I took a look of your implementation, I'm not sure it is necessary to 
remove trailing white spaces or inner spaces ( " 1 000 000 " is not a 
correct representation of a number, that's all ! )
Or you have to manage "\t", "," or any localized separator.

In lot of language when you convert "123toto" you get 123 not an error.
And does not allow "1.123" is a mistake for me since uint64(1.123) -> 
1(ui64).

I made an implementation in builtin for all (u)int functions that raises 
error only on too long input string ("10000000000000000000" for example 
) and empty string ( but we can convert to 0 like %nan )
I manage "nan", "NaN" "%nan", "inf", "Inf", "%inf", "-inf", "-Inf", 
"-%inf" to respectively 0, minval and maxval
And "icing on the cake", is little bit faster than yours :p
(between 2 and 100 times depending of input size, C++ vs script)

(missing NRT, changes ... but it is Saturday ^^ )
https://codereview.scilab.org/#/c/20587/

Regards,
Antoine
Le 27/10/2018 ? 17:34, Samuel Gougeon a ?crit?:
> Hello Antoine,
>
> Thanks for your answer.
> I have opened a bug report #15837 
> <http://bugzilla.scilab.org/show_bug.cgi?id=15837> about this topic.
>
> About the overload:
>
> Le 27/10/2018 ? 14:00, Antoine ELIAS a ?crit?:
>> Hello Samuel,
>>
>> Currently, parser ... lexer, in fact, try to read "number" and 
>> convert it to floating point number, at this moment, we have no idea 
>> what the final goal of this number.
>> After that, the parser try to understand what to do with this number 
>> (already a double).
>> So I think the first case is not possible with the current management 
>> of numbers.
>>
>> For string argument, I think it cannot be done easily in an overload 
>> macro for the same reason.
>
> In the report, i have posted a proposal for a working 11-rows-long 
> %c_uint64() overload (without the error messages ;)
> With it, we get for instance
>
> --> %c_uint64("9000000000000001000") + [ 1 -1001 ; 4 7]
> ?ans? =
> ? 9000000000000001001? 8999999999999999999
> ? 9000000000000001004? 9000000000000001007
>
> whereas
> --> uint64(9000000000000001000) + [ 1 -1001 ; 4 7]
> ?ans? =
> ? 9000000000000001025? 9000000000000000023
> ? 9000000000000001028? 9000000000000001031
>
> It can process any relevant input array of any number of dimensions.
>
> Best regards
> Samuel
>
>
>
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/dev

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

From Clement.David at esi-group.com  Tue Oct 30 13:51:36 2018
From: Clement.David at esi-group.com (=?iso-8859-1?Q?Cl=E9ment_David?=)
Date: Tue, 30 Oct 2018 12:51:36 +0000
Subject: [Scilab-Dev] Big literal integers for int64() and uint64()
In-Reply-To: <c2b4b019-edcd-113e-d71b-5ff200078e9a@scilab-enterprises.com>
References: <def34a2e-5f00-cbd6-bb89-1f9d12dd9bea@free.fr>
 <2c5d75e4-5bed-fc9e-47d8-91f92471c281@scilab-enterprises.com>
 <9de6a4ab-c0ef-af8b-91c1-dd875d8a524a@free.fr>
 <c2b4b019-edcd-113e-d71b-5ff200078e9a@scilab-enterprises.com>
Message-ID: <AM6PR0502MB370204A888D765F37466B7F3B0CC0@AM6PR0502MB3702.eurprd05.prod.outlook.com>

Hello all, 

 

Nice implementation ! IMHO `double()` might also be extended to support a
string, do you expect any other functions to be impacted by ?string
interpretation? on type conversion ?

 

Thanks,

 

--

Cl?ment

 

From: dev <dev-bounces at lists.scilab.org> On Behalf Of Antoine ELIAS
Sent: Saturday, October 27, 2018 8:29 PM
To: dev at lists.scilab.org
Subject: Re: [Scilab-Dev] Big literal integers for int64() and uint64()

 

Hello again,
I worked on it ( challenge accepted ! )

I took a look of your implementation, I'm not sure it is necessary to remove
trailing white spaces or inner spaces ( " 1 000 000 " is not a correct
representation of a number, that's all ! )
Or you have to manage "\t", "," or any localized separator.

In lot of language when you convert "123toto" you get 123 not an error.
And does not allow "1.123" is a mistake for me since uint64(1.123) ->
1(ui64).

I made an implementation in builtin for all (u)int functions that raises
error only on too long input string ("10000000000000000000" for example )
and empty string ( but we can convert to 0 like %nan )
I manage "nan", "NaN" "%nan", "inf", "Inf", "%inf", "-inf", "-Inf", "-%inf"
to respectively 0, minval and maxval
And "icing on the cake", is little bit faster than yours :p
(between 2 and 100 times depending of input size, C++ vs script)

(missing NRT, changes ... but it is Saturday ^^ )
https://codereview.scilab.org/#/c/20587/

Regards,
Antoine

Le 27/10/2018 ? 17:34, Samuel Gougeon a ?crit :

Hello Antoine,

Thanks for your answer.
I have opened a bug report #15837
<http://bugzilla.scilab.org/show_bug.cgi?id=15837>  about this topic.

About the overload:

Le 27/10/2018 ? 14:00, Antoine ELIAS a ?crit :

Hello Samuel,

Currently, parser ... lexer, in fact, try to read "number" and convert it to
floating point number, at this moment, we have no idea what the final goal
of this number.
After that, the parser try to understand what to do with this number
(already a double).
So I think the first case is not possible with the current management of
numbers.

For string argument, I think it cannot be done easily in an overload macro
for the same reason.


In the report, i have posted a proposal for a working 11-rows-long
%c_uint64() overload (without the error messages ;)
With it, we get for instance

--> %c_uint64("9000000000000001000") + [ 1 -1001 ; 4 7]
 ans  =
  9000000000000001001  8999999999999999999
  9000000000000001004  9000000000000001007

whereas
--> uint64(9000000000000001000) + [ 1 -1001 ; 4 7]
 ans  =
  9000000000000001025  9000000000000000023
  9000000000000001028  9000000000000001031

It can process any relevant input array of any number of dimensions.

Best regards
Samuel






_______________________________________________
dev mailing list
dev at lists.scilab.org <mailto: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/20181030/bef2e167/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4425 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/dev/attachments/20181030/bef2e167/attachment.p7s>

From sgougeon at free.fr  Tue Oct 30 14:24:43 2018
From: sgougeon at free.fr (Samuel Gougeon)
Date: Tue, 30 Oct 2018 14:24:43 +0100
Subject: [Scilab-Dev] Big literal integers for int64() and uint64()
In-Reply-To: <AM6PR0502MB370204A888D765F37466B7F3B0CC0@AM6PR0502MB3702.eurprd05.prod.outlook.com>
References: <def34a2e-5f00-cbd6-bb89-1f9d12dd9bea@free.fr>
 <2c5d75e4-5bed-fc9e-47d8-91f92471c281@scilab-enterprises.com>
 <9de6a4ab-c0ef-af8b-91c1-dd875d8a524a@free.fr>
 <c2b4b019-edcd-113e-d71b-5ff200078e9a@scilab-enterprises.com>
 <AM6PR0502MB370204A888D765F37466B7F3B0CC0@AM6PR0502MB3702.eurprd05.prod.outlook.com>
Message-ID: <73976421-4fa9-0a79-4d59-857f998054ef@free.fr>

Hello,

Le 30/10/2018 ? 13:51, Cl?ment David a ?crit :
>
> Hello all,
>
> Nice implementation ! IMHO `double()` might also be extended to 
> support a string,
>

The question is: What to do? With wich features?
It would be a nice replacement of strtod(). IMO, it should in no way 
duplicate it.

But is it really a priority?
There are already too many functions all doing rather the same thing, 
and rather weakly:
strtod(), msscanf(), evstr() (and still eval().. whose removal is not 
yet merged <https://codereview.scilab.org/19797>).

However, there are certainly priorities in matter of string conversion. 
Noticeably,
currently, there is no way to read imaginary parts of complex numbers
as text, and convert them into numeric type.

You may have a look at a (still) vain analysis at 
http://bugzilla.scilab.org/4401
As well, supporting hexa and octal string input is requested for msscanf()
there http://bugzilla.scilab.org/8905 . These formats are also discussed 
as strtod()
possible input (with the same tolerance (and output) about any trailing 
part),
in the bug 4401 report.

Bets regards
Samuel

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

From sgougeon at free.fr  Tue Oct 30 14:33:30 2018
From: sgougeon at free.fr (Samuel Gougeon)
Date: Tue, 30 Oct 2018 14:33:30 +0100
Subject: [Scilab-Dev] Big literal integers for int64() and uint64()
In-Reply-To: <73976421-4fa9-0a79-4d59-857f998054ef@free.fr>
References: <def34a2e-5f00-cbd6-bb89-1f9d12dd9bea@free.fr>
 <2c5d75e4-5bed-fc9e-47d8-91f92471c281@scilab-enterprises.com>
 <9de6a4ab-c0ef-af8b-91c1-dd875d8a524a@free.fr>
 <c2b4b019-edcd-113e-d71b-5ff200078e9a@scilab-enterprises.com>
 <AM6PR0502MB370204A888D765F37466B7F3B0CC0@AM6PR0502MB3702.eurprd05.prod.outlook.com>
 <73976421-4fa9-0a79-4d59-857f998054ef@free.fr>
Message-ID: <4f16b9ec-3dcd-cd7c-ea66-fc7670c5fd35@free.fr>

Le 30/10/2018 ? 14:24, Samuel Gougeon a ?crit :
> Hello,
>
> Le 30/10/2018 ? 13:51, Cl?ment David a ?crit :
>>
>> Hello all,
>>
>> Nice implementation ! IMHO `double()` might also be extended to 
>> support a string,
>>
>
> The question is: What to do? With wich features?
> It would be a nice replacement of strtod(). IMO, it should in no way 
> duplicate it.
>
> But is it really a priority?
> There are already too many functions all doing rather the same thing, 
> and rather weakly:
> strtod(), msscanf(), evstr() (and still eval().. whose removal is not 
> yet merged <https://codereview.scilab.org/19797>).
>
> However, there are certainly priorities in matter of string 
> conversion. Noticeably,
> currently, there is no way to read imaginary parts of complex numbers
> as text, and convert them into numeric type.


csvTextScan() (another guy..) does it. It is definitely not emphasized 
in its description.
It has only a small not-illustrated example. But it does it.

Samuel

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