[Scilab-users] Bug report etiquette : memory leaks in graphics

[Antoine Monmayrant]

Hi all,

I know that it's usually bad practice to duplicate an already existing bug.
But it's also good practice to make one report per specific bug.
I've just waisted two days on a nasty memory leak when plotting/clearing a 
graph in a loop (50 iterations were enough to kill scilab).
Looking at reports of bugzilla, I see plethora of memory leak bugs for graphics 
(eg #14310, #14508, #14977 to name just a few) that are most probably all 
related.

Should I report a new bug or comment on these ones, being slightly off topic?

Antoine

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] BUG legends_mc with xsave and xload

[Perrichon]

PS : xsave and xload correctly work with « legend » instruction under 5.5.2,
but « legends_mc » is the ideal presentation.

 

 

De : Perrichon  
Envoyé : mercredi 15 janvier 2020 10:05
À : 'Users mailing list for Scilab' 
Objet : RE: [Scilab-users] BUG legends_mc with xsave and xload

 

Hello Samuel,

You are rigth, it runs with scilab .0.2

But my project is written ith scilab 5.5.2, and I can’t actually go to
6.0.2. May be in the second part of 2020

 

Is there a way to write a workaround with 5.5.2 ?

 

I’ve done a copy of xload from 6.02 and try to adapt

1 no recursive for gcf().uid~=uid ==> replace by hh=gcf() then hh.uid~=uid

2 && not an operator in 5.5.2 (C langage) replace by &

 

But the problem seems with load(fil) in function xloadFigure(fil)

 

This is urgent for me to find a solution

Any advices ?

 

Best regards

 

Pierre P.

 

De : users mailto:users-boun...@lists.scilab.org> > De la part de Samuel Gougeon
Envoyé : mardi 14 janvier 2020 21:08
À : users@lists.scilab.org <mailto:users@lists.scilab.org> 
Objet : Re: [Scilab-users] BUG legends_mc with xsave and xload

 

Hello Pierre,

 

Le 14/01/2020 à 18:33, Perrichon a écrit :

Hello, Hello Samuel,

 

It seems that it is not possible to correctly record or to restaure a graph
using « legends_scm » with « xsave » and « xload »

Structures of the graph are not respected and illegible.

 

If the bug is not corrected, I’ll will be obliged to go back with the «
legend » instruction

Sincerely

 

How to reproduce the bugg :

 

scf(1)

clf, plot2d(), legends_mc('line #'+string(1:3), Lpc=-1, pos="ul" ) //
classic

xsave("foo.scg", gcf())

scf(2)

xload("foo.scg")

 

I am not able to reproduce any issue when running this code with Scilab
6.0.2 on Windows 7.
The initial legend is recovered with the whole figure.

Samuel

 

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] BUG legends_mc with xsave and xload

[Perrichon]

Hello Samuel,

You are rigth, it runs with scilab .0.2

But my project is written ith scilab 5.5.2, and I can’t actually go to
6.0.2. May be in the second part of 2020

 

Is there a way to write a workaround with 5.5.2 ?

 

I’ve done a copy of xload from 6.02 and try to adapt

1 no recursive for gcf().uid~=uid ==> replace by hh=gcf() then hh.uid~=uid

2 && not an operator in 5.5.2 (C langage) replace by &

 

But the problem seems with load(fil) in function xloadFigure(fil)

 

This is urgent for me to find a solution

Any advices ?

 

Best regards

 

Pierre P.

 

De : users  De la part de Samuel Gougeon
Envoyé : mardi 14 janvier 2020 21:08
À : users@lists.scilab.org
Objet : Re: [Scilab-users] BUG legends_mc with xsave and xload

 

Hello Pierre,

 

Le 14/01/2020 à 18:33, Perrichon a écrit :

Hello, Hello Samuel,

 

It seems that it is not possible to correctly record or to restaure a graph
using « legends_scm » with « xsave » and « xload »

Structures of the graph are not respected and illegible.

 

If the bug is not corrected, I’ll will be obliged to go back with the «
legend » instruction

Sincerely

 

How to reproduce the bugg :

 

scf(1)

clf, plot2d(), legends_mc('line #'+string(1:3), Lpc=-1, pos="ul" ) //
classic

xsave("foo.scg", gcf())

scf(2)

xload("foo.scg")

 

I am not able to reproduce any issue when running this code with Scilab
6.0.2 on Windows 7.
The initial legend is recovered with the whole figure.

Samuel

 

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] BUG legends_mc with xsave and xload

[Samuel Gougeon]

Hello Pierre,

Le 14/01/2020 à 18:33, Perrichon a écrit :


Hello, Hello Samuel,

It seems that it is not possible to correctly record or to restaure a 
graph using « legends_scm » with « xsave » and « xload »


Structures of the graph are not respected and illegible.

If the bug is not corrected, I’ll will be obliged to go back with the 
« legend » instruction


Sincerely

How to reproduce the bugg :

scf(1)

clf, plot2d(), legends_mc('line #'+string(1:3), Lpc=-1, pos="ul" ) // 
classic


xsave("foo.scg", gcf())

scf(2)

xload("foo.scg")



I am not able to reproduce any issue when running this code with Scilab 
6.0.2 on Windows 7.

The initial legend is recovered with the whole figure.

Samuel


___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] BUG legends_mc with xsave and xload

[Perrichon]

Hello, Hello Samuel,

 

It seems that it is not possible to correctly record or to restaure a graph
using < legends_scm > with < xsave > and < xload >

Structures of the graph are not respected and illegible.

 

If the bug is not corrected, I'll will be obliged to go back with the <
legend > instruction

Sincerely

 

 

How to reproduce the bugg :

 

scf(1)

clf, plot2d(), legends_mc('line #'+string(1:3), Lpc=-1, pos="ul" ) //
classic

xsave("foo.scg", gcf())

scf(2)

xload("foo.scg")

 

 

 

 

 

 

 

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Bug scilab-6 libjava.so

[Chin Luh Tan]

Hi, 



A few suggestion to try out:



1. Try to locate the libjava.so to see whether java is install. if you, u could 
try to temporary set the JAVA_HOME and try to run scilab again



e.g.: 



$ locate libjava.so 

or

$ update-java-alternatives -l



and then



$ export JAVA_HOME="/usr/lib/jvm/java-8-openjdk-amd64/"   <-- use the path 
obtained from above

$ scilab

or

$ SCIPATH/scilab





2. If the installed java does not works, try to install the openjdk-11 jre

$ sudo apt-get install openjdk-11-jre



repeat the export and run the scilab again.



If it works, u could set the JAVA_HOME path at .bashrc to make it permanent



Hope this helps.



rgds,
CL 









 On Mon, 11 Nov 2019 08:22:40 +0800 Domec Jean Louis  
wrote 



Hello,

I just begin with this list.

I have a  problem with scilab6:

On different PC 64bits, i boot with knoppix-8.6

It uses → Linux kernel 5.2.5 and Xorg 7.7 (core 1.20.4) for supporting 
current computer hardware.

Whem i start scilab-6.02 (installed by 
scilab-6.0.2.bin.linux-x86_64.tar.gz ):

/usr/bin/scilab-bin: error while loading shared libraries: libjava.so: 
cannot open shared object file: No such file or directory

Have you an idea to solve this problem ?

Thank you

-- 

Jean-louis Domec
 Professeur de Physique appliquée
 domecCHEZac-bordeaux.fr
 Laboratoire de Physique Appliquée:
 Tel 0559282228 poste 314
 Fax: 0559280631
 Lycée du Pays de Soule - Chéraute (64)
 
 Courrier réalisé avec le Logiciel Libre Mozilla .
 Sous le Système d'exploitation Libre, Linux Mandriva 2008
 
 Logiciels libres: Le partage des connaissances
 http://www.april.org/
 http://www.ofset.org


___
users mailing list
mailto:users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] Bug scilab-6 libjava.so

[Domec Jean Louis]

Hello,

I just begin with this list.

I have a  problem with scilab6:

On different PC 64bits, i boot with knoppix-8.6

It uses → Linux kernel 5.2.5 and Xorg 7.7 (core 1.20.4) for supporting 
current computer hardware.


Whem i start scilab-6.02 (installed by 
scilab-6.0.2.bin.linux-x86_64.tar.gz ):


/usr/bin/scilab-bin: error while loading shared libraries: libjava.so: 
cannot open shared object file: No such file or directory


Have you an idea to solve this problem ?

Thank you

--

Jean-louis Domec
 Professeur de Physique appliquée
 domecCHEZac-bordeaux.fr
 Laboratoire de Physique Appliquée:
 Tel 0559282228 poste 314
 Fax: 0559280631
 Lycée du Pays de Soule - Chéraute (64)
 
 Courrier réalisé avec le Logiciel Libre Mozilla .

 Sous le Système d'exploitation Libre, Linux Mandriva 2008
 
 Logiciels libres: Le partage des connaissances

 http://www.april.org/
 http://www.ofset.org


___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] bug in scilab histplot normalization

[philippe]

Hi to all

the histograms from histplot looks to have a bad normalization  in
scilab 6.0.1 (ubuntu 18.04) , see :

http://bugzilla.scilab.org/show_bug.cgi?id=15832

the images in the help page for histplot show the problem even on scilab
website :

https://help.scilab.org/docs/6.0.1/fr_FR/histplot.html

just run the example #3 to confirm :

lambda = 2;
X = grand(10,1,"exp", 1/lambda);
Xmax = max(X);
clf()
histplot(40, X, style=2)
x = linspace(0,max(Xmax),100)';
plot2d(x,lambda*exp(-lambda*x),strf="000",style=5)
legend(["exponential random sample histogram" "exact density curve"]);


best regards,
Philippe

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] bug when setting gcbo field in a callback function ?

[Samuel Gougeon]

Le 29/09/2018 à 18:16, Stéphane Mottelet a écrit :
Another example of such weirdness: consider (fixed) bug #13359. Its 
non-regression test fail (at least on my OSX and Linux machines) 
systematicaly when run by


--> test_run cacsd bug_13359

When run interactively by

--> exec SCI/modules/cacsd/tests/nonreg_tests/bug_13359.tst

it sometimes succeed and sometimes fail, this completely random. 
However, if you insert a sleep line 25


(...)
d1 = datatipCreate(pl, 200);
sleep(10) // line inserted
txt_datatip = d1.text;
assert_checkequal(strindex(txt_datatip(2), "-"), 1);

Then the test, executed by exec SCI/... above, always succeed. 
However, even with a bigger duration of sleep, even sleep(1000), then 
"test_run cacsd bug_13359" always fail.


A follow-up is proposed on dev@ starting at 
http://mailinglists.scilab.org/Re-Scilab-users-bug-when-setting-gcbo-field-in-a-callback-function-tp4038626.html


Samuel

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] bug when setting gcbo field in a callback function ?

[Stéphane Mottelet]

Another example of such weirdness: consider (fixed) bug #13359. Its 
non-regression test fail (at least on my OSX and Linux machines) 
systematicaly when run by


--> test_run cacsd bug_13359

When run interactively by

--> exec SCI/modules/cacsd/tests/nonreg_tests/bug_13359.tst

it sometimes succeed and sometimes fail, this completely random. 
However, if you insert a sleep line 25


(...)
d1 = datatipCreate(pl, 200);
sleep(10) // line inserted
txt_datatip = d1.text;
assert_checkequal(strindex(txt_datatip(2), "-"), 1);

Then the test, executed by exec SCI/... above, always succeed. However, 
even with a bigger duration of sleep, even sleep(1000), then "test_run 
cacsd bug_13359" always fail.


S.

Le 29/09/2018 à 13:05, Stéphane Mottelet a écrit :

Hello Antoine

There are multiple other problems like this one, solved when inserting a pause 
or a sleep. They are java synchronization problems, likely

S.


Le 29 sept. 2018 à 12:47, antoine monmayrant  a 
écrit :




Le 29/09/2018 à 12:10, Samuel Gougeon a écrit :

Le 29/09/2018 à 00:31, antoine monmayrant a écrit :
Hello Stéphane,

Well, I tried exactly this trick with mixed results: it kind of works most of 
the time, but sometimes it fails.
I did not manage to reproduce the issue with my minimum working example though.

It's weird, no?
Why would gcbo behave differently than h?

As for why "set" is working, while "gcbo.whatever=something" is failing, I think it's 
because something goes wrong when scilab is parsing "gcbo.whatever=something".
It is as if scilab forgot about the fact that gcbo exists and does what we 
expect when creating a struct:
 doesnotexists.whatever=something;
creates a "doesnotexists" struct with one field==something.

This bug exists at least since Scilab 5.3.3 (not tested with older versions) 
and is not yet reported. u

He, he, I assume that we are all guilty here, right? ;-)
So here it is: 
https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=15786
Could some of you try it on their preferred platform/scilab_version and comment 
on the bug report accordingly?

I also got this problem (a handle turning into a struct) when updating a 
graphic handle field quickly inside a loop.
It's less frequent and I never managed to reproduce the bug in a deterministic 
way so I never reported it.
Of course, whenever I faced this bug, trying to pause and run the code 
step-by-step does not show any bug.
Could there be some sort of race condition here, like when you access the 
handle fields too many times too quickly, scilab does as if the handle does not 
exists and interpret your code as the creation of a new struct with a given 
field?

Cheers,

Antoine

Samuel

___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] bug when setting gcbo field in a callback function ?

[Stéphane Mottelet]

Hello Antoine 

There are multiple other problems like this one, solved when inserting a pause 
or a sleep. They are java synchronization problems, likely

S.

> Le 29 sept. 2018 à 12:47, antoine monmayrant  a 
> écrit :
> 
> 
> 
>> Le 29/09/2018 à 12:10, Samuel Gougeon a écrit :
>>> Le 29/09/2018 à 00:31, antoine monmayrant a écrit :
>>> Hello Stéphane,
>>> 
>>> Well, I tried exactly this trick with mixed results: it kind of works most 
>>> of the time, but sometimes it fails.
>>> I did not manage to reproduce the issue with my minimum working example 
>>> though.
>>> 
>>> It's weird, no?
>>> Why would gcbo behave differently than h?
>>> 
>>> As for why "set" is working, while "gcbo.whatever=something" is failing, I 
>>> think it's because something goes wrong when scilab is parsing 
>>> "gcbo.whatever=something".
>>> It is as if scilab forgot about the fact that gcbo exists and does what we 
>>> expect when creating a struct:
>>> doesnotexists.whatever=something;
>>> creates a "doesnotexists" struct with one field==something.
>> 
>> This bug exists at least since Scilab 5.3.3 (not tested with older versions) 
>> and is not yet reported. u
> He, he, I assume that we are all guilty here, right? ;-)
> So here it is: 
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=15786
> Could some of you try it on their preferred platform/scilab_version and 
> comment on the bug report accordingly?
> 
> I also got this problem (a handle turning into a struct) when updating a 
> graphic handle field quickly inside a loop.
> It's less frequent and I never managed to reproduce the bug in a 
> deterministic way so I never reported it.
> Of course, whenever I faced this bug, trying to pause and run the code 
> step-by-step does not show any bug.
> Could there be some sort of race condition here, like when you access the 
> handle fields too many times too quickly, scilab does as if the handle does 
> not exists and interpret your code as the creation of a new struct with a 
> given field?
> 
> Cheers,
> 
> Antoine
>> 
>> Samuel
>> 
>> ___
>> users mailing list
>> users@lists.scilab.org
>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
>> 
> 
> ___
> users mailing list
> users@lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] bug when setting gcbo field in a callback function ?

[antoine monmayrant]

Le 29/09/2018 à 12:10, Samuel Gougeon a écrit :

Le 29/09/2018 à 00:31, antoine monmayrant a écrit :

Hello Stéphane,

Well, I tried exactly this trick with mixed results: it kind of works 
most of the time, but sometimes it fails.
I did not manage to reproduce the issue with my minimum working 
example though.


It's weird, no?
Why would gcbo behave differently than h?

As for why "set" is working, while "gcbo.whatever=something" is 
failing, I think it's because something goes wrong when scilab is 
parsing "gcbo.whatever=something".
It is as if scilab forgot about the fact that gcbo exists and does 
what we expect when creating a struct:

    doesnotexists.whatever=something;
creates a "doesnotexists" struct with one field==something.


This bug exists at least since Scilab 5.3.3 (not tested with older 
versions) and is not yet reported. u

He, he, I assume that we are all guilty here, right? ;-)
So here it is: http://bugzilla.scilab.org/show_bug.cgi?id=15786
Could some of you try it on their preferred platform/scilab_version and 
comment on the bug report accordingly?


I also got this problem (a handle turning into a struct) when updating a 
graphic handle field quickly inside a loop.
It's less frequent and I never managed to reproduce the bug in a 
deterministic way so I never reported it.
Of course, whenever I faced this bug, trying to pause and run the code 
step-by-step does not show any bug.
Could there be some sort of race condition here, like when you access 
the handle fields too many times too quickly, scilab does as if the 
handle does not exists and interpret your code as the creation of a new 
struct with a given field?


Cheers,

Antoine


Samuel

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users



___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] bug when setting gcbo field in a callback function ?

[Samuel Gougeon]

Le 29/09/2018 à 00:31, antoine monmayrant a écrit :

Hello Stéphane,

Well, I tried exactly this trick with mixed results: it kind of works 
most of the time, but sometimes it fails.
I did not manage to reproduce the issue with my minimum working 
example though.


It's weird, no?
Why would gcbo behave differently than h?

As for why "set" is working, while "gcbo.whatever=something" is 
failing, I think it's because something goes wrong when scilab is 
parsing "gcbo.whatever=something".
It is as if scilab forgot about the fact that gcbo exists and does 
what we expect when creating a struct:

doesnotexists.whatever=something;
creates a "doesnotexists" struct with one field==something.


This bug exists at least since Scilab 5.3.3 (not tested with older 
versions) and is not yet reported.


Samuel

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] bug when setting gcbo field in a callback function ?

[antoine monmayrant]

Hello Stéphane,

Well, I tried exactly this trick with mixed results: it kind of works 
most of the time, but sometimes it fails.
I did not manage to reproduce the issue with my minimum working example 
though.


It's weird, no?
Why would gcbo behave differently than h?

As for why "set" is working, while "gcbo.whatever=something" is failing, 
I think it's because something goes wrong when scilab is parsing 
"gcbo.whatever=something".
It is as if scilab forgot about the fact that gcbo exists and does what 
we expect when creating a struct:

    doesnotexists.whatever=something;
creates a "doesnotexists" struct with one field==something.

Antoine


Le 29/09/2018 à 00:04, Stéphane Mottelet a écrit :

Hello Antoine,

Never trust the life time of gcbo, and first copy the value of gcbo 
like this:


function  funcb1()
    h=gcbo
    disp(typeof(h));
    h.callback_type=-1;
    disp(typeof(h));
    h.callback_type=0;
endfunction

With this trick the type of h is always a handle. However, I cannot 
explain why the second syntax using set() always works...


S.

Le 28/09/2018 à 21:00, antoine monmayrant a écrit :

Hi all,

In a callback function, gcbo is a handle to the calling uicontrol.
There are 2 ways to set one of the fields of this handle (let's take 
"callback_type" as an example):

    (1)    gcbo.callback_type=-1;
or equivalently
    (2)    set(gcbo, "callback_type",-1);

In theory, both are perfectly equivalent.
In practice however, (1) leads to recurrent issues where gcbo is no 
longer a handle, but a structure!


See below  an example script showing the difference:
- two slides with equivalent callback functions funcb1 and funcb2, 
but for the different syntactic sugar (1) or (2).
- if you play with the top slider in the figure, everything's fine, 
gcbo remains a handle (see output on the console).
- if you play with the bottom slider in the figure, gcbo turns into a 
struct (see output on the console).


Needless to say, this kind of issue made my GUI debugging session 
really fun.
To make things even more fun, if you "pause" then execute "funcb1()" 
step by step, you don't necessarily trigger the bug, it's quite 
random and fairly unfrequent.


Can you try to reproduce this bug on your computer?

Cheers,

Antoine


// BUG_gcbo_set.sce //
h=scf();

hs1=uicontrol(h, ...
    "style", "slider", ...
    "tag", "slide1", ...
    "backgroundcolor", [1 1 1], ...
    "value", 0, ...
    "min", -100, ...
    "max", 100, ...
    "sliderstep", [1, 10], ...
    "position", [20,40,200,20], ...
    "constraints", createConstraints("border", "top"), ...
    "callback", "funcb1");

function  funcb1()
    disp(typeof(gcbo));
    gcbo.callback_type=-1;
    disp(typeof(gcbo));
    gcbo.callback_type=0;
endfunction


hs2=uicontrol(h, ...
    "style", "slider", ...
    "tag", "slide1", ...
    "backgroundcolor", [1 1 1], ...
    "value", 0, ...
    "min", -100, ...
    "max", 100, ...
    "sliderstep", [1, 10], ...
    "position", [20,80,200,20], ...
    "constraints", createConstraints("border", "top"), ...
    "callback", "funcb2");

function  funcb2()
    disp(typeof(gcbo));
    set(gcbo, "callback_type",-1);
    disp(typeof(gcbo));
    set(gcbo, "callback_type",0)
endfunction

___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users 



___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users



___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] bug when setting gcbo field in a callback function ?

[Stéphane Mottelet]

Hello Antoine,

Never trust the life time of gcbo, and first copy the value of gcbo like 
this:


function  funcb1()
    h=gcbo
    disp(typeof(h));
    h.callback_type=-1;
    disp(typeof(h));
    h.callback_type=0;
endfunction

With this trick the type of h is always a handle. However, I cannot 
explain why the second syntax using set() always works...


S.

Le 28/09/2018 à 21:00, antoine monmayrant a écrit :

Hi all,

In a callback function, gcbo is a handle to the calling uicontrol.
There are 2 ways to set one of the fields of this handle (let's take 
"callback_type" as an example):

    (1)    gcbo.callback_type=-1;
or equivalently
    (2)    set(gcbo, "callback_type",-1);

In theory, both are perfectly equivalent.
In practice however, (1) leads to recurrent issues where gcbo is no 
longer a handle, but a structure!


See below  an example script showing the difference:
- two slides with equivalent callback functions funcb1 and funcb2, but 
for the different syntactic sugar (1) or (2).
- if you play with the top slider in the figure, everything's fine, 
gcbo remains a handle (see output on the console).
- if you play with the bottom slider in the figure, gcbo turns into a 
struct (see output on the console).


Needless to say, this kind of issue made my GUI debugging session 
really fun.
To make things even more fun, if you "pause" then execute "funcb1()" 
step by step, you don't necessarily trigger the bug, it's quite random 
and fairly unfrequent.


Can you try to reproduce this bug on your computer?

Cheers,

Antoine


// BUG_gcbo_set.sce //
h=scf();

hs1=uicontrol(h, ...
    "style", "slider", ...
    "tag", "slide1", ...
    "backgroundcolor", [1 1 1], ...
    "value", 0, ...
    "min", -100, ...
    "max", 100, ...
    "sliderstep", [1, 10], ...
    "position", [20,40,200,20], ...
    "constraints", createConstraints("border", "top"), ...
    "callback", "funcb1");

function  funcb1()
    disp(typeof(gcbo));
    gcbo.callback_type=-1;
    disp(typeof(gcbo));
    gcbo.callback_type=0;
endfunction


hs2=uicontrol(h, ...
    "style", "slider", ...
    "tag", "slide1", ...
    "backgroundcolor", [1 1 1], ...
    "value", 0, ...
    "min", -100, ...
    "max", 100, ...
    "sliderstep", [1, 10], ...
    "position", [20,80,200,20], ...
    "constraints", createConstraints("border", "top"), ...
    "callback", "funcb2");

function  funcb2()
    disp(typeof(gcbo));
    set(gcbo, "callback_type",-1);
    disp(typeof(gcbo));
    set(gcbo, "callback_type",0)
endfunction

___
users mailing list
users@lists.scilab.org
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users 



___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] bug when setting gcbo field in a callback function ?

[antoine monmayrant]

Hi all,

In a callback function, gcbo is a handle to the calling uicontrol.
There are 2 ways to set one of the fields of this handle (let's take 
"callback_type" as an example):

    (1)    gcbo.callback_type=-1;
or equivalently
    (2)    set(gcbo, "callback_type",-1);

In theory, both are perfectly equivalent.
In practice however, (1) leads to recurrent issues where gcbo is no 
longer a handle, but a structure!


See below  an example script showing the difference:
- two slides with equivalent callback functions funcb1 and funcb2, but 
for the different syntactic sugar (1) or (2).
- if you play with the top slider in the figure, everything's fine, gcbo 
remains a handle (see output on the console).
- if you play with the bottom slider in the figure, gcbo turns into a 
struct (see output on the console).


Needless to say, this kind of issue made my GUI debugging session really 
fun.
To make things even more fun, if you "pause" then execute "funcb1()" 
step by step, you don't necessarily trigger the bug, it's quite random 
and fairly unfrequent.


Can you try to reproduce this bug on your computer?

Cheers,

Antoine


// BUG_gcbo_set.sce //
h=scf();

hs1=uicontrol(h, ...
    "style", "slider", ...
    "tag", "slide1", ...
    "backgroundcolor", [1 1 1], ...
    "value", 0, ...
    "min", -100, ...
    "max", 100, ...
    "sliderstep", [1, 10], ...
    "position", [20,40,200,20], ...
    "constraints", createConstraints("border", "top"), ...
    "callback", "funcb1");

function  funcb1()
    disp(typeof(gcbo));
    gcbo.callback_type=-1;
    disp(typeof(gcbo));
    gcbo.callback_type=0;
endfunction


hs2=uicontrol(h, ...
    "style", "slider", ...
    "tag", "slide1", ...
    "backgroundcolor", [1 1 1], ...
    "value", 0, ...
    "min", -100, ...
    "max", 100, ...
    "sliderstep", [1, 10], ...
    "position", [20,80,200,20], ...
    "constraints", createConstraints("border", "top"), ...
    "callback", "funcb2");

function  funcb2()
    disp(typeof(gcbo));
    set(gcbo, "callback_type",-1);
    disp(typeof(gcbo));
    set(gcbo, "callback_type",0)
endfunction

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] bug in degree and polynomials comparison ?

[philippe]

Le 20/08/2018 à 17:50, Samuel Gougeon a écrit :
> Hello Philippe,
> 
> This is fixed in Scilab 6.0.2-. Please see mainly
> http://bugzilla.scilab.org/14701
> http://bugzilla.scilab.org/14708

thanks Samuel, I missed those reports on bugzilla

Best regards,

Philippe

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] bug in degree and polynomials comparison ?

[Samuel Gougeon]

Hello Philippe,

This is fixed in Scilab 6.0.2-. Please see mainly
http://bugzilla.scilab.org/14701
http://bugzilla.scilab.org/14708

Regards
Samuel

Le 20/08/2018 à 17:27, philippe a écrit :

Hi,

while upgrading one of my toolboxes I discovered a strange error in
polynomial comparisons. The error appeared during automatic unit tests,
a " assert_checkequal(P1,P2)" was expected to be True and was in fact
False. After some investigations It looks like there is an error in
degree so that   P1==P2 can be False  while  P1-P2==0.

Can someone confirm the bug in scilab-6.0.1  before I fill in a report
on bugzilla. Run the following commands :

X=poly(0,'x')
A=(X-1)^3
B=(X+1)^2
R=20 +12*X
Q=(A-R*X^3)/B;
Q=Q.num

A,(B*Q+R*X^3) // equal
A-(B*Q+R*X^3)  //=0
A==(B*Q+R*X^3)  // %F 
coeff((B*Q+R*X^3))
coeff(A)
degree((B*Q+R*X^3)) // =4 !!
degree(A)  // = 3

and compare with the expected result thereafter

Sincerly yours,

Philippe

--> A,B,Q,R
  A  =

 2   3
   -1 +3x -3x  +x

  B  =

2
1 +2x +x

  Q  =

  2
   -1 +5x -12x

  R  =


20 +12x


--> A,(B*Q+R*X^3)
  A  =

 2   3
   -1 +3x -3x  +x

  ans  =

 2   3
   -1 +3x -3x  +x


--> A-(B*Q+R*X^3)
  ans  =


0


--> A==(B*Q+R*X^3)
  ans  =

   F


--> coeff((B*Q+R*X^3))
  ans  =

   -1.   3.  -3.   1.   0.


--> coeff(A)
  ans  =

   -1.   3.  -3.   1.


--> degree((B*Q+R*X^3))
  ans  =

4.


--> degree(A)
  ans  =

3.

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users



___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] bug in degree and polynomials comparison ?

[philippe]

Hi,

while upgrading one of my toolboxes I discovered a strange error in
polynomial comparisons. The error appeared during automatic unit tests,
a " assert_checkequal(P1,P2)" was expected to be True and was in fact
False. After some investigations It looks like there is an error in
degree so that   P1==P2 can be False  while  P1-P2==0.

Can someone confirm the bug in scilab-6.0.1  before I fill in a report
on bugzilla. Run the following commands :

X=poly(0,'x')
A=(X-1)^3
B=(X+1)^2
R=20 +12*X
Q=(A-R*X^3)/B;
Q=Q.num

A,(B*Q+R*X^3) // equal
A-(B*Q+R*X^3)  //=0
A==(B*Q+R*X^3)  // %F 
coeff((B*Q+R*X^3))
coeff(A)
degree((B*Q+R*X^3)) // =4 !!
degree(A)  // = 3

and compare with the expected result thereafter

Sincerly yours,

Philippe

--> A,B,Q,R
 A  =

2   3
  -1 +3x -3x  +x

 B  =

   2
   1 +2x +x

 Q  =

 2
  -1 +5x -12x

 R  =


   20 +12x


--> A,(B*Q+R*X^3)
 A  =

2   3
  -1 +3x -3x  +x

 ans  =

2   3
  -1 +3x -3x  +x


--> A-(B*Q+R*X^3)
 ans  =


   0


--> A==(B*Q+R*X^3)
 ans  =

  F


--> coeff((B*Q+R*X^3))
 ans  =

  -1.   3.  -3.   1.   0.


--> coeff(A)
 ans  =

  -1.   3.  -3.   1.


--> degree((B*Q+R*X^3))
 ans  =

   4.


--> degree(A)
 ans  =

   3.

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Bug? plot with nan values (Linux Ubuntu 17.04

[Richard llom]

On my Linux machine it is also working as expected.

System:Host: cray3 Kernel: 4.12.4-1-CHAKRA x86_64 bits: 64 Desktop: KDE
Plasma 5.10.5 Distro: Chakra
Machine:   Device: desktop Mobo: ASUSTeK model: A88XM-PLUS v: Rev X.0x
serial: N/A
   UEFI: American Megatrends v: 3003 date: 03/04/2017
CPU:   Quad core AMD A10-7850K Radeon R7 12 Compute Cores 4C+8G (-MCP-)
cache: 8192 KB
   clock speeds: max: 4200 MHz 1: 1700 MHz 2: 1700 MHz 3: 1700 MHz
4: 1700 MHz
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Fiji [Radeon R9 FURY /
NANO Series]
   Display Server: x11 (X.Org 1.19.3 ) driver: amdgpu Resolution:
2560x1440@143.86hz
   OpenGL: renderer: Gallium 0.4 on AMD FIJI (DRM 3.15.0 /
4.12.4-1-CHAKRA, LLVM 4.0.1)
   version: 4.5 Mesa 17.1.5



--
Sent from: 
http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Bug?: plot with nan values (Linux Ubuntu 17.04)

[CRETE Denis]

Hello Antoine
I used a Lenovo T420 with Ubuntu 16.04 (I need to check when I am back on this 
machine, and I'll try to find what is the graphic driver), and Scilab 6.0. 
With this machine, but under Windows and Scilab 5.5.2, this did not happen = it 
used to be correct, with open gap at the %Nan value.
I can't try this machine and SciLab 6 under Windows, as Windows is not on this 
machine anymore.
I also tried the following code:
// Code
X=1:5;
Y=X.^2; Y(3)=%nan;
 plot2d(X',Y')
// End of code
- with an HP Z440 + Windows 7 Pro + SciLab 6.0  : both plot and plot2d are 
correct
- with an HP Z420 + Windows 7 Pro + SciLab 5.5.2 : both plot and plot2d are 
correct
I did not fill a bug report.

I notice a different behaviour between "your bug" and "my bug": in your 
bug/no_bug PNGs, Nan points are plot in the center (both x-wise and y-wise) of 
the graph, whereas in my observation (sorry, I do not have the true result, I 
can produce it when I am back on the Linux machine) only the y coordinate is 
"fake" data in the mid-range of Y, but at the right value of X...
HTH
Denis

-Message d'origine-
De : users [mailto:users-boun...@lists.scilab.org] De la part de Antoine 
Monmayrant
Envoyé : mercredi 18 octobre 2017 16:47
À : Users mailing list for Scilab
Objet : Re: [Scilab-users] ?==?utf-8?q? ?==?utf-8?q? ?= )

Yep, you're right, it looks the same.
Did you fill a bug report?
On what machine/OS did you observe this bug?

Antoine
 
 
Le Mercredi, Octobre 18, 2017 14:23 CEST, CRETE Denis 
 a écrit: 
 
> This seems to be the same problem I discussed with Christophe (although he 
> observed a correct behaviour) :
> --
> 
> Objet: Scilab 6's plot2d displays %nan on the horizontal line in the 
> mid-range of vertical axis
> 
> Hello Denis,
> 
> > De  CRETE Denis
> > Envoyé : mercredi 17 mai 2017 14:20
> >
> > If %nan values are in the Y vector,
> > plot2d behaves as if the following was performed before display:
> > Y (isnan(Y))=(YM + Ym)/2
> 
> I'm not sure I understand what you're pointing out.
> The following code works exactly as I expect:
> --
> x = 1:5;
> y=x.^2;
> y(3)=%nan;
> plot(x, y)
> --
> i.e. the point at x=3 is simply missing, with a blank between x=2 and x=4.
> --
> Christophe Dang Ngoc Chan
> 
> 
> -Message d'origine-
> De : users [mailto:users-boun...@lists.scilab.org] De la part de 
> Rafael Guerra Envoyé : mercredi 18 octobre 2017 13:35 À : 
> antoine.monmayr...@laas.fr; Users mailing list for Scilab Objet : Re: 
> [Scilab-users] ?==?utf-8?q? ?==?utf-8?q? Bug?: plot with nan values 
> (Linux Ubuntu 17.04)
> 
> Hi Antoine,
> 
> I observe the "No bug" behavior (i.e., gaps when plotting nans) in both 
> Scilab 5.5.2 and Scilab 6.0.0 installations on Win7 64-bit PC.
> 
> Regards,
> Rafael
> 
> 
> -Original Message-
> From: users [mailto:users-boun...@lists.scilab.org] On Behalf Of 
> Antoine Monmayrant
> Sent: Wednesday, October 18, 2017 1:26 PM
> To: Users mailing list for Scilab 
> Subject: Re: [Scilab-users] ?==?utf-8?q? ?==?utf-8?q? Bug?: plot with 
> nan values (Linux Ubuntu 17.04)
> 
> Update:
> 
> 1) Here is a simpler minimal working example:
> 
> ///
> x=1:100;
> y=rand(x);
> th=0.1;
> rg=find(y ynan=y;
> ynan(rg)=%nan;
> 
> scf();
> plot(x,y,'k.-');
> plot(x,ynan,'r.-');
> ///
> 
> 2) This might be due to some graphic drivers, but I think I am up to date on 
> that front. How can I check it's related to a graphic driver or not?
> 
> Antoine
>  
>  
> Le Mercredi, Octobre 18, 2017 13:22 CEST, "Antoine Monmayrant" 
>  a écrit: 
>  
> > Hi everyone,
> > 
> > I think I stumble upon a weird bug when plotting data with nan values: 
> > instead of a gap in the plot line, I have segments that go go towards the 
> > center of my plots.
> > This bug is present on Ubuntu 17.04, but not on Ubuntu 16.04 and it affects 
> > both scilab 5.5.2 and 6.0.
> > I attached the expected plot ('no_bug.png', what I get with 16.04), the 
> > bugged one ('bug.png') and the minimum working example ('bug_plot_nan.sce') 
> > with the original dataset with nans ('dat_with_nans.txt').
> > Are you also affected by this bug? Which platform (OS) are you working on?
> > 
> > Cheers,
> > 
> > Antoine
> 
> ___
> users mailing list
> users@lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
> ___
> users mailing list
> users@lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
> ___
> users mailing list
> users@lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
>

___
users mailing list
users@lists.scilab.org

Re: [Scilab-users] Bug?: plot with nan values (Linux Ubuntu 17.04)

[Patrice MEGRET]

Dear Antoine,

Correct behavior in Windows 10 and Scilab 6.0.0

Patrice 


-Message d'origine-
De : users [mailto:users-boun...@lists.scilab.org] De la part de Antoine 
Monmayrant
Envoyé : mercredi 18 octobre 2017 13:23
À : users@lists.scilab.org
Objet : [Scilab-users] Bug?: plot with nan values (Linux Ubuntu 17.04)

Hi everyone,

I think I stumble upon a weird bug when plotting data with nan values: instead 
of a gap in the plot line, I have segments that go go towards the center of my 
plots.
This bug is present on Ubuntu 17.04, but not on Ubuntu 16.04 and it affects 
both scilab 5.5.2 and 6.0.
I attached the expected plot ('no_bug.png', what I get with 16.04), the bugged 
one ('bug.png') and the minimum working example ('bug_plot_nan.sce') with the 
original dataset with nans ('dat_with_nans.txt').
Are you also affected by this bug? Which platform (OS) are you working on?

Cheers,

Antoine
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Bug with file exchange ?

[JFER Girj]

Hi everyone,

This error persists. Unable to add files

regards





--
View this message in context: 
http://mailinglists.scilab.org/Scilab-users-Bug-with-file-exchange-tp4035642p4036153.html
Sent from the Scilab users - Mailing Lists Archives mailing list archive at 
Nabble.com.
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] Bug in input statement

[Osvaldo Sergio Farhat de Carvalho]

Hello,I was trying some simple programs that use the input statement on Scilab 6.0.0, and I got unexpected behaviour. Here is a test:n = input("n = ")
while n > 0
n = input("n = ")
end
printf("\nThanks")Here is the result of this program on Scilab 6.0.0 console with input 1, 2, 3, 4 and 0:n = 1n = --> 2n = 3n = 4n = 0Thanks2+2 ans  =   4.Compare this with the output on Scilab 5.5.2 console for the same input:n = 1n = 2n = 3n = 4n = 0Thanks This is much more what one should expect from this litle program. Remark that on 6.0.0 console1) There is a disturbing new line after printing the input statement message2) There is a spurious apearance of the console prompt "-->" after the first execution of input statement3) The console prompt "-->" does not appear after the end of program execution.I am using Scilab on a Windows 10 system.Thanks for your attention.Osvaldo
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Bug with file exchange ?

[Samuel Gougeon]

Le 01/03/2017 à 08:58, Pierre Payen a écrit :

Hi everyone,
How can we post on file exchange ? When i try to add something i get 
this error :


Could not create the file set. Please correct the errors below and try 
again.


Although there aren't any errors (see screen-shot in attachment).


The manual versionning is the last feature very recently added to FE.
One-2 months ago, it was only automatic, with a 1 increment (1.0, 2.0, 
3.0 etc).

May be trying with an integer version ?

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Bug of input function in Scilab 6.0 beta 1

[SCHULZ Wolfgang]

Ok, because it is not clear whether this bug is related to another one I 
decided to enter a new bug report:
Bug 14424

Wolfgang


> -Ursprüngliche Nachricht-
> Von: users [mailto:users-boun...@lists.scilab.org] Im Auftrag von JLan
> Gesendet: Donnerstag, 25. Februar 2016 17:53
> An: users@lists.scilab.org
> Betreff: Re: [Scilab-users] Bug of input function in Scilab 6.0 beta 1
> 
> I doubt that it is related to bug 14375.
> That seems to be caused by a long temporary prompt:
> prompt('CRASH CRASH CRASH CRASH CRASH CRASH CRASH CRASH CRASH
> CRASH CRASH
> >')
> 
> But the behavior is certainly strange and inconsistent, should be reported as
> a separate bug. This is what I got once, but I cannot repeat it exactly:
> 
> --> a=input("a:");
> a:1
> a:2
> --> disp(a)
>2.
> --> b=input('b:');
> b:3
> --> disp(b)
>3.
> --> b=input("b:");
> b:4
> --> a=input("a:");
> b:5
> b:6
>  ans  =
>    6.
> --> disp(a)
>2.
> --> disp(b)
>5.
> 
> 
> 
> 
> 
> --
> View this message in context: http://mailinglists.scilab.org/Scilab-users-Bug-
> of-input-function-in-Scilab-6-0-beta-1-tp4033549p4033571.html
> Sent from the Scilab users - Mailing Lists Archives mailing list archive at
> Nabble.com.
> ___
> users mailing list
> users@lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] bug in function iir ?

[Serge Steer]

Le 25/02/2016 18:10, grivet a écrit :

Le 24/02/2016 21:40, Serge Steer a écrit :

Le 24/02/2016 11:30, grivet a écrit :
I appreciate your help; however, neither suggestion works: I still 
get the same error message.

The similar line
[frq,repf]=repfreq(hz,0.01,0.49);
has no problem

You are right the problem is exactly for the frequency 0.5 besause
exp(2*%pi*%i*0.5) -> - 1. + 1.225D-16i
and hz.num has 2 zeros  very near  -1

I checked the hz value with Matlab, the results are the same. So it 
seems that hz is ok. So it is probabily a probleme due to floating point 
computations procucing a zero value instead of a very small one.


Serge
please can you save the hz value using the Scilab save function and 
send the file?

Serge



Voila le code:
//filtre Butterworth
Order   = 2; // The order of the filter
Fs  = 1000; // The sampling frequency
Fcutoff = 40;   // The cutoff frequency

// We design a low pass Butterworth filter
hz = iir(Order,'lp','butt',Fcutoff/Fs/2,[0.1 0.1]);

// We compute the frequency response of the filter
[frq,repf]=repfreq(hz,0,0.5);
[db_repf, phi_repf] = dbphi(repf);

// And plot the bode like representation of the digital filter
subplot(2,1,1);
plot2d(Fs*frq,db_repf);
xtitle('Obtained Frequency Response (Magnitude)');
subplot(2,1,2);
plot2d(Fs*frq,phi_repf);
xtitle('Obtained Frequency Response (Phase in degree)');

iir est sauvegardé dans "svgd_iir" joint (binaire).

Cordialement,
JP Grivet



___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users


___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] bug in function iir ?

[grivet]

Le 24/02/2016 21:40, Serge Steer a écrit :

Le 24/02/2016 11:30, grivet a écrit :
I appreciate your help; however, neither suggestion works: I still 
get the same error message.

The similar line
[frq,repf]=repfreq(hz,0.01,0.49);
has no problem
please can you save the hz value using the Scilab save function and 
send the file?

Serge



Voila le code:
//filtre Butterworth
Order   = 2; // The order of the filter
Fs  = 1000; // The sampling frequency
Fcutoff = 40;   // The cutoff frequency

// We design a low pass Butterworth filter
hz = iir(Order,'lp','butt',Fcutoff/Fs/2,[0.1 0.1]);

// We compute the frequency response of the filter
[frq,repf]=repfreq(hz,0,0.5);
[db_repf, phi_repf] = dbphi(repf);

// And plot the bode like representation of the digital filter
subplot(2,1,1);
plot2d(Fs*frq,db_repf);
xtitle('Obtained Frequency Response (Magnitude)');
subplot(2,1,2);
plot2d(Fs*frq,phi_repf);
xtitle('Obtained Frequency Response (Phase in degree)');

iir est sauvegardé dans "svgd_iir" joint (binaire).

Cordialement,
JP Grivet



svgd_iir
Description: Binary data
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Bug of input function in Scilab 6.0 beta 1

[JLan]

I doubt that it is related to bug 14375.
That seems to be caused by a long temporary prompt:
prompt('CRASH CRASH CRASH CRASH CRASH CRASH CRASH CRASH CRASH CRASH CRASH
>')

But the behavior is certainly strange and inconsistent, should be reported
as a separate bug. This is what I got once, but I cannot repeat it exactly:

--> a=input("a:");
a:1
a:2
--> disp(a)
   2.
--> b=input('b:');
b:3
--> disp(b)
   3.
--> b=input("b:");
b:4
--> a=input("a:");
b:5
b:6
 ans  =
   6.
--> disp(a)
   2.
--> disp(b)
   5.





--
View this message in context: 
http://mailinglists.scilab.org/Scilab-users-Bug-of-input-function-in-Scilab-6-0-beta-1-tp4033549p4033571.html
Sent from the Scilab users - Mailing Lists Archives mailing list archive at 
Nabble.com.
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Bug of input function in Scilab 6.0 beta 1

[Clément David]

Hi Wolfgang,

It might be the http://bugzilla.scilab.org/show_bug.cgi?id=14375 about input 
behavior.

Regards,

--
Clément

Le jeudi 25 février 2016 à 15:00 +, SCHULZ Wolfgang a écrit :
> Clement,
> shoud I add my findings to the original bug report? In case of yes - which 
> bug report number is
> it?
> Thanks
> Wolfgang
> 
> 
> > -Ursprüngliche Nachricht-
> > Von: users [mailto:users-boun...@lists.scilab.org] Im Auftrag von Clément
> > David
> > Gesendet: Mittwoch, 24. Februar 2016 17:06
> > An: users@lists.scilab.org
> > Betreff: Re: [Scilab-users] ?==?utf-8?q? Bug of input function in Scilab 6.0
> > beta 1
> > 
> > Hi Antoine,
> > 
> > Note sure about that, we have to investigate more on that point and opening
> > two bug will leave the door open to solving issues in two ways.
> > 
> > --
> > Clément
> > 
> > 
> > Le mardi 23 février 2016 à 18:27 +0100, Antoine Monmayrant a écrit :
> > > 
> > > Le Mardi 23 Février 2016 17:16 CET, Clément David
> > >  a écrit:
> > > 
> > > > Hi Wolfgang,
> > > > 
> > > > It seems to be a bug, please report it.
> > > 
> > > Is this related to the previous 'input()' bug reported here (crashing for 
> > > long
> > input string)?
> > 
> > ___
> > users mailing list
> > users@lists.scilab.org
> > http://lists.scilab.org/mailman/listinfo/users
> ___
> users mailing list
> users@lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Bug of input function in Scilab 6.0 beta 1

[SCHULZ Wolfgang]

Clement,
shoud I add my findings to the original bug report? In case of yes - which bug 
report number is it?
Thanks
Wolfgang


> -Ursprüngliche Nachricht-
> Von: users [mailto:users-boun...@lists.scilab.org] Im Auftrag von Clément
> David
> Gesendet: Mittwoch, 24. Februar 2016 17:06
> An: users@lists.scilab.org
> Betreff: Re: [Scilab-users] ?==?utf-8?q? Bug of input function in Scilab 6.0
> beta 1
> 
> Hi Antoine,
> 
> Note sure about that, we have to investigate more on that point and opening
> two bug will leave the door open to solving issues in two ways.
> 
> --
> Clément
> 
> 
> Le mardi 23 février 2016 à 18:27 +0100, Antoine Monmayrant a écrit :
> >
> > Le Mardi 23 Février 2016 17:16 CET, Clément David
> >  a écrit:
> >
> > > Hi Wolfgang,
> > >
> > > It seems to be a bug, please report it.
> >
> > Is this related to the previous 'input()' bug reported here (crashing for 
> > long
> input string)?
> 
> ___
> users mailing list
> users@lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] bug in function iir ?

[Serge Steer]

Le 24/02/2016 11:30, grivet a écrit :
I appreciate your help; however, neither suggestion works: I still get 
the same error message.

The similar line
[frq,repf]=repfreq(hz,0.01,0.49);
has no problem
please can you save the hz value using the Scilab save function and send 
the file?

Serge
Your problem arises because one frequency value you ask for  
corresponds exactly to a zero of hz.num

log(roots(hz.num))/(2*%pi)
so you want to compute the gain in dB of a zero value which is -inf

To avoid such problem you can let repfreq to do the frequency 
discretization.

[frq,repf]=repfreq  (hz)
or equivalently
[frq,repf]=repfreq  (hz,0,0.5)
in  this case the discretization uses  varying  frequency step
Serge

Le 23/02/2016 14:41, grivet a écrit :

Le 23/02/2016 14:21, Serge Steer a écrit :

Please can you give more details :
value of Order and Fcutoff/Fs/2
and what you are doing with hz (because iir does not call dbphi)
Serge






___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users


___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] bug in function iir ?

[grivet]

I appreciate your help; however, neither suggestion works: I still get 
the same error message.

The similar line
[frq,repf]=repfreq(hz,0.01,0.49);
has no problem
Your problem arises because one frequency value you ask for  
corresponds exactly to a zero of hz.num

log(roots(hz.num))/(2*%pi)
so you want to compute the gain in dB of a zero value which is -inf

To avoid such problem you can let repfreq to do the frequency 
discretization.
[frq,repf]=repfreq (hz) or equivalently 
[frq,repf]=repfreq (hz,0,0.5)

in  this case the discretization uses  varying  frequency step
Serge

Le 23/02/2016 14:41, grivet a écrit :

Le 23/02/2016 14:21, Serge Steer a écrit :

Please can you give more details :
value of Order and Fcutoff/Fs/2
and what you are doing with hz (because iir does not call dbphi)
Serge




___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Bug of input function in Scilab 6.0 beta 1

[Clément David]

Hi Wolfgang,

It seems to be a bug, please report it.

--
Clément

Le mardi 23 février 2016 à 14:48 +, SCHULZ Wolfgang a écrit :
> Hello,
> since Scilab 6.0 beta 1 I have a problem with the input function (everything 
> worked under Scilab
> 6.0 alpha 1).
>  
> I execute the following code:
> Code:
> mode(0);
> ieee(1);
> clear;
> iteration = input("Sensor data of which Iteration:");
> name = sprintf("iteration%03d.sensor",iteration)
>  
> With Scilab 5.5.2 I enter 1 and get the following output:
> -->exec('H:\SCILAB\Problem_input_data.sce', -1)
> Sensor data of which Iteration:1
> name  =
>  iteration001.sensor  
>  
> Scilab 6.0 beta 1: I had to input “1” 2 times:
>  
> --> exec('H:\SCILAB\Problem_input_data.sce', -1)
> Sensor data of which Iteration:1
> Sensor data of which Iteration:1 name  =
>  
> iteration001.sensor
>  
> As mentioned Scilab 5.5.2 and the Scilab 6.0 alpha 1 worked without problems 
> (I didn’t try Scilab
> 6.0 alpha 2).
>  
> Is this a bug and simply a new behavior of the input function?
> Best regards
> Wolfgang
>  
>  
>  
> ___
> users mailing list
> users@lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] Bug of input function in Scilab 6.0 beta 1

[SCHULZ Wolfgang]

Hello,

since Scilab 6.0 beta 1 I have a problem with the input function (everything 
worked under Scilab 6.0 alpha 1).



I execute the following code:

Code:

mode(0);

ieee(1);

clear;

iteration = input("Sensor data of which Iteration:");

name = sprintf("iteration%03d.sensor",iteration)



With Scilab 5.5.2 I enter 1 and get the following output:

-->exec('H:\SCILAB\Problem_input_data.sce', -1)

Sensor data of which Iteration:1

name  =

 iteration001.sensor



Scilab 6.0 beta 1: I had to input "1" 2 times:



--> exec('H:\SCILAB\Problem_input_data.sce', -1)

Sensor data of which Iteration:1

Sensor data of which Iteration:1 name  =



iteration001.sensor



As mentioned Scilab 5.5.2 and the Scilab 6.0 alpha 1 worked without problems (I 
didn't try Scilab 6.0 alpha 2).



Is this a bug and simply a new behavior of the input function?

Best regards

Wolfgang






___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] bug in function iir ?

[Serge Steer]

Your problem arises because one frequency value you ask for  corresponds 
exactly to a zero of hz.num

log(roots(hz.num))/(2*%pi)
so you want to compute the gain in dB of a zero value which is -inf

To avoid such problem you can let repfreq to do the frequency 
discretization.


[frq,repf]=repfreq  (hz)
or equivalently
[frq,repf]=repfreq  (hz,0,0.5)

in  this case the discretization uses  varying  frequency step
Serge

Le 23/02/2016 14:41, grivet a écrit :

Le 23/02/2016 14:21, Serge Steer a écrit :

Please can you give more details :
value of Order and Fcutoff/Fs/2
and what you are doing with hz (because iir does not call dbphi)
Serge
I am just running the example found in "how to design an elliptic 
filter". Here is the code:


Order=  2;  // The order of the filter
Fs   =  1000;  // The sampling frequency
Fcutoff  =  40;// The cutoff frequency

// We design a low pass elliptic filter
hz  =  iir  (Order,'lp','ellip',[Fcutoff/Fs/2  0],[0.1  0.1]);

// We compute the frequency response of the filter
[frq,repf]=repfreq  (hz,0:0.001:0.5);
[db_repf,  phi_repf]  =  dbphi  (repf);

// And plot the bode like representation of the digital filter
subplot  (2,1,1);
plot2d  (Fs*frq,db_repf);
xtitle  ('Obtained Frequency Response (Magnitude)');
subplot  (2,1,2);
plot2d  (Fs*frq,phi_repf);
xtitle  ('Obtained Frequency Response (Phase in degree)');


with 'ellip' replaced by 'butt', and [Fcutoff/Fs/2 0] replaced 
byFcutoff/Fs/2.
I am beginning to use digital filters to treat some data. As my first 
step, I try to run the examples in the help,how to design an elliptic 
filter (using Scilab 5.5.1, Win7-64). This works . However, when I 
select a Butterworth filter:

 hz = iir(Order,'lp','butt',Fcutoff/Fs/2,[0.1 0.1]);
I get this error message:

Singularité de la fonction log ou tan.
at line   6 of function dbphi called by :
[db_repf, phi_repf] = dbphi(repf);

What did I miss ?
No bugs have been reported for function dbphi, but three similar 
bugs are listed for iir.

Any suggestion welcome.
JPGrivet




___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users


___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] bug in function iir ?

[grivet]

Hello,
I am beginning to use digital filters to treat some data. As my first 
step, I try to run the examples in the help,how to design an elliptic 
filter (using Scilab 5.5.1, Win7-64). This works . However, when I 
select a Butterworth filter:

 hz = iir(Order,'lp','butt',Fcutoff/Fs/2,[0.1 0.1]);
I get this error message:

Singularité de la fonction log ou tan.
at line   6 of function dbphi called by :
[db_repf, phi_repf] = dbphi(repf);

What did I miss ?
No bugs have been reported for function dbphi, but three similar bugs 
are listed for iir.

Any suggestion welcome.
JPGrivet


___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] bug #13158 /parallel_run on MacOSX

[Stéphane Mottelet]

Le 07/04/2015 15:39, Stéphane Mottelet a écrit :

Hello,

Is there any plan to solve bug #13158 ?

http://bugzilla.scilab.org/show_bug.cgi?id=13158

There is no assignee since the bug has been signaled (in 2014)... As 
far as I am concerned, I have access to a Linux machine where 
parallel_run is completely functional, but my usual machine is a 
MacPro and I would like to use parallel_run on MacOS also.


S.


Hello all,

I have proposed a workaround which seems to work seamlessly. OSX users 
can proceed to the bug page to see the nop unix trick:


http://bugzilla.scilab.org/show_bug.cgi?id=13158

S.

--
Département de Génie Informatique
EA 4297 Transformations Intégrées de la Matière Renouvelable
Université de Technologie de Compiègne -  CS 60319
60203 Compiègne cedex

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] Bug in csim in Scilab 5.5.0?

[Stefan Du Rietz]

Hello,
I have a function using csim that worked OK in 5.4.1 but not in 5.5.0. 
However, if I use the csim.sci from 5.4.1 it also works in 5.5.0.


I stop the simulation, read the states, insert an impulse by adding to 
the first state, and continue with the the states as initial states 
(x0) in a new run.


So it seems like the new csim does something different with the 
initial states?


Regards
Stefan
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] Bug?

[SCHULZ Wolfgang]

Hello,
I'm not sure this is a bug - therefore I want to ask her first:
I'm using Scilab 5.4.1 64 bit under Win7:
Depending on the size of the figure the axis are disappearing or not.

Is it a bug or can I avoid/circumvent this feature somehow?
Thanks a lot
Wolfgang
attachment: test.pngattachment: test1.png___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Bug?

[Calixte Denizet]

Hi Wolfgang,

It is probably a bug.
Could you report it on bugzilla.scilab.org with a little test case please ?

Thanks

Best regards

Calixte

On 26/02/2014 15:56, SCHULZ Wolfgang wrote:

Hello,
I'm not sure this is a bug - therefore I want to ask her first:
I'm using Scilab 5.4.1 64 bit under Win7:
Depending on the size of the figure the axis are disappearing or not.

Is it a bug or can I avoid/circumvent this feature somehow?
Thanks a lot
Wolfgang


___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users



--
Calixte Denizet
Software Development Engineer
---
Scilab Enterprises
143bis rue Yves Le Coz - 78000 Versailles, France
http://www.scilab-enterprises.com

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Bug?

[Antoine Monmayrant]

On 02/26/2014 04:07 PM, Calixte Denizet wrote:

Hi Wolfgang,

It is probably a bug.
Could you report it on bugzilla.scilab.org with a little test case 
please ?

And if you post the test case here, I'll try to reproduce it on linux...

Antoine


Thanks

Best regards

Calixte

On 26/02/2014 15:56, SCHULZ Wolfgang wrote:

Hello,
I'm not sure this is a bug - therefore I want to ask her first:
I'm using Scilab 5.4.1 64 bit under Win7:
Depending on the size of the figure the axis are disappearing or not.

Is it a bug or can I avoid/circumvent this feature somehow?
Thanks a lot
Wolfgang


___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users



--
Calixte Denizet
Software Development Engineer
---
Scilab Enterprises
143bis rue Yves Le Coz - 78000 Versailles, France
http://www.scilab-enterprises.com


___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] bug report on http://wiki.scilab.org/howto/global%20and%20local%20variables

[Stefan Du Rietz]

On 2014-01-28 18:42, Serge Steer wrote:


Le 28/01/2014 17:14, Adrien Vogt-Schilb a écrit :

The page does not mention pause


Just because pause behave similarily to  functions with respect to
calling context


And you think the fact that it behaves equal to (not similar to) 
functions is self-evident?


Of course, I have read help *pause*:

Switch to the pause mode; inserted in the code of a function, pause 
interrupts the execution of the function: one receives a prompt symbol 
which indicates the level of the pause (e.g. -1-). The user is then 
in a new workspace in which all the lower-level variables (and in 
particular all the variable of the function) are available.


I have therefore always thought that the given prompt symbol -1- was 
the level of the function (see the link below), and that I still was 
at that level!


Stefan


http://wiki.scilab.org/howto/global%20and%20local%20variables

sorry, o busy to file a bug



___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users





___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] bug report on http://wiki.scilab.org/howto/global%20and%20local%20variables

[Stefan Du Rietz]

On 2014-01-29 20:03, Stefan Du Rietz wrote:


On 2014-01-28 18:42, Serge Steer wrote:


Le 28/01/2014 17:14, Adrien Vogt-Schilb a écrit :

The page does not mention pause


Just because pause behave similarily to  functions with respect to
calling context


And you think the fact that it behaves equal to (not similar to)
functions is self-evident?

Of course, I have read help *pause*:

Switch to the pause mode; inserted in the code of a function, pause
interrupts the execution of the function: one receives a prompt symbol
which indicates the level of the pause (e.g. -1-). The user is then
in a new workspace in which all the lower-level variables (and in
particular all the variable of the function) are available.

I have therefore always thought that the given prompt symbol -1- was
the level of the function (see the link below), and that I still was
at that level!

And, as I have earlier worked with Matlab, I therefore believed that 
*pause* worked like its *keyboard*:

http://www.mathworks.se/help/matlab/ref/keyboard.html

keyboard , when placed in a program .m file, stops execution of the 
file and gives control to the keyboard. The special status is 
indicated by a K appearing before the prompt. You can examine or 
change variables; all MATLAB® commands are valid. This keyboard mode 
is useful for debugging your functions.



Stefan


http://wiki.scilab.org/howto/global%20and%20local%20variables

sorry, o busy to file a bug



___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users





___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users




___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] bug report on http://wiki.scilab.org/howto/global%20and%20local%20variables

[Adrien Vogt-Schilb]

The page does not mention pause

http://wiki.scilab.org/howto/global%20and%20local%20variables

sorry, o busy to file a bug

--
Adrien Vogt-Schilb
PhD Student (Cired)

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] bug report on http://wiki.scilab.org/howto/global%20and%20local%20variables

[Serge Steer]

Le 28/01/2014 17:14, Adrien Vogt-Schilb a écrit :

The page does not mention pause

Just because pause behave similarily to  functions with respect to 
calling context

http://wiki.scilab.org/howto/global%20and%20local%20variables

sorry, o busy to file a bug



___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] bug in scilab 5.41 and 5.5beta? 64bit versions

[G I Fuchs]

I have been using scilab for many years.
today I downloaded for my new computer scilab 5.41(64bit) and got 
afterwards on the first start

an error message like the ones further down
on the version 5.5beta(64bit) there happens the same sort of thing
on both versions the control bar  file, edititing ... does not work 
i.e. no response on klick


for version 5.41
Starte Ausführung: (start execution)
lade Startumgebung (load startenviroment)
%val=[�000sinternalslib;
!--error 2
Ungültiger Faktor. (unvalid factor)
in execstr instruction called by :
at line 35 of function evstr called by :
at line 848 of function %_sodload called by :
at line 6 of function atomsSystemInit called by :
atomsSystemInit();
at line 107 of exec file called by :
exec('SCI/etc/scilab.start',-1);;

and for the beta
starte Ausführung: (start execution)
lade Startumgebung (load startenviroment)
%val=[�000sinternalslib;
!--error 2
Ungültiger Faktor. (unvalid factor)
in execstr instruction called by :
at line 35 of function evstr called by :
at line 908 of function %_sodload called by :
at line 6 of function atomsSystemInit called by :
atomsSystemInit();
at line 113 of exec file called by :
exec('SCI/etc/scilab.start',-1);;

I use windows 7 home premium
Gerhard Fuchs
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] Bug in MatLab to Scilab conversion ?

[CRETE Denis]

Hello,
While 'E1 = 1i*r; ' is converted correctly by both mfile2sci and 
translatepaths, the following line is not:
E2 = 1i*r; % pb of coexistence 1i/comment
Giving this report
E2 = 1i*r; ;// pb of coexistence 1i/comment
 !--error 276
Opérateur, virgule ou point-virgule manquant.
This problem occurs as soon as a % sign for comments is appended to the line 
containing 1i.
Denis
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] bug

[Zeyu Liu]

in fact, scilab works with float numbers. so this kind of things always
happen. say,

--format(25);

--1-0.9
 ans  =

0.0999777955

and

--0.1 == 1 - 0.9
 ans  =

  F

you need to remember that this software is not for symbolic algebra system
like maxima or maple


On Wed, Dec 12, 2012 at 2:01 AM, Пилюгин Иван pilyugi...@yandex.ru wrote:

 programm code
 -
 clear
 z=mscanf('%g')

 --

 Input   7.9

 Result  z=7.901


 --78.8
  z  =

 78.83




 ___
 users mailing list
 users@lists.scilab.org
 http://lists.scilab.org/mailman/listinfo/users

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] bug

[Пилюгин Иван]

programm code
-
clear
z=mscanf('%g')

--

Input   7.9

Result  z=7.901


--78.8
 z  =
 
78.83  




___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] Bug 6737

[Frei Matthias]

Hi,

I've seen the bug report http://bugzilla.scilab.org/show_bug.cgi?id=6737.
The report is 2 years old, can we still hope it will be fixed? 

Thanks,
Matthias

ferag...
Ferag AG
Matthias Frei
Forschung  Entwicklung
Zürichstrasse 74
CH-8340 Hinwil
Telefon +41 44 938 65 86
matthias.f...@ferag.com
www.ferag.com http://www.ferag.com/ 




This message is intended only for [users@lists.scilab.org]. If you are not 
the intended recipient you are notified that disclosing, copying, distributing 
or taking any action in reliance on the contents of this information is 
strictly prohibited.
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Bug II of the demos using Scilab 5.4.0 on Ubuntu 12.04 32 bit

[Uwe Fechner]

Ok, than your problem is not related to my bug report.

I do have a C compiler and a Fortran compiler installed. On Windows their is no
compiler installed by default. Only if you have these compilers installed and
Scilab doesn't find them it would be a bug.

But I agree, I am missing a page in the wiki or in the help file that explains 
how
to install the necessary compilers on Windows.

Regards:

Uwe Fechner


Am 27.10.2012 23:50, schrieb Lester Anderson:

I am working on Windows 7 64-bit

On 27 October 2012 22:26, Uwe Fechner u.fech...@tudelft.nl 
mailto:u.fech...@tudelft.nl wrote:

Which operation system do you use?

Regards:

Uwe Fechner

Am 27.10.2012 23:09, schrieb Lester Anderson:

I tried the n-pendulum demo on both 5.4.0 and 5.3.3 and both times it says 
the demo is
disbled because it could not find a C compiler. This happens on a few 
others too.

Lester

On 27 October 2012 19:26, Uwe Fechner u.fech...@tudelft.nl 
mailto:u.fech...@tudelft.nl wrote:

I created a bug report:
http://bugzilla.scilab.org/show_bug.cgi?id=12039

Regards:

Uwe Fechner



--
View this message in context:

http://mailinglists.scilab.org/Scilab-users-Bug-II-of-the-demos-using-Scilab-5-4-0-on-Ubuntu-12-04-32-bit-tp4025016p4025084.html
Sent from the Scilab users - Mailing Lists Archives mailing list 
archive at Nabble.com.
___
users mailing list
users@lists.scilab.org mailto:users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users




___
users mailing list
users@lists.scilab.org  mailto:users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users





___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Bug II of the demos using Scilab 5.4.0 on Ubuntu 12.04 32 bit

[Lester Anderson]

I tried the n-pendulum demo on both 5.4.0 and 5.3.3 and both times it says
the demo is disbled because it could not find a C compiler. This happens on
a few others too.

Lester

On 27 October 2012 19:26, Uwe Fechner u.fech...@tudelft.nl wrote:

 I created a bug report:
 http://bugzilla.scilab.org/show_bug.cgi?id=12039

 Regards:

 Uwe Fechner



 --
 View this message in context:
 http://mailinglists.scilab.org/Scilab-users-Bug-II-of-the-demos-using-Scilab-5-4-0-on-Ubuntu-12-04-32-bit-tp4025016p4025084.html
 Sent from the Scilab users - Mailing Lists Archives mailing list archive
 at Nabble.com.
 ___
 users mailing list
 users@lists.scilab.org
 http://lists.scilab.org/mailman/listinfo/users

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users