[Scilab-Dev] Re: Debug de Scipad

[Enrico Segre]

Hi Bruno,

On Thu, 2008-05-15 at 09:53 +0200, Bruno JOFRET wrote:   
> Separating the TCL thread let it be more autonomous, and remove some 
> "hard" link with scilab.

this is undoubtedly good.

> I agree it was the case in the Scilab 4.X :
> - Mono-thread structure with scilab at the very top of that
> managing even the TCL code interpretation
> - Scilab was scheduling the time and the priority of each execution :
> TCL interpreter
> Scilab "kernel".

I agree that these facts were causing us too many headaches. Just as a
case story, see bug 865.


> I had a look at your code.
> I'm not try to fight fault with, and I easily understand  the reason why 
> it has been written that way.
> Now, I just picked out a line :
>  set skipline "TCL_EvalStr(\\\"\"if {\\\[isnocodeline 
> \\\[gettextareacur\\\] insert\\\] && \\\[isbreakhit_bp\\\]} 
> {stepbystepover_bp 0 0 ; break_bp} else 
> {updatewatchvars;unsetdebuggerbusycursor}\\\"\",\\\"\"scipad\\\"\");"

you take this line out of its context. If it was just for it, Scipad
could execute it as tcl code and point. But it is not.

The problem is that during debugging it is Scilab who has to decide
whether to execute the tcl snippet or not (see below in the same proc
checkendofdebug_bp in file db_states.tcl at line 511) depending on the
result of a scilab where() launched at the right time.
And to complicate further the matter (in a way, to simplify it,
factorizing common code) the tcl command $skipline is Scipad-context
dependent. Scipad judges how exactly to build the commands that it wants
to receive back (conditionally) from Scilab.

Please note also that all that construct is ScilabEval'd *seq* that
time; other times "sync" or both or "flush" is relevant.

The debugger is full of similar two-way constructs. Building them based
on reentrancy was a regrettable contorsion. I do wish that they can be
straightened, and speculate that it may be possible if locking control
is made accessible to the user both ways -- that is tcl has the
possibility to ckeck if scilab is busy, to reserve it for itself or to
release it, and viceversa for scilab->tcl.

Reentrancy here was used to enforce sequenciality too - Scipad may send
a scilab command to the interpreter AND want to do something else right
after the scilab command has completed - polling for a scilab busy state
alone won't be a guarantee because some other user event might sneak in
between and keep scilab busy at the wrong moment, perhaps even
destroying the scilab data the debugger is counting on.

An additional issue (coming sometimes as a bonus, sometimes as a curse)
with spawned interpreters was the creation of local scilab namespaces.
The locality of the spawned interpreter lowers sometimes the risk of
collision of a debugger [scilab] variable with an user variable.

Btw, on the wiki page, you say:

"For synchronization process we had to lock the global Tcl interp, in
order that no concurrent access can happen."

I understand that with this you decided that a TCL_.. scilab command, by
default enforces a lock on the tcl thread, which is released at the
completion of the command. IIUC, what I'm asking amounts to give the
programmer the option to override the default behavior, and decide when
to lock/release the tcl thread programmatically. Actually, I'm more
thinking at the opposite direction, but the idea should be reflexive.
  
> The point is, if we are in a TCL code, just "run" all what can be run 
> within it and avoid asking scilab to ask the interpreter to do it.

I hope I am clear above - ScilabEval(TCL_Evalstr()) was a necessity, not
a funny way of executing pure tcl code "as if looking from the scilab
side".

> > Your forgetting about reeentrance will also break existing features, see a
> > recent example here:
> > http://groups.google.fr/group/comp.soft-sys.math.scilab/browse_thread/thread/d13da70c713b925a

I understand that in that case what happens is just that executing from
Scipad translates once more in a ScilabEval(TCL_Evalstr()).
   
> > Aside from the technical issue discussed here, I would like to move this thread
> > to the dev mailing list. Other people may very well have useful ideas, andit's a
> > good occasion to share and consult, isn't it?
> > Anybody having a concern with moving the discussion to a public place, please
> > speak now.
> >   
> So far as this is a discussion between the scipad dev and scilab dev 
> which is
> not really an open issue I prefer it is done just within us 4.

For reasons already stated a number of times, I'd prefer to keep the
thread on the dev list.

Enrico