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

[Samuel Gougeon]

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

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