[prev in list] [next in list] [prev in thread] [next in thread]
List: scilab-dev
Subject: Re: [Scilab-Dev] [Scilab-users] bug when setting gcbo field in a callback function ?
From: Samuel Gougeon <sgougeon () free ! fr>
Date: 2018-09-29 20:03:34
Message-ID: fd89ced4-62ed-e6ad-f7db-a983f5b76b58 () free ! fr
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Le 29/09/2018 à 21:34, Samuel Gougeon a écrit :
> This is a follow-up of the users@ thread
> http://mailinglists.scilab.org/Scilab-users-bug-when-setting-gcbo-field-in-a-callback-function-tp4038615.html
>
> 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.
>
> It is here really another bug, about datatip rendering: when we
> increase the sleep() time -- say up to 10 s --, we have enough time to
> see that the datatip is created -- its square anchor is visible -- but
> stays empty for the whole sleep time (so d1.text=="").
> Hence, it's not just a matter of delay: something is wrong about
> datatips rendering when things are done in a Scilab session created
> inside the current session (this is what test_run does): The test_run
> environment definitely cancels the rendering of the datatip label.
> I tried
>
> * without the TEST-WITH-GRAPHIC mode, to cancel the -nw option when
> running the test: same issue
> * with get(d1,"text") instead of d1.text: as expected, same
> (upstream) issue
> * with a drawnow, or gcf().immediate_drawing="on", or
> gcf().visible="off" // + "on": this does not cancels the bug
>
> I also tried in NO-CHECK-REF mode in order to cancel opening a diary,
> but this is not the case: A diary is opened anyway.
> But opening a diary in the current session before directly running
> exec(the_test_file) does not yield the issue.
>
> To be more explored...
I've got it: this bug is due to the -quit option used to run the
test_run scilab session: removing it uncancels the datatip rendering.
Since the -quit option is needed to cancel the test when a syntax error
occurs in it, this is still only a first step to fix the issue...
[Attachment #5 (text/html)]
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 29/09/2018 à 21:34, Samuel Gougeon a
écrit :<br>
</div>
<blockquote cite="mid:627b5c0d-d5de-64d8-88e7-237b6a8f63e3@free.fr"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">This is a follow-up of the users@
thread<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://mailinglists.scilab.org/Scilab-users-bug-when-setting-gcbo-field-in-a-cal \
lback-function-tp4038615.html">http://mailinglists.scilab.org/Scilab-users-bug-when-setting-gcbo-field-in-a-callback-function-tp4038615.html</a><br>
<br>
Le 29/09/2018 à 18:16, Stéphane Mottelet a écrit :<br>
</div>
<blockquote cite="mid:f36a0e26-3c28-7b67-9fda-84379d82c806@utc.fr"
type="cite">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 <br>
<br>
--> test_run cacsd bug_13359 <br>
<br>
When run interactively by <br>
<br>
--> exec SCI/modules/cacsd/tests/nonreg_tests/bug_13359.tst <br>
<br>
it sometimes succeed and sometimes fail, this completely random.
However, if you insert a sleep line 25 <br>
<br>
(...) <br>
d1 = datatipCreate(pl, 200); <br>
sleep(10) // line inserted <br>
txt_datatip = d1.text; <br>
assert_checkequal(strindex(txt_datatip(2), "-"), 1); <br>
<br>
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. <br>
</blockquote>
<br>
It is here really another bug, about datatip rendering: when we
increase the sleep() time -- say up to 10 s --, we have enough
time to see that the datatip is created -- its square anchor is
visible -- but stays empty for the whole sleep time (so
d1.text=="").<br>
Hence, it's not just a matter of delay: something is wrong about
datatips rendering when things are done in a Scilab session
created inside the current session (this is what test_run does):
The test_run environment definitely cancels the rendering of the
datatip label. <br>
I tried <br>
<ul>
<li>without the TEST-WITH-GRAPHIC mode, to cancel the -nw option
when running the test: same issue</li>
<li>with get(d1,"text") instead of d1.text: as expected, same
(upstream) issue<br>
</li>
<li>with a drawnow, or gcf().immediate_drawing="on", or
gcf().visible="off" // + "on": this does not cancels the bug</li>
</ul>
I also tried in NO-CHECK-REF mode in order to cancel opening a
diary, but this is not the case: A diary is opened anyway.<br>
But opening a diary in the current session before directly running
exec(the_test_file) does not yield the issue.<br>
<br>
To be more explored...<br>
</blockquote>
<br>
I've got it: this bug is due to the -quit option used to run the
test_run scilab session: removing it uncancels the datatip
rendering.<br>
<br>
Since the -quit option is needed to cancel the test when a syntax
error occurs in it, this is still only a first step to fix the
issue...<br>
<br>
</body>
</html>
_______________________________________________
dev mailing list
dev@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic