Debug de Scipad

[Bruno JOFRET]

fvogelnew1 at free.fr wrote:
> Selon Sylvestre Ledru <sylvestre.ledru at inria.fr>:
>   
>> A priori, on va pas remettre en place la réentrance du TCL (trop
>> compliqué et pose trop de pb annexe).
>>     
>
> Could you please develop your reasons? The above sounds quite short.
> I can assure you that working around the new limitation introduced in Scilab 5
> is also very very complicated in Scipad.
>   
Separating the TCL thread let it be more autonomous, and remove some 
"hard" link
with scilab.
Now the TCL thread is independent so any peace of "pure" TCL code is 
executed
without any scilab "management".
This bring more freedom for any TCL code, but raises some drawbacks with 
reentrant communication.
>
> http://wiki.scilab.org/Tcl_Thread#head-e76a052af725f97db7a6bac94e3d88958fc10f77
>
> As stated in previous emails, I already had a try in the past but I gave up.
> It's just toot difficult to do on a line by line basis.
>
> Enrico has correctly explained why we had to use reentrance. In particular,
> there are very complex reentrant structures, needed to guarantee the correct
> execution order of ScilabEvaled instructions *mixed* with Scilab code. Sync seq
> does not help in this case, at least it didn't with the previous interface.
>   
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".

Now it's a bit different, because Scilab no longer "strongly" manage TCL.
The TCL interp, even if it is accessible from scilab, lives alone 
without any
scheduling coming from scilab.
> I have already pointed you to proc checkendofdebug_bp in
> SCI/modules/scipad/tcl/db_states.tcl for a nice example of the gymnastics I had
> to do, did you have a look? Really, did you? Please do. Now, how is this
> translatable into non reentrant code? I'm not proficient enough to tell.
>   
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\\\"\");"

It seems you are creating some TCL pure code (we are in the TCL interp 
there), then ask scilab to run it,
"Run it" means ask the TCL interp to evaluate the pure TCL code.
But the TCL interp is there the one you are calling from.
So why do not evaluate it "directly" into the interp "we are in".
Or, and that seems to be the case there, concat the commands you need
and run it after, but in this TCL interp.

> Honestly, handling this is a big big work. You're more or less asking for a
> rewrite of the debugger from scratch, because changing things on a per line
> basis copied/pasted on the wiki example will just not work.
> I would probably need months to have only partial features in the debugger if no
> reentrant call would be available.
> This is certainly not what you were hoping to hear, but this is just the raw
> truth.
>   
I understand your point.
The work is huge and not so pleasant.
It's more than a "per line" instruction split.
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.
> Enrico's proposal is a good idea I think.
> Basically, being able to restore the reentrance behaviour of Scilab4 by a
> command would probably help.
>
> Otherwise, I don't know. On one hand I tend to agree with the new interface
> being cleaner than the previous one, but on the other hand complying with the
> new limitation of this interface really is a huge work, believe me.
>
> 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 guess this has nothing to do with reentrance.
It's a kind of message I've seen too many times. :-S (Specially while 
working on scicos)
In fact if you crash something in your Scilab that does not really kill it,
it tries to close "properly" by executing *.quit.
That's the scipad.quit
> 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.

Add-on : seems I was not fast enough...

-- 
Bruno JOFRET

         Project Engineer
___SCILAB - INRIA Rocquencourt___
  Domaine de Voluceau - B.P. 105
    78153 Le Chesnay Cedex
  Tel : (+33/0)1.39.63.58.63
  Mailto : bruno.jofret at inria.fr
     http://www.scilab.org