[Gambas-user] a Debug question

[Doriano Blengino]

Sergio A. Hernandez ha scritto:
> Doriano,
> >From my experience programming under languages that don't have any
> debugger at all like PHP-LAMP, the best thing to do in these cases is
> to create a debug subclass with a constructor that fills out all the
> data on a large form (however you want, with static or random data).
> That way you avoid entry the data and only focus to make sure your
> application works the way it supposed to.
> Hope this help you.
>   
This is why I was asking for some compiler switch to include/exclude 
debugging code.
I am afraid to leave in place things which should'nt stay there...

Surely you also used the tecnique of logging a lot of informations; but 
all the debugging code you put in, you don't want to have it in the 
final release. Gambas has some support for this (DEBUG instruction), but 
it could be more general.

Thanks for the suggestion,
Doriano

> On Sat, May 2, 2009 at 1:02 AM, Doriano Blengino
> <doriano.blengino at ...1909...> wrote:
>   
>> Benoît Minisini ha scritto:
>>     
>>>> If  one puts in a breakpoint, and is  stepping through the code one line at
>>>> a time to check values of variables etc, is there any way or re-setting to
>>>> a line in the same subroutine prior to the current line you have stopped
>>>> on.
>>>>
>>>> I've found sometimes I'm trying to find a bug, and I put in multiple break
>>>> points so that I can skip from one to another, and then want to check
>>>> something in the middle that I've gone past, but have to stop the entire
>>>> program and start again.
>>>>
>>>>         
>>> Alas you cannot go back in time in debuggers yet. I've heard about people
>>> thinking about it, but I don't think you will never see it in Gambas!
>>>
>>>
>>>       
>> This is a serious problem, tough. There are programs which, for one
>> reason or another, are a little difficult to debug using the internal
>> gambas debugger. For example, think at a data-entry form, with a lot of
>> controls, each having validation (perhaps, put on top of a database). If
>> you want to debug the final action of the form (the Apply button, may
>> be), then you have to fill in all the values. Every time you discover a
>> bug, even a stupid one, you must restart the program from the beginning;
>> and, may be, that form is nested deep in the program logic - you have to
>> step through many menus and dialogs to arrive at the point of interest.
>> Other times, you don't have a clear idea of the algorithm you have to
>> write, so you try again and again. In these situations, the more you can
>> do through the debugger, the more time you save.
>>
>> There could be some improvements to the debugger:
>>
>>    - the possibility to assign new values to variables (perhaps not the
>> structured, but only the simplest ones)
>>    - the possibility to modify the program text and continue debugging
>> (perhaps without adding/deleting lines)
>>    - the possibility to change the program counter (perhaps with
>> constraints)
>>    - the possibility to add "debug" code, which is compiled in only
>> when a special "debug run" is invoked
>>    - conditional breakpoints / break on the "Nth occurence"
>>
>> ...and may be other which does'nt come to my mind at the moment.
>>
>> We already discussed a little about this: I know this is somehow hard to
>> implement, but having the gambas virtual machine ready in memory should
>> help... I mean: if the debugger "knows" how to obtain the value of a
>> variable, and how to display it, then perhaps it is possible to
>> [relatively] easily assign a new value. Or, the possibility to modify
>> the source and continue debugging, seems to me not very hard to do (but
>> I could be wrong, of course).
>>
>> I know that I am biased, because for my work I go deep to the processor
>> hardware, and the debugger lets me do nearly everything I want, but you
>> could consider whether any improvement could be done to the gambas debugger.
>>
>> Hope I did'nt annoyed you, they were simply ideas.
>>
>> Regards,
>>
>> --
>> Doriano Blengino
>>
>> "Listen twice before you speak.
>> This is why we have two ears, but only one mouth."
>>
>>
>> ------------------------------------------------------------------------------
>> Register Now & Save for Velocity, the Web Performance & Operations
>> Conference from O'Reilly Media. Velocity features a full day of
>> expert-led, hands-on workshops and two days of sessions from industry
>> leaders in dedicated Performance & Operations tracks. Use code vel09scf
>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>> _______________________________________________
>> Gambas-user mailing list
>> Gambas-user at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gambas-user
>>
>>     
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations 
> Conference from O'Reilly Media. Velocity features a full day of 
> expert-led, hands-on workshops and two days of sessions from industry 
> leaders in dedicated Performance & Operations tracks. Use code vel09scf 
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
>   


-- 
Doriano Blengino

"Listen twice before you speak.
This is why we have two ears, but only one mouth."