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

[Vincent COUVERT]

Hi François,

I think that Serge is the person of the opteam who is the most able to 
help you on this work. I'll be back from China next week.

Vincent

François Vogel a écrit :
> Hi Vincent,
>
> Perfect. Works exactly like you describe it below.
>
> Now on the hard work. Will somebody of the opteam work on this 
> problem? I had a look some time ago and I remember it was quite 
> borderline wrt my proficiency. I don't think I can fix the problem alone.
>
> Francois
>
>
> Vincent COUVERT said on 22/10/2008 15:06:
>> 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
==============================================