Scipad debugger

[Vincent COUVERT]

Hi François,

fvogelnew1 at free.fr a écrit :
> Vincent,
>
> I cannot say I'm happy with what you are writing underneath but thank you anyway
> for informing us.
>
> I guess it is useless to moan or to hunt for the guilty party. Therefore, I will
> make no comment about how or why the situation was messed up that much. Anyway
> you certainly already know how upset I am about all this.
>
>
> Looking forward, let's be pragmatic:
>
> 1. Deactivation of Scipad's debugger
>
> I will unplug the debugger from Scipad in trunk. Please let me do it and don't
> do it yourself.
>
> What is the last date for commit in trunk before Scilab 5?
>   
No problem for me to let you do this work.
The last date for commit in TRUNK before Scilab 5 is next Monday (1st 
September) at 12am.
>
> 2. Reentrancy of Tcl instructions (Observation #1 in the wiki page)
>
> In your post scriptum below, are you saying that reentrancy is now fully
> working?
> I have seen some work around this but the commit log was about a "try".
>
> Also, could your team please answer about observations #2 and #3 in this same
> page?
>
>   
We are going to update this page and explain what work and what does not 
work.
A diagram explaining how the TCL thread works is currently written.
> 3. Scipad event loop
>
> I think I understand what your description of the problem.
>
> With respect to the solution of this problem we are facing, you seem to have a
> precise idea of what should be done but you do not elaborate very much, please
> explain. What should we do in order to make the debugger work again?
>   
For the moment we have to technical solution to have a working debugger, 
we have to identify precisely the problem and then see how to fix it 
without breaking Scilab parsing loop.
> Please discuss with externals this time when you will want to fix this. Learn
> from experience. I note you are writing "together" below, which is a good sign.
> Also, this discussion shall be public.
>
>   
The modifications to do in "Scilab debugging system" could be the object 
of a new SEP.
> Last point, what Scilab version do you target for making the Scilab loop work
> again?
>   

For the moment, no idea of the version where debugging actions will be 
available again. It will depend on the amount of work needed to make it 
work.
>
> Let's hope future will allow for better work with your team. I have not yet
> stepped out but nausea experiences are sadly accumulating.
>
> Francois
>   

Vincent
>
>
> Vincent COUVERT <vincent.couvert at scilab.org> said on Tue, 26 Aug 2008 17:05:48
> +0200:
>
>   
>> Hi Enrico,
>> Hi François,
>>
>> We have bad news for Scipad debugger in Scilab 5.0.
>>
>> Bruno spent the last two weeks working on it and finally it appears that
>> we have no chance to make it work for Scilab 5.0. All main bugs in TCL
>> event loop and TCL interface are now fixed and Scipad debugger still
>> does not work.
>>
>> We thought that the problem was due to the TCL event loop
>> reorganization, but it was not. Actually, if Scipad debugger does not
>> work in current version, it is because of Scilab internal loop which
>> remains blocked in some cases such as a breakpoint in the code to debug.
>> In previous versions, a timer ensured all the commands in the
>> "storecommand queue" were read and executed (hence make Scilab run again
>> when in pause mode) even if Scilab was paused inside the parsing loop.
>> In current version, when Scilab is blocked inside its parser, there is
>> nothing that can wake it up.
>>
>> The modifications needed to make Scipad debugger work are too important
>> and dangerous to be done one week before Scilab 5.0 release, we were
>> sure that the modifications in the TCL loop made recently would be
>> enough to fix the problem, but it was not the case.
>>
>> So, we think that it would be better to desactivate Scipad debugger
>> inside Scilab 5.0 and then we could work together to find a solution to
>> make it work for a future release of Scilab.
>>
>> Vincent.
>>
>> PS : About
>>
>>     
> http://wiki.scilab.org/Scipad_debugger_inner_beauties?highlight=(debugger)#head-f92972929ff85460e97200581afae62d16b097b8
>   
>> Point 1) is now fixed, calls to TCL_* and ScilabEval can now be imbricated
>>
>>
>> --
>> ==============================================
>> Vincent COUVERT
>> Centre de Recherche INRIA Paris-Rocquencourt
>> Domaine de Voluceau - B.P. 105
>> 78153 Le Chesnay Cedex
>> ==============================================
>> Equipe Projet SCILAB
>> Bâtiment 1B - Bureau 013
>> Email : vincent.couvert at inria.fr
>> Tél : +33 (0)1 39 63 54 46
>> Fax : +33 (0)1 39 63 55 94
>> ==============================================
>>
>>
>>     
>
>
>   


-- 
==============================================
Vincent COUVERT
Centre de Recherche INRIA Paris-Rocquencourt
Domaine de Voluceau - B.P. 105
78153 Le Chesnay Cedex
==============================================
Equipe Projet SCILAB
Bâtiment 1B - Bureau 013
Email : vincent.couvert at inria.fr
Tél : +33 (0)1 39 63 54 46
Fax : +33 (0)1 39 63 55 94
==============================================