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

[François Vogel]

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