Scipad debugger

[fvogelnew1 at free.fr]

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?


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?


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?
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.

Last point, what Scilab version do you target for making the Scilab loop work
again?


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 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
> ==============================================
>
>