[Scilab-Dev] [Fwd: Re: Debug de Scipad]

[Enrico Segre]

> > > Bruno a decrit sur le wiki comment le remplacer:
> > >
> >
http://wiki.scilab.org/Tcl_Thread#head-e76a052af725f97db7a6bac94e3d88958fc10f77
> > >
> > > Est ce que tu pense que ca réglerait les pbs du débugger ?
> > > Si ça n'est pas le cas, tu aurais besoin de quoi pour pouvoir le
> > > régler ?

I have to remember first of all why the recursive complication was
mandatory until scilab4 (it was for sure, otherwise we wouldn't have
been forced to use it). I think this comment in scipad.sci says it
neatly:

"what is executed during a sync is not available in the interpreter
after the sync has ended (because sync launches a new interpreter - same
thing as running in a function)"

now this is supposedly not anymore the case with only two interlocked
tcl and scilab interpreters (no spawn). Part of that complication also
arose because originally ScilabEval was NOT guaranteeing any
synchronism, but that evolved into sync and seq.

However I also seem to remember that me and Francois were simply
convinced that what Bruno writes in the wiki "just won't work, it's not
that easy". I have to recall why that, if there is a reason at all. It
is certainly not that we are lazy to revise our code and want to dump on
you the task to leave things as before, cumbersome as they were.
Precondition for accepting the change, however, is that sync and seq
really do what they are supposed to, also in retrospect to all the filed
ScilabEval bugs & evolution across the years. 

The only potential danger I see on the spot about Bruno's wiki solution
is that some scilab command could sneak between 

ScilabEval "\[db_str,db_n,db_l,db_func\]=lasterror();" "sync" "seq" 

and

ScilabEval  "TCL_SetVar(\"errnum\", string(db_n), \"scipad\");" "sync"
"seq"

and change (db_n) before Scipad has a chance to use it. That itself may
look unlikely, but you never know how far you can get on any construct
of this kind if anything the like could ever happen. There might be
more, nontrivial showstoppers, I really have to check.

Enrico