Re: [Scilab-users] bug when setting gcbo field in a callback function ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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
