From akraus39 at gmail.com Tue Dec 1 11:09:25 2020 From: akraus39 at gmail.com (PaY_DaY) Date: Tue, 1 Dec 2020 03:09:25 -0700 (MST) Subject: [Scilab-users] Change input values while simulation is running Message-ID: <1606817365392-0.post@n3.nabble.com> Hello guys, I'm facing the problem that I need to change my input values of my HIL with an Arduino as I/O-Device (Arduino Toolbox). Right now I am using tk-scale blocks but that feels so bad and I want to scale my project with more than one HIL-Device. Have you guys any idea if it's possible to create my own UI to change the parameters in real time? Microdaq offers a solution with Labview but it's only for their products. Thanks advance and best regards -- Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html From tanchinluh at gmail.com Thu Dec 3 02:10:06 2020 From: tanchinluh at gmail.com (TanCL) Date: Wed, 2 Dec 2020 18:10:06 -0700 (MST) Subject: [Scilab-users] ipcv vs scicv In-Reply-To: References: Message-ID: <1606957806191-0.post@n3.nabble.com> Hi, my previous message seems like not able to get posted due to some reason, just to add some comment on this, I think the functions with same name under 2 different modules could be possibly called by: moduleA.myfunc moduleB.myfunc ______________________ Start Toolbox A Load macros Start Toolbox B Load macros --> toolboxAlib.scilab_sum(2,1) "This is function from ToolboxA" ans = 3. --> toolboxBlib.scilab_sum(2,1) "This is function from ToolboxB" ans = 3. -- Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html From tanchinluh at gmail.com Thu Dec 3 02:16:07 2020 From: tanchinluh at gmail.com (TanCL) Date: Wed, 2 Dec 2020 18:16:07 -0700 (MST) Subject: [Scilab-users] image insertion using scicv In-Reply-To: References: Message-ID: <1606958167644-0.post@n3.nabble.com> I believe both modules treat the image differently, scicv treat the image as OpenCV object, while IPCV import image as Scilab matrix. so when you try to implement a small image into a part of a big image in IPCV, you could simply using Scilab way, say A is 256x256x3, and B is 64x64x3, u can use the assignment such as A(1:64,1:64,:) = B; e,g: --> S = imread('linear.png'); --> S2 = rand(64,64,3).*255; --> S2 = uint8(S2); --> S(1:64,1:64,:) = S2; --> imshow(S2); --> imshow(S); -- Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html From fmiyara at fceia.unr.edu.ar Thu Dec 3 06:33:44 2020 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Thu, 3 Dec 2020 02:33:44 -0300 Subject: [Scilab-users] linear prediction model Message-ID: <43340658-cbc3-6426-4a06-d6962b8eb478@fceia.unr.edu.ar> Dear All, Is there a script or function somewhere which calculates the Linear prediction model (LPC) of a signal frame? I tried to implement a function (below) without using the algorithm of Levinson & Durbin but it doesn't seem to work properly. seemingly the problem is due to inaccuracy of the matrix equation solution. Regards, Federico Miyara function a=lpc(x, p) // Calculation of the LPC coeficients // Usage: // a = lpc(x, p) // where // x: Signal vector // p: Order of the linear prediction model // a: Coefficients of the linear prediction model // // The coefficients are computed so to get minimize the // prediction error by the least-square method // // ------------------------------ // Author: Federico Miyara // Date: 20202-09-27 if 1==2 // Test data --delete-- // LPC order p = 10 // Signal length N = 512 // Create whiter noise exec whitenoise.sci; y = whitenoise(2*N-1,1); // Create a filter // Create some poles within the unit circle for stability pol = 0.7 + %i*linspace(-0.3,0.3,10) // Denominator polynomial in z AAA = real(prod(%z - pol)) // Theoretical LPC coefficients aa = -coeff(AAA)($-1:-1:1) // Autorregressive (AR) transfer function HH = 1/(1 - sum(aa.*%z^(-(1:p)))) // Numerator and denominator BB = HH.num AA = HH.den // Filter white noise x = filter(BB, AA, y); x = x(N+1:2*N); plot(x) end for h = 1:p // Row h for i = 1:p // Column i A(h,i) = sum(x(p+1-i:$-i).*x(p+1-h:$-h)); end B(h) = sum(x(p+1:$).*x(p+1-h:$-h)); end a = ((inv(A)*B))'; if 1==2 H = 1/(1 - sum(a.*%z^(-(1:p)))) // Numerator and denominator B1 = H.num A1 = H.den // Filter white noise x1 = filter(B1, A1, y); x1 = x1(N+1:2*N); plot(x1) end endfunction -- El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine.monmayrant at laas.fr Thu Dec 3 09:48:24 2020 From: antoine.monmayrant at laas.fr (Antoine Monmayrant) Date: Thu, 3 Dec 2020 09:48:24 +0100 Subject: [Scilab-users] Headless graphics in scilab: time & memory issues Message-ID: Hello all, In these days of remote working, I need to use again scilab in headless mode to generate graphics. In other words, I connect? in command line only to a remote server where scilab is installed and I want it to generate graphics using a combination of driver, xinit and xend. There seems to be some issues with driver/xinit/xend: huge memory overhead and long computation time that makes it impossible to generate some plots in headless mode. For example, a simple Sgrayplot that takes ~1 second to plot and save to a png in normal mode takes more than 200 seconds and huge amount of ram in headless mode (see attached test script). I also have some plots that works without a problem in normal mode, but fail in headless mode because of some memory limitation: xend: An error occurred: Unable to create export file, not enough memory. Decreasing the number of elements or the size of the figure should fix this error. Is there a way to get around these problems? Thanks for your help, Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xend_test.sce Type: application/x-scilab-sce Size: 486 bytes Desc: not available URL: From antoine.monmayrant at laas.fr Thu Dec 3 09:59:56 2020 From: antoine.monmayrant at laas.fr (Antoine Monmayrant) Date: Thu, 3 Dec 2020 09:59:56 +0100 Subject: [Scilab-users] Headless graphics in scilab: time & memory issues In-Reply-To: References: Message-ID: <037ad3a9-7e49-dbd3-7748-522fa7cb3bb6@laas.fr> Hello again, Just to add to my previous message: increasing nx or ny in my script can crash scilab during the call to xend(). On my small local machine, this occurs for: nx=4000; ny=3000; for which scilab takes ~7 seconds to create the png in "normal" mode... Can any of you confirm this bug? Antoine On 03/12/2020 09:48, Antoine Monmayrant wrote: > > Hello all, > > In these days of remote working, I need to use again scilab in > headless mode to generate graphics. > > In other words, I connect? in command line only to a remote server > where scilab is installed and I want it to generate graphics using a > combination of driver, xinit and xend. > > There seems to be some issues with driver/xinit/xend: huge memory > overhead and long computation time that makes it impossible to > generate some plots in headless mode. > > For example, a simple Sgrayplot that takes ~1 second to plot and save > to a png in normal mode takes more than 200 seconds and huge amount of > ram in headless mode (see attached test script). > > I also have some plots that works without a problem in normal mode, > but fail in headless mode because of some memory limitation: > > xend: An error occurred: Unable to create export file, not enough > memory. Decreasing the number of elements or the size of the > figure should fix this error. > > Is there a way to get around these problems? > > Thanks for your help, > > Antoine > > > > > > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christophe.Dang at sidel.com Thu Dec 3 10:27:41 2020 From: Christophe.Dang at sidel.com (Dang Ngoc Chan, Christophe) Date: Thu, 3 Dec 2020 09:27:41 +0000 Subject: [Scilab-users] {EXT} Re: Headless graphics in scilab: time & memory issues In-Reply-To: <037ad3a9-7e49-dbd3-7748-522fa7cb3bb6@laas.fr> References: <037ad3a9-7e49-dbd3-7748-522fa7cb3bb6@laas.fr> Message-ID: Hello Antoine, > De : Antoine Monmayrant > Envoy? : jeudi 3 d?cembre 2020 10:00 > > Can any of you confirm this bug? I don't know what you mean by headless mode but I get the same error as you error when I run your script (except it is in Franch): "xs2png : Impossible de cr?er le fichier d'export, pas assez de m?moire disponible. Diminuer le nombre d'?l?ments ou la taille de la figure devrait corriger cette erreur." Regards -- Christophe Dang Ngoc Chan Mechanical calculation engineer General This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From stephane.mottelet at utc.fr Thu Dec 3 10:46:41 2020 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Thu, 3 Dec 2020 10:46:41 +0100 Subject: [Scilab-users] Headless graphics in scilab: time & memory issues In-Reply-To: References: Message-ID: <304eb306-4302-295d-3cc5-3df3114f6efd@utc.fr> Hello Antoine, Exporting in headless mode (all drivers but the default "Rec") is fundamentally different from the default "Rec" mode where graphics are actually rendered on screen on a joGL Canvas. In this case there is virtually no overhead when exporting this Canvas to a bitmap image format (png,jpeg,gif,...). In headless mode the rendering cannot use joGL and there is the same overhead as when you try to export a figure to a vectorial format (svg,pdf,eps) : nx=4000; ny=300; nc=100; x=1:nx; y=[1:ny].'; z=(y*x); driver Rec h=scf(); h.color_map=hotcolormap(nc); Sgrayplot(x,y,z.'); xs2pdf(h,"screen.pdf") at line??? 13 of executed file /Users/mottelet/Desktop/xend_test.sce xs2pdf: Unable to create export file, not enough memory. Decreasing the number of elements or the size of the figure should fix this error. S. Le 03/12/2020 ? 09:48, Antoine Monmayrant a ?crit?: > > Hello all, > > In these days of remote working, I need to use again scilab in > headless mode to generate graphics. > > In other words, I connect? in command line only to a remote server > where scilab is installed and I want it to generate graphics using a > combination of driver, xinit and xend. > > There seems to be some issues with driver/xinit/xend: huge memory > overhead and long computation time that makes it impossible to > generate some plots in headless mode. > > For example, a simple Sgrayplot that takes ~1 second to plot and save > to a png in normal mode takes more than 200 seconds and huge amount of > ram in headless mode (see attached test script). > > I also have some plots that works without a problem in normal mode, > but fail in headless mode because of some memory limitation: > > xend: An error occurred: Unable to create export file, not enough > memory. Decreasing the number of elements or the size of the > figure should fix this error. > > Is there a way to get around these problems? > > Thanks for your help, > > Antoine > > > > > > > > _______________________________________________ > users mailing list > users at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -- 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: From antoine.monmayrant at laas.fr Thu Dec 3 11:01:15 2020 From: antoine.monmayrant at laas.fr (Antoine Monmayrant) Date: Thu, 3 Dec 2020 11:01:15 +0100 Subject: [Scilab-users] Headless graphics in scilab: time & memory issues In-Reply-To: <304eb306-4302-295d-3cc5-3df3114f6efd@utc.fr> References: <304eb306-4302-295d-3cc5-3df3114f6efd@utc.fr> Message-ID: On 03/12/2020 10:46, St?phane Mottelet wrote: > In headless mode the rendering cannot use joGL and there is the same > overhead as when you try to export a figure to a vectorial format > (svg,pdf,eps) : OK thanks for the clarification. That's a weird and unexpected limitation, no? I would not have guessed that going headless and using a bitmap format would result in facing this limitation. Moreover, there is still a memory issue as I can crash scilab when pushing things a bit further. Antoine From stephane.mottelet at utc.fr Thu Dec 3 11:20:23 2020 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Thu, 3 Dec 2020 11:20:23 +0100 Subject: [Scilab-users] Headless graphics in scilab: time & memory issues In-Reply-To: References: <304eb306-4302-295d-3cc5-3df3114f6efd@utc.fr> Message-ID: <0eaef19d-43ec-7338-9493-605b887323c1@utc.fr> Le 03/12/2020 ? 11:01, Antoine Monmayrant a ?crit?: > > On 03/12/2020 10:46, St?phane Mottelet wrote: >> In headless mode the rendering cannot use joGL and there is the same >> overhead as when you try to export a figure to a vectorial format >> (svg,pdf,eps) : > > > OK thanks for the clarification. > That's a weird and unexpected limitation, no? No. In fact fast offscreen rendering is possible in joGL. In my previous answer I should have said "In headless mode the rendering *does not* use joGL". The pity is that the main author of Scilab Graphics Java backend has left the team long time ago. It would have been an easy task for him. If your project is hosted on a Linux server, I would advise you to redirect the display of your Scilab instance to a virtual frame buffer by using any flavor of VNC (TurboVNC is nice as the server can use the hardware GPU capabilities of the server). In this case you can stick to the Rec driver and j xs2png (or any bitmap variant) will be fast. That's what I used with xmllab many years ago... S. > I would not have guessed that going headless and using a bitmap format > would result in facing this limitation. > Moreover, there is still a memory issue as I can crash scilab when > pushing things a bit further. > > Antoine > > _______________________________________________ > users mailing list > users at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users > -- 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 Thu Dec 3 11:24:16 2020 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Thu, 3 Dec 2020 11:24:16 +0100 Subject: [Scilab-users] Headless graphics in scilab: time & memory issues In-Reply-To: <0eaef19d-43ec-7338-9493-605b887323c1@utc.fr> References: <304eb306-4302-295d-3cc5-3df3114f6efd@utc.fr> <0eaef19d-43ec-7338-9493-605b887323c1@utc.fr> Message-ID: The xmllab is actually still working, try e.g. http://marguerite.lmac.utc.fr/~xmllab/cgi-bin/XMLlabServer.cgi?timing=no&lang=english&simulation=/home/xmllab/scilab-5.5.2/share/scilab/contrib/xmllab/1.7.6//examples/Image-Processing/clown.xml&action=launch S. Le 03/12/2020 ? 11:20, St?phane Mottelet a ?crit?: > > Le 03/12/2020 ? 11:01, Antoine Monmayrant a ?crit?: >> >> On 03/12/2020 10:46, St?phane Mottelet wrote: >>> In headless mode the rendering cannot use joGL and there is the same >>> overhead as when you try to export a figure to a vectorial format >>> (svg,pdf,eps) : >> >> >> OK thanks for the clarification. >> That's a weird and unexpected limitation, no? > > No. In fact fast offscreen rendering is possible in joGL. In my > previous answer I should have said "In headless mode the rendering > *does not* use joGL". The pity is that the main author of Scilab > Graphics Java backend has left the team long time ago. It would have > been an easy task for him. > > If your project is hosted on a Linux server, I would advise you to > redirect the display of your Scilab instance to a virtual frame buffer > by using any flavor of VNC (TurboVNC is nice as the server can use the > hardware GPU capabilities of the server). In this case you can stick > to the Rec driver and j xs2png (or any bitmap variant) will be fast. > That's what I used with xmllab many years ago... > > S. > >> I would not have guessed that going headless and using a bitmap >> format would result in facing this limitation. >> Moreover, there is still a memory issue as I can crash scilab when >> pushing things a bit further. >> >> Antoine >> >> _______________________________________________ >> users mailing list >> users at lists.scilab.org >> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users >> > -- 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 cfuttrup at gmail.com Thu Dec 3 16:37:09 2020 From: cfuttrup at gmail.com (Claus Futtrup) Date: Thu, 3 Dec 2020 16:37:09 +0100 Subject: [Scilab-users] ipcv vs scicv In-Reply-To: <1606957806191-0.post@n3.nabble.com> References: <1606957806191-0.post@n3.nabble.com> Message-ID: <0854879a-54d0-1342-1ad9-aea2cca1e181@gmail.com> Hi Tan I agree. The proposal, is it something we can do ourselves now, or will it require implementation into Scilab first? Thank you for resending. /Claus On 03-12-2020 02:10, TanCL wrote: > Hi, my previous message seems like not able to get posted due to some reason, > just to add some comment on this, I think the functions with same name under > 2 different modules could be possibly called by: > > moduleA.myfunc > > moduleB.myfunc > > > ______________________ > > Start Toolbox A > Load macros > > Start Toolbox B > Load macros > > > --> toolboxAlib.scilab_sum(2,1) > > "This is function from ToolboxA" > ans = > > 3. > > --> toolboxBlib.scilab_sum(2,1) > > "This is function from ToolboxB" > ans = > > 3. > > > > > > -- > 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 From antoine.monmayrant at laas.fr Thu Dec 3 17:28:52 2020 From: antoine.monmayrant at laas.fr (Antoine Monmayrant) Date: Thu, 3 Dec 2020 17:28:52 +0100 Subject: [Scilab-users] ipcv vs scicv In-Reply-To: <1606957806191-0.post@n3.nabble.com> References: <1606957806191-0.post@n3.nabble.com> Message-ID: On 03/12/2020 02:10, TanCL wrote: > Hi, my previous message seems like not able to get posted due to some reason, > just to add some comment on this, I think the functions with same name under > 2 different modules could be possibly called by: That is exactly how things are working in Ada: myfunc : local definition in the current file somepackage.myfunc : definition one can find in somepackage that is included in the current file by "with somepackage;" And one can rename the package with "package S renames somepackage" which allow writting "s.myfunc" I assume it's similar in Python too. Antoine > moduleA.myfunc > > moduleB.myfunc > > > ______________________ > > Start Toolbox A > Load macros > > Start Toolbox B > Load macros > > > --> toolboxAlib.scilab_sum(2,1) > > "This is function from ToolboxA" > ans = > > 3. > > --> toolboxBlib.scilab_sum(2,1) > > "This is function from ToolboxB" > ans = > > 3. > > > > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Thu Dec 3 17:36:29 2020 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Thu, 3 Dec 2020 17:36:29 +0100 Subject: [Scilab-users] ipcv vs scicv In-Reply-To: References: <1606957806191-0.post@n3.nabble.com> Message-ID: This is the way it works in scilab for libraries: mkdir lib1 mputl("function y=foo(x);y=x;end","lib1/foo.sci") genlib("lib1","lib1") mkdir lib2 mputl("function y=foo(x);y=2*x;end","lib2/foo.sci") genlib("lib2","lib2") lib("lib1") lib("lib2") -> lib1.foo(1) ans = 1. --> lib2.foo(1) ans = 2. S. Le 03/12/2020 ? 17:28, Antoine Monmayrant a ?crit?: > > > On 03/12/2020 02:10, TanCL wrote: >> Hi, my previous message seems like not able to get posted due to some reason, >> just to add some comment on this, I think the functions with same name under >> 2 different modules could be possibly called by: > > That is exactly how things are working in Ada: > > myfunc : local definition in the current file > somepackage.myfunc : definition one can find in somepackage that > is included in the current file by "with somepackage;" > > And one can rename the package with "package S renames somepackage" > which allow writting "s.myfunc" > I assume it's similar in Python too. > > Antoine > >> moduleA.myfunc >> >> moduleB.myfunc >> >> >> ______________________ >> >> Start Toolbox A >> Load macros >> >> Start Toolbox B >> Load macros >> >> >> --> toolboxAlib.scilab_sum(2,1) >> >> "This is function from ToolboxA" >> ans = >> >> 3. >> >> --> toolboxBlib.scilab_sum(2,1) >> >> "This is function from ToolboxB" >> ans = >> >> 3. >> >> >> >> >> >> -- >> 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 > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -- 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: From tanchinluh at gmail.com Fri Dec 4 01:57:09 2020 From: tanchinluh at gmail.com (Chin Luh Tan) Date: Fri, 4 Dec 2020 08:57:09 +0800 Subject: [Scilab-users] ipcv vs scicv In-Reply-To: References: <1606957806191-0.post@n3.nabble.com> Message-ID: Hi all, Stephane, Thanks for the quick examples to illustrate this. Claus, as shown by Stephane, this could be now by ourselves now from our own modules. Stephane has illustrated a quick demo on this, while the one I was testing with is the copy of toolbox skeleton inside the Scilab contrib, modified to 2 modules, installed with atoms and let it load at start, results are the same. There are 2 potential issues which we should take notes: 1. The module which is loaded last, will have the "dominant" in the base function. for e.g.: the example that Stephane showed, we could call "lib1.foo" and "lib2.foo", and calling just "foo" will be the same as "lib2.foo". 2. Only macros function could be called this way, if a module has a scilab gateway that called direct from Scilab, (such as scicv), you could not call scicvlib.imread as the imread is directly expose from the C lib to Scilab. So during the design of the module, you could have a macros wrapper to call the gateway functions so that they could be listed in the library's macros list. Thanks. rgds, CL On Fri, 4 Dec 2020 at 00:36, St?phane Mottelet wrote: > This is the way it works in scilab for libraries: > > mkdir lib1mputl("function y=foo(x);y=x;end","lib1/foo.sci")genlib("lib1","lib1")mkdir lib2mputl("function y=foo(x);y=2*x;end","lib2/foo.sci")genlib("lib2","lib2")lib("lib1")lib("lib2") > -> lib1.foo(1) > ans = > > 1. > --> lib2.foo(1) > ans = > > 2. > > > S. > > Le 03/12/2020 ? 17:28, Antoine Monmayrant a ?crit : > > > On 03/12/2020 02:10, TanCL wrote: > > Hi, my previous message seems like not able to get posted due to some reason, > just to add some comment on this, I think the functions with same name under > 2 different modules could be possibly called by: > > That is exactly how things are working in Ada: > > myfunc : local definition in the current file > somepackage.myfunc : definition one can find in somepackage that is > included in the current file by "with somepackage;" > > And one can rename the package with "package S renames somepackage" which > allow writting "s.myfunc" > I assume it's similar in Python too. > > Antoine > > moduleA.myfunc > > moduleB.myfunc > > > ______________________ > > Start Toolbox A > Load macros > > Start Toolbox B > Load macros > > > --> toolboxAlib.scilab_sum(2,1) > > "This is function from ToolboxA" > ans = > > 3. > > --> toolboxBlib.scilab_sum(2,1) > > "This is function from ToolboxB" > ans = > > 3. > > > > > > -- > Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html > _______________________________________________ > users mailing listusers at lists.scilab.orghttp://lists.scilab.org/mailman/listinfo/users > > > _______________________________________________ > users mailing listusers at lists.scilab.orghttps://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users > > -- > 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)344234688http://www.utc.fr/~mottelet > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Dec 4 19:36:48 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 4 Dec 2020 19:36:48 +0100 Subject: [Scilab-users] ipcv vs scicv In-Reply-To: References: <1606957806191-0.post@n3.nabble.com> Message-ID: <0b1b5b89-bc94-b647-8ae4-900aaf1f99d4@free.fr> Hello Chin Luh, Le 04/12/2020 ? 01:57, Chin Luh Tan a ?crit?: > Hi all, > > Stephane, Thanks for the quick? examples to illustrate this. > > Claus, as shown by Stephane, this could be now by ourselves now from > our own modules. Stephane has illustrated a quick demo on this, while > the one I was testing with is the copy of toolbox skeleton inside the > Scilab contrib, modified to 2 modules, installed with atoms and let it > load at start, results are the same. > > There are 2 potential issues which we should take notes: > 1. The module which is loaded last, will have the "dominant" in the > base function. Are you sure about this? This was the rule with Scilab 5, but the removal of the variables stack changed it within Scilab 6. I noticed with Scilab 6.0 that the libraries are scanned for the required function only after sorting their names in anti-alphabetical order. So if both alib.myfunc() and zlib.myfunc() exist, myfunc() will call zlib.myfunc(), whatever is the loading order of alib and zlib. On this respect, neither the https://help.scilab.org/docs/6.1.0/en_US/library.html page is up-to-date, not other pages dealing with libraries, like the genlib(). Here is the test: File = TMPDIR+"\test\"; mkdir(File+"alib"); mkdir(File+"zlib"); code = [ "function test()" ; "disp(""test from alib"")" ; "endfunction"]; mputl(code, File+"alib\test.sci"); genlib("alib", File+"alib"); code = [ "function test()" ; "disp(""test from zlib"")" ; "endfunction"]; mputl(code, File+"zlib\test.sci"); genlib("zlib", File+"zlib"); clear alib zlib load(File+"zlib\lib") load(File+"alib\lib") test() --> test() "test from zlib" > for e.g.: the example that Stephane showed, we could call "lib1.foo" > and "lib2.foo", and calling just "foo" will be the same as? "lib2.foo". > 2. Only macros function could be called this way, if a module has a > scilab gateway that called?direct from Scilab, (such as scicv), you > could not call scicvlib.imread?as the imread is directly expose from > the C lib to Scilab. This is true only if the homonymous function is called without specifying its library. Otherwise, the name resolution works: File = TMPDIR+"\test\"; mkdir(File+"alib"); code = [ "function cos(a)" ; "disp(""cos() from alib"")" ; "endfunction"]; mputl(code, File+"alib\cos.sci"); genlib("alib", File+"alib"); clear alib load(File+"alib\lib") cos(1) alib.cos(1) --> cos(1) ?ans? = ?? 0.5403023 --> alib.cos(1) ? "cos() from alib" Best regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From tanchinluh at gmail.com Sat Dec 5 01:55:22 2020 From: tanchinluh at gmail.com (Chin Luh Tan) Date: Sat, 5 Dec 2020 08:55:22 +0800 Subject: [Scilab-users] ipcv vs scicv In-Reply-To: <0b1b5b89-bc94-b647-8ae4-900aaf1f99d4@free.fr> References: <1606957806191-0.post@n3.nabble.com> <0b1b5b89-bc94-b647-8ae4-900aaf1f99d4@free.fr> Message-ID: Hi Samuel, Thanks for your details explanations and examples, they are really helpful. Yes you're right, the functions loaded are base on what you have describe, not depending on the order the modules being loaded. Thanks for pointing this out. Regards, Chin Luh On Sat, 5 Dec 2020 at 02:37, Samuel Gougeon wrote: > Hello Chin Luh, > > Le 04/12/2020 ? 01:57, Chin Luh Tan a ?crit : > > Hi all, > > Stephane, Thanks for the quick examples to illustrate this. > > Claus, as shown by Stephane, this could be now by ourselves now from our > own modules. Stephane has illustrated a quick demo on this, while the one I > was testing with is the copy of toolbox skeleton inside the Scilab contrib, > modified to 2 modules, installed with atoms and let it load at start, > results are the same. > > There are 2 potential issues which we should take notes: > 1. The module which is loaded last, will have the "dominant" in the base > function. > > Are you sure about this? This was the rule with Scilab 5, but the removal > of the variables stack changed it within Scilab 6. I noticed with Scilab > 6.0 that the libraries are scanned for the required function only after > sorting their names in anti-alphabetical order. > So if both alib.myfunc() and zlib.myfunc() exist, myfunc() will call > zlib.myfunc(), whatever is the loading order of alib and zlib. > > On this respect, neither the > https://help.scilab.org/docs/6.1.0/en_US/library.html page is up-to-date, > not other pages dealing with libraries, like the genlib(). > Here is the test: > > File = TMPDIR+"\test\";mkdir(File+"alib");mkdir(File+"zlib"); > code = [ "function test()" ; " disp(""test from alib"")" ; "endfunction"];mputl(code, File+"alib\test.sci");genlib("alib", File+"alib"); > code = [ "function test()" ; " disp(""test from zlib"")" ; "endfunction"];mputl(code, File+"zlib\test.sci");genlib("zlib", File+"zlib"); > clear alib zlibload(File+"zlib\lib")load(File+"alib\lib") > test() > --> test() > "test from zlib" > > for e.g.: the example that Stephane showed, we could call "lib1.foo" and > "lib2.foo", and calling just "foo" will be the same as "lib2.foo". > 2. Only macros function could be called this way, if a module has a scilab > gateway that called direct from Scilab, (such as scicv), you could not call > scicvlib.imread as the imread is directly expose from the C lib to Scilab. > > This is true only if the homonymous function is called without specifying > its library. Otherwise, the name resolution works: > > File = TMPDIR+"\test\";mkdir(File+"alib");code = [ "function cos(a)" ; " disp(""cos() from alib"")" ; "endfunction"];mputl(code, File+"alib\cos.sci");genlib("alib", File+"alib");clear alibload(File+"alib\lib") > cos(1)alib.cos(1) > > > --> cos(1) > ans = > 0.5403023 > > --> alib.cos(1) > "cos() from alib" > > Best regards > Samuel > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.muehlmann at gmail.com Mon Dec 7 09:02:20 2020 From: p.muehlmann at gmail.com (P M) Date: Mon, 7 Dec 2020 09:02:20 +0100 Subject: [Scilab-users] ipcv vs scicv In-Reply-To: References: <1606957806191-0.post@n3.nabble.com> <0b1b5b89-bc94-b647-8ae4-900aaf1f99d4@free.fr> Message-ID: Please enlighten me....on my PC the current situation is like this: Scilab 6.1.0 Loading order 1: - scicv - IPCV --> in console: help imread --> img = imread(filename[,flag]) // hence the imread function from scicv is found / used (?) ------- Loading order 2: - IPCV - scicv --> in console: help imread --> im = imread(filename) --> im = imread(url) // hence the imread function from IPCV is found / used (?) Does this not describe what Chin Luh has mentioned? The behaviour described above would be different, when there is: scicv.imread IPCV.imread ...which is indeed python-like. Thanks for your patience. Philipp Am Sa., 5. Dez. 2020 um 01:56 Uhr schrieb Chin Luh Tan : > Hi Samuel, > > Thanks for your details explanations and examples, they are really > helpful. Yes you're right, the functions loaded are base on what you have > describe, not depending on the order the modules being loaded. Thanks for > pointing this out. > > Regards, > Chin Luh > > On Sat, 5 Dec 2020 at 02:37, Samuel Gougeon wrote: > >> Hello Chin Luh, >> >> Le 04/12/2020 ? 01:57, Chin Luh Tan a ?crit : >> >> Hi all, >> >> Stephane, Thanks for the quick examples to illustrate this. >> >> Claus, as shown by Stephane, this could be now by ourselves now from our >> own modules. Stephane has illustrated a quick demo on this, while the one I >> was testing with is the copy of toolbox skeleton inside the Scilab contrib, >> modified to 2 modules, installed with atoms and let it load at start, >> results are the same. >> >> There are 2 potential issues which we should take notes: >> 1. The module which is loaded last, will have the "dominant" in the base >> function. >> >> Are you sure about this? This was the rule with Scilab 5, but the removal >> of the variables stack changed it within Scilab 6. I noticed with Scilab >> 6.0 that the libraries are scanned for the required function only after >> sorting their names in anti-alphabetical order. >> So if both alib.myfunc() and zlib.myfunc() exist, myfunc() will call >> zlib.myfunc(), whatever is the loading order of alib and zlib. >> >> On this respect, neither the >> https://help.scilab.org/docs/6.1.0/en_US/library.html page is >> up-to-date, not other pages dealing with libraries, like the genlib(). >> Here is the test: >> >> File = TMPDIR+"\test\";mkdir(File+"alib");mkdir(File+"zlib"); >> code = [ "function test()" ; " disp(""test from alib"")" ; "endfunction"];mputl(code, File+"alib\test.sci");genlib("alib", File+"alib"); >> code = [ "function test()" ; " disp(""test from zlib"")" ; "endfunction"];mputl(code, File+"zlib\test.sci");genlib("zlib", File+"zlib"); >> clear alib zlibload(File+"zlib\lib")load(File+"alib\lib") >> test() >> --> test() >> "test from zlib" >> >> for e.g.: the example that Stephane showed, we could call "lib1.foo" and >> "lib2.foo", and calling just "foo" will be the same as "lib2.foo". >> 2. Only macros function could be called this way, if a module has a >> scilab gateway that called direct from Scilab, (such as scicv), you could >> not call scicvlib.imread as the imread is directly expose from the C lib to >> Scilab. >> >> This is true only if the homonymous function is called without specifying >> its library. Otherwise, the name resolution works: >> >> File = TMPDIR+"\test\";mkdir(File+"alib");code = [ "function cos(a)" ; " disp(""cos() from alib"")" ; "endfunction"];mputl(code, File+"alib\cos.sci");genlib("alib", File+"alib");clear alibload(File+"alib\lib") >> cos(1)alib.cos(1) >> >> >> --> cos(1) >> ans = >> 0.5403023 >> >> --> alib.cos(1) >> "cos() from alib" >> >> Best regards >> Samuel >> >> _______________________________________________ >> 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: From sgougeon at free.fr Mon Dec 7 18:12:53 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Mon, 7 Dec 2020 18:12:53 +0100 Subject: [Scilab-users] ipcv vs scicv In-Reply-To: References: <1606957806191-0.post@n3.nabble.com> <0b1b5b89-bc94-b647-8ae4-900aaf1f99d4@free.fr> Message-ID: Hello Philipp, Le 07/12/2020 ? 09:02, P M a ?crit?: > Please enlighten me....on my PC the current situation is like this: > > Scilab 6.1.0 > > Loading order 1: > - scicv > - IPCV > --> in console: help imread > > --> img = imread(filename[,flag])??????????? // hence the imread > function from scicv is found / used (?) I guess that you are here only calling the help, not the function. This is a different topic. I don't know how the help viewer manages homonymous pages from external modules (or even an external against an internal). Maybe yes the last loaded is the default one. Anyway, in the viewer, all modules and homonymous pages are displayed in distinct chapters. Now, we could address the way to force the viewer targeting a given chapter from the command line, for instance with something like --> help alib.cos If so, i am afraid that, to me, it will be a (very) low priority wish ;-) Regards Samuel From antoine.monmayrant at laas.fr Wed Dec 9 15:09:38 2020 From: antoine.monmayrant at laas.fr (Antoine Monmayrant) Date: Wed, 9 Dec 2020 15:09:38 +0100 Subject: [Scilab-users] unicode in variable names and Scinotes syntax highlighting Message-ID: <24db629c-624a-dbe0-5e17-87f14088ab39@laas.fr> Hi all, Scilab can use unicode characters (at least some) as variable names. However, this does not play well with Scinotes syntax highlighting in functions. In particular, input/output arguments are no longer highlighted and local line number inside the function does no longer work as expected. You can see the attached screenshot to better see what I mean. Here is a bunch of function definitions that shows the issue: function [Sum, Diff] = AddSubs(arga, argb) ??? Sum=arga+argb; ??? Diff=arga-argb; endfunction function [Sum, Diff] = AddSubs2(arg?, argb) ??? Sum=arg?+argb; ??? Diff=arg?-argb; endfunction function [Sum, ?] = AddSubs(arga, argb) ??? Sum=arga+argb; ??? Diff=arga-argb; endfunction Can anyone reproduce the issue? Cheers, Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: scinotes_unicode.png Type: image/png Size: 26760 bytes Desc: not available URL: From antoine.monmayrant at laas.fr Wed Dec 9 15:53:51 2020 From: antoine.monmayrant at laas.fr (Antoine Monmayrant) Date: Wed, 9 Dec 2020 15:53:51 +0100 Subject: [Scilab-users] unicode in variable names and Scinotes syntax highlighting In-Reply-To: <24db629c-624a-dbe0-5e17-87f14088ab39@laas.fr> References: <24db629c-624a-dbe0-5e17-87f14088ab39@laas.fr> Message-ID: <2483dc76-3618-2435-56d6-1d147593a253@laas.fr> Ah, and of course, there is a stupid bug in one of my functions! A virtual croissant to the first one to spot it! Antoine PS: BTW, it's one of the errors that should be easy to catch with a proper argument highlighting... On 09/12/2020 15:09, Antoine Monmayrant wrote: > > Hi all, > > Scilab can use unicode characters (at least some) as variable names. > However, this does not play well with Scinotes syntax highlighting in > functions. > In particular, input/output arguments are no longer highlighted and > local line number inside the function does no longer work as expected. > You can see the attached screenshot to better see what I mean. > > Here is a bunch of function definitions that shows the issue: > > function [Sum, Diff] = AddSubs(arga, argb) > > ??? Sum=arga+argb; > > ??? Diff=arga-argb; > > endfunction > > > function [Sum, Diff] = AddSubs2(arg?, argb) > > ??? Sum=arg?+argb; > > ??? Diff=arg?-argb; > > endfunction > > > function [Sum, ?] = AddSubs(arga, argb) > > ??? Sum=arga+argb; > > ??? Diff=arga-argb; > > endfunction > > Can anyone reproduce the issue? > > Cheers, > > Antoine > > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvulpillieres at gmail.com Fri Dec 11 19:20:06 2020 From: jvulpillieres at gmail.com (jvulpillieres) Date: Fri, 11 Dec 2020 11:20:06 -0700 (MST) Subject: [Scilab-users] Troubleshooting Scilab 6.1-branch installation on Mac Big Sur Message-ID: <1607710806728-0.post@n3.nabble.com> Hello, I downloaded and installed Scilab-branch-6.1 on MacOS Big Sur 11.0.1 from https://www.utc.fr/~mottelet/scilab_for_macOS.html Install process and Apple checking went smoothly. As mentioned, the needed Java Runtime Edition should be downloaded the first time I open Scilab. But the only thing I get when opening Scilab for the 1st time is a Mac OS error message: /? warning: failed to load external entity "/Library/Internet" warning: failed to load external entity "Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/../Info.plist" (1) ? / and Scilab doesn't launch further. I downloaded and installed a recent version of JRE but it doesn?t help. /julien at Julien-MacBookPro MacOS % /usr/libexec/java_home -V Matching Java Virtual Machines (1): 1.8.271.09 (x86_64) "Oracle Corporation" - "Java" /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/ I will be grateful for any help, Julien de Vulpilli?res IT teacher -- Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html From stephane.mottelet at utc.fr Fri Dec 11 19:45:22 2020 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Fri, 11 Dec 2020 19:45:22 +0100 Subject: [Scilab-users] Troubleshooting Scilab 6.1-branch installation on Mac Big Sur In-Reply-To: <1607710806728-0.post@n3.nabble.com> References: <1607710806728-0.post@n3.nabble.com> Message-ID: <08ef04dd-08f9-76a5-67cc-0efeacf70a75@utc.fr> Hi, Le 11/12/2020 ? 19:20, jvulpillieres a ?crit?: > Hello, > > I downloaded and installed Scilab-branch-6.1 on MacOS Big Sur 11.0.1 from > https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.utc.fr/~mottelet/scilab_for_macOS.html > Install process and Apple checking went smoothly. As mentioned, the needed > Java Runtime Edition should be downloaded the first time I open Scilab. This is not the case because you already have installed a JRE (but unfortunately the wrong one, see below). > > But the only thing I get when opening Scilab for the 1st time is a Mac OS > error message: > /? warning: failed to load external entity "/Library/Internet" > warning: failed to load external entity > "Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/../Info.plist" (1) ? / > and Scilab doesn't launch further. > > > I downloaded and installed a recent version of JRE but it doesn?t help. > /julien at Julien-MacBookPro MacOS % /usr/libexec/java_home -V > Matching Java Virtual Machines (1): > 1.8.271.09 (x86_64) "Oracle Corporation" - "Java" /Library/Internet > Plug-Ins/JavaAppletPlugin.plugin/Contents/Home > /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/ Seems that this is an Oracle JRE. You won't be able to run Scilab with it. Remove it from the system and let Scilab download itself the AdoptOpenJDK JRE at first run. S. > > I will be grateful for any help, > > Julien de Vulpilli?res > IT teacher > > > > -- > Sent from: https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html > _______________________________________________ > users mailing list > users at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -- 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 tanchinluh at gmail.com Mon Dec 14 05:44:24 2020 From: tanchinluh at gmail.com (Chin Luh Tan) Date: Mon, 14 Dec 2020 12:44:24 +0800 Subject: [Scilab-users] Atoms Modules Message-ID: Sometimes it is hard to decide whether to continue maintaining an atoms module or not.... So I did "snapshots" of downloads on 9/11/2020 21:44 and 14/12/2020 12:20 respectively to see which modules are in the actual top downloads. Still, this is not a fair result, such as IPCV having some "patches" which will increase the download number, and some other factors as well. So should IPCV continue to be maintained ...? Here's the results. Image Processing and Computer Vision Toolbox 4620 CPGE 3176 MinGw toolbox 2946 Arduino 2936 CelestLab 2841 iodelay toolbox 2429 Coselica 1812 SIMM 1800 Image Processing Design Toolbox 1394 Fuzzy Logic Toolbox 1186 Scilab Computer Vision Module 1129 GUI Builder 972 Scilab Image and Video Processing toolbox 860 Distfun 855 Apifun 804 Serial Communication Toolbox 781 Time Frequency Toolbox 776 Free Access Chemometric Toolbox 770 Autoelem Toolbox 768 Specfun 738 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Mon Dec 14 16:50:36 2020 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Mon, 14 Dec 2020 16:50:36 +0100 Subject: [Scilab-users] Scicolpack toolbox Message-ID: Hi all, A new toolbox has been uploaded at https://atoms.scilab.org/toolboxes/scicolpack: Scicolpack is is the Scilab interface to CSCsw/ColPack (https://github.com/CSCsw/ColPack), a Graph Coloring Algorithm Package applied to efficient computation of sparse Jacobian and Hessian. When you have to compute the Jacobian of a function f or the Hessian of f knowing its gradient g, once you know its sparsity pattern, even if you have derived it symbolically, it may still be faster to estimate it by using the techniques which are used by Colpack. Roughly speaking, this works by building a graph where each vertex is associated to a column of the Jacobian or Hessian, and an edge connects to vertices/columns if they are not structurally orthogonal, i.e. have at least one non-zero term in a common row. Then a proper coloring is done on this graph: at least, two adjacent vertices cannot have the same color, but more properties of the coloring may be expected. The coloring defines a partition of the columns under the form of p subsets and the Jacobian (resp. Hessian) can be recovered from only p evaluation of directional derivatives of f (resp. g). For example, for a tridiagonal matrix the value of p is 3. In the Scilab interface these directional derivatives are approximated by using finite differences (the toolbox allows to compute them by using the complex step technique up to machine precision). This toolbox can be an nice addon to SciIpopt toolbox (https://atoms.scilab.org/toolboxes/sci_ipopt) where the Interior Point algorithm can be greatly accelerated when the Hessian of the Lagrangian is sparse. When I have time I will update the demo section of the module to add such an example. Don't hesitate to report successful uses, bugs or whishes. For the moment the toolbox is available under OSX and Linux. Any help for a Windows build is welcome ! Best, -- 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 jvulpillieres at gmail.com Tue Dec 15 09:49:23 2020 From: jvulpillieres at gmail.com (jvulpillieres) Date: Tue, 15 Dec 2020 01:49:23 -0700 (MST) Subject: [Scilab-users] Troubleshooting Scilab 6.1-branch installation on Mac Big Sur In-Reply-To: <08ef04dd-08f9-76a5-67cc-0efeacf70a75@utc.fr> References: <1607710806728-0.post@n3.nabble.com> <08ef04dd-08f9-76a5-67cc-0efeacf70a75@utc.fr> Message-ID: <1608022163852-0.post@n3.nabble.com> Yes, it worked. Thank you for the tip. -- Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html From sgougeon at free.fr Tue Dec 15 18:58:03 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Tue, 15 Dec 2020 18:58:03 +0100 Subject: [Scilab-users] Headless graphics in scilab: time & memory issues In-Reply-To: <037ad3a9-7e49-dbd3-7748-522fa7cb3bb6@laas.fr> References: <037ad3a9-7e49-dbd3-7748-522fa7cb3bb6@laas.fr> Message-ID: <8d52301a-d667-bf6d-8535-2e43d90d9740@free.fr> Le 03/12/2020 ? 09:59, Antoine Monmayrant a ?crit?: > > Hello again, > > Just to add to my previous message: increasing nx or ny in my script > can crash scilab during the call to xend(). > On my small local machine, this occurs for: > > nx=4000; > ny=3000; > > for which scilab takes ~7 seconds to create the png in "normal" mode... > > Can any of you confirm this bug? > The crash is due to a too small Java Heap of memory. When increasing it through the user's Preferences from 256 MB to 1 GB, the PNG export works as fast as expected. I get i nice png image from 4000x3000 with --> tic(); Sgrayplot(x,y,z.'); toc() ?ans? = ?? 8.1342045 --> tic(); xs2png(0, "test.png"); toc ?ans? = ?? 0.4060765 Best regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Tue Dec 15 19:02:49 2020 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 15 Dec 2020 19:02:49 +0100 Subject: [Scilab-users] Scicolpack toolbox In-Reply-To: References: Message-ID: <2b7dc3c2-8c05-9300-cf7a-4195355807df@utc.fr> Hello, With the help of Antoine we now have a Windows build. Moreover some glitches have been fixed (get rid of OpenMP and a failing load under macOS) and a new version 0.2 is now online on Atoms. To give it a try: --> atomsInstall scicolpack Best, S. Le 14/12/2020 ? 16:50, St?phane Mottelet a ?crit?: > Hi all, > > A new toolbox has been uploaded at > https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/atoms.scilab.org/toolboxes/scicolpack: > > Scicolpack is is the Scilab interface to CSCsw/ColPack > (https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/github.com/CSCsw/ColPack), > a Graph Coloring Algorithm Package applied to efficient computation of > sparse Jacobian and Hessian. > > When you have to compute the Jacobian of a function f or the Hessian > of f knowing its gradient g, once you know its sparsity pattern, even > if you have derived it symbolically, it may still be faster to > estimate it by using the techniques which are used by Colpack. Roughly > speaking, this works by building a graph where each vertex is > associated to a column of the Jacobian or Hessian, and an edge > connects to vertices/columns if they are not structurally orthogonal, > i.e. have at least one non-zero term in a common row. Then a proper > coloring is done on this graph: at least, two adjacent vertices cannot > have the same color, but more properties of the coloring may be > expected. The coloring defines a partition of the columns under the > form of p subsets and the Jacobian (resp. Hessian) can be recovered > from only p evaluation of directional derivatives of f (resp. g). For > example, for a tridiagonal matrix the value of p is 3. In the Scilab > interface these directional derivatives are approximated by using > finite differences (the toolbox allows to compute them by using the > complex step technique up to machine precision). > > This toolbox can be an nice addon to SciIpopt toolbox > (https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/atoms.scilab.org/toolboxes/sci_ipopt) > where the Interior Point algorithm can be greatly accelerated when the > Hessian of the Lagrangian is sparse. When I have time I will update > the demo section of the module to add such an example. > > Don't hesitate to report successful uses, bugs or whishes. For the > moment the toolbox is available under OSX and Linux. Any help for a > Windows build is welcome ! > > Best, > -- 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 Tue Dec 15 19:09:59 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Tue, 15 Dec 2020 19:09:59 +0100 Subject: [Scilab-users] Increasing Scilab default Java heap memory to 512 MB? Message-ID: <4b7e04ce-b2c8-b032-591c-c0b727f0d1df@free.fr> Opening a new thread after http://mailinglists.scilab.org/Scilab-users-Headless-graphics-in-scilab-time-memory-issues-tp4041133p4041160.html Le 15/12/2020 ? 18:58, Samuel Gougeon a ?crit?: > Le 03/12/2020 ? 09:59, Antoine Monmayrant a ?crit?: >> >> Hello again, >> >> Just to add to my previous message: increasing nx or ny in my script >> can crash scilab during the call to xend(). >> On my small local machine, this occurs for: >> >> nx=4000; >> ny=3000; >> >> for which scilab takes ~7 seconds to create the png in "normal" mode... >> >> Can any of you confirm this bug? >> > > The crash is due to a too small Java Heap of memory. > When increasing it through the user's Preferences from 256 MB to 1 GB, > the PNG export works as fast as expected. > By the way, everyone, what do you think about increasing the default Scilab java Heap from 256 MB to 512 MB? This default 256 MB was set a long time ago, when on computers the average RAM what much smaller than today... Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christophe.Dang at sidel.com Wed Dec 16 08:37:26 2020 From: Christophe.Dang at sidel.com (Dang Ngoc Chan, Christophe) Date: Wed, 16 Dec 2020 07:37:26 +0000 Subject: [Scilab-users] {EXT} Increasing Scilab default Java heap memory to 512 MB? In-Reply-To: <4b7e04ce-b2c8-b032-591c-c0b727f0d1df@free.fr> References: <4b7e04ce-b2c8-b032-591c-c0b727f0d1df@free.fr> Message-ID: Hello, > De : De la part de Samuel Gougeon > Envoy? : mardi 15 d?cembre 2020 19:10 > > By the way, everyone, what do you think about increasing the default Scilab java Heap from 256 MB to 512 MB? > This default 256 MB was set a long time ago, when on computers the average RAM what much smaller than today... 100 % agree. Best regards -- Christophe Dang Ngoc Chan Mechanical calculation engineer General This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From antoine.monmayrant at laas.fr Wed Dec 16 14:16:07 2020 From: antoine.monmayrant at laas.fr (Antoine Monmayrant) Date: Wed, 16 Dec 2020 14:16:07 +0100 Subject: [Scilab-users] Increasing Scilab default Java heap memory to 512 MB? In-Reply-To: <4b7e04ce-b2c8-b032-591c-c0b727f0d1df@free.fr> References: <4b7e04ce-b2c8-b032-591c-c0b727f0d1df@free.fr> Message-ID: <2cad07e1-eb66-aafc-3900-79a3418ed384@laas.fr> That's the very first thing we change after installing scilab on all the computers in our group, so I agree we need to change it. Is there a way to make people aware of this settings and tell them that it's related to plotting? Like displaying a tip saying that they can crank it up when they need to display/export large plots and that it will add up to the memory used by scilab? Antoine On 15/12/2020 19:09, Samuel Gougeon wrote: > Opening a new thread after > http://mailinglists.scilab.org/Scilab-users-Headless-graphics-in-scilab-time-memory-issues-tp4041133p4041160.html > > Le 15/12/2020 ? 18:58, Samuel Gougeon a ?crit?: >> Le 03/12/2020 ? 09:59, Antoine Monmayrant a ?crit?: >>> >>> Hello again, >>> >>> Just to add to my previous message: increasing nx or ny in my script >>> can crash scilab during the call to xend(). >>> On my small local machine, this occurs for: >>> >>> nx=4000; >>> ny=3000; >>> >>> for which scilab takes ~7 seconds to create the png in "normal" mode... >>> >>> Can any of you confirm this bug? >>> >> >> The crash is due to a too small Java Heap of memory. >> When increasing it through the user's Preferences from 256 MB to 1 >> GB, the PNG export works as fast as expected. >> > By the way, everyone, what do you think about increasing the default > Scilab java Heap from 256 MB to 512 MB? > This default 256 MB was set a long time ago, when on computers the > average RAM what much smaller than today... > > Samuel > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From arctica1963 at gmail.com Thu Dec 17 13:21:28 2020 From: arctica1963 at gmail.com (arctica1963) Date: Thu, 17 Dec 2020 05:21:28 -0700 (MST) Subject: [Scilab-users] Problem with dos function Message-ID: <1608207688306-0.post@n3.nabble.com> Hello, I have an issue with the dos function for running an external program; tested in 5.5.2 and 6.1.0 with same result: --> [s,bOK]=dos('grdinfo crop1.grd') s = [] bOK = T The result of grdinfo is empty and should give the following if typed at the command prompt: D:\Geoscience\Scilab>grdinfo crop1.grd crop1.grd: Title: Grid computed with Mirone crop1.grd: Command: crop1.grd: Remark: File written from Matlab crop1.grd: Gridline node registration used [Geographic grid] crop1.grd: Grid file format: nf = GMT netCDF format (32-bit float), CF-1.7 crop1.grd: x_min: 1.05833333333 x_max: 5.14166666667 x_inc: 0.0166666666667 (1 min) name: longitude n_columns: 246 crop1.grd: y_min: 3.84166666667 y_max: 7.90833333333 y_inc: 0.0166666666667 (1 min) name: latitude n_rows: 245 crop1.grd: z_min: -106.033233643 z_max: 131.578842163 name: z [unknown] crop1.grd: scale_factor: 1 add_offset: 0 crop1.grd: format: netCDF-4 chunk_size: 246,245 shuffle: on deflation_level: 8 However, dos('dir','-echo') works and list the directory! Is there a bug or a missing option to apply? In an earlier version (5.4.1) it worked fine. Thanks Lester -- Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html From sgougeon at free.fr Fri Dec 18 18:16:26 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 18 Dec 2020 18:16:26 +0100 Subject: [Scilab-users] [bis] forge.scilab.org retirement In-Reply-To: References: Message-ID: <596f4d5a-18a8-210a-563a-2e9aabd8bf27@free.fr> After http://mailinglists.scilab.org/forge-scilab-org-retirement-tt4041018.html : Indeed, this topic deserved being cross-posted on both users@ and devs@ Scilab mailing lists. But cross-posting is forbidden, and only subscribers to devs@ have received the announcement. Repairing this issue here: > -------- Message transf?r? -------- > Subject?: [Scilab-Dev] forge.scilab.org retirement > Date?: Mon, 21 Sep 2020 15:26:09 +0000 > From : Cl?ment David > Reply to : List dedicated to the development of Scilab > > To : Users mailing list for Scilab , List > dedicated to the development of Scilab > > > > Dear users, toolbox contributors, > > We started to provide forge.scilab.org eight years ago intending to > maintain Scilab toolboxes as projects with source code and bug > reports. This was supposed to ease the maintenance and delivery of > high-quality toolboxes. This required us to provide a reliable service > and extra IT work out of Scilab development. > After Github.com and Gitlab.com successes, the needs of a forge > dedicated to Scilab are not present anymore. Projects can be hosted > and referenced with ease; these websites have high availability and > extra services that we cannot provide. > Beginning today, all projects are migrated to a GitLab sub-project [1] > and will remain accessible from there. If needed, request the access > to write on your repository (from the GitLab interface) or migrate it > somewhere else. The forge server is still up for now but will be > discarded soon. > [1]: https://gitlab.com/esi-group/scilab/forge > -- > Cl?ment DAVID Scilab Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jean-Yves.Baudais at insa-rennes.fr Fri Dec 18 18:38:08 2020 From: Jean-Yves.Baudais at insa-rennes.fr (Jean-Yves Baudais) Date: Fri, 18 Dec 2020 18:38:08 +0100 (CET) Subject: [Scilab-users] atomsLoad Message-ID: <1893395180.452434.1608313088195.JavaMail.zimbra@insa-rennes.fr> Hi, I face problem with atomsLoad. (It's the first time I use atoms!) 1) I installed scilab-6.1.0.bin.linux-x86_64.tar.gz on my $HOME. 2) I added the atoms repository http://atoms.scilab/org because the default one is http://atoms.scilab.org/6.1 and it gives nothing! 3) I installed emd_toolbox and the installed files are on $HOME/.Scilab/scilab-6.1.0/atoms/ ($HOME/.Scilab/scilab-6.1.0 is the SCIHOME variable in Scilab) So far, all is good. But the next step, atomsLoad("emd_toolbox") does not work. The message is atomsLoad: An error occurred while loading 'stftb-1.2-1': lib: /home/jbaudais/.Scilab/scilab-6.1.0/atoms/stftb/1.2-1/macros/ is not a valid lib path. at line 346 of function atomsLoad ( /home/jbaudais/scilab-6.1.0/share/scilab/modules/atoms/macros/atomsLoad.sci line 362 ) Note: emd_toolbox needs stftb but if I try atomsLoad("stftb"), the result is the same. I don't understand because the directory /home/jbaudais/.Scilab/scilab-6.1.0/atoms/stftb/1.2-1/macros/ exists and it contains the "names" file and all the .bin, .sci files. Any ideas? -- Jean-Yves From sgougeon at free.fr Fri Dec 18 19:22:47 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 18 Dec 2020 19:22:47 +0100 Subject: [Scilab-users] Atoms Modules In-Reply-To: References: Message-ID: Dear Chin Luh, Thank you so much for addressing the critical topic of external modules maintenance. While IPCV is the most downloaded module, your fair question >So should IPCV continue to be maintained ...? sounds desperate to me. I rather share the same feeling: Almost 5 days after your message, not a single answer from users...! So, apparently, the answer is likely: No, it's not worth maintaining the most downloaded module, and therefore No, it's not worth maintaining any other external module. Let's stop maintaining ATOMS for 2021. The ghosts of silent users are certainly rich enough to pay commercial equivalent tools. Since there are 12 days left before 2021, i will answer for particular cases in separate (sub-)threads. Best regards Samuel Le 14/12/2020 ? 05:44, Chin Luh Tan a ?crit?: > Sometimes it is hard to decide whether to continue maintaining an > atoms module or not.... So I did "snapshots" of downloads on 9/11/2020 > 21:44 and 14/12/2020 12:20 respectively to see which modules are in > the actual top downloads. > > Still, this is not a fair result, such as IPCV having some "patches" > which will increase?the download number, and some other factors as well. > > So should IPCV continue to be maintained ...? > > Here's the results. > > Image Processing and Computer Vision Toolbox 4620 > CPGE 3176 > MinGw toolbox 2946 > Arduino 2936 > CelestLab 2841 > iodelay toolbox 2429 > Coselica 1812 > SIMM 1800 > Image Processing Design Toolbox 1394 > Fuzzy Logic Toolbox 1186 > Scilab Computer Vision Module 1129 > GUI Builder 972 > Scilab Image and Video Processing toolbox 860 > Distfun 855 > Apifun 804 > Serial Communication Toolbox 781 > Time Frequency Toolbox 776 > Free Access Chemometric Toolbox 770 > Autoelem Toolbox 768 > Specfun 738 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.muehlmann at gmail.com Fri Dec 18 19:50:27 2020 From: p.muehlmann at gmail.com (P M) Date: Fri, 18 Dec 2020 19:50:27 +0100 Subject: [Scilab-users] Atoms Modules In-Reply-To: References: Message-ID: Hi Samuel. Chin Luh, Ok...let me command as a user. I hesitated to comment, because I am not sure if I am educated enough to answer the question, if IPCV maintenance should be continued. My first question back to Chin Luh would be...What do you mean by maintenance?... Adding new functions? My second question is: Why would the obviously success of the toolbox be a reason to stop maintenance? Best Regards, Philipp Am Freitag, 18. Dezember 2020 schrieb Samuel Gougeon : > Dear Chin Luh, > > Thank you so much for addressing the critical topic of external modules > maintenance. > While IPCV is the most downloaded module, your fair question > >So should IPCV continue to be maintained ...? > sounds desperate to me. I rather share the same feeling: Almost 5 days > after your message, not a single answer from users...! > > So, apparently, the answer is likely: No, it's not worth maintaining the > most downloaded module, and therefore No, it's not worth maintaining any > other external module. > Let's stop maintaining ATOMS for 2021. The ghosts of silent users are > certainly rich enough to pay commercial equivalent tools. > > Since there are 12 days left before 2021, i will answer for particular > cases in separate (sub-)threads. > > Best regards > Samuel > > Le 14/12/2020 ? 05:44, Chin Luh Tan a ?crit : > > Sometimes it is hard to decide whether to continue maintaining an atoms > module or not.... So I did "snapshots" of downloads on 9/11/2020 21:44 and > 14/12/2020 12:20 respectively to see which modules are in the actual top > downloads. > > Still, this is not a fair result, such as IPCV having some "patches" which > will increase the download number, and some other factors as well. > > So should IPCV continue to be maintained ...? > > Here's the results. > > Image Processing and Computer Vision Toolbox 4620 > CPGE 3176 > MinGw toolbox 2946 > Arduino 2936 > CelestLab 2841 > iodelay toolbox 2429 > Coselica 1812 > SIMM 1800 > Image Processing Design Toolbox 1394 > Fuzzy Logic Toolbox 1186 > Scilab Computer Vision Module 1129 > GUI Builder 972 > Scilab Image and Video Processing toolbox 860 > Distfun 855 > Apifun 804 > Serial Communication Toolbox 781 > Time Frequency Toolbox 776 > Free Access Chemometric Toolbox 770 > Autoelem Toolbox 768 > Specfun 738 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Dec 18 19:56:48 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 18 Dec 2020 19:56:48 +0100 Subject: [Scilab-users] atomsLoad In-Reply-To: <1893395180.452434.1608313088195.JavaMail.zimbra@insa-rennes.fr> References: <1893395180.452434.1608313088195.JavaMail.zimbra@insa-rennes.fr> Message-ID: <47471eed-5584-4bfb-e21d-940790812bc9@free.fr> Hello Jean-Yves, Le 18/12/2020 ? 18:38, Jean-Yves Baudais a ?crit?: > Hi, > I face problem with atomsLoad. (It's the first time I use atoms!) > > 1) I installed scilab-6.1.0.bin.linux-x86_64.tar.gz on my $HOME. > 2) I added the atoms repository http://atoms.scilab/org because the default one is http://atoms.scilab.org/6.1 and it gives nothing! > 3) I installed emd_toolbox and the installed files are on $HOME/.Scilab/scilab-6.1.0/atoms/ ($HOME/.Scilab/scilab-6.1.0 is the SCIHOME variable in Scilab) > > So far, all is good. But the next step, atomsLoad("emd_toolbox") does not work. The message is > > atomsLoad: An error occurred while loading 'stftb-1.2-1': Hard to help without knowing what you exactly did to install the toolbox, but clearly, this version of the Time Frequency Toolbox has been shipped for Scilab 5.3, and can in no way work with Scilab 6.1! Its most recent 2.0.2 version has been compiled for Scilab 6.0. So unless you recompile it by your own for Scilab 6.1, you could not use it on Scilab 6.1 (because it includes some hard-coded functions). Why have you chosen a so old version? Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Dec 18 20:01:59 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 18 Dec 2020 20:01:59 +0100 Subject: [Scilab-users] [serial] module <= Re: Atoms Modules In-Reply-To: References: Message-ID: <38df255c-798b-7d13-bcb0-17abae3923c2@free.fr> Le 14/12/2020 ? 05:44, Chin Luh Tan a ?crit?: > Sometimes it is hard to decide whether to continue maintaining an > atoms module or not.... So I did "snapshots" of downloads on 9/11/2020 > 21:44 and 14/12/2020 12:20 respectively to see which modules are in > the actual top downloads. > > Still, this is not a fair result, such as IPCV having some "patches" > which will increase?the download number, and some other factors as well. > > So should IPCV continue to be maintained ...? > > Here's the results. > > Image Processing and Computer Vision Toolbox 4620 > CPGE 3176 > MinGw toolbox 2946 > Arduino 2936 > CelestLab 2841 > iodelay toolbox 2429 > Coselica 1812 > SIMM 1800 > Image Processing Design Toolbox 1394 > Fuzzy Logic Toolbox 1186 > Scilab Computer Vision Module 1129 > GUI Builder 972 > Scilab Image and Video Processing toolbox 860 > Distfun 855 > Apifun 804 > Serial Communication Toolbox 781 > For information, I upgraded this toolbox last summer, but I still have to document the upgrade. I plan to do it and to publish it on ATOMS in the next 2 weeks. It's on the top of my TODO list. Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Fri Dec 18 20:30:18 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 18 Dec 2020 20:30:18 +0100 Subject: [Scilab-users] Problem with dos function In-Reply-To: <1608207688306-0.post@n3.nabble.com> References: <1608207688306-0.post@n3.nabble.com> Message-ID: Dear Lester, It's hard to help you without being able to reproduce the issue with the actual file. Since you are using Scilab on Windows, have you tried [s, bOK] = powershell("grdinfo crop1.grd") ? Samuel Le 17/12/2020 ? 13:21, arctica1963 a ?crit?: > Hello, > > I have an issue with the dos function for running an external program; > tested in 5.5.2 and 6.1.0 with same result: > > --> [s,bOK]=dos('grdinfo crop1.grd') > s = > > [] > bOK = > > T > > The result of grdinfo is empty and should give the following if typed at the > command prompt: > .../... From sgougeon at free.fr Fri Dec 18 22:45:13 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 18 Dec 2020 22:45:13 +0100 Subject: [Scilab-users] iodelay module => in Scilab Message-ID: <06b88038-b9d7-839d-79f6-3205d1b3ae4e@free.fr> After http://mailinglists.scilab.org/Scilab-users-Atoms-Modules-tp4041157.html : > -------- Message transf?r? -------- > Date?: Mon, 14 Dec 2020 12:44:24 +0800 > From : Chin Luh Tan > To : Users mailing list for Scilab > > > > Sometimes it is hard to decide whether to continue maintaining an > atoms module or not.... So I did "snapshots" of downloads on 9/11/2020 > 21:44 and 14/12/2020 12:20 respectively to see which modules are in > the actual top downloads. > > Still, this is not a fair result, such as IPCV having some "patches" > which will increase?the download number, and some other factors as well. > > So should IPCV continue to be maintained ...? > > Here's the results. > > Image Processing and Computer Vision Toolbox 4620 > CPGE 3176 > MinGw toolbox 2946 > Arduino 2936 > CelestLab 2841 > *iodelay toolbox* *2429* > This module is a small one, containing a single iodelay() public function, and only functions --mainly overloads --? in Scilab language, making the module easy to update. This module is among the ATOMS Best-of noticeably because several other popular modules require it as a dependency. Then iodelay is automatically installed when its "parents" are installed. This means that when iodelay is not up-to-date, this blocks other modules depending on it to work. This is currently the case : 10 months after the publication of Scilab 6.1.0, the current iodelay version is only for Scilab 6.0. All these aspects make me thinking that iodelay should be part of Scilab, to be included either in the CACSD or in the signal_processing internal Scilab modules. Then no repackaging and re-publication tasks of the module would be needed anymore for each new Scilab 6.x version. The iodelay module is currently published under the Cecill license. This looks compatible with the Scilab's license. To me this inclusion could be proposed in the next Scilab 6.1.1 release. There is no reason to wait more. Any comment is welcome about this proposal, noticeably from Serge, the iodelay author. Thanks Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From arctica1963 at gmail.com Fri Dec 18 23:39:07 2020 From: arctica1963 at gmail.com (arctica1963) Date: Fri, 18 Dec 2020 15:39:07 -0700 (MST) Subject: [Scilab-users] Problem with dos function In-Reply-To: References: <1608207688306-0.post@n3.nabble.com> Message-ID: <1608331147566-0.post@n3.nabble.com> Hello Samuel, Yes I did try the powershell option and it is the same response, the program runs (boolean result is true) but the result is not resolved in the output. The external program is using GMT (Generic mapping tools) and so that needs to be installed to test this issue. I also installed 5.4.1 to check and that also gives the same problem. I checked the function in Octave (5.1.0) which looks the same as Scilab and it gives the proper result: https://octave.sourceforge.io/octave/function/dos.html >> dos('grdinfo crop1.grd') crop1.grd: Title: Grid computed with Mirone crop1.grd: Command: crop1.grd: Remark: File written from Matlab crop1.grd: Gridline node registration used [Geographic grid] crop1.grd: Grid file format: nf = GMT netCDF format (32-bit float), CF-1.7 crop1.grd: x_min: 1.05833333333 x_max: 5.14166666667 x_inc: 0.0166666666667 (1 min) name: longitude n_columns: 24 6 crop1.grd: y_min: 3.84166666667 y_max: 7.90833333333 y_inc: 0.0166666666667 (1 min) name: latitude n_rows: 245 crop1.grd: z_min: -106.033233643 z_max: 131.578842163 name: z [unknown] crop1.grd: scale_factor: 1 add_offset: 0 crop1.grd: format: netCDF-4 chunk_size: 246,245 shuffle: on deflation_level: 8 ans = 0 I have looked at the Octave file, but it uses a "system" function which is not the same in Scilab: function [status, text] = dos (command, echo_arg) if (nargin < 1 || nargin > 2) print_usage (); endif status = 1; text = ""; ## FIXME: Should this be ispc ()? There may be an issue with MinGW if (! isunix ()) [status, text] = system (command); if (nargin > 1 || nargout == 0) printf ("%s\n", text); endif endif endfunction Where is the dos function in Scilab? Not sure if it is relevant, but testing on Windows 8. Lester -- Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html From sgougeon at free.fr Fri Dec 18 23:45:10 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 18 Dec 2020 23:45:10 +0100 Subject: [Scilab-users] Problem with dos function In-Reply-To: <1608331147566-0.post@n3.nabble.com> References: <1608207688306-0.post@n3.nabble.com> <1608331147566-0.post@n3.nabble.com> Message-ID: Then you can check if the results are sent to the consolebox instead of to the Scilab console: Press F13 or run --> consolebox on to display the consolebox and see its content. https://help.scilab.org/docs/6.1.0/en_US/consolebox.html Le 18/12/2020 ? 23:39, arctica1963 a ?crit?: > Hello Samuel, > > Yes I did try the powershell option and it is the same response, the program > runs (boolean result is true) but the result is not resolved in the output. > > The external program is using GMT (Generic mapping tools) and so that needs > to be installed to test this issue. > > I also installed 5.4.1 to check and that also gives the same problem. > > I checked the function in Octave (5.1.0) which looks the same as Scilab and > it gives the proper result: > https://octave.sourceforge.io/octave/function/dos.html > .../... From fmiyara at fceia.unr.edu.ar Sat Dec 19 01:43:06 2020 From: fmiyara at fceia.unr.edu.ar (Federico Miyara) Date: Fri, 18 Dec 2020 21:43:06 -0300 Subject: [Scilab-users] Atoms Modules In-Reply-To: References: Message-ID: Dear All, I haven't used IPCVso far, but I was planning to start trying it when finishing with a project that will take me still most of 2021. And probably earlier than that, since something as basic as reading or saving an image file is not in the core of Scilab (I think it should be, in line with the availability of wavread / wavwrite or csvRead functions). If terminating maintenance could eventually lead to an incompatibility with future versions of Scilab, I think it would be a bad thing. But the addition of new features is a different question, and as usually happens with any FOSS project, is driven by the users's wish-lists and requests and by developers which are sufficiently motivated to work on those features. If there is no demand then there is no need to go further. Regards, Federico On 18/12/2020 15:22, Samuel Gougeon wrote: > Dear Chin Luh, > > Thank you so much for addressing the critical topic of external > modules maintenance. > While IPCV is the most downloaded module, your fair question > >So should IPCV continue to be maintained ...? > sounds desperate to me. I rather share the same feeling: Almost 5 days > after your message, not a single answer from users...! > > So, apparently, the answer is likely: No, it's not worth maintaining > the most downloaded module, and therefore No, it's not worth > maintaining any other external module. > Let's stop maintaining ATOMS for 2021. The ghosts of silent users are > certainly rich enough to pay commercial equivalent tools. > > Since there are 12 days left before 2021, i will answer for particular > cases in separate (sub-)threads. > > Best regards > Samuel > > Le 14/12/2020 ? 05:44, Chin Luh Tan a ?crit?: >> Sometimes it is hard to decide whether to continue maintaining an >> atoms module or not.... So I did "snapshots" of downloads on >> 9/11/2020 21:44 and 14/12/2020 12:20 respectively to see which >> modules are in the actual top downloads. >> >> Still, this is not a fair result, such as IPCV having some "patches" >> which will increase?the download number, and some other factors as well. >> >> So should IPCV continue to be maintained ...? >> >> Here's the results. >> >> Image Processing and Computer Vision Toolbox 4620 >> CPGE 3176 >> MinGw toolbox 2946 >> Arduino 2936 >> CelestLab 2841 >> iodelay toolbox 2429 >> Coselica 1812 >> SIMM 1800 >> Image Processing Design Toolbox 1394 >> Fuzzy Logic Toolbox 1186 >> Scilab Computer Vision Module 1129 >> GUI Builder 972 >> Scilab Image and Video Processing toolbox 860 >> Distfun 855 >> Apifun 804 >> Serial Communication Toolbox 781 >> Time Frequency Toolbox 776 >> Free Access Chemometric Toolbox 770 >> Autoelem Toolbox 768 >> Specfun 738 >> > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -- El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From arctica1963 at gmail.com Sat Dec 19 09:14:20 2020 From: arctica1963 at gmail.com (arctica1963) Date: Sat, 19 Dec 2020 01:14:20 -0700 (MST) Subject: [Scilab-users] Problem with dos function In-Reply-To: References: <1608207688306-0.post@n3.nabble.com> <1608331147566-0.post@n3.nabble.com> Message-ID: <1608365660142-0.post@n3.nabble.com> Hi Samuel, Tested with consolebox on and it is empty, so it's not sending data there. As a test, I did a simple windows copy: dos('copy crop1.grd crop1a.grd','-echo') and that worked, so no issue with basic windows commands. Not sure what else to try unless it's an installation issue? Lester -- Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html From sgougeon at free.fr Sat Dec 19 12:59:36 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 19 Dec 2020 12:59:36 +0100 Subject: [Scilab-users] Problem with dos function In-Reply-To: <1608365660142-0.post@n3.nabble.com> References: <1608207688306-0.post@n3.nabble.com> <1608331147566-0.post@n3.nabble.com> <1608365660142-0.post@n3.nabble.com> Message-ID: Le 19/12/2020 ? 09:14, arctica1963 a ?crit?: > Not sure what else to try unless it's an installation issue? unix_w, unix_g ... functions From sgougeon at free.fr Sat Dec 19 13:29:35 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 19 Dec 2020 13:29:35 +0100 Subject: [Scilab-users] Problem with dos function In-Reply-To: <1608365660142-0.post@n3.nabble.com> References: <1608207688306-0.post@n3.nabble.com> <1608331147566-0.post@n3.nabble.com> <1608365660142-0.post@n3.nabble.com> Message-ID: Le 19/12/2020 ? 09:14, arctica1963 a ?crit?: > Not sure what else to try unless it's an installation issue? In addition to unix_*(), you may also try to redirect the standard error stream to the standard output: [s,bOK] = dos('grdinfo crop1.grd 2>&1') From arctica1963 at gmail.com Sat Dec 19 13:55:05 2020 From: arctica1963 at gmail.com (arctica1963) Date: Sat, 19 Dec 2020 05:55:05 -0700 (MST) Subject: [Scilab-users] Problem with dos function In-Reply-To: References: <1608207688306-0.post@n3.nabble.com> <1608331147566-0.post@n3.nabble.com> <1608365660142-0.post@n3.nabble.com> Message-ID: <1608382505210-0.post@n3.nabble.com> HI Samuel, Tried the unix_*() options with no success, redirect also did not work. Lester -- Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html From sgougeon at free.fr Sat Dec 19 16:24:05 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Sat, 19 Dec 2020 16:24:05 +0100 Subject: [Scilab-users] Increasing Scilab default Java heap memory to 512 MB? In-Reply-To: <2cad07e1-eb66-aafc-3900-79a3418ed384@laas.fr> References: <4b7e04ce-b2c8-b032-591c-c0b727f0d1df@free.fr> <2cad07e1-eb66-aafc-3900-79a3418ed384@laas.fr> Message-ID: <0b9f7e77-1cc2-7522-434a-817aef18d77a@free.fr> Le 16/12/2020 ? 14:16, Antoine Monmayrant a ?crit?: > > That's the very first thing we change after installing scilab on all > the computers in our group, so I agree we need to change it. > I conclude that 512 MB is enough. Otherwise you would not have experienced and reported the issue. A patch with this value is submitted for Scilab 6.1.1 @ https://codereview.scilab.org/21650 Samuel From cfuttrup at gmail.com Sat Dec 19 17:00:31 2020 From: cfuttrup at gmail.com (Claus Futtrup) Date: Sat, 19 Dec 2020 17:00:31 +0100 Subject: [Scilab-users] Atoms Modules In-Reply-To: References: Message-ID: <9a4730d6-e56a-9852-9865-9ffeb76035bb@gmail.com> Hi there I am personally not the most vivid user of the IPCV, but I can see among my scripts that I was playing around with it in October 2018. I have used IPCV to manipulate a piece of graphics that I made, and in a programmatic way (something totally impractical in any other way). The results: https://www.cfuttrup.com/blogspot.html#think_global I think the IPCV belongs in the toolbox for Scilab. When it comes to ATOMS, I think the concept is fundamentally good. I am not qualified to give feedback to any of the specifics within ATOMS as I found it very difficult to read up on how to create an ATOMS module, so what I say is that as a tool for community driven development, it needs a lot better support. With kind regards, Claus On 18-12-2020 19:22, Samuel Gougeon wrote: > Dear Chin Luh, > > Thank you so much for addressing the critical topic of external > modules maintenance. > While IPCV is the most downloaded module, your fair question > >So should IPCV continue to be maintained ...? > sounds desperate to me. I rather share the same feeling: Almost 5 days > after your message, not a single answer from users...! > > So, apparently, the answer is likely: No, it's not worth maintaining > the most downloaded module, and therefore No, it's not worth > maintaining any other external module. > Let's stop maintaining ATOMS for 2021. The ghosts of silent users are > certainly rich enough to pay commercial equivalent tools. > > Since there are 12 days left before 2021, i will answer for particular > cases in separate (sub-)threads. > > Best regards > Samuel > > Le 14/12/2020 ? 05:44, Chin Luh Tan a ?crit?: >> Sometimes it is hard to decide whether to continue maintaining an >> atoms module or not.... So I did "snapshots" of downloads on >> 9/11/2020 21:44 and 14/12/2020 12:20 respectively to see which >> modules are in the actual top downloads. >> >> Still, this is not a fair result, such as IPCV having some "patches" >> which will increase?the download number, and some other factors as well. >> >> So should IPCV continue to be maintained ...? >> >> Here's the results. >> >> Image Processing and Computer Vision Toolbox 4620 >> CPGE 3176 >> MinGw toolbox 2946 >> Arduino 2936 >> CelestLab 2841 >> iodelay toolbox 2429 >> Coselica 1812 >> SIMM 1800 >> Image Processing Design Toolbox 1394 >> Fuzzy Logic Toolbox 1186 >> Scilab Computer Vision Module 1129 >> GUI Builder 972 >> Scilab Image and Video Processing toolbox 860 >> Distfun 855 >> Apifun 804 >> Serial Communication Toolbox 781 >> Time Frequency Toolbox 776 >> Free Access Chemometric Toolbox 770 >> Autoelem Toolbox 768 >> Specfun 738 >> > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From arctica1963 at gmail.com Sun Dec 20 15:18:05 2020 From: arctica1963 at gmail.com (arctica1963) Date: Sun, 20 Dec 2020 07:18:05 -0700 (MST) Subject: [Scilab-users] Problem with dos function In-Reply-To: <1608382505210-0.post@n3.nabble.com> References: <1608207688306-0.post@n3.nabble.com> <1608331147566-0.post@n3.nabble.com> <1608365660142-0.post@n3.nabble.com> <1608382505210-0.post@n3.nabble.com> Message-ID: <1608473885315-0.post@n3.nabble.com> Same issue with console-only Scilab: Scilex,exe and WScilex-cli.exe. For reference, GMT can be installed from https://www.generic-mapping-tools.org/ Using Win64 version https://github.com/GenericMappingTools/gmt/releases/tag/6.1.1 Lester -- Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html From antoine.monmayrant at laas.fr Sun Dec 20 18:53:17 2020 From: antoine.monmayrant at laas.fr (Antoine Monmayrant) Date: Sun, 20 Dec 2020 18:53:17 +0100 Subject: [Scilab-users] Increasing Scilab default Java heap memory to 512 MB? In-Reply-To: <0b9f7e77-1cc2-7522-434a-817aef18d77a@free.fr> References: <4b7e04ce-b2c8-b032-591c-c0b727f0d1df@free.fr> <2cad07e1-eb66-aafc-3900-79a3418ed384@laas.fr> <0b9f7e77-1cc2-7522-434a-817aef18d77a@free.fr> Message-ID: <2b553193-ee4b-748d-c539-bddca144da90@laas.fr> On 19/12/2020 16:24, Samuel Gougeon wrote: > Le 16/12/2020 ? 14:16, Antoine Monmayrant a ?crit?: >> >> That's the very first thing we change after installing scilab on all >> the computers in our group, so I agree we need to change it. >> > I conclude that 512 MB is enough. Otherwise you would not have > experienced and reported the issue. Wait, what? I don't see how you conclude 512 is enough? In my case, I set it to 2GB: > A patch with this value is submitted for Scilab 6.1.1 @ > https://codereview.scilab.org/21650 Cool! Antoine > > Samuel > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users > From cfuttrup at gmail.com Sun Dec 20 19:42:37 2020 From: cfuttrup at gmail.com (Claus Futtrup) Date: Sun, 20 Dec 2020 19:42:37 +0100 Subject: [Scilab-users] IPCV upscaling of image Message-ID: Hi there I have a 4K picture, which I thought I'll try to upscale with the imsuperres in the IPCV toolbox. The code simply looks like this: imagefile = 'D:\Userdata\Claus\Pictures\Think_Global_4K.png'; im = imread(imagefile); imout? = imsuperres(im); The file is read and I get the following response: Unsigned Integer 8 bits (2160 x 3840). Then Scilab crashes. I'm running Scilab 6.1.0 (the original release) on Windows 10 - in a MS Windows dialog box I get: >Scilab 6.1.0 (Desktop) has stopped working >A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available. I am not sure that I've understood how to use imsuperres correctly. I see in the _params that rfactor = 4 is the default, so I was expecting the image to be scaled by a factor 4 (maybe that's 2 x 2 = I get an 8K image = 4320 x 7680 pixels). The way I understand the documentation, I don't need to run imsuperres_params if I'm satisified with the defaults. Kind regards, Claus From p.muehlmann at gmail.com Sun Dec 20 22:55:18 2020 From: p.muehlmann at gmail.com (P M) Date: Sun, 20 Dec 2020 22:55:18 +0100 Subject: [Scilab-users] IPCV upscaling of image In-Reply-To: References: Message-ID: Dear Claus, you need to feed a list into imsuperres()....not directly the image. Following should work. imgList = list();imgList(1) = imread('path_to_image');imgOut = imsuperres(imgList); figure();imshow(imgList(1));figure();imshow(imgOut); BR Philipp Am So., 20. Dez. 2020 um 19:42 Uhr schrieb Claus Futtrup : > Hi there > > I have a 4K picture, which I thought I'll try to upscale with the > imsuperres in the IPCV toolbox. The code simply looks like this: > > imagefile = 'D:\Userdata\Claus\Pictures\Think_Global_4K.png'; > im = imread(imagefile); > imout = imsuperres(im); > > The file is read and I get the following response: Unsigned Integer 8 > bits (2160 x 3840). Then Scilab crashes. I'm running Scilab 6.1.0 (the > original release) on Windows 10 - in a MS Windows dialog box I get: > > >Scilab 6.1.0 (Desktop) has stopped working > > >A problem caused the program to stop working correctly. Windows will > close the program and notify you if a solution is available. > > I am not sure that I've understood how to use imsuperres correctly. I > see in the _params that rfactor = 4 is the default, so I was expecting > the image to be scaled by a factor 4 (maybe that's 2 x 2 = I get an 8K > image = 4320 x 7680 pixels). The way I understand the documentation, I > don't need to run imsuperres_params if I'm satisified with the defaults. > > Kind regards, > > Claus > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfuttrup at gmail.com Mon Dec 21 09:19:56 2020 From: cfuttrup at gmail.com (Claus Futtrup) Date: Mon, 21 Dec 2020 09:19:56 +0100 Subject: [Scilab-users] IPCV upscaling of image In-Reply-To: References: Message-ID: <715f2f7f-4785-d041-ecee-6e723938beff@gmail.com> Hi Philipp I see, thank you for explaining it to me. I also see that the upscale is not 2x2 = 4, but it is 4x4 so the upscaled image is huge. The output file is saved - I believe - in wherever your Scilab file browser is currently active. Best regards, Claus On 20-12-2020 22:55, P M wrote: > Dear Claus, > > you need to feed a list into imsuperres()....not directly the image. > Following should work. > imgList = list(); > imgList(1) = imread('path_to_image'); > imgOut = imsuperres(imgList);figure(); imshow(imgList(1)); figure(); > imshow(imgOut); BR Philipp > > > Am So., 20. Dez. 2020 um 19:42?Uhr schrieb Claus Futtrup > >: > > Hi there > > I have a 4K picture, which I thought I'll try to upscale with the > imsuperres in the IPCV toolbox. The code simply looks like this: > > imagefile = 'D:\Userdata\Claus\Pictures\Think_Global_4K.png'; > im = imread(imagefile); > imout? = imsuperres(im); > > The file is read and I get the following response: Unsigned Integer 8 > bits (2160 x 3840). Then Scilab crashes. I'm running Scilab 6.1.0 > (the > original release) on Windows 10 - in a MS Windows dialog box I get: > > ?>Scilab 6.1.0 (Desktop) has stopped working > > ?>A problem caused the program to stop working correctly. Windows > will > close the program and notify you if a solution is available. > > I am not sure that I've understood how to use imsuperres correctly. I > see in the _params that rfactor = 4 is the default, so I was > expecting > the image to be scaled by a factor 4 (maybe that's 2 x 2 = I get > an 8K > image = 4320 x 7680 pixels). The way I understand the > documentation, I > don't need to run imsuperres_params if I'm satisified with the > defaults. > > Kind regards, > > Claus > > _______________________________________________ > 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: From Jean-Yves.Baudais at insa-rennes.fr Mon Dec 21 10:16:04 2020 From: Jean-Yves.Baudais at insa-rennes.fr (Jean-Yves Baudais) Date: Mon, 21 Dec 2020 10:16:04 +0100 (CET) Subject: [Scilab-users] atomsLoad In-Reply-To: <47471eed-5584-4bfb-e21d-940790812bc9@free.fr> References: <1893395180.452434.1608313088195.JavaMail.zimbra@insa-rennes.fr> <47471eed-5584-4bfb-e21d-940790812bc9@free.fr> Message-ID: <647110036.530161.1608542164931.JavaMail.zimbra@insa-rennes.fr> Hi, > Hard to help without knowing what you exactly did to install the toolbox, As I wrote I did --> atomsRepositoryAdd("http://atoms.scilab.org") --> atomsInstall("emd_toolbox") --> atomsLoad("emd_toolbox") Nothing else. > but > clearly, [ https://atoms.scilab.org/toolboxes/stftb/1.2.1 | this > version ] of the Time Frequency Toolbox has been shipped for Scilab 5.3, and can > in no way work with Scilab 6.1! > > Its most recent 2.0.2 version has been compiled for Scilab 6.0. So unless you > recompile it by your own for Scilab 6.1, you could not use it on Scilab 6.1 > (because it includes some hard-coded functions). Ok. So the error message "lib: [...] is not a valid lib path" does not mean the path does not exist but the version 1.2-1 cannot be used. Right? > Why have you chosen a so old version? Regards > Samuel Hum... I chosen nothing, I let Scilab functions atomsInstall() and atomsLoad() do the job... -- Jean-Yves Baudais From p.muehlmann at gmail.com Mon Dec 21 11:21:52 2020 From: p.muehlmann at gmail.com (P M) Date: Mon, 21 Dec 2020 11:21:52 +0100 Subject: [Scilab-users] IPCV upscaling of image In-Reply-To: <715f2f7f-4785-d041-ecee-6e723938beff@gmail.com> References: <715f2f7f-4785-d041-ecee-6e723938beff@gmail.com> Message-ID: Dear Claus, the example did not include saving the image as a file. Best guesses: - use imwrite - use one of the xs2...-functions (e.g.: xs2bmp) BR Philipp Am Mo., 21. Dez. 2020 um 09:20 Uhr schrieb Claus Futtrup : > Hi Philipp > > I see, thank you for explaining it to me. I also see that the upscale is > not 2x2 = 4, but it is 4x4 so the upscaled image is huge. The output file > is saved - I believe - in wherever your Scilab file browser is currently > active. > > Best regards, > Claus > > On 20-12-2020 22:55, P M wrote: > > Dear Claus, > > you need to feed a list into imsuperres()....not directly the image. > Following should work. > > imgList = list();imgList(1) = imread('path_to_image');imgOut = imsuperres(imgList);figure();imshow(imgList(1));figure();imshow(imgOut); > BR > Philipp > > > Am So., 20. Dez. 2020 um 19:42 Uhr schrieb Claus Futtrup < > cfuttrup at gmail.com>: > >> Hi there >> >> I have a 4K picture, which I thought I'll try to upscale with the >> imsuperres in the IPCV toolbox. The code simply looks like this: >> >> imagefile = 'D:\Userdata\Claus\Pictures\Think_Global_4K.png'; >> im = imread(imagefile); >> imout = imsuperres(im); >> >> The file is read and I get the following response: Unsigned Integer 8 >> bits (2160 x 3840). Then Scilab crashes. I'm running Scilab 6.1.0 (the >> original release) on Windows 10 - in a MS Windows dialog box I get: >> >> >Scilab 6.1.0 (Desktop) has stopped working >> >> >A problem caused the program to stop working correctly. Windows will >> close the program and notify you if a solution is available. >> >> I am not sure that I've understood how to use imsuperres correctly. I >> see in the _params that rfactor = 4 is the default, so I was expecting >> the image to be scaled by a factor 4 (maybe that's 2 x 2 = I get an 8K >> image = 4320 x 7680 pixels). The way I understand the documentation, I >> don't need to run imsuperres_params if I'm satisified with the defaults. >> >> Kind regards, >> >> Claus >> >> _______________________________________________ >> users mailing list >> users at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/users >> > > _______________________________________________ > users mailing listusers at lists.scilab.orghttp://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: From cfuttrup at gmail.com Mon Dec 21 11:37:32 2020 From: cfuttrup at gmail.com (Claus Futtrup) Date: Mon, 21 Dec 2020 11:37:32 +0100 Subject: [Scilab-users] IPCV upscaling of image In-Reply-To: References: <715f2f7f-4785-d041-ecee-6e723938beff@gmail.com> Message-ID: <999e17b6-d526-3827-3dcf-3b2d44f4f9b0@gmail.com> Hi Philipp The file was saved automatically. I don't think you can set what to save, or even the name of the file. I also did a xs2png, but that only saves the current figure. In my case a 610 x 460 pixel image (=the screen figure). Cheers, Claus On 21-12-2020 11:21, P M wrote: > Dear Claus, > > the example did not include saving the image as a file. > > Best guesses: > - use imwrite > - use one of the xs2...-functions (e.g.: xs2bmp) > > BR > Philipp > > > Am Mo., 21. Dez. 2020 um 09:20?Uhr schrieb Claus Futtrup > >: > > Hi Philipp > > I see, thank you for explaining it to me. I also see that the > upscale is not 2x2 = 4, but it is 4x4 so the upscaled image is > huge. The output file is saved - I believe - in wherever your > Scilab file browser is currently active. > > Best regards, > Claus > > On 20-12-2020 22:55, P M wrote: >> Dear Claus, >> >> you need to feed a list into imsuperres()....not directly the image. >> Following should work. >> imgList = list(); >> imgList(1) = imread('path_to_image'); >> imgOut = imsuperres(imgList);figure(); imshow(imgList(1)); figure(); >> imshow(imgOut); BR Philipp >> >> >> Am So., 20. Dez. 2020 um 19:42?Uhr schrieb Claus Futtrup >> >: >> >> Hi there >> >> I have a 4K picture, which I thought I'll try to upscale with >> the >> imsuperres in the IPCV toolbox. The code simply looks like this: >> >> imagefile = 'D:\Userdata\Claus\Pictures\Think_Global_4K.png'; >> im = imread(imagefile); >> imout? = imsuperres(im); >> >> The file is read and I get the following response: Unsigned >> Integer 8 >> bits (2160 x 3840). Then Scilab crashes. I'm running Scilab >> 6.1.0 (the >> original release) on Windows 10 - in a MS Windows dialog box >> I get: >> >> ?>Scilab 6.1.0 (Desktop) has stopped working >> >> ?>A problem caused the program to stop working correctly. >> Windows will >> close the program and notify you if a solution is available. >> >> I am not sure that I've understood how to use imsuperres >> correctly. I >> see in the _params that rfactor = 4 is the default, so I was >> expecting >> the image to be scaled by a factor 4 (maybe that's 2 x 2 = I >> get an 8K >> image = 4320 x 7680 pixels). The way I understand the >> documentation, I >> don't need to run imsuperres_params if I'm satisified with >> the defaults. >> >> Kind regards, >> >> Claus >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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: From sgougeon at free.fr Mon Dec 21 12:51:50 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Mon, 21 Dec 2020 12:51:50 +0100 Subject: [Scilab-users] atomsLoad In-Reply-To: <647110036.530161.1608542164931.JavaMail.zimbra@insa-rennes.fr> References: <1893395180.452434.1608313088195.JavaMail.zimbra@insa-rennes.fr> <47471eed-5584-4bfb-e21d-940790812bc9@free.fr> <647110036.530161.1608542164931.JavaMail.zimbra@insa-rennes.fr> Message-ID: <89745f0a-e74a-a27d-6a86-42166ab46469@free.fr> Le 21/12/2020 ? 10:16, Jean-Yves Baudais a ?crit?: > Hi, > >> Hard to help without knowing what you exactly did to install the toolbox, > As I wrote I did > --> atomsRepositoryAdd("http://atoms.scilab.org") > --> atomsInstall("emd_toolbox") > --> atomsLoad("emd_toolbox") > > Nothing else. Hello Jean-Yves, I was not aware that the whole portal "http://atoms.scilab.org" can be successfully targeted without specifying any Scilab X.y version. So i was assuming that you dowloaded the binary file by hand,? and then you installed it offline. > 2) I added the atoms repository http://atoms.scilab/org because the default one is http://atoms.scilab.org/6.1 and it gives nothing! I guess that by "it gives nothing" you mean that you did not get any emd_toolbox version installed. That's expected, since the last published version with binaries for Linux was the 1.2 version for Scilab 5.5. So it is filtered out if the target Scilab version is 6.1. As far as i know, you won't be actually able to install and use the emd_toolbox with Scilab 6.1. You have either to use Scilab 5.5 for this, or to port emb_toolbox to Scilab 6.1 yourself, by updating and recompiling it. By the way, the behavior of the ATOMS server when no Scilab version is specified in the repository URL would deserve either being documented, or fixed. As far as i understand, then the user is completely free and responsible of what it does. In your case, by default the very first emd_toolbox version 1.0 has been installed (why not. It could be the last available one, instead...). Then the automatical choice of the default version of the dependency (stftb) is more obscure... Samuel From Jean-Yves.Baudais at insa-rennes.fr Mon Dec 21 15:53:04 2020 From: Jean-Yves.Baudais at insa-rennes.fr (Jean-Yves Baudais) Date: Mon, 21 Dec 2020 15:53:04 +0100 (CET) Subject: [Scilab-users] atomsLoad In-Reply-To: <89745f0a-e74a-a27d-6a86-42166ab46469@free.fr> References: <1893395180.452434.1608313088195.JavaMail.zimbra@insa-rennes.fr> <47471eed-5584-4bfb-e21d-940790812bc9@free.fr> <647110036.530161.1608542164931.JavaMail.zimbra@insa-rennes.fr> <89745f0a-e74a-a27d-6a86-42166ab46469@free.fr> Message-ID: <1147985828.557207.1608562384245.JavaMail.zimbra@insa-rennes.fr> Hi, Thank you for the explanations. They make me the atom philosophy clearer :-) >> 2) I added the atoms repository http://atoms.scilab/org because the default one >> is http://atoms.scilab.org/6.1 and it gives nothing! > I guess that by "it gives nothing" you mean that you did not get any > emd_toolbox version installed. Yes, and I understand now it's rather good nothing was installed because the atoms "emd_toolbox" is not compatible with Scilab-6.1. > By the way, the behavior of the ATOMS server when no Scilab version is > specified in the repository URL would deserve either being documented, > or fixed. As far as i understand, then the user is completely free and > responsible of what it does. Yes, but I have to learn and I'm more irresponsible to do what I did :-) > In your case, by default the very first > emd_toolbox version 1.0 has been installed (why not. It could be the > last available one, instead...). Then the automatical choice of the > default version of the dependency (stftb) is more obscure... So, I think the best way it to use older Scilab version because - only too old emd_toolbox is "atomsInstalled" with Scilab-6.1 and not "atomsLoadable" - with http://atoms.scilab.org/5.3 repository, the atomsLoad() function alway gives "bad library path" - I'm not able to start with library source code Two questions: - Which Scilab version should I used? (only 5.5.2 or 5.1.1 are available on http://www.scilab.org) - Is the message "bad libray path" given by atomsLoad() mean there is a compatiliby issues? If yes, why does atomsInstall() intall without any error while atomsLoad() give errors? Thank for all, -- Jean-Yves From sgougeon at free.fr Mon Dec 21 16:10:23 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Mon, 21 Dec 2020 16:10:23 +0100 Subject: [Scilab-users] atomsLoad In-Reply-To: <1147985828.557207.1608562384245.JavaMail.zimbra@insa-rennes.fr> References: <1893395180.452434.1608313088195.JavaMail.zimbra@insa-rennes.fr> <47471eed-5584-4bfb-e21d-940790812bc9@free.fr> <647110036.530161.1608542164931.JavaMail.zimbra@insa-rennes.fr> <89745f0a-e74a-a27d-6a86-42166ab46469@free.fr> <1147985828.557207.1608562384245.JavaMail.zimbra@insa-rennes.fr> Message-ID: <3004f551-7647-2e8c-33a5-4db321fd91db@free.fr> Le 21/12/2020 ? 15:53, Jean-Yves Baudais a ?crit?: > So, I think the best way it to use older Scilab version because > - only too old emd_toolbox is "atomsInstalled" with Scilab-6.1 and not "atomsLoadable" > - with http://atoms.scilab.org/5.3 repository, the atomsLoad() function alway gives "bad library path" > - I'm not able to start with library source code > > Two questions: > - Which Scilab version should I used? (only 5.5.2 or 5.1.1 are available on http://www.scilab.org) You must use Scilab 5.5.2 and install the 1.2 version of the toolbox. It should run out of the box. From sgougeon at free.fr Mon Dec 21 16:42:01 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Mon, 21 Dec 2020 16:42:01 +0100 Subject: [Scilab-users] Increasing Scilab default Java heap memory to 512 MB? In-Reply-To: <2b553193-ee4b-748d-c539-bddca144da90@laas.fr> References: <4b7e04ce-b2c8-b032-591c-c0b727f0d1df@free.fr> <2cad07e1-eb66-aafc-3900-79a3418ed384@laas.fr> <0b9f7e77-1cc2-7522-434a-817aef18d77a@free.fr> <2b553193-ee4b-748d-c539-bddca144da90@laas.fr> Message-ID: Le 20/12/2020 ? 18:53, Antoine Monmayrant a ?crit?: > > On 19/12/2020 16:24, Samuel Gougeon wrote: >> Le 16/12/2020 ? 14:16, Antoine Monmayrant a ?crit?: >>> >>> That's the very first thing we change after installing scilab on all >>> the computers in our group, so I agree we need to change it. >>> >> I conclude that 512 MB is enough. Otherwise you would not have >> experienced and reported the issue. > Wait, what? > I don't see how you conclude 512 is enough? You are right: 512 MB is enough to pass the example reformulated by St?phane and Christophe, not to pass its original version with driver("PNG"). But when i increase the java heap to 1 GB, your original script passes without error: --> exec('test.sce', -1) ? "SCREEN: Time to plot = 1.2227456s" ? "HEADLESS: Time to plot = 33.772641s" By the way, beside the driver() discussion, the Java memory consumption of the grayplot family is known for a long time: http://bugzilla.scilab.org/8747? http://bugzilla.scilab.org/13150 and so on. From sgougeon at free.fr Mon Dec 21 17:04:54 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Mon, 21 Dec 2020 17:04:54 +0100 Subject: [Scilab-users] Headless graphics in scilab: time & memory issues In-Reply-To: References: Message-ID: figure("visible","off") allows to avoid using driver(), but the same memory consumption is then observable, when exporting the Sgrayploy with xs2png(). By the way, at least on my system, the final figure.png file is reddish. nx=4000; ny=300; nc=100; x=1:nx; y=[1:ny].'; z=(y*x); h = figure("visible","off"); h.color_map=hotcolormap(nc); Sgrayplot(x,y,z.'); xs2png(h,"C:/windows/temp/figure.png") Le 03/12/2020 ? 09:48, Antoine Monmayrant a ?crit?: > > Hello all, > > In these days of remote working, I need to use again scilab in > headless mode to generate graphics. > > In other words, I connect? in command line only to a remote server > where scilab is installed and I want it to generate graphics using a > combination of driver, xinit and xend. > > There seems to be some issues with driver/xinit/xend: huge memory > overhead and long computation time that makes it impossible to > generate some plots in headless mode. > > For example, a simple Sgrayplot that takes ~1 second to plot and save > to a png in normal mode takes more than 200 seconds and huge amount of > ram in headless mode (see attached test script). > > I also have some plots that works without a problem in normal mode, > but fail in headless mode because of some memory limitation: > > xend: An error occurred: Unable to create export file, not enough > memory. Decreasing the number of elements or the size of the > figure should fix this error. > > Is there a way to get around these problems? > > Thanks for your help, > > Antoine > > > > > > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.muehlmann at gmail.com Mon Dec 21 21:54:10 2020 From: p.muehlmann at gmail.com (P M) Date: Mon, 21 Dec 2020 21:54:10 +0100 Subject: [Scilab-users] IPCV upscaling of image In-Reply-To: <999e17b6-d526-3827-3dcf-3b2d44f4f9b0@gmail.com> References: <715f2f7f-4785-d041-ecee-6e723938beff@gmail.com> <999e17b6-d526-3827-3dcf-3b2d44f4f9b0@gmail.com> Message-ID: Hi Claus, this works for me: imgList = list();imgList(1) = imread(fullpath(getIPCVpath() + "/images/superres/input001.png"));imgOut = imsuperres(imgList);figure();imshow(imgOut);outPath_1 = 'd:\testIn.png';outPath_2 = 'd:\testOut.png';res = imwrite(imgList(1), outPath_1);res = imwrite(imgOut, outPath_2);xdel(); The input file is saved as a 64x64 image. The superresolution image is saved as a 256 x 256 image. Interestingly enough: If the output paths are set to "c:\testOut.png", imwrite would not work...unsure why. Regards, Philipp Am Mo., 21. Dez. 2020 um 11:37 Uhr schrieb Claus Futtrup : > Hi Philipp > > The file was saved automatically. I don't think you can set what to save, > or even the name of the file. > I also did a xs2png, but that only saves the current figure. In my case a > 610 x 460 pixel image (=the screen figure). > > Cheers, > Claus > > On 21-12-2020 11:21, P M wrote: > > Dear Claus, > > the example did not include saving the image as a file. > > Best guesses: > - use imwrite > - use one of the xs2...-functions (e.g.: xs2bmp) > > BR > Philipp > > > Am Mo., 21. Dez. 2020 um 09:20 Uhr schrieb Claus Futtrup < > cfuttrup at gmail.com>: > >> Hi Philipp >> >> I see, thank you for explaining it to me. I also see that the upscale is >> not 2x2 = 4, but it is 4x4 so the upscaled image is huge. The output file >> is saved - I believe - in wherever your Scilab file browser is currently >> active. >> >> Best regards, >> Claus >> >> On 20-12-2020 22:55, P M wrote: >> >> Dear Claus, >> >> you need to feed a list into imsuperres()....not directly the image. >> Following should work. >> >> imgList = list();imgList(1) = imread('path_to_image');imgOut = imsuperres(imgList);figure();imshow(imgList(1));figure();imshow(imgOut); >> BR >> Philipp >> >> >> Am So., 20. Dez. 2020 um 19:42 Uhr schrieb Claus Futtrup < >> cfuttrup at gmail.com>: >> >>> Hi there >>> >>> I have a 4K picture, which I thought I'll try to upscale with the >>> imsuperres in the IPCV toolbox. The code simply looks like this: >>> >>> imagefile = 'D:\Userdata\Claus\Pictures\Think_Global_4K.png'; >>> im = imread(imagefile); >>> imout = imsuperres(im); >>> >>> The file is read and I get the following response: Unsigned Integer 8 >>> bits (2160 x 3840). Then Scilab crashes. I'm running Scilab 6.1.0 (the >>> original release) on Windows 10 - in a MS Windows dialog box I get: >>> >>> >Scilab 6.1.0 (Desktop) has stopped working >>> >>> >A problem caused the program to stop working correctly. Windows will >>> close the program and notify you if a solution is available. >>> >>> I am not sure that I've understood how to use imsuperres correctly. I >>> see in the _params that rfactor = 4 is the default, so I was expecting >>> the image to be scaled by a factor 4 (maybe that's 2 x 2 = I get an 8K >>> image = 4320 x 7680 pixels). The way I understand the documentation, I >>> don't need to run imsuperres_params if I'm satisified with the defaults. >>> >>> Kind regards, >>> >>> Claus >>> >>> _______________________________________________ >>> users mailing list >>> users at lists.scilab.org >>> http://lists.scilab.org/mailman/listinfo/users >>> >> >> _______________________________________________ >> users mailing listusers at lists.scilab.orghttp://lists.scilab.org/mailman/listinfo/users >> >> >> _______________________________________________ >> users mailing list >> users at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/users >> > > _______________________________________________ > users mailing listusers at lists.scilab.orghttp://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: From Jean-Yves.Baudais at insa-rennes.fr Tue Dec 22 12:36:25 2020 From: Jean-Yves.Baudais at insa-rennes.fr (Jean-Yves Baudais) Date: Tue, 22 Dec 2020 12:36:25 +0100 (CET) Subject: [Scilab-users] atomsLoad In-Reply-To: <3004f551-7647-2e8c-33a5-4db321fd91db@free.fr> References: <1893395180.452434.1608313088195.JavaMail.zimbra@insa-rennes.fr> <47471eed-5584-4bfb-e21d-940790812bc9@free.fr> <647110036.530161.1608542164931.JavaMail.zimbra@insa-rennes.fr> <89745f0a-e74a-a27d-6a86-42166ab46469@free.fr> <1147985828.557207.1608562384245.JavaMail.zimbra@insa-rennes.fr> <3004f551-7647-2e8c-33a5-4db321fd91db@free.fr> Message-ID: <450958042.598780.1608636985061.JavaMail.zimbra@insa-rennes.fr> Hi, > You must use Scilab 5.5.2 and install the 1.2 version of the toolbox. It > should run out of the box. Ok. I installed it. "scilab" command and "scilab -nw" or "-nb" or "-ns" or "-noatomsautoload" give the so funny "Segmentation fault" :-( Hopefully, "scilab -nwni" works, but I only have the head_comments help and no plot. So, not so funny, but I can juggle between scilab-5.5.2 and scilab-6.1.0 "scilab -debug" does not work anymore (but I not able to use gdb!) gdb: SCI/lib/thirdparty/libtinfo.so.5: no version information available (required by gdb) gdb: SCI/lib/thirdparty/libtinfo.so.5: no version information available (required by /lib/x86_64-linux-gnu/libreadline.so.7) [...] gdb: relocation error: /lib/x86_64-linux-gnu/libncursesw.so.5: symbol _nc_putchar version NCURSES_TINFO_5.9.20150530 not defined in file libtinfo.so.5 with link time reference and "scilab -nogui" gives (maybe more informative) Scilab startup function detected that the function proposed to the engine is the wrong one. Usually, it comes from a linker problem in your distribution/OS. Here, Scilab should have 'libscijvm-disable' defined but gets 'libscijvm' instead. If you do not know what it means, please report a bug on http://bugzilla.scilab.org/. If you do, you probably know that you should change the link order in SCI/modules/Makefile.am Is there a simple way to solve this JVM problem? (Note that the default scilab-6.0 installed in my Unbuntu has a JVM problem also and does not work. Maybe I will try to solve it another time.) -- Jean-Yves Baudais From Clement.David at esi-group.com Tue Dec 22 14:47:19 2020 From: Clement.David at esi-group.com (=?iso-8859-1?Q?Cl=E9ment_David?=) Date: Tue, 22 Dec 2020 13:47:19 +0000 Subject: [Scilab-users] atomsLoad In-Reply-To: <450958042.598780.1608636985061.JavaMail.zimbra@insa-rennes.fr> References: <1893395180.452434.1608313088195.JavaMail.zimbra@insa-rennes.fr> <47471eed-5584-4bfb-e21d-940790812bc9@free.fr> <647110036.530161.1608542164931.JavaMail.zimbra@insa-rennes.fr> <89745f0a-e74a-a27d-6a86-42166ab46469@free.fr> <1147985828.557207.1608562384245.JavaMail.zimbra@insa-rennes.fr> <3004f551-7647-2e8c-33a5-4db321fd91db@free.fr>, <450958042.598780.1608636985061.JavaMail.zimbra@insa-rennes.fr> Message-ID: Hello, It looks like the scilab 5.5.2 binary is not compatible with your system (nc_putchar version error). IMHO it should be better to use the latest Scilab version and try to build dependencies by hand ; regarding the toolboxes: * http://forge.scilab.org/index.php/p/stftb/ is not published for 6.1 but might compile on it ; get the sources and try to build on your own machine. * https://atoms.scilab.org/toolboxes/emd_toolbox/ already uses the pvApiCtx symbol ; it might be possible to port it to scilab 6.1 without a big refactoring. Thanks, Cl?ment ________________________________ De : users de la part de Jean-Yves Baudais Envoy? : mardi 22 d?cembre 2020 12:36 ? : Users mailing list for Scilab Objet : Re: [Scilab-users] atomsLoad Hi, > You must use Scilab 5.5.2 and install the 1.2 version of the toolbox. It > should run out of the box. Ok. I installed it. "scilab" command and "scilab -nw" or "-nb" or "-ns" or "-noatomsautoload" give the so funny "Segmentation fault" :-( Hopefully, "scilab -nwni" works, but I only have the head_comments help and no plot. So, not so funny, but I can juggle between scilab-5.5.2 and scilab-6.1.0 "scilab -debug" does not work anymore (but I not able to use gdb!) gdb: SCI/lib/thirdparty/libtinfo.so.5: no version information available (required by gdb) gdb: SCI/lib/thirdparty/libtinfo.so.5: no version information available (required by /lib/x86_64-linux-gnu/libreadline.so.7) [...] gdb: relocation error: /lib/x86_64-linux-gnu/libncursesw.so.5: symbol _nc_putchar version NCURSES_TINFO_5.9.20150530 not defined in file libtinfo.so.5 with link time reference and "scilab -nogui" gives (maybe more informative) Scilab startup function detected that the function proposed to the engine is the wrong one. Usually, it comes from a linker problem in your distribution/OS. Here, Scilab should have 'libscijvm-disable' defined but gets 'libscijvm' instead. If you do not know what it means, please report a bug on http://bugzilla.scilab.org/. If you do, you probably know that you should change the link order in SCI/modules/Makefile.am Is there a simple way to solve this JVM problem? (Note that the default scilab-6.0 installed in my Unbuntu has a JVM problem also and does not work. Maybe I will try to solve it another time.) -- Jean-Yves Baudais _______________________________________________ users mailing list users at lists.scilab.org http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Tue Dec 22 15:17:56 2020 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 22 Dec 2020 15:17:56 +0100 Subject: [Scilab-users] atomsLoad In-Reply-To: References: <1893395180.452434.1608313088195.JavaMail.zimbra@insa-rennes.fr> <47471eed-5584-4bfb-e21d-940790812bc9@free.fr> <647110036.530161.1608542164931.JavaMail.zimbra@insa-rennes.fr> <89745f0a-e74a-a27d-6a86-42166ab46469@free.fr> <1147985828.557207.1608562384245.JavaMail.zimbra@insa-rennes.fr> <3004f551-7647-2e8c-33a5-4db321fd91db@free.fr> <450958042.598780.1608636985061.JavaMail.zimbra@insa-rennes.fr> Message-ID: <441fce18-9bf0-4276-6319-100a27f19cf5@utc.fr> Hi, Le 22/12/2020 ? 14:47, Cl?ment David a ?crit?: > Hello, > > It looks like the scilab 5.5.2 binary is not compatible with your > system (nc_putchar version error). IMHO it should be better to use the > latest Scilab version and try to build dependencies by hand ; > regarding the toolboxes: > ?* http://forge.scilab.org/index.php/p/stftb/ > > is not published for 6.1 but might compile on it ; get the sources and > try to build on your own machine. > ?* https://atoms.scilab.org/toolboxes/emd_toolbox/ > > already uses the pvApiCtx symbol ; it might be possible to port it to > scilab 6.1 without a big refactoring. It is quite easy (a 10 min. job). I made the needed modifications and it compiles and loads under OSX. If you give me the rights on Gitlab I can commit the modifications this afternoon. S. > > Thanks, > > Cl?ment > ------------------------------------------------------------------------ > *De :* users de la part de Jean-Yves > Baudais > *Envoy? :* mardi 22 d?cembre 2020 12:36 > *? :* Users mailing list for Scilab > *Objet :* Re: [Scilab-users] atomsLoad > Hi, > > > You must use Scilab 5.5.2 and install the 1.2 version of the toolbox. It > > should run out of the box. > > Ok. I installed it. "scilab" command and "scilab -nw" or "-nb" or > "-ns" or "-noatomsautoload" give the so funny "Segmentation fault" :-( > Hopefully, "scilab -nwni" works, but I only have the head_comments > help and no plot. So, not so funny, but I can juggle between > scilab-5.5.2 and scilab-6.1.0 > > "scilab -debug" does not work anymore (but I not able to use gdb!) > > gdb: SCI/lib/thirdparty/libtinfo.so.5: no version information > available (required by gdb) > gdb: SCI/lib/thirdparty/libtinfo.so.5: no version information > available (required by /lib/x86_64-linux-gnu/libreadline.so.7) > [...] > gdb: relocation error: /lib/x86_64-linux-gnu/libncursesw.so.5: symbol > _nc_putchar version NCURSES_TINFO_5.9.20150530 not defined in file > libtinfo.so.5 with link time reference > > and "scilab -nogui" gives (maybe more informative) > > Scilab startup function detected that the function proposed to the > engine is the wrong one. Usually, it comes from a linker problem in > your distribution/OS. > Here, Scilab should have 'libscijvm-disable' defined but gets > 'libscijvm' instead. > If you do not know what it means, please report a bug on > http://bugzilla.scilab.org/ > . > If you do, you probably know that you should change the link order in > SCI/modules/Makefile.am > > Is there a simple way to solve this JVM problem? (Note that the > default scilab-6.0 installed in my Unbuntu has a JVM problem also and > does not work. Maybe I will try to solve it another time.) > > -- > Jean-Yves Baudais > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users > > > _______________________________________________ > users mailing list > users at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -- 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: From stephane.mottelet at utc.fr Tue Dec 22 15:20:39 2020 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 22 Dec 2020 15:20:39 +0100 Subject: [Scilab-users] atomsLoad In-Reply-To: <441fce18-9bf0-4276-6319-100a27f19cf5@utc.fr> References: <1893395180.452434.1608313088195.JavaMail.zimbra@insa-rennes.fr> <47471eed-5584-4bfb-e21d-940790812bc9@free.fr> <647110036.530161.1608542164931.JavaMail.zimbra@insa-rennes.fr> <89745f0a-e74a-a27d-6a86-42166ab46469@free.fr> <1147985828.557207.1608562384245.JavaMail.zimbra@insa-rennes.fr> <3004f551-7647-2e8c-33a5-4db321fd91db@free.fr> <450958042.598780.1608636985061.JavaMail.zimbra@insa-rennes.fr> <441fce18-9bf0-4276-6319-100a27f19cf5@utc.fr> Message-ID: <33cd9acd-1f90-c17d-f47f-ef8cd53fc097@utc.fr> Seems that emd_toolbox is not on the forge... Le 22/12/2020 ? 15:17, St?phane Mottelet a ?crit?: > > Hi, > > > Le 22/12/2020 ? 14:47, Cl?ment David a ?crit?: >> Hello, >> >> It looks like the scilab 5.5.2 binary is not compatible with your >> system (nc_putchar version error). IMHO it should be better to use >> the latest Scilab version and try to build dependencies by hand ; >> regarding the toolboxes: >> ?* http://forge.scilab.org/index.php/p/stftb/ >> >> is not published for 6.1 but might compile on it ; get the sources >> and try to build on your own machine. >> ?* https://atoms.scilab.org/toolboxes/emd_toolbox/ >> >> already uses the pvApiCtx symbol ; it might be possible to port it to >> scilab 6.1 without a big refactoring. > > It is quite easy (a 10 min. job). I made the needed modifications and > it compiles and loads under OSX. If you give me the rights on Gitlab I > can commit the modifications this afternoon. > > > S. > >> >> Thanks, >> >> Cl?ment >> ------------------------------------------------------------------------ >> *De :* users de la part de Jean-Yves >> Baudais >> *Envoy? :* mardi 22 d?cembre 2020 12:36 >> *? :* Users mailing list for Scilab >> *Objet :* Re: [Scilab-users] atomsLoad >> Hi, >> >> > You must use Scilab 5.5.2 and install the 1.2 version of the >> toolbox. It >> > should run out of the box. >> >> Ok. I installed it. "scilab" command and "scilab -nw" or "-nb" or >> "-ns" or "-noatomsautoload" give the so funny "Segmentation fault" >> :-( Hopefully, "scilab -nwni" works, but I only have the >> head_comments help and no plot. So, not so funny, but I can juggle >> between scilab-5.5.2 and scilab-6.1.0 >> >> "scilab -debug" does not work anymore (but I not able to use gdb!) >> >> gdb: SCI/lib/thirdparty/libtinfo.so.5: no version information >> available (required by gdb) >> gdb: SCI/lib/thirdparty/libtinfo.so.5: no version information >> available (required by /lib/x86_64-linux-gnu/libreadline.so.7) >> [...] >> gdb: relocation error: /lib/x86_64-linux-gnu/libncursesw.so.5: symbol >> _nc_putchar version NCURSES_TINFO_5.9.20150530 not defined in file >> libtinfo.so.5 with link time reference >> >> and "scilab -nogui" gives (maybe more informative) >> >> Scilab startup function detected that the function proposed to the >> engine is the wrong one. Usually, it comes from a linker problem in >> your distribution/OS. >> Here, Scilab should have 'libscijvm-disable' defined but gets >> 'libscijvm' instead. >> If you do not know what it means, please report a bug on >> http://bugzilla.scilab.org/ >> . >> If you do, you probably know that you should change the link order in >> SCI/modules/Makefile.am >> >> Is there a simple way to solve this JVM problem? (Note that the >> default scilab-6.0 installed in my Unbuntu has a JVM problem also and >> does not work. Maybe I will try to solve it another time.) >> >> -- >> Jean-Yves Baudais >> _______________________________________________ >> users mailing list >> users at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/users >> >> >> _______________________________________________ >> users mailing list >> users at lists.scilab.org >> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users > -- > 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 > > _______________________________________________ > users mailing list > users at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -- 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: From Jean-Yves.Baudais at insa-rennes.fr Tue Dec 22 16:12:17 2020 From: Jean-Yves.Baudais at insa-rennes.fr (Jean-Yves Baudais) Date: Tue, 22 Dec 2020 16:12:17 +0100 (CET) Subject: [Scilab-users] atomsLoad In-Reply-To: <441fce18-9bf0-4276-6319-100a27f19cf5@utc.fr> References: <1893395180.452434.1608313088195.JavaMail.zimbra@insa-rennes.fr> <647110036.530161.1608542164931.JavaMail.zimbra@insa-rennes.fr> <89745f0a-e74a-a27d-6a86-42166ab46469@free.fr> <1147985828.557207.1608562384245.JavaMail.zimbra@insa-rennes.fr> <3004f551-7647-2e8c-33a5-4db321fd91db@free.fr> <450958042.598780.1608636985061.JavaMail.zimbra@insa-rennes.fr> <441fce18-9bf0-4276-6319-100a27f19cf5@utc.fr> Message-ID: <1607135779.616587.1608649937970.JavaMail.zimbra@insa-rennes.fr> Hi, > It is quite easy (a 10 min. job). I made the needed modifications and it > compiles and loads under OSX. If you give me the rights on Gitlab I can commit > the modifications this afternoon. Ok, but I don't how to do this, but I'm ready to learn :-) So, could you give me the step starting with "stftb" source? https://atoms.scilab.org/toolboxes/stftb/2.0.2/files/stftb-2.0.2-src.zip (I'm regular with Linux command-line, not too much with makefile) Or, maybe there already exists a document explaining the steps? -- Jean-Yves Baudais From Clement.David at esi-group.com Tue Dec 22 16:41:58 2020 From: Clement.David at esi-group.com (=?iso-8859-1?Q?Cl=E9ment_David?=) Date: Tue, 22 Dec 2020 15:41:58 +0000 Subject: [Scilab-users] atomsLoad In-Reply-To: <1607135779.616587.1608649937970.JavaMail.zimbra@insa-rennes.fr> References: <1893395180.452434.1608313088195.JavaMail.zimbra@insa-rennes.fr> <647110036.530161.1608542164931.JavaMail.zimbra@insa-rennes.fr> <89745f0a-e74a-a27d-6a86-42166ab46469@free.fr> <1147985828.557207.1608562384245.JavaMail.zimbra@insa-rennes.fr> <3004f551-7647-2e8c-33a5-4db321fd91db@free.fr> <450958042.598780.1608636985061.JavaMail.zimbra@insa-rennes.fr> <441fce18-9bf0-4276-6319-100a27f19cf5@utc.fr>, <1607135779.616587.1608649937970.JavaMail.zimbra@insa-rennes.fr> Message-ID: Hello, >From the source directory, you could use `exec builder.sce` [1]. Atoms toolboxes only rely on Scilab scripts to describe and execute the build (Makefiles are used behind the scene) ; for just rebuilding the toolbox, it should be as simple as executing the builder, bumping the version and zip the directory. [1]: https://wiki.scilab.org/howto/Create%20a%20toolbox#Build_and_load_a_module howto/Create a toolbox - Scilab Wiki Creating an ATOMS toolbox. This page describes the usual method to create, package, and distribute a Scilab external module (ATOMS Toolbox). In the first part, we show how to structure the module by creating directories, sub-directories and files at the right place. wiki.scilab.org Thanks, Cl?ment ________________________________ De : users de la part de Jean-Yves Baudais Envoy? : mardi 22 d?cembre 2020 16:12 ? : Users mailing list for Scilab Objet : Re: [Scilab-users] atomsLoad Hi, > It is quite easy (a 10 min. job). I made the needed modifications and it > compiles and loads under OSX. If you give me the rights on Gitlab I can commit > the modifications this afternoon. Ok, but I don't how to do this, but I'm ready to learn :-) So, could you give me the step starting with "stftb" source? https://atoms.scilab.org/toolboxes/stftb/2.0.2/files/stftb-2.0.2-src.zip (I'm regular with Linux command-line, not too much with makefile) Or, maybe there already exists a document explaining the steps? -- Jean-Yves Baudais _______________________________________________ users mailing list users at lists.scilab.org http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Tue Dec 22 16:46:25 2020 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 22 Dec 2020 16:46:25 +0100 Subject: [Scilab-users] atomsLoad In-Reply-To: <1607135779.616587.1608649937970.JavaMail.zimbra@insa-rennes.fr> References: <1893395180.452434.1608313088195.JavaMail.zimbra@insa-rennes.fr> <647110036.530161.1608542164931.JavaMail.zimbra@insa-rennes.fr> <89745f0a-e74a-a27d-6a86-42166ab46469@free.fr> <1147985828.557207.1608562384245.JavaMail.zimbra@insa-rennes.fr> <3004f551-7647-2e8c-33a5-4db321fd91db@free.fr> <450958042.598780.1608636985061.JavaMail.zimbra@insa-rennes.fr> <441fce18-9bf0-4276-6319-100a27f19cf5@utc.fr> <1607135779.616587.1608649937970.JavaMail.zimbra@insa-rennes.fr> Message-ID: <35e5ca3e-fa52-d40f-69d0-86acbc57d067@utc.fr> Hi, Le 22/12/2020 ? 16:12, Jean-Yves Baudais a ?crit?: > Hi, > >> It is quite easy (a 10 min. job). I made the needed modifications and it >> compiles and loads under OSX. If you give me the rights on Gitlab I can commit >> the modifications this afternoon. > Ok, but I don't how to do this, but I'm ready to learn :-) So, could you give me the step starting with "stftb" source? https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/atoms.scilab.org/toolboxes/stftb/2.0.2/files/stftb-2.0.2-src.zip (I'm regular with Linux command-line, not too much with makefile) > > Or, maybe there already exists a document explaining the steps? First, uncompress the zip file. In the obtained directory, go to the sci_gateway/c folder and remove #include at line 8 in the file kiss_fft.h Then in main toolbox directory, exec builder.sce as already said by Cl?ment. If you had no error just "exec loader.sce". S. > > -- > Jean-Yves Baudais > _______________________________________________ > users mailing list > users at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -- 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 Tue Dec 22 17:02:48 2020 From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=) Date: Tue, 22 Dec 2020 17:02:48 +0100 Subject: [Scilab-users] atomsLoad In-Reply-To: <1607135779.616587.1608649937970.JavaMail.zimbra@insa-rennes.fr> References: <1893395180.452434.1608313088195.JavaMail.zimbra@insa-rennes.fr> <647110036.530161.1608542164931.JavaMail.zimbra@insa-rennes.fr> <89745f0a-e74a-a27d-6a86-42166ab46469@free.fr> <1147985828.557207.1608562384245.JavaMail.zimbra@insa-rennes.fr> <3004f551-7647-2e8c-33a5-4db321fd91db@free.fr> <450958042.598780.1608636985061.JavaMail.zimbra@insa-rennes.fr> <441fce18-9bf0-4276-6319-100a27f19cf5@utc.fr> <1607135779.616587.1608649937970.JavaMail.zimbra@insa-rennes.fr> Message-ID: <2742c2dc-8ce3-469e-fefd-a6b25b809386@utc.fr> I sent you (private message) the modified sources of emd_toolbox, for the gateway part only. The toolbox compiles and loads, but then there are problems due to the convention with the empty matrix that changed since Scilab 6. I hope you will be able to fix them yourself (keep us informed of your fixes). S. Le 22/12/2020 ? 16:12, Jean-Yves Baudais a ?crit?: > Hi, > >> It is quite easy (a 10 min. job). I made the needed modifications and it >> compiles and loads under OSX. If you give me the rights on Gitlab I can commit >> the modifications this afternoon. > Ok, but I don't how to do this, but I'm ready to learn :-) So, could you give me the step starting with "stftb" source? https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/atoms.scilab.org/toolboxes/stftb/2.0.2/files/stftb-2.0.2-src.zip (I'm regular with Linux command-line, not too much with makefile) > > Or, maybe there already exists a document explaining the steps? > > -- > Jean-Yves Baudais > _______________________________________________ > users mailing list > users at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -- 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 cfuttrup at gmail.com Tue Dec 22 18:12:59 2020 From: cfuttrup at gmail.com (Claus Futtrup) Date: Tue, 22 Dec 2020 18:12:59 +0100 Subject: [Scilab-users] IPCV upscaling of image In-Reply-To: References: <715f2f7f-4785-d041-ecee-6e723938beff@gmail.com> <999e17b6-d526-3827-3dcf-3b2d44f4f9b0@gmail.com> Message-ID: Hi Philipp Interesting ... I think this should be part of the help available. I hope Chin Lun Tan sees this and feel inspired... Cheers, Claus On 21-12-2020 21:54, P M wrote: > Hi Claus, > > this works for me: > > imgList = list(); > imgList(1) = imread(fullpath(getIPCVpath() + "/images/superres/input001.png")); > imgOut = imsuperres(imgList); > figure(); > imshow(imgOut); > outPath_1 = 'd:\testIn.png'; > outPath_2 = 'd:\testOut.png'; > res = imwrite(imgList(1), outPath_1); > res = imwrite(imgOut, outPath_2); > xdel(); > The input file is saved as a 64x64 image. > The superresolution image is saved as a 256 x 256 image. > > Interestingly enough: > If the output paths are set to "c:\testOut.png", imwrite would not > work...unsure why. > > Regards, Philipp > > Am Mo., 21. Dez. 2020 um 11:37?Uhr schrieb Claus Futtrup > >: > > Hi Philipp > > The file was saved automatically. I don't think you can set what > to save, or even the name of the file. > I also did a xs2png, but that only saves the current figure. In my > case a 610 x 460 pixel image (=the screen figure). > > Cheers, > Claus > > On 21-12-2020 11:21, P M wrote: >> Dear Claus, >> >> the example did not include saving the image as a file. >> >> Best guesses: >> - use imwrite >> - use one of the xs2...-functions (e.g.: xs2bmp) >> >> BR >> Philipp >> >> >> Am Mo., 21. Dez. 2020 um 09:20?Uhr schrieb Claus Futtrup >> >: >> >> Hi Philipp >> >> I see, thank you for explaining it to me. I also see that the >> upscale is not 2x2 = 4, but it is 4x4 so the upscaled image >> is huge. The output file is saved - I believe - in wherever >> your Scilab file browser is currently active. >> >> Best regards, >> Claus >> >> On 20-12-2020 22:55, P M wrote: >>> Dear Claus, >>> >>> you need to feed a list into imsuperres()....not directly >>> the image. >>> Following should work. >>> imgList = list(); >>> imgList(1) = imread('path_to_image'); >>> imgOut = imsuperres(imgList);figure(); imshow(imgList(1)); figure(); >>> imshow(imgOut); BR Philipp >>> >>> >>> Am So., 20. Dez. 2020 um 19:42?Uhr schrieb Claus Futtrup >>> >: >>> >>> Hi there >>> >>> I have a 4K picture, which I thought I'll try to upscale >>> with the >>> imsuperres in the IPCV toolbox. The code simply looks >>> like this: >>> >>> imagefile = >>> 'D:\Userdata\Claus\Pictures\Think_Global_4K.png'; >>> im = imread(imagefile); >>> imout? = imsuperres(im); >>> >>> The file is read and I get the following response: >>> Unsigned Integer 8 >>> bits (2160 x 3840). Then Scilab crashes. I'm running >>> Scilab 6.1.0 (the >>> original release) on Windows 10 - in a MS Windows dialog >>> box I get: >>> >>> ?>Scilab 6.1.0 (Desktop) has stopped working >>> >>> ?>A problem caused the program to stop working >>> correctly. Windows will >>> close the program and notify you if a solution is available. >>> >>> I am not sure that I've understood how to use imsuperres >>> correctly. I >>> see in the _params that rfactor = 4 is the default, so I >>> was expecting >>> the image to be scaled by a factor 4 (maybe that's 2 x 2 >>> = I get an 8K >>> image = 4320 x 7680 pixels). The way I understand the >>> documentation, I >>> don't need to run imsuperres_params if I'm satisified >>> with the defaults. >>> >>> Kind regards, >>> >>> Claus >>> >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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: From Jean-Yves.Baudais at insa-rennes.fr Wed Dec 23 10:42:26 2020 From: Jean-Yves.Baudais at insa-rennes.fr (Jean-Yves Baudais) Date: Wed, 23 Dec 2020 10:42:26 +0100 (CET) Subject: [Scilab-users] atomsLoad In-Reply-To: <2742c2dc-8ce3-469e-fefd-a6b25b809386@utc.fr> References: <1893395180.452434.1608313088195.JavaMail.zimbra@insa-rennes.fr> <1147985828.557207.1608562384245.JavaMail.zimbra@insa-rennes.fr> <3004f551-7647-2e8c-33a5-4db321fd91db@free.fr> <450958042.598780.1608636985061.JavaMail.zimbra@insa-rennes.fr> <441fce18-9bf0-4276-6319-100a27f19cf5@utc.fr> <1607135779.616587.1608649937970.JavaMail.zimbra@insa-rennes.fr> <2742c2dc-8ce3-469e-fefd-a6b25b809386@utc.fr> Message-ID: <1607437615.8528.1608716546818.JavaMail.zimbra@insa-rennes.fr> Hi, Thank you for the code. I'm going to see what I can do. -- Jean-Yves ----- Original Message ----- > From: "St?phane Mottelet" > To: "Users mailing list for Scilab" > Sent: Tuesday, 22 December, 2020 17:02:48 > Subject: Re: [Scilab-users] atomsLoad > I sent you (private message) the modified sources of emd_toolbox, for > the gateway part only. The toolbox compiles and loads, but then there > are problems due to the convention with the empty matrix that changed > since Scilab 6. I hope you will be able to fix them yourself (keep us > informed of your fixes). > > S. > > Le 22/12/2020 ? 16:12, Jean-Yves Baudais a ?crit?: >> Hi, >> >>> It is quite easy (a 10 min. job). I made the needed modifications and it >>> compiles and loads under OSX. If you give me the rights on Gitlab I can commit >>> the modifications this afternoon. >> Ok, but I don't how to do this, but I'm ready to learn :-) So, could you give me >> the step starting with "stftb" source? >> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/atoms.scilab.org/toolboxes/stftb/2.0.2/files/stftb-2.0.2-src.zip >> (I'm regular with Linux command-line, not too much with makefile) >> >> Or, maybe there already exists a document explaining the steps? >> >> -- >> Jean-Yves Baudais >> _______________________________________________ >> users mailing list >> users at lists.scilab.org >> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users > > -- > 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 > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -- Jean-Yves Baudais From Jean-Yves.Baudais at insa-rennes.fr Wed Dec 23 11:46:54 2020 From: Jean-Yves.Baudais at insa-rennes.fr (Jean-Yves Baudais) Date: Wed, 23 Dec 2020 11:46:54 +0100 (CET) Subject: [Scilab-users] file permission and demo_gui() Message-ID: <1392734057.18564.1608720414608.JavaMail.zimbra@insa-rennes.fr> Hello, When I installed Scilab, I unziped the file on my home directory. The permission for all files is read only, and execute if needed. Then, the demo_gui() needs to be executed twice to work. The first time, in file demo_gui.sci: - line 54, the permission of 'File' is read only; - line 55, 'File2' has not been created yet; - line 58, 'File2' is created with the same permission as 'File'; - line 65, 'xmlWrite' cannot write because of read permission only and demo_gui() stops with the error message "Cannot write the file...". The second time 'File2' exists, then demo_gui() works. By default, unzip doesn't change the permission, timestamp... So, is it a bug? -- Jean-Yves Baudais From sgougeon at free.fr Wed Dec 23 14:35:42 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 23 Dec 2020 14:35:42 +0100 Subject: [Scilab-users] file permission and demo_gui() In-Reply-To: <1392734057.18564.1608720414608.JavaMail.zimbra@insa-rennes.fr> References: <1392734057.18564.1608720414608.JavaMail.zimbra@insa-rennes.fr> Message-ID: <096e5fd8-f4a6-9364-917c-343568c5fe58@free.fr> Hello Jean-Yves, Never met this issue. It looks proper to your install. Could you please post the actual full error message? Presently, we don't know if you are analyzing the issue, or if you -- partially -- report it. In addition to the described installation, the full error message would definitely help. Thanks Samuel Le 23/12/2020 ? 11:46, Jean-Yves Baudais a ?crit?: > Hello, > > When I installed Scilab, I unziped the file on my home directory. The permission for all files is read only, and execute if needed. Then, the demo_gui() needs to be executed twice to work. > > The first time, in file demo_gui.sci: > - line 54, the permission of 'File' is read only; > - line 55, 'File2' has not been created yet; > - line 58, 'File2' is created with the same permission as 'File'; > - line 65, 'xmlWrite' cannot write because of read permission only and demo_gui() stops with the error message "Cannot write the file...". > > The second time 'File2' exists, then demo_gui() works. > > By default, unzip doesn't change the permission, timestamp... So, is it a bug? > From sgougeon at free.fr Wed Dec 23 14:58:16 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 23 Dec 2020 14:58:16 +0100 Subject: [Scilab-users] file permission and demo_gui() In-Reply-To: <096e5fd8-f4a6-9364-917c-343568c5fe58@free.fr> References: <1392734057.18564.1608720414608.JavaMail.zimbra@insa-rennes.fr> <096e5fd8-f4a6-9364-917c-343568c5fe58@free.fr> Message-ID: <447ebc33-eede-255e-df41-38c662410b88@free.fr> Le 23/12/2020 ? 14:35, Samuel Gougeon a ?crit?: > > Le 23/12/2020 ? 11:46, Jean-Yves Baudais a ?crit?: >> Hello, >> >> ?? When I installed Scilab, I unziped the file on my home directory. >> The permission for all files is read only, and execute if needed. >> Then, the demo_gui() needs to be executed twice to work. >> >> The first time, in file demo_gui.sci: >> - line 54, the permission of 'File' is read only; >> - line 55, 'File2' has not been created yet; >> - line 58, 'File2' is created with the same permission as 'File'; This is an issue, because File2 is copied from File in your TMPDIR where all files are assumed to be writable. >> - line 65, 'xmlWrite' cannot write because of read permission only >> and demo_gui() stops with the error message "Cannot write the file...". >> >> The second time 'File2' exists, then demo_gui() works. Yes, because File2 exists, but has not been possibly updated according to your Preferences=>General demo GUI? preference. I will try to test by forcing File permissions on my system, and see what copyfile() does. From sgougeon at free.fr Wed Dec 23 15:15:36 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 23 Dec 2020 15:15:36 +0100 Subject: [Scilab-users] file permission and demo_gui() In-Reply-To: <447ebc33-eede-255e-df41-38c662410b88@free.fr> References: <1392734057.18564.1608720414608.JavaMail.zimbra@insa-rennes.fr> <096e5fd8-f4a6-9364-917c-343568c5fe58@free.fr> <447ebc33-eede-255e-df41-38c662410b88@free.fr> Message-ID: <11706453-fd99-3323-ec71-77ccb588e2bf@free.fr> Le 23/12/2020 ? 14:58, Samuel Gougeon a ?crit?: > > Yes, because File2 exists, but has not been possibly updated according > to your Preferences=>General demo GUI? preference. > > I will try to test by forcing File permissions on my system, and see > what copyfile() does. On Windows, using copyfile() to copy a non-writeable source file does not keep the non-writeable status for the destination copy: the copy is writeable. For the time being i have no access to any Linux session to test, but readers working on Linux may test and confirm (or nor). From Jean-Yves.Baudais at insa-rennes.fr Wed Dec 23 18:14:57 2020 From: Jean-Yves.Baudais at insa-rennes.fr (Jean-Yves Baudais) Date: Wed, 23 Dec 2020 18:14:57 +0100 (CET) Subject: [Scilab-users] file permission and demo_gui() In-Reply-To: <096e5fd8-f4a6-9364-917c-343568c5fe58@free.fr> References: <1392734057.18564.1608720414608.JavaMail.zimbra@insa-rennes.fr> <096e5fd8-f4a6-9364-917c-343568c5fe58@free.fr> Message-ID: <1978358024.31364.1608743697055.JavaMail.zimbra@insa-rennes.fr> > Never met this issue. It looks proper to your install. Could you please > post the actual full error message? Presently, we don't know if you are > analyzing the issue, or if you -- partially -- report it. In addition to > the described installation, the full error message would definitely help. I analyzed and detailled the issue. The full message is --> demo_gui() at line 49 of function demo_gui ( SCI/modules/demo_tools/macros/demo_gui.sci line 65 ) xmlWrite: Cannot write the file: /tmp/SCI_TMP_22935_iLRVVA/demo_gui_dockable.xml Notes that the permission of /tmp/SCI_TPM_22935/ directory is 'wrx'. All created files by Scilab in /tmp/SCI_TMP_22935/ are 'wr' ones, except demo_gui_dockable.xml (because of the use of copyfile function and because of the original file permissions). -- Jean-Yves From sgougeon at free.fr Wed Dec 23 18:28:44 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 23 Dec 2020 18:28:44 +0100 Subject: [Scilab-users] file permission and demo_gui() In-Reply-To: <1978358024.31364.1608743697055.JavaMail.zimbra@insa-rennes.fr> References: <1392734057.18564.1608720414608.JavaMail.zimbra@insa-rennes.fr> <096e5fd8-f4a6-9364-917c-343568c5fe58@free.fr> <1978358024.31364.1608743697055.JavaMail.zimbra@insa-rennes.fr> Message-ID: <2ee8aab2-dbd1-a5ce-0c19-9febdeb8110e@free.fr> Le 23/12/2020 ? 18:14, Jean-Yves Baudais a ?crit?: > I analyzed and detailled the issue. The full message is > > --> demo_gui() > at line 49 of function demo_gui ( SCI/modules/demo_tools/macros/demo_gui.sci line 65 ) > xmlWrite: Cannot write the file: /tmp/SCI_TMP_22935_iLRVVA/demo_gui_dockable.xml > > > Notes that the permission of /tmp/SCI_TPM_22935/ directory is 'wrx'. Thank you for this confirmation and additional information. > All created files by Scilab in /tmp/SCI_TMP_22935/ are 'wr' ones, except demo_gui_dockable.xml (because of the use of copyfile function and because of the original file permissions). This is really the point. This copyfile behaviour looks proper to Linux. More tests about it would be required, and compared to file permissions coming from unix("cp ...") If your first results are confirmed, as well from other Linux users, it will be clearly an issue to address ASAP. Best regards From Jean-Yves.Baudais at insa-rennes.fr Wed Dec 23 18:40:39 2020 From: Jean-Yves.Baudais at insa-rennes.fr (Jean-Yves Baudais) Date: Wed, 23 Dec 2020 18:40:39 +0100 (CET) Subject: [Scilab-users] file permission and demo_gui() In-Reply-To: <447ebc33-eede-255e-df41-38c662410b88@free.fr> References: <1392734057.18564.1608720414608.JavaMail.zimbra@insa-rennes.fr> <096e5fd8-f4a6-9364-917c-343568c5fe58@free.fr> <447ebc33-eede-255e-df41-38c662410b88@free.fr> Message-ID: <117148253.31869.1608745239769.JavaMail.zimbra@insa-rennes.fr> > I will try to test by forcing File permissions on my system, and see > what copyfile() does. I tested for different combinaison of permissions ('w', 'r', 'x'): copyfile() keeps them unchanged. (Permissions are kept for 'user' only, I guess permission mask or something like that for 'group' and 'other'.) -- Jean-Yves From Jean-Yves.Baudais at insa-rennes.fr Wed Dec 23 18:45:09 2020 From: Jean-Yves.Baudais at insa-rennes.fr (Jean-Yves Baudais) Date: Wed, 23 Dec 2020 18:45:09 +0100 (CET) Subject: [Scilab-users] file permission and demo_gui() In-Reply-To: <117148253.31869.1608745239769.JavaMail.zimbra@insa-rennes.fr> References: <1392734057.18564.1608720414608.JavaMail.zimbra@insa-rennes.fr> <096e5fd8-f4a6-9364-917c-343568c5fe58@free.fr> <447ebc33-eede-255e-df41-38c662410b88@free.fr> <117148253.31869.1608745239769.JavaMail.zimbra@insa-rennes.fr> Message-ID: <1139372128.31984.1608745509102.JavaMail.zimbra@insa-rennes.fr> > I tested for different combinaison of permissions ('w', 'r', 'x'): copyfile() > keeps them unchanged. (Permissions are kept for 'user' only, I guess permission > mask or something like that for 'group' and 'other'.) I forgot: That 'permission mask' for 'group' and 'other' is fixed by Linux system or user account, I don't know, but clearly it does not depends on Scilab. -- Jean-Yves From sgougeon at free.fr Wed Dec 23 19:00:18 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 23 Dec 2020 19:00:18 +0100 Subject: [Scilab-users] file permission and demo_gui() In-Reply-To: <117148253.31869.1608745239769.JavaMail.zimbra@insa-rennes.fr> References: <1392734057.18564.1608720414608.JavaMail.zimbra@insa-rennes.fr> <096e5fd8-f4a6-9364-917c-343568c5fe58@free.fr> <447ebc33-eede-255e-df41-38c662410b88@free.fr> <117148253.31869.1608745239769.JavaMail.zimbra@insa-rennes.fr> Message-ID: <5c3e0bd4-8ec2-fbad-6da7-e48cf685e967@free.fr> Le 23/12/2020 ? 18:40, Jean-Yves Baudais a ?crit?: >> I will try to test by forcing File permissions on my system, and see >> what copyfile() does. > > I tested for different combinaison of permissions ('w', 'r', 'x'): copyfile() keeps them unchanged. (Permissions are kept for 'user' only, I guess permission mask or something like that for 'group' and 'other'.) copyfile has no option to force permissions of the copy. You might do and test the following: 1. replace the copyfile instruction with a mgetl + mputl combination: // r = copyfile(File, File2); r = mgetl(File); mputl(r, File2); 2. exec demo_gui.sci to update it 3. Remove demo_gui_dockable.xml in TMPDIR, or just exit and run a new session (so with a new TMPDIR) 4. run demo_gui(), and play with its dockable preferences. If it works, i will push a patch for Scilab 6.1.1. Anyway the copyfile issue would have to be addressed. Since copyfile() is used 18 times within Scilab, other issues elsewhere could be expected. At least, the fact that permissions are kept should be documented in the copyfile help page. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jean-Yves.Baudais at insa-rennes.fr Wed Dec 23 19:40:50 2020 From: Jean-Yves.Baudais at insa-rennes.fr (Jean-Yves Baudais) Date: Wed, 23 Dec 2020 19:40:50 +0100 (CET) Subject: [Scilab-users] file permission and demo_gui() In-Reply-To: <5c3e0bd4-8ec2-fbad-6da7-e48cf685e967@free.fr> References: <1392734057.18564.1608720414608.JavaMail.zimbra@insa-rennes.fr> <096e5fd8-f4a6-9364-917c-343568c5fe58@free.fr> <447ebc33-eede-255e-df41-38c662410b88@free.fr> <117148253.31869.1608745239769.JavaMail.zimbra@insa-rennes.fr> <5c3e0bd4-8ec2-fbad-6da7-e48cf685e967@free.fr> Message-ID: <443286600.32700.1608748850331.JavaMail.zimbra@insa-rennes.fr> > You might do and test the following: > > 1. replace the copyfile instruction with a mgetl + mputl combination: // r = > copyfile(File, File2); r = mgetl ( File ) ; mputl ( r , File2 ) ; > 2. exec demo_gui.sci to update it > 3. Remove demo_gui_dockable . xml in TMPDIR, or just exit and run a new session > (so with a new TMPDIR) > 4. run demo_gui(), and play with its dockable preferences. > > If it works, i will push a patch for Scilab 6.1.1. Anyway the copyfile issue > would have to be addressed. Since copyfile() is used 18 times within Scilab, > other issues elsewhere could be expected. At least, the fact that permissions > are kept should be documented in the copyfile help page. For me, it's ok and now demo_gui() works: The permission of the demo_gui_dockable.xml file in TMPDIR is now read and write. -- Jean-Yves From sgougeon at free.fr Wed Dec 23 20:09:44 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Wed, 23 Dec 2020 20:09:44 +0100 Subject: [Scilab-users] file permission and demo_gui() In-Reply-To: <443286600.32700.1608748850331.JavaMail.zimbra@insa-rennes.fr> References: <1392734057.18564.1608720414608.JavaMail.zimbra@insa-rennes.fr> <096e5fd8-f4a6-9364-917c-343568c5fe58@free.fr> <447ebc33-eede-255e-df41-38c662410b88@free.fr> <117148253.31869.1608745239769.JavaMail.zimbra@insa-rennes.fr> <5c3e0bd4-8ec2-fbad-6da7-e48cf685e967@free.fr> <443286600.32700.1608748850331.JavaMail.zimbra@insa-rennes.fr> Message-ID: <50b6e768-411f-133e-83bf-cd7faf2f1903@free.fr> Le 23/12/2020 ? 19:40, Jean-Yves Baudais a ?crit?: >> You might do and test the following: >> >> 1. replace the copyfile instruction with a mgetl + mputl combination: // r = >> copyfile(File, File2); r = mgetl ( File ) ; mputl ( r , File2 ) ; >> 2. exec demo_gui.sci to update it >> 3. Remove demo_gui_dockable . xml in TMPDIR, or just exit and run a new session >> (so with a new TMPDIR) >> 4. run demo_gui(), and play with its dockable preferences. >> >> If it works, i will push a patch for Scilab 6.1.1. >> .../... Done > For me, it's ok and now demo_gui() works: The permission of the > demo_gui_dockable.xml file in TMPDIR is now read and write > -- > Jean-Yves > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Tue Dec 29 16:39:49 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Tue, 29 Dec 2020 16:39:49 +0100 Subject: [Scilab-users] New constant %chars to get sets of symbols Message-ID: Dear Scilabers, The need of easily accessing to some sets of symbols in Scilab -- like greek letters, etc -- has been reported for years, for instance in 2011 as the wish 9221 , or more recently as the wish 16505 (July 2020). While these reports have still no actual answer, I definitely share this opinion. In many usual situations it is possible and preferable to directly use and write symbols -- in the documentation, in graphics titles, legends or other annotations, etc -- that do not necessarily request LaTeX expressions or HTML entities, and that are then directly readable in the code. For more than 3 years now, i have set in my startup file and i use on a regular way a constant built as a structure, whose fields are the name of some "classes" of characters. Then, displaying the constant in the console, and copying/pasting selected characters from the display is straightforward, and always available. I find it much more handy than if there were somewhere a menu to browse, a menu item to select, a popup showing a table of characters to expect, added to the selection/copy/pasting of the chosen character. As well, i must confess that having a ALT+X or any other keys shortcut able to convert a series of 2 to 4 input unicodes to the corresponding character -- as proposed in wish #16505 -- would be of almost no help to me, because i do not remember unicodes of any non-ascii characters. Who does? Such a ALT-X shortcut is used for instance in the -- yet great -- /Inskscape/ free drawing software. Then, each time that a greek letter or another symbol must be used, we need to find its unicodes in an extra document (most often on internet). It's definitely not handy. So, i would like to propose to add this new constant to Scilab, for the benefit of all users. In this respect, you will find there the proposed help page for such a new constant . As for now, i have named it %chars: * Most of existing Scilab constants have a name starting with %. We can keep this convention. * A short name is desirable, to keep it handy. As warned in the proposed page, and as experimented during 3 years on my side, Character sets provided by %chars must not be considered as fixed and definitive. The number of sets, their names, hierarchy, and order can vary in the future, as well as the order of characters in the sets. In addition, a given character may belong to several sets. Every comment is welcome about such a new constant. Best regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine.monmayrant at laas.fr Thu Dec 31 10:36:31 2020 From: antoine.monmayrant at laas.fr (Antoine Monmayrant) Date: Thu, 31 Dec 2020 10:36:31 +0100 Subject: [Scilab-users] New constant %chars to get sets of symbols In-Reply-To: References: Message-ID: On 29/12/2020 16:39, Samuel Gougeon wrote: > As well, i must confess that having a ALT+X or any other keys shortcut > able to convert a series of 2 to 4 input unicodes to the corresponding > character -- as proposed in wish #16505 -- would be of almost no help > to me, because i do not remember unicodes of any non-ascii characters. > Who does? Such a ALT-X shortcut is used for instance in the -- yet > great -- /Inskscape/ free drawing software. Then, each time that a > greek letter or another symbol must be used, we need to find its > unicodes in an extra document (most often on internet). It's > definitely not handy. I agree with you here. It is not a good idea to use such a shortcut that replicates what is already present at the OS level: on linux for example Crtl+Alt+Maj+u allows to type the unicode of a character (like 3BB for ?). Equivalent shortcuts exist under Windows and MacOS. From my personal experience, my preferred implementation is the one used by Julia: type the LaTeX macro (like \lambda for ?) then Tab and you get the unicode character. I assume implementation something like that in Scilab is quite a lot of work... Your proposition might be a good compromise between ease of implementation and usefulness. Cheers, Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Thu Dec 31 13:44:13 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 31 Dec 2020 13:44:13 +0100 Subject: [Scilab-users] New constant %chars to get sets of symbols In-Reply-To: References: Message-ID: Le 31/12/2020 ? 10:36, Antoine Monmayrant a ?crit?: > On 29/12/2020 16:39, Samuel Gougeon wrote: >> As well, i must confess that having a ALT+X or any other keys >> shortcut able to convert a series of 2 to 4 input unicodes to the >> corresponding character -- as proposed in wish #16505 -- would be of >> almost no help to me, because i do not remember unicodes of any >> non-ascii characters. Who does? Such a ALT-X shortcut is used for >> instance in the -- yet great -- /Inskscape/ free drawing software. >> Then, each time that a greek letter or another symbol must be used, >> we need to find its unicodes in an extra document (most often on >> internet). It's definitely not handy. > I agree with you here. > It is not a good idea to use such a shortcut that replicates what is > already present at the OS level: on linux for example Crtl+Alt+Maj+u > allows to type the unicode of a character (like 3BB for ?). Equivalent > shortcuts exist under Windows and MacOS. > > From my personal experience, my preferred implementation is the one > used by Julia: type the LaTeX macro (like \lambda for ?) then Tab and > you get the unicode character. > I assume implementation something like that in Scilab is quite a lot > of work... > > Your proposition might be a good compromise between ease of > implementation and usefulness. > Thank you for your input and for supporting the proposal, Antoine. About any shortcut proposal, may i add that, yes it would be a more general solution than the selected characters in %chars. But while getting an external document referencing unicodes of some requested symbols, i don't see any reason to get the unicodes and use the shortcut, instead of directly copying the character from this external document and copying it wherever it is needed in Scilab or elsewhere, as in a documentation page edited with Notepadd++ for instance. Therefore, the right external document to select is not a document listing unicodes, but more simply a document listing characters sets rendered without gif or other images. Before implementing this %chars, it was what i used to do. I am not sure that implementing the Julia solution with LaTeX would improve a lot the situation: * first, we still have to remember a code, the latex one ; this is simple for common characters, but get harder and harder for less frequent ones. While a selection among displayed/rendered characters do not need to remember any code. I have written 700 pages in LaTeX without wysiwym software like LyX, and hopefully i had always a hand on "A Guide to LaTeX-2e"? and its tables of illustrated codes to get the right one. * Moreover, we can put in %chars some characters that have no LaTeX code. * Finally, implementing a LaTeX shortcut could not be used when editing the documentation out of the console and Scinotes, except to render the character in order to then, anyway, copy/paste it wherever needed. So, to me, the main purposes are * to stop having to remember any code for the -- say 500 or 1000 -- most used characters, when no complex expression is required. * to stop having to search in an external document when working with Scilab * and possibly, to present classes of characters, what can help finding the required one. Beyong this current topic and the trivial implementation of %chars, it could then even be useful to have an easy way to get the LaTeX code from a selected character, instead of the opposite! Regards Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine.monmayrant at laas.fr Thu Dec 31 15:27:11 2020 From: antoine.monmayrant at laas.fr (Antoine Monmayrant) Date: Thu, 31 Dec 2020 15:27:11 +0100 Subject: [Scilab-users] New constant %chars to get sets of symbols In-Reply-To: References: Message-ID: <43361e27-a09f-eaef-0add-206b1bc4e824@laas.fr> On 31/12/2020 13:44, Samuel Gougeon wrote: > Le 31/12/2020 ? 10:36, Antoine Monmayrant a ?crit?: >> On 29/12/2020 16:39, Samuel Gougeon wrote: >>> As well, i must confess that having a ALT+X or any other keys >>> shortcut able to convert a series of 2 to 4 input unicodes to the >>> corresponding character -- as proposed in wish #16505 -- would be of >>> almost no help to me, because i do not remember unicodes of any >>> non-ascii characters. Who does? Such a ALT-X shortcut is used for >>> instance in the -- yet great -- /Inskscape/ free drawing software. >>> Then, each time that a greek letter or another symbol must be used, >>> we need to find its unicodes in an extra document (most often on >>> internet). It's definitely not handy. >> I agree with you here. >> It is not a good idea to use such a shortcut that replicates what is >> already present at the OS level: on linux for example Crtl+Alt+Maj+u >> allows to type the unicode of a character (like 3BB for ?). >> Equivalent shortcuts exist under Windows and MacOS. >> >> From my personal experience, my preferred implementation is the one >> used by Julia: type the LaTeX macro (like \lambda for ?) then Tab and >> you get the unicode character. >> I assume implementation something like that in Scilab is quite a lot >> of work... >> >> Your proposition might be a good compromise between ease of >> implementation and usefulness. >> > > Thank you for your input and for supporting the proposal, Antoine. > > About any shortcut proposal, may i add that, yes it would be a more > general solution than the selected characters in %chars. But while > getting an external document referencing unicodes of some requested > symbols, i don't see any reason to get the unicodes and use the > shortcut, instead of directly copying the character from this external > document and copying it wherever it is needed in Scilab or elsewhere, > as in a documentation page edited with Notepadd++ for instance. > Therefore, the right external document to select is not a document > listing unicodes, but more simply a document listing characters sets > rendered without gif or other images. Before implementing this %chars, > it was what i used to do. > > I am not sure that implementing the Julia solution with LaTeX would > improve a lot the situation: > > * first, we still have to remember a code, the latex one ; this is > simple for common characters, but get harder and harder for less > frequent ones. While a selection among displayed/rendered > characters do not need to remember any code. I have written 700 > pages in LaTeX without wysiwym software like LyX, and hopefully i > had always a hand on "A Guide to LaTeX-2e"? and its tables of > illustrated codes to get the right one. > * Moreover, we can put in %chars some characters that have no LaTeX > code. > * Finally, implementing a LaTeX shortcut could not be used when > editing the documentation out of the console and Scinotes, except > to render the character in order to then, anyway, copy/paste it > wherever needed. > > So, to me, the main purposes are > > * to stop having to remember any code for the -- say 500 or 1000 -- > most used characters, when no complex expression is required. > Well, I don't see how this should work then. How do I select ? in your proposed solution? Should I have to visually scan a 500-symbol long list? I think I missed something in your proposal. > > * > > > * to stop having to search in an external document when working with > Scilab > * and possibly, to present classes of characters, what can help > finding the required one. > > Beyong this current topic and the trivial implementation of %chars, it > could then even be useful to have an easy way to get the LaTeX code > from a selected character, instead of the opposite! > Well, here is my assumption (that might be wrong): most of the people trying to use ? or ? might be aware that they are called lambda and Delta and from there, the LaTeX naming convention is usually quite sensible: \lambda, \Delta. I think there is quite a difference between remembering Ctrl+Maj+Alt+u+03BB and remembering \lambda+Tab to get ?! For me, the second solution is way more user friendly... :-) Antoine > Regards > Samuel > > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Thu Dec 31 15:43:07 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 31 Dec 2020 15:43:07 +0100 Subject: [Scilab-users] New constant %chars to get sets of symbols In-Reply-To: <43361e27-a09f-eaef-0add-206b1bc4e824@laas.fr> References: <43361e27-a09f-eaef-0add-206b1bc4e824@laas.fr> Message-ID: Le 31/12/2020 ? 15:27, Antoine Monmayrant a ?crit?: > .../... >> >> I am not sure that implementing the Julia solution with LaTeX would >> improve a lot the situation: >> >> * first, we still have to remember a code, the latex one ; this is >> simple for common characters, but get harder and harder for less >> frequent ones. While a selection among displayed/rendered >> characters do not need to remember any code. I have written 700 >> pages in LaTeX without wysiwym software like LyX, and hopefully i >> had always a hand on "A Guide to LaTeX-2e"? and its tables of >> illustrated codes to get the right one. >> * Moreover, we can put in %chars some characters that have no LaTeX >> code. >> * Finally, implementing a LaTeX shortcut could not be used when >> editing the documentation out of the console and Scinotes, except >> to render the character in order to then, anyway, copy/paste it >> wherever needed. >> >> So, to me, the main purposes are >> >> * to stop having to remember any code for the -- say 500 or 1000 -- >> most used characters, when no complex expression is required. >> > Well, I don't see how this should work then. > How do I select ? in your proposed solution? Should I have to visually > scan a 500-symbol long list? > I think I missed something in your proposal. > We enter and display --> %chars?? // (OK not here. See the proposed documentation for the full display) or for a chosen class --> %chars.greek ?ans? = ? lower = "?????????????????????????????????????????" ? upper = "??????????????????????????? ???" Then we select ?, and copy/paste it where needed. >> >> * to stop having to search in an external document when working >> with Scilab >> * and possibly, to present classes of characters, what can help >> finding the required one. >> >> Beyong this current topic and the trivial implementation of %chars, >> it could then even be useful to have an easy way to get the LaTeX >> code from a selected character, instead of the opposite! >> > Well, here is my assumption (that might be wrong): most of the people > trying to use ? or ? might be aware that they are called lambda and > Delta and from there, the LaTeX naming convention is usually quite > sensible: \lambda, \Delta. > Yes, these are the frequent easy characters to remember. > I think there is quite a difference between remembering > Ctrl+Maj+Alt+u+03BB and remembering \lambda+Tab to get ?! > For me, the second solution is way more user friendly... :-) > For sure, but, still, i won't remember \Diamond (why with a capital?), \diamondsuit (all in lowercases), \vdash, etc etc codes without _/first/ sawing_ them rendered. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.mottelet at utc.fr Thu Dec 31 15:46:59 2020 From: stephane.mottelet at utc.fr (=?utf-8?Q?St=C3=A9phane_Mottelet?=) Date: Thu, 31 Dec 2020 15:46:59 +0100 Subject: [Scilab-users] New constant %chars to get sets of symbols In-Reply-To: <43361e27-a09f-eaef-0add-206b1bc4e824@laas.fr> References: <43361e27-a09f-eaef-0add-206b1bc4e824@laas.fr> Message-ID: <09CD5227-9C90-4C77-B8DA-0ACD67BE4F01@utc.fr> > Le 31 d?c. 2020 ? 15:28, Antoine Monmayrant a ?crit : > > ? > > > On 31/12/2020 13:44, Samuel Gougeon wrote: >>> Le 31/12/2020 ? 10:36, Antoine Monmayrant a ?crit : >>>> On 29/12/2020 16:39, Samuel Gougeon wrote: >>>>> As well, i must confess that having a ALT+X or any other keys shortcut able to convert a series of 2 to 4 input unicodes to the corresponding character -- as proposed in wish #16505 -- would be of almost no help to me, because i do not remember unicodes of any non-ascii characters. Who does? Such a ALT-X shortcut is used for instance in the -- yet great -- Inskscape free drawing software. Then, each time that a greek letter or another symbol must be used, we need to find its unicodes in an extra document (most often on internet). It's definitely not handy. >>>> I agree with you here. >>>> It is not a good idea to use such a shortcut that replicates what is already present at the OS level: on linux for example Crtl+Alt+Maj+u allows to type the unicode of a character (like 3BB for ?). Equivalent shortcuts exist under Windows and MacOS. >>>> >>>> From my personal experience, my preferred implementation is the one used by Julia: type the LaTeX macro (like \lambda for ?) then Tab and you get the unicode character. >>>> I assume implementation something like that in Scilab is quite a lot of work... >>>> Your proposition might be a good compromise between ease of implementation and usefulness. >>>> >>> >>> Thank you for your input and for supporting the proposal, Antoine. >>> >>> About any shortcut proposal, may i add that, yes it would be a more general solution than the selected characters in %chars. But while getting an external document referencing unicodes of some requested symbols, i don't see any reason to get the unicodes and use the shortcut, instead of directly copying the character from this external document and copying it wherever it is needed in Scilab or elsewhere, as in a documentation page edited with Notepadd++ for instance. >>> Therefore, the right external document to select is not a document listing unicodes, but more simply a document listing characters sets rendered without gif or other images. Before implementing this %chars, it was what i used to do. >>> >>> I am not sure that implementing the Julia solution with LaTeX would improve a lot the situation: >>> >>> first, we still have to remember a code, the latex one ; this is simple for common characters, but get harder and harder for less frequent ones. While a selection among displayed/rendered characters do not need to remember any code. I have written 700 pages in LaTeX without wysiwym software like LyX, and hopefully i had always a hand on "A Guide to LaTeX-2e" and its tables of illustrated codes to get the right one. >>> Moreover, we can put in %chars some characters that have no LaTeX code. >>> Finally, implementing a LaTeX shortcut could not be used when editing the documentation out of the console and Scinotes, except to render the character in order to then, anyway, copy/paste it wherever needed. >>> So, to me, the main purposes are >>> >>> to stop having to remember any code for the -- say 500 or 1000 -- most used characters, when no complex expression is required. >> Well, I don't see how this should work then. >> How do I select ? in your proposed solution? Should I have to visually scan a 500-symbol long list? >> I think I missed something in your proposal. >> >> to stop having to search in an external document when working with Scilab >> and possibly, to present classes of characters, what can help finding the required one. >> Beyong this current topic and the trivial implementation of %chars, it could then even be useful to have an easy way to get the LaTeX code from a selected character, instead of the opposite! >> > Well, here is my assumption (that might be wrong): most of the people trying to use ? or ? might be aware that they are called lambda and Delta and from there, the LaTeX naming convention is usually quite sensible: \lambda, \Delta. > > I think there is quite a difference between remembering Ctrl+Maj+Alt+u+03BB and remembering \lambda+Tab to get ?! > For me, the second solution is way more user friendly... :-) > +1 S. > > > Antoine > >> Regards >> Samuel >> >> >> >> >> _______________________________________________ >> users mailing list >> users at lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/users > _______________________________________________ > users mailing list > users at lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Thu Dec 31 15:49:54 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 31 Dec 2020 15:49:54 +0100 Subject: [Scilab-users] New constant %chars to get sets of symbols In-Reply-To: References: <43361e27-a09f-eaef-0add-206b1bc4e824@laas.fr> Message-ID: <55342192-2ef2-f818-9466-b90ebd170f2a@free.fr> Please read Le 31/12/2020 ? 15:43, Samuel Gougeon a ?crit?: > For sure, but, still, i won't remember \Diamond (why with a capital?), > \diamondsuit (all in lowercases), \vdash, etc etc codes without > _/first/ s*ee*ing_ them rendered. ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine.monmayrant at laas.fr Thu Dec 31 16:11:24 2020 From: antoine.monmayrant at laas.fr (Antoine Monmayrant) Date: Thu, 31 Dec 2020 16:11:24 +0100 Subject: [Scilab-users] New constant %chars to get sets of symbols In-Reply-To: References: <43361e27-a09f-eaef-0add-206b1bc4e824@laas.fr> Message-ID: <981b2550-cb94-f1a4-cd99-5a5ecfbb21df@laas.fr> On 31/12/2020 15:43, Samuel Gougeon wrote: > Le 31/12/2020 ? 15:27, Antoine Monmayrant a ?crit?: >> .../... >>> >>> I am not sure that implementing the Julia solution with LaTeX would >>> improve a lot the situation: >>> >>> * first, we still have to remember a code, the latex one ; this is >>> simple for common characters, but get harder and harder for less >>> frequent ones. While a selection among displayed/rendered >>> characters do not need to remember any code. I have written 700 >>> pages in LaTeX without wysiwym software like LyX, and hopefully >>> i had always a hand on "A Guide to LaTeX-2e"? and its tables of >>> illustrated codes to get the right one. >>> * Moreover, we can put in %chars some characters that have no >>> LaTeX code. >>> * Finally, implementing a LaTeX shortcut could not be used when >>> editing the documentation out of the console and Scinotes, >>> except to render the character in order to then, anyway, >>> copy/paste it wherever needed. >>> >>> So, to me, the main purposes are >>> >>> * to stop having to remember any code for the -- say 500 or 1000 >>> -- most used characters, when no complex expression is required. >>> >> Well, I don't see how this should work then. >> How do I select ? in your proposed solution? Should I have to >> visually scan a 500-symbol long list? >> I think I missed something in your proposal. >> > We enter and display > --> %chars?? // (OK not here. See the proposed documentation for the > full display) > > or for a chosen class > > --> %chars.greek > ?ans? = > ? lower = "?????????????????????????????????????????" > ? upper = "??????????????????????????? ???" OK, I see better what you propose. But you are trading remembering a code (ie \lambda for ?) for remembering which class the symbol you are looking for belongs to... Again, for some of them, it might be obvious (ie \lambda is easy, so is %chars.greek for a Greek symbol) but for some others it's far from obvious. Like where would you put your \Diamond or \vdash? I've used my share of LaTeX IDEs and all the symbols assistants failed me in the same way: they give you easy and obvious access to symbols you already know by heart (ie \alpha is in Greek, top first element) but are a useless mess when looking for more obscure symbols (why is \bigstar in Misc-Math, between \blacklozenge and \spadsuit ?) > > > Then we select ?, and copy/paste it where needed. >>> >>> * to stop having to search in an external document when working >>> with Scilab >>> * and possibly, to present classes of characters, what can help >>> finding the required one. >>> >>> Beyong this current topic and the trivial implementation of %chars, >>> it could then even be useful to have an easy way to get the LaTeX >>> code from a selected character, instead of the opposite! >>> >> Well, here is my assumption (that might be wrong): most of the people >> trying to use ? or ? might be aware that they are called lambda and >> Delta and from there, the LaTeX naming convention is usually quite >> sensible: \lambda, \Delta. >> > > Yes, these are the frequent easy characters to remember. > >> I think there is quite a difference between remembering >> Ctrl+Maj+Alt+u+03BB and remembering \lambda+Tab to get ?! >> For me, the second solution is way more user friendly... :-) >> > For sure, but, still, i won't remember \Diamond (why with a capital?), > \diamondsuit (all in lowercases), \vdash, etc etc codes without > _/first/ sawing_ them rendered. > > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Thu Dec 31 16:36:45 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 31 Dec 2020 16:36:45 +0100 Subject: [Scilab-users] New constant %chars to get sets of symbols In-Reply-To: <981b2550-cb94-f1a4-cd99-5a5ecfbb21df@laas.fr> References: <43361e27-a09f-eaef-0add-206b1bc4e824@laas.fr> <981b2550-cb94-f1a4-cd99-5a5ecfbb21df@laas.fr> Message-ID: <60df5c09-54c1-16d6-aa20-b8be940b02c0@free.fr> Le 31/12/2020 ? 16:11, Antoine Monmayrant a ?crit?: > On 31/12/2020 15:43, Samuel Gougeon wrote: >> .../... >> We enter and display >> --> %chars?? // (OK not here. See the proposed documentation for the >> full display) >> >> or for a chosen class >> >> --> %chars.greek >> ?ans? = >> ? lower = "?????????????????????????????????????????" >> ? upper = "??????????????????????????? ???" > > OK, I see better what you propose. > But you are trading remembering a code (ie \lambda for ?) for > remembering which class the symbol you are looking for belongs to... %chars displays all of them, on less than a screen (50 characters per line x 20 lines make 1000 characters ;-). It is illustrated in the provided help page. And it is hierarchical. So remembering 2 to 10 trivial fields names is enough (instead of 1000 codes), if you wish to display subsets. > Again, for some of them, it might be obvious (ie \lambda is easy, so > is %chars.greek for a Greek symbol) but for some others it's far from > obvious. > Like where would you put your \Diamond or \vdash? I may not understand the question. Please see the documentation. Both are already included in my current %chars illustrated in the doc. > I've used my share of LaTeX IDEs and all the symbols assistants failed > me in the same way: they give you easy and obvious access to symbols > you already know by heart (ie \alpha is in Greek, top first element) > but are a useless mess when looking for more obscure symbols (why is > \bigstar in Misc-Math, between \blacklozenge and \spadsuit ?) +1. That's the point. This is why most often i display the whole %chars. Just %chars. Without any codes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.muehlmann at gmail.com Thu Dec 31 17:28:07 2020 From: p.muehlmann at gmail.com (P M) Date: Thu, 31 Dec 2020 17:28:07 +0100 Subject: [Scilab-users] New constant %chars to get sets of symbols In-Reply-To: <60df5c09-54c1-16d6-aa20-b8be940b02c0@free.fr> References: <43361e27-a09f-eaef-0add-206b1bc4e824@laas.fr> <981b2550-cb94-f1a4-cd99-5a5ecfbb21df@laas.fr> <60df5c09-54c1-16d6-aa20-b8be940b02c0@free.fr> Message-ID: Dear, if the content of e.g. %chars.greek.lower is a string: Why not even subdivide this further, such as: %chars.greek.lower.alpha = "?" %chars.greek.lower.beta = "?" ... Some work to create at first, but handy to use Best Regards, Philppp Am Do., 31. Dez. 2020 um 16:37 Uhr schrieb Samuel Gougeon : > Le 31/12/2020 ? 16:11, Antoine Monmayrant a ?crit : > > On 31/12/2020 15:43, Samuel Gougeon wrote: > > .../... > We enter and display > --> %chars // (OK not here. See the proposed documentation for the full > display) > > or for a chosen class > > --> %chars.greek > ans = > lower = "?????????????????????????????????????????" > upper = "??????????????????????????? ???" > > > OK, I see better what you propose. > But you are trading remembering a code (ie \lambda for ?) for remembering > which class the symbol you are looking for belongs to... > > %chars displays all of them, on less than a screen (50 characters per line > x 20 lines make 1000 characters ;-). It is illustrated in the provided help > page. > And it is hierarchical. So remembering 2 to 10 trivial fields names is > enough (instead of 1000 codes), if you wish to display subsets. > > > Again, for some of them, it might be obvious (ie \lambda is easy, so is > %chars.greek for a Greek symbol) but for some others it's far from obvious. > Like where would you put your \Diamond or \vdash? > > I may not understand the question. Please see the documentation. Both are > already included in my current %chars illustrated in the doc. > > > I've used my share of LaTeX IDEs and all the symbols assistants failed me > in the same way: they give you easy and obvious access to symbols you > already know by heart (ie \alpha is in Greek, top first element) but are a > useless mess when looking for more obscure symbols (why is \bigstar in > Misc-Math, between \blacklozenge and \spadsuit ?) > > +1. That's the point. This is why most often i display the whole %chars. > Just %chars. Without any codes. > > > _______________________________________________ > users mailing list > users at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Thu Dec 31 17:42:55 2020 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 31 Dec 2020 17:42:55 +0100 Subject: [Scilab-users] New constant %chars to get sets of symbols In-Reply-To: References: <43361e27-a09f-eaef-0add-206b1bc4e824@laas.fr> <981b2550-cb94-f1a4-cd99-5a5ecfbb21df@laas.fr> <60df5c09-54c1-16d6-aa20-b8be940b02c0@free.fr> Message-ID: <132d27a4-c4df-1b18-1faa-a6cc5709bc88@free.fr> Hello Philipp, Le 31/12/2020 ? 17:28, P M a ?crit?: > Dear, > > if the content of e.g. %chars.greek.lower is a string: > > Why not even subdivide this further, such as: > > %chars.greek.lower.alpha = "?" > %chars.greek.lower.beta = "?" Because then this would reintroduce some codes (and even worse, paths to codes), and break the overall visibility over sets, which is definitely against the main purposes of the proposal. Cheers Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: