Commit 23351 about the Tcl event loop

classic Classic list List threaded Threaded
4 messages Options
Francois Vogel-2 Francois Vogel-2
Reply | Threaded
Open this post in threaded view
|

Commit 23351 about the Tcl event loop

Hi,

I have noticed commit 23351 from Bruno Jofret, and I see three points to raise
about it.


1. This commit:

http://viewvc.scilab.org/bin/cgi/viewvc.cgi/trunk/scilab/modules/core/src/c/syncexec.c?limit_changes=0&r1=23350&r2=23351

has changed a fix that Serge has made for bugs 2455 and 2384.

a. Did you check that those bugs do not show up again?

b. What is the reason for overriding what parse has set in the interruptible
flag?


2. In the same commit, we can now read this:

http://viewvc.scilab.org/bin/cgi/viewvc.cgi/trunk/scilab/modules/scipad/tcl/scilabexec.tcl?limit_changes=0&r1=23350&r2=23351

 # Bruno : Communication between Scipad and Scilab through
 # TCL global interp is not a clever idea...

I will check this in depth, but I think I remember it didn't work correctly when
the scipad Tcl interpreter was used, that's why I had to use the global Tcl
interp.

Anyway, Bruno Jofret, could you please elaborate on why you say it's not clever?


3. Still in scilabexec.tcl:

ScilabEval_lt "flush"

must be useless since all the previous ScilabEvals use "sync" "seq".

If your changes do no longer work when you remove the flush, then it means that
the sync option of ScilabEval does not work.


Looking forward to read your answers.

Francois



Bruno JOFRET Bruno JOFRET
Reply | Threaded
Open this post in threaded view
|

Re: Commit 23351 about the Tcl event loop

[hidden email] wrote:

> Hi,
>
> I have noticed commit 23351 from Bruno Jofret, and I see three points to raise
> about it.
>
>
> 1. This commit:
>
> http://viewvc.scilab.org/bin/cgi/viewvc.cgi/trunk/scilab/modules/core/src/c/syncexec.c?limit_changes=0&r1=23350&r2=23351
>
> has changed a fix that Serge has made for bugs 2455 and 2384.
>
> a. Did you check that those bugs do not show up again?
>  
I did not have any knowledge about those fixes (even after 45 min speak
with Serge), so thanks for the tip.
It seems ok for me. Can you check it back ?
> b. What is the reason for overriding what parse has set in the interruptible
> flag?
>  
The reason is after having an error in syncexec, the storecommand is put
in uninterruptible mode.
So all the callbacks we were storing after that were looping endlessly.
You can reproduce that behaviour with those steps :
- open scipad
- type "error(10)"
all seems allright...
- close scipad
- do 1+2 in the console, you lost scilab.

He is looping on an empty command that can not end because it's
un-interruptible.

Weird..

>
> 2. In the same commit, we can now read this:
>
> http://viewvc.scilab.org/bin/cgi/viewvc.cgi/trunk/scilab/modules/scipad/tcl/scilabexec.tcl?limit_changes=0&r1=23350&r2=23351
>
>  # Bruno : Communication between Scipad and Scilab through
>  # TCL global interp is not a clever idea...
>
> I will check this in depth, but I think I remember it didn't work correctly when
> the scipad Tcl interpreter was used, that's why I had to use the global Tcl
> interp.
>
> Anyway, Bruno Jofret, could you please elaborate on why you say it's not clever?
>  
I am a bit busy for now, I promiss to write some documentation about the
new Tcl behaviour.
To put it shortly, we have now a separated thread for Tcl stuff.
And those commands were making reentrant call so that we stay in a
deadlock process.

I guess it is the same issue with debug mode.

>
> 3. Still in scilabexec.tcl:
>
> ScilabEval_lt "flush"
>
> must be useless since all the previous ScilabEvals use "sync" "seq".
>
> If your changes do no longer work when you remove the flush, then it means that
> the sync option of ScilabEval does not work.
>
>  
Oups... My mistake...
It was only a debug/investigation purpose.
It works fine for me without this. Is it ok for you too ?

Bruno.

--
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 : [hidden email]
     http://www.scilab.org


Francois Vogel-2 Francois Vogel-2
Reply | Threaded
Open this post in threaded view
|

Re: Commit 23351 about the Tcl event loop

Bruno,

Thanks for having answered. Much appreciated.


Bruno JOFRET said on 07/03/2008 17:30:
> It seems ok for me. Can you check it back ?

I tried with the most up-to-date Scilab svn. It's OK for me (on Windows).


> I am a bit busy for now, I promiss to write some documentation about the
> new Tcl behaviour.

OK, noted ;-)


> To put it shortly, we have now a separated thread for Tcl stuff.
> And those commands were making reentrant call so that we stay in a
> deadlock process.

Not sure I understand you here, but you said you would detail this
later, which is fine for me.


> I guess it is the same issue with debug mode.

Ditto.


>> 3. Still in scilabexec.tcl:
>>
>> ScilabEval_lt "flush"
>>
>>  
> Oups... My mistake...
> It was only a debug/investigation purpose.
> It works fine for me without this. Is it ok for you too ?

It must work without it anyway.

Good luck for the upcoming changes in the Tcl loop. I have already
seen misc. improvements in the recent past, for instance there is no
need for me to hit enter in the shell any longer to make the event
loop move. This can be seen for instance when "Open source of...", or
when Ctrl-F& inside a word in Scipad. However the debugger is still
completely broken. Let me know if I can be of any help on this topic.

Francois

Enrico Segre Enrico Segre
Reply | Threaded
Open this post in threaded view
|

Re: Commit 23351 about the Tcl event loop

In reply to this post by Bruno JOFRET
> It works fine for me without this. Is it ok for you too ?

well, if I would be in condition to build I would be able to tell you.
Enrico