[Scilab-Dev] Tcl and Scilab Event loop

[François Vogel]

Hi all,

Improving the Tcl/Scilab interface in trunk was indeed badly needed. 
The main issue is (or was, perhaps?) bug 2514 and 2640, which prevent 
from using anything in Tcl within the trunk. So, I wish a warm welcome 
to this work!


Bruno JOFRET said on 11/01/2008 11:07:
> It works as follow :
> * I created a timer thread within this one
> * WHILE Tcl is started
>    IF we have a TCL command to execute
>       runIt
>    ELSE
>       Do "update"
>       Wait until we receive a "wake up" signal
>    ENDIF
> ENDWHILE

The above is oriented towards having responsive Tcl interfaces while 
Scilab is busy running, and that's the main goal of course.

However, the Tcl command that gets run in the "runIt" line above might 
take time to execute. Say that the following command is sent from a 
Tcl script:

ScilabEval "j=0;for i=1:1e6;j=j+1;end"

Ok that's a stupid command but it's only to illustrate.

How does that command get executed? Does it get executed in parallel 
with the work Scilab is currently doing, say while Scilab is busy 
executing some (very clever) loop such as:

while %t;end

or does the ScilabEval-ed command interrupt the Scilab work?
or does it wait until the main flow (the while loop) has finished? In 
that latter case, is the ScilabEval call blocking or did you keep a 
queueing mechanism as it was the case so far (on this, see also below)?

A related topic: In which variable space does the ScilabEval-ed 
command execute? Can the ScilabEval-ed command have access to the 
variables that Scilab currently uses at the time of execution of the 
ScilabEval? I.e. does it see the variables that can be seen from the 
current pause (-n->) level?
Or does it execute in something more like a separate instance of 
Scilab, that cannot access the variables from the main flow?

The latter would break a lot of features in Scipad, is it the case?


> The timer thread is quite dummy.
> It only send  periodically a "wake up" signal.
> 
> "Wake up" signal are also send when asking for a TCL command through 
> Scilab.
> A call to Tcl_EvalStr for instance.

In Scipad I had to use very complicated recursive combinations of 
ScilabEval and TCL_EvalStr commands, for instance:

set comm "TCL_EvalStr(\"ScilabEval {TCL_EvalStr(\"\"set myvariable 
false\"\",\"\"scipad\"\")} seq\",\"scipad\");"
ScilabEval $comm

Does this still work?


> - Some others commands may be broken.

Other aspects I can mention:

- All options of ScilabEval (see help ScilabEval) should be supported 
in order not to break too many things in Scipad, and especially the 
debugger. Is it the case?
You can also have a look at bug 2596, which is a drastically trimmed 
down test case.


- The sciprompt variable set by tksynchro.
This variable is set by Scilab and used in Scipad every time Scipad 
needs to ScilabEval something. The Scilab parse/run functions set 
sciprompt to -1 while busy, and back to the pause level -n-> while idle.
Does this variable still exist (even if perhaps always set to zero)?
If it's not the case, then Scipad has to be modified, potentially in 
depth. This is because in the debugger context Scipad has to know when 
Scilab has finished executing the previous statement so that debug 
commands can be issued. For that reason the debugger needs to know if 
Scilab is still busy running or not.

And that's another reason why the ScilabEval options must be 
supported. The debug commands are queued in such a way that they will 
get executed as soon as Scilab stops at a breakpoint. If they now 
execute in parallel with the main Scilab flow (my question above), 
this will be an issue we'll have to fix. For instance retrieval of the 
value of the watched variables at the breakpoint stop must be done 
only after Scilab has finished the debug step, not in between.


> - As soon as we will have Windows similar functionalities, and taking 
> into account your comments,
> we will include this into the Trunk and kindly ask you for some feedbacks.

I look forward to being able to test it. I guess most of my comments 
above could be easier discussed against some reference implementation 
made available in trunk.

Cheers,
Francois