QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: FellippeHeitor on March 08, 2022, 08:30:45 am
-
It's been 5 months since v2 came out, and although I'm personally a heavy user of the new $Debug features, I was wondering if/how it's been useful to you guys as well.
If you have no idea what I'm talking about, please make sure to check the release video again:
Curious for your feedback.
Love to all!
Fellippe.
-
Lord knows I need all the help I can get....it's been very, very helpful. Thank you for same. You wouldn't by any chance have a written wiki dedicated to just all the features and how to use $Debug most effectively??
-
@Dimster not in detail yet. The wiki page for $Debug contains a summary, but the feature does indeed deserve more documentation. Glad it's been a good companion for your coding!
-
Very happy with $Debug
It is not in my system yet to automatically think about using it, but that happens more and more until I don't know any better :-)
One minor thing missing that I really loved in PBDS7 was to put a cursor on any variable and press Shift-F9 to lookup it's value and then Enter to add it to watch-list.
-
Honestly I had established my own ways of debugging before and this is too complicated to remember or go back and watch the video over and over.
-
@mdijkens Great to hear! The variable lookup is planned for a future update, I'll keep you posted.
@bplus: I respect that.
-
@mdijkens Great to hear! The variable lookup is planned for a future update, I'll keep you posted.
That is really cool!
I remember I used 'instant watch' more then regular watch-list.
Imagine you put a breakpoint in the troublesome code, use F8 and Shift-F8 to walk through it
and at any time quickly look at any variable with Shift-F9 Esc, other variable Shift F9 Esc, etc.
Way quicker then searching variable list or typing an expression to add it to the watch list
-
@FellippeHeitor What would be extremely helpful, not just with debugging but other things as well, is a having a message box modal dialog for QB64, either use Windows Api call or QB64 routine.
We could get some inside info from program without ruining the output screen.
If I get really desperate for debugging I threaten myself with dragging my message box code in to use. So far never that desperate to drag that clunky thing in but when I review oh, I might just add it to Interpreter.
Oh my reply answers same point as @mdijkens ha, ha, great minds think alike! :)
-
Hi @FellippeHeitor,
$DEBUG has been very valuable to me lately when revising the falcon tool set to allow printing on non-32-bit alpha blended screens. It works like charm. However, there was especially one feature I've missed in the variabels watch list. It would be great, if we had a chance here to change the display of numeric variables to either DEC/OCT/HEX/BIN instead just default it to decimal. Had been made checking the 32bit color values much easier to have them as HEX rather than DEC. As I already added the new _BIN$ function to the 2.1 development branch, this is maybe a neat feature to add in the future.
-
Hi @FellippeHeitor,
$DEBUG has been very valuable to me lately when revising the falcon tool set to allow printing on non-32-bit alpha blended screens. It works like charm. However, there was especially one feature I've missed in the variabels watch list. It would be great, if we had a chance here to change the display of numeric variables to either DEC/OCT/HEX/BIN instead just default it to decimal. Had been made checking the 32bit color values much easier to have them as HEX rather than DEC. As I already added the new _BIN$ function to the 2.1 development branch, this is maybe a neat feature to add in the future.
Sounds cool (and very doable!) indeed. Thank you, Rho!
-
Sounds cool (and very doable!) indeed. Thank you, Rho!
Great, and best would be, if the variables would remember its current display choice between the debug sessions, at least as long as they're not removed from the watch list or the IDE is closed at all.
-
Suggestion noted 😉
-
@RhoSigma Does this look like what you had in mind?
-
@RhoSigma Does this look like what you had in mind?
@FellippeHeitor, that's perfect. Nice & easy implemented. With that tiny button appearing when hovering a number I'd even say, we can waive to the "remember" feature I suggested, as access and changing the value is only a click away :), well done...
-
Hmmm, too late. Added it already 🤩
I'll get this one in its own thread as soon as it's out in the latest Dev build, so you guys can help me break it.
-
I really like having the debug/watch feature, and it's helped me quite a bit.
However, there are some issues that could make it more useful:
1. If a variable being watched has been removed since the last debugging session, the debugger will crash when you hit a breakpoint.
2. Remove a BP while the program is paused on that BP... and the program will still pause there on the next cycle. I seem to remember this happening frequently.
3. It is not possible to add watch variables defined in include files. We need a way to add those variables - possibly through a different watch dialog that simply asks for the variable name and its scope.
4. With a large program, the list of watch variables can get huge... it would be nice if I could just add a watch by selecting it in the source code or typing its name, rather than having to parse that huge watch list.
In fact, the variable list is the part of the debugger I don't like. While it looks great, it's unwieldly when there are more than a few variables in the program. I'd much rather just be able to type in the scope and/or variable name:
+-------------------------------------+
| Add Watch |
| Sub/Function: _____________ |
| Variable: _____________ |
| Member: _____________ |
| [Add Watch] [Cancel] |
+-------------------------------------+
-
Actually, this would also be solved with an 'Instant Watch' implementation as PDS had:
You don't have to look for a variable in a list (which could be very long), but you can just select any variable (also when declared in an include-file)
With 'Instant Watch' not only could you put your cursor on a variable in the source and press Shift-F9 to view it and then Enter to add it to the watchlist (or Esc if you don't need that), but you could also select any (complex) expression in the source and do the same. e.g. select Val(Mid$(Str$(var!), Instr(Mid$(Str$(var!),"."))+1)) as a watch-value.
-
@tomxp411 thanks for your feedback - and yes, as @mdijkens put it, the new var lookup feature I intend to add next will help you out with issue #4. Just making sure we're on the same page (especially because I use the debugger to debug QB64 itself sometimes, with a rather large list of 1932 variables only in the main file, since $includes are, ahem, excluded) do you use the filter feature? Maybe I need to document it/exemplify it more deeply, but it does make my life so easy when looking for variables either by name or by scope (or both).
Thanks for the report about the crashes/misbehaviors - I will have to try to reproduce the scenarios you outlined, since I don't recall getting any of those before.
@mdijkens don't hold high hopes for watching expressions, don't forget it's compiled code we're dealing with, and that request would require a full-blown interpreter to be integrated, which is not our goal in the end.
Regarding variables in $includes, I remember having a very good reason to exclude them, I just don't recall exactly what it was. After the 4 months of development of $Debug, I remember I still had that reason in mind - I'll let you all know if I remember what it was.
-
Hate to be a naysayer BUT, It seems to be way too invasive, there are a multitude of buttons associated with it that constantly cause popups if accidentally pressed. Plus clicking too far to the left side trying to get to the beginning of a line.
Perhaps an option to completely disable it if you don't need it? That way it doesn't get in the way but, can still be turned back on when needed?
-
@Cobalt suggestion noted.
-
@mdijkens don't hold high hopes for watching expressions, don't forget it's compiled code we're dealing with, and that request would require a full-blown interpreter to be integrated, which is not our goal in the end.
I can totally understand the issue there. PDS ran in some intermediate debug/interpreted mode (also slower then final compiled/linked program. Instant watch variables would already be very valuable.
-
@Cobalt you do know you've asked me this before and that I did add it to the Debug menu, right?
[ This attachment cannot be displayed inline in 'Print Page' view ]
Took me a hot second to remember.
-
Latest dev build available now contains the new ability to choose number format, as per @RhoSigma's suggestion (dec/hex/oct/bin) as well as a fix for the issue reported by @tomxp411 regarding occasional crashes due to removing variables between $debug sessions.
@tomxp411 I could not reproduce the issue regarding breakpoints, so I'd be glad if you could list the exact steps to reproduce it (provide some simple code if you can).
@mdijkens var lookup might take a tad longer, but hang in there.
Thank you all for your feedback and for trying the latest dev build. Help me break it, so the next release comes out as stable as it gets.
-
Latest dev build available now contains the new ability to choose number format, as per @RhoSigma's suggestion (dec/hex/oct/bin) as well as a fix for the issue reported by @tomxp411 regarding occasional crashes due to removing variables between $debug sessions.
@tomxp411 I could not reproduce the issue regarding breakpoints, so I'd be glad if you could list the exact steps to reproduce it (provide some simple code if you can).
Thanks.
I'll see what I can do on the stuck BP issue. I seem to recall it being kind of random, and toggling the BP the second time always fixed it.
-
@tomxp411 I could not reproduce the issue regarding breakpoints, so I'd be glad if you could list the exact steps to reproduce it (provide some simple code if you can).
I can't reproduce it on a simple test program, either. I'll try it again the next time I'm working on my Trek program.
-
Latest dev build available now contains the new ability to choose number format, as per @RhoSigma's suggestion (dec/hex/oct/bin) as well as a fix for the issue reported by @tomxp411 regarding occasional crashes due to removing variables between $debug sessions.
Just tested, works perfect for me, even the "remember" feature between debug sessions.
But what happened to the development builds? - 145MB 7z, with nearly 30000 files each (32/64)?
Oh, after a closer look, it seems both archives deliver both compiler versions (mingw32/64), one of it is renamed to c_compiler (according to version), but instead deleting the other one, it remains in place. Is this intended or a glitch in the build process?
I mean I could live with it in the development builds, but later in the release archives it should definitly strip out the unused compiler distibution.
PS - talking about the windows archives...
-
@luke will know.
-
I'm not a heavy user of debug features, but the few times I've used it, I've found it helpful. A worthwhile feature in general. I wouldn't characterize it as a particularly intuitive a system, but I could get over that by more use and familiarity.
If I were to critique a personal negative aspect, it would be the loss of full line highlighting by clicking at the line number bar. I always liked being able to do that. I could easily make multiples of code lines, make small changes in each and then comment toggle among them. It's gone now, which I found an irritation.
As it is now, I have to be very precise with my mouse dragging from column 1 of the line I want to column 1 of the next line, to highlight a code line for cut/paste ops. My hands are those of an arthritic farmer, not a surgeon, and I have to maneuver very close to the line number bar to do this and If I'm not careful, it's constantly asking if I want to add $DEBUG, which I then have to cancel. If I actually want $DEBUG, I can go do it manually. The auto add part of it, otherwise, interferes with my workflow.
PS I see from an earlier post how to turn off the auto add feature, which helps. Still I can no longer single click to highlight a line. I suppose I better hang on to 1.5
-
Thank you for your feedback, @OldMoses
Yes, you can disable the "Add $Debug metacommand?" prompt in the Debug menu, as in the screenshot above. That won't give you back line number clicking to select a line, but should solve 50% of your problems. I'll consider re-adding the line selection feature when the prompt is disabled, I'll let you know about it.
For comment toggling though, you don't need to select a line. Just have the cursor on it and hit Ctrl+T. 75% percent of your problems solved there now 😉
I hope you also know that you can single click a line, hold shift, then single click another line to select a line range. Hope that helps too.
-
Just turning off the auto add feature made it reasonable to use again.
-
Debug for me works very well.
With all the little bits added to every executed line. Which make debugging possible. I don't know if I am assuming something wrong. Unless I remark the $debug line at the top. Every execute module produced will be debugging enabled.
I suggest an change to the QB64 IDE drop down. Instead of only make EXE option (F11). Another option of make EXE with debug disabled. This way I don't need to comment out the $debug to create a tight EXE.
-
@OldMoses & @FellippeHeitor - thanks guys for that series of Q&A - I had not realized that ctrl+T or single click + shift worked as they do. Nor did I realize I could toggle on/off the debug metacommand. Wonder if @SMcNeill will have a chapter on those key control short cuts?
-
@Dimster glad it's been useful!
@doppler The intention is really to get you to remove $Debug once you're done coding.
Thank you for your feedback.
-
Wonder if @SMcNeill will have a chapter on those key control short cuts?
I hope to, just as soon as I get a little time once again. As you guys probably all know, (I'm certain I mentioned it at least a few times), my mother passed away back in January. My brother, being the dope head drunkard that he is, needs the money from her estate RIGHT NOW -- heck, yesterday even!! -- and he's being a complete PITA with everything. We've found a buyer for mom's estate (and we're dumping it for $180k, when it's estimated to be worth $300k, just to push everything through as quickly as possible so we can basically be done with it and with him), and if all goes well, the final sell and transfer of everything should go through on the 14th of this month. (Monday -- I'm counting the days down!!)
As you can imagine, this rushed deadline has ate up almost any semblance of free time which I could pretend to have. We've been clearing out all furniture. Selling off whatnots. Distributing family photos and mom's music books (I write novels; mom wrote songs)... This past month has just been a complete and utter pain in my rear, and I'll be soooo happy once things settle down and calm down.
If all works well, I'm going to take a few weeks vacation after all this is finished, just to get away from it all. (Depending on if the state of the world will allow for such extravagant things as traveling and affording the gas to go somewhere decent to enjoy the southernmost warmth and breezes, like the Florida keys.)
After that (so some time around the start of next month), I hope to get back into writing and working on my QB64 bible and adding a lot more info to it. A nice few chapters covering the IDE itself and all our hotkeys would definitely be nice to add into it at some point, but they're not in my "QB64 Bible" yet. Maybe by summer, since I definitely didn't make much headway on things before Spring rolled around here... ;)
-
@OldMoses I've reenabled clicking line numbers to select in the latest dev build when the "auto add $debug metacommand" is disabled. Please try it. https://qb64.org/index.php/development-builds/
-
Thanks Fellippe, that works like old times and grabs the best of both worlds. Much appreciated.
-
@Cobalt you do know you've asked me this before and that I did add it to the Debug menu, right?
Took me a hot second to remember.
Must have missed the memo...
-
😂
-
Personally, I absolutely love the debug features. I have a program I've written that is over 11,000 lines at this point and every once in a while, tracking a problem is a royal pain in the backside. This has made my life much easier.
-
That's great to hear, @hanness! Glad it's been useful!
-
Just using Watchpoints and the condition can only be a simple one variable condition (which I understand from the nature of compiled code).
Wouldn't it be great if there was also a $DEBUG metacommand to set a programmatic watchpoint in your code only to be executed during $DEBUG ?
e.g. something like:
or:
This might be doable?
It would also be possible if you can detect in code if running in debug-mode
And then put a normal watchpoint on MyWatchExpr1%
-
Wouldn't $ASSERTS and the _ASSERT command serve for this kind of debugging https://wiki.qb64.org/wiki/$ASSERTS (https://wiki.qb64.org/wiki/$ASSERTS) ??
-
Functionally yes, but not integrated with the new $Debug functionality.
I would still use $ASSERTS for (debug) logging purposes.
-
Although not going into specifics here, it was/is a great help - although floating point handling, as already noted is (and probably always still will be) an issue (and not referring to FLOAT which is a "problem" in itself).
Probably the best thing for me with $Debug was that it brought QB64 much closer to the already existing functionality of MS PDS 7.1 (upgrade to QB45) which I still use a lot (QB64 has a lot of catching up to what PDS could do).