[dev build] $DEBUG mode ✨ Step through your code, watch variables! 🤩

[FellippeHeitor]

Notice that a variable doesn't need to be in the Watch Panel for a Watchpoint to be monitored.

Also notice that adding too many watchpoints will slow things down. You should only add watchpoints to variables of interest to the specific bug you're researching.

[hanness]

So far so good. Even working well with indices in my testing so far.

Can't express how freakin' awesome this is. Only wish I had all these capabilities 12,000 lines of code ago. I would probably still have hair as a result :-)

[Richard]

@FellippeHeitor

Initial testing dev d651f37 works exactly as described by you (so far) - not a problem - must always remember (get used to) the watchpoint being specific to the current module when envoked by the F4 routine (as previously advised by you (Disco)).

Feature request (user option) - "On watchpoint being reached - an audio response (e.g. cash register "cha-ching") being played. In my case the longer running QB64 programs are "buried" under other applications and it may take me a while before I remember to check up on the QB64 program(s).

[Richard]

@FellippeHeitor dev d651f37 Win 10 x64 Pro 21H1 (aug update)

Not a problem - just a bit confused on how $DEBUG interacts when main module has



ON ERROR GOTO ErrHandler:

.....

Errhandler:
....
RESUME NEXT
RETURN


In my program which often comes up with a particular error, my RESUME NEXT allows the program to carry on normally (and $DEBUG status ... "Error occurred on line 351") but from then on I do not seem to be able to then use F4 to watch values.

Is it "dangerous" to rely on $DEBUG (watch values etc) in this situation (meanwhile my program is still carrying on OK 99.9% of the time)?

Not a problem - rather some advice please.

[mpgcan]

Previous code that failed to compile now compiles with the new dev builds, that really is excellent, thank you Spriggsy and Fellippe.

For testing I used a program that is difficult to debug, it has a new window process and uses subclassing.
I had a few teething problems with the debugger mainly setting inappropriate break points and incorrect use of menu options.
That said I was surprised how stable QB64 debug is. It really is turning into an indispensable tool keep up the great work.
 
QB64 Development Builds:
QB64x32 1.6 d651f37
QB64x64 1.6 d651f37

PC spec as follows:  Windows 8.1,  Processor Intel(R) Core(TM) i3-3217U CPU 1.8 GHz, RAM 4GB, 64-bit

[RhoSigma]

@FellippeHeitor dev d651f37 Win 10 x64 Pro 21H1 (aug update)

Not a problem - just a bit confused on how $DEBUG interacts when main module has



ON ERROR GOTO ErrHandler:

.....

Errhandler:
....
RESUME NEXT
RETURN


In my program which often comes up with a particular error, my RESUME NEXT allows the program to carry on normally (and $DEBUG status ... "Error occurred on line 351") but from then on I do not seem to be able to then use F4 to watch values.

Is it "dangerous" to rely on $DEBUG (watch values etc) in this situation (meanwhile my program is still carrying on OK 99.9% of the time)?

Not a problem - rather some advice please.

@Richard, Have you ever tried to get rid of that damn RETURN after RESUME NEXT? - The ErrHandler: label is NOT a GOSUB called subroutine, see also the detailed discussion here: https://www.qb64.org/forum/index.php?topic=4172.msg135334#msg135334

[FellippeHeitor]

Previous code that failed to compile now compiles with the new dev builds, that really is excellent, thank you Spriggsy and Fellippe.

For testing I used a program that is difficult to debug, it has a new window process and uses subclassing.
I had a few teething problems with the debugger mainly setting inappropriate break points and incorrect use of menu options.
That said I was surprised how stable QB64 debug is. It really is turning into an indispensable tool keep up the great work.

That's great to hear, mpgcan!

In my program which often comes up with a particular error, my RESUME NEXT allows the program to carry on normally (and $DEBUG status ... "Error occurred on line 351") but from then on I do not seem to be able to then use F4 to watch values.

Interaction between ON ERROR and $DEBUG has not been researched. My suggestion is to disable/comment out custom error handlers when using $Debug, cause one will use $Debug exactly to find an issue, as opposed to using ON ERROR which will trap predictable issues. ON ERROR could end up masking an error you're trying to figure out.

Feature request (user option) - "On watchpoint being reached - an audio response (e.g. cash register "cha-ching") being played. In my case the longer running QB64 programs are "buried" under other applications and it may take me a while before I remember to check up on the QB64 program(s).

No "cha-ching", Richard. One is sitting in front of the computer watching the outcome of a buggy program in order to find the bug so the program can run indefinitely. One will see the condition be met. One is not leaving a program run in debug mode and go grab lunch.

So far so good. Even working well with indices in my testing so far.

Can't express how freakin' awesome this is. Only wish I had all these capabilities 12,000 lines of code ago. I would probably still have hair as a result :-)

Thank you, hanness ❤️

Thank you all for trying it out and helping me find issues. Can't wait to have it stable for general availability. 🥰

[Richard]

@RhoSigma Now I am trying  without the RETURN - thanks.

[Richard]

@FellippeHeitor

Dev e30f7a1 Windows 10 x64 Pro build 21H1 (aug updated)

Feature request

IDE > Options > IDE Colors

Display a (sample window with the current line background) in addition to the already present (sample window with the background).

So the TWO sample windows both are simultaneously displaying the selected item (e.g. Normal Text, Keywords, Numbers, etc) with the respected BG (Background/Current_Line_Background)

[Richard]

@FellippeHeitor

Dev e30f7a1 Windows 10 x64 Pro build 21H1 (aug updated)

Just tried $DEBUG for the first time for this dev build and got the following message:-

Failed to initiate debug session.
Cannot receive connections on port 9000. Check your firewall permissions.

First time this message ever occurred to me. Normally when using a new dev build a pop-up occurs and I allow... NO pop-up this time.

[Richard]

@FellippeHeitor

Firewall problem solved - removed all running instances of  previous $DEBUG  active processes.

Someone keeps releasing new dev builds... :)

[Richard]

@FellippeHeitor

Dev e30f7a1 Windows 10 x64 Pro build 21H1 (aug updated)


I may have lost track on fixes for BIT stuff...  but I get a few problems with watch values refer screen shots:-

The variable array comes up as      a~`1( )   instead of   a~`( )
It appears only the first index a~`(0) is updated and is incorrect (displays it seems the number of times I press  F7)
The array is not initialized  - though not a problem (... never assume...)



   [ You are not allowed to view this attachment ]  




  [ You are not allowed to view this attachment ]  

[FellippeHeitor]

The variable array comes up as      a~`1( )   instead of   a~`( )

Those are equivalent, it is by design.

It appears only the first index a~`(0) is updated and is incorrect (displays it seems the number of times I press  F7)
The array is not initialized  - though not a problem (... never assume...)

I'll check the behavior of _bit arrays. Thanks for reporting.

Regular _Bit variables are working as expected in my tests.

[FellippeHeitor]

✨
New dev build now available, with functional watching/sending values for _BIT arrays.

[Richard]

@FellippeHeitor


dev 3e498df   Win 10 x64 Pro build 21H1 (AUG updated)



All _BIT combinations (single bit) work exactly as expected!





  [ You are not allowed to view this attachment ]  


Note the above screenshot before DIM was performed




  [ You are not allowed to view this attachment ]  




Many thanks - works like a charm.