I Saw It The First Time

BlitzMax Forums/BlitzMax Beginners Area/I Saw It The First Time

dw817(Posted 2016) [#1]
Now that I'm getting into the 'meat' of my Carryall Routine, it is necessary for me to have several debugging tools to assist.

While I was using PRINT before, it is suggested that I use DebugLog() instead.

I would except for the fact that it automatically outputs the text, "DebugLog:" before every single text, making a very cluttered display with several of them.

Is there a difference between PRINT and DeBugLog, and/or is there a better method to have output appear only during debug and not during final code ?
Function dbug(a$,b$)
  DebugLog ""
  DebugLog Chr$(17)+Upper$(a$)
  DebugLog b$
EndFunction



Derron(Posted 2016) [#2]
print - gets output everytime
debugLog - gets output only during debug
customPrint - gets output whenever you want

To get rid of the "debuglog:" use something like this

Function MyDebugLog(s:string)
?debug
print s
?
End Function


If you want to skip multiple entries of the same debuglog after each other, store the last "s" and only print "s" if it differs from the backup one.


bye
Ron


dw817(Posted 2016) [#3]
Hi Derron. Actually I found that PRINT is apparently completely ignored in final runtime if you have the following flag set:

Build Options )) Build GUI App

If you compile your program to a final runtime via Debug Build being deselected, then anything you PRINT does not appear for the created and external EXE.

Thanks for the code you wrote though. That's a good way to get around it if it insisted on printing anyways for final EXE.


Derron(Posted 2016) [#4]
Even with a GUI build you should see the prints... it just does not create this "console window" anymore.

So when running it from MaxIDE (build+run) you should see the output.

If you start your GUI-app from the terminal you should see it too.


@MyDebugLog
Feel free to log to a file :-)
(I use this code - of interest for you: TLogFile).


bye
Ron


grable(Posted 2016) [#5]
To add to what Derron said, Print (and any other console IO function) will slow down your process if doing a lot of logging in tight loops and such, even in GUI mode.
Writing to stdout isnt a fast operation. Actually, logging to a file is probably faster ;)

Ive never liked DebugLog to be honest, since it isnt completely removed in Release mode.
The call still happens, its implementation just calls another NoOp function instead of the actual implementation via a function pointer.

I even made a tool to strip unneeded debug info present in Release mode from the generated assembly, but it was a pain to keep in sync so i abandoned it :p


dw817(Posted 2016) [#6]
Good to know, Grable. OK, I'll add the ?debug comparison just to be safe.

And no, I rely quite a bit on the text output to keep me abreast of values.

Now I suppose it's perfectly possible to create a really busy one that outputs directly to the graphic screen with a scrollbar to go up and down in debugged values, but this is fine for what I need. :)