[Scilab-Dev] Re: bug debugguer scipad,...

[Vincent COUVERT]

Hi François,

Pierre as just created a new branch to work on Scipad debugger. The 
modifications needed for this work can break Scilab, so we think it is 
better to work with a branch.

How to work with this branch:
// Clone the repository
git clone git at git.scilab.org:scilab

// Create a shortcut for scipad
git branch scipad refs/remotes/origin/scipad

// Work on Scipad branch
git checkout scipad

// Check existing branches (a star must appear in front of "scipad")
git branch

// Merge "master" branch modifications to "scipad" branch
git merge master

// Merge "scipad" branch modifications to "master" branch
git checkout master
git merge scipad

The changes on GetCommandLine.c have been merged into this branch.

Vincent



François Vogel a écrit :
> Hi guys,
>
> Referring to the message below, we are now well beyond Scilab 5 release.
>
> Shouldn't we discuss about a plan, a roadmap or something in order to 
> get the debugger back in?
>
> Target would be Scilab 5.1 (dec. 2008, IIRC a previous post) and first 
> step should be to put back in Serge's changes in GetCommandLine.c
>
> How can we organize all this together? What do you think?
>
> Francois
>
>
> Bruno JOFRET said on 01/09/2008 11:21:
>> Hi there,
>>
>> After some discussion with Serge (and some mysterious BUG showing off 
>> under windows with the last modification) we decided to revert the 
>> GetCommandLine to previous version.
>>
>> But it is only during the time we need to Tag the 5.0 version.
>> I will do the commit back right after the tag.
>>
>> It is a very good step for the resolution of our problems but not 
>> safe enough with the close deadline of Scilab 5.0.
>>
>> Regards,
>>
>> François Vogel a écrit :
>>> Serge,
>>>
>>> Many thanks for looking at this thorny problem. New eyes on a muddy 
>>> problem proves efficient, well done.
>>>
>>> It seems that you have indeed made a good step forward. Now the 
>>> debugger is no longer locked. Well, at least most of the time.
>>>
>>> Sometimes the user still has to hit enter in the Scilab shell in 
>>> order to make things move, but definitely you have made progress.
>>>
>>> Example that almost works:
>>>
>>> 1. Launch Scilab
>>>
>>> 2. Launch Scipad.
>>>
>>> 3. Now, after Scipad is open:
>>>
>>> TCL_EvalStr("set bug2789_fixed true","scipad")
>>>
>>> (this will unlock the debugger - I had locked it two days ago in 
>>> r27121 upon opteam request)
>>>
>>> 4. Paste this in scipad:
>>>
>>> function stupid
>>>   a=1
>>>   b=2
>>> endfunction
>>>
>>> 5. Configure (F10) and click OK.
>>>
>>> 6. Step in (F8).
>>>     ----> The debugger correctly goes into DebugInProgress mode (red 
>>> tag on the lower left of Scipad window). However, the active 
>>> breakpointed line does not show up.
>>>
>>> 7. Hit enter in the Scilab shell (this should not be needed if it 
>>> would work correctly).
>>>     ----> The current stop point is shown in Scipad.
>>>
>>> 8. F8 again
>>>     ----> The new stop point is shown
>>>
>>> etc.
>>>
>>>
>>> Try with other examples, perhaps a bit more complicated, you will 
>>> see that it often works but not always. Sometimes you need to hit 
>>> enter in the shell to make things move.
>>>
>>>
>>> I have also experienced a number of crashes, where Scilab 
>>> unexpectedly closes with no message at all.
>>> Also:
>>> Warning !!!
>>> Scilab has found a critical error (EXCEPTION_ACCESS_VIOLATION)
>>> with "TCL_EvalStr" function.
>>> Save your data and restart Scilab.
>>>
>>>
>>> Finally, for the debuggger to work OK, bug 1469 and 3407 should be 
>>> fixed too. There are still many problems with continued lines, that 
>>> were counted differently in 4.x than they are now in 5.0
>>>
>>>
>>> As a conclusion I think we are still not fully OK, but progress is 
>>> clear. A lot of testing and bug fixing will be needed in the next 
>>> days if the debugger is to be replugged. Please let me know what you 
>>> think and what is your plan with respect to the upcoming Scilab 5.
>>>
>>> Francois
>>>
>>>
>>> Serge Steer said on 30/08/2008 09:03:
>>>> Je pense avoir corrige le bug qui empechait le debugguer de scipad de
>>>> fonctionner et qui faisait que dans certains cas scilab se mettait a
>>>> boucler avec l'execution d'un callback
>>>>
>>>> zzledt (GetCommandLine.c) ne signifiait pas que la lecture a ete
>>>> interrompu par la presence d'un callback dans la queue et 
>>>> retournait une
>>>> ligne blanche comme instruction.
>>>>
>>>> voir la modif que j'ai committe dans modules/shell/GetCommandLine.c
>>>>
>>>> Serge
>>>>
>>>>
>>
>>


-- 
==============================================
Vincent COUVERT
Responsable du développement
                    ------                    
Fondation DIGITEO - Consortium Scilab
Domaine de Voluceau - B.P. 105
78153 Le Chesnay Cedex
Bâtiment 23 - Bureau 22
                    ------                    
Email : vincent.couvert at scilab.org
Tél : +33 (0)1 39 63 54 46
Fax : +33 (0)1 39 63 55 94
==============================================