[Graham]

I think my most common method as of now is to add numbered message lines around my programming. Around the spot the problem is persisting I'll add * "1", * "2", * "3" and so on in between the lines and run the program to watch where the numbers stop displaying. Then I'll study the code and look for spelling errors or expression syntax mistakes or reasons a label is not being called, etc. of course there are many variations of this method depending on the section of code it's being applied in, but that's the basic idea.

What are some of your methods for finding and fixing bugs? I may use some of the methods given in an upcoming tutorial I'm planning on doing on debugging. Plus you can help out some of the newer programmers out there.

Also you could help me, you see I'm trying to figure out a complex bug right now and my usual method isn't working out. So maybe a fresh idea will help me, thanks.

[Dr Lancer-X]

I generally use counters and strings and the F11 menu to do debugging. I just set a bunch of debug counters and strings (typically with names preceded with underscores so they appear at the top) with whatever data I feel I might need and use that to try and work out what's going wrong.

This is partly because I'm often working in an area that makes stuff hard to trivially display on the screen and partly because I generally want to output a ton of information, more than could really be displayed on the message row. I can also export the counter set from the F11 menu and look at both my debug counters + strings and the actual counters + strings in a text editor while editing the suspect code, so I can attempt to work out the ways in which the current program state is inconsistent with what the code should be doing.

For particularly hardcore tasks I will sometimes write out logging data to a file; I'll typically have a log.txt that I erase at the start in the global robot:

set "log.txt" "fwrite_open"
set "" "fwrite_open

and then I'll just write out anything that happens to it with fwrite_append so I can close the file each time so that it doesn't interfere with any actual file writing my game might do:

set "log.txt" "fwrite_append"
set "$_dbg" "d &loopcount& &local2&\n"
set "$_dbg" "fwrite&$_dbg.length&"
set "" "fwrite_append"

I also tend to throw in the occasional assertion, although usually not too many because they take up space and can't be automatically removed in a trivial fashion. For me an assertion is usually something like:

if "(('local2'<0)o('local2'>150))" = 1 "wtf"

...
: "wtf"
ask "WTF"
end

if local2 will always be between 0 and 150. I tend to use the "wtf" label for all assertions, so this doesn't tell you which one triggered, but at least you know something is up and can dig into it later. The reason I use ask is because the 'ask' dialogue uses the protected palette and charset (or just charset in SMZX mode) so you can actually see the message. Not that it really matters because it's not a very descriptive message, but still!

[Lachesis]

I'd hold off a tutorial for debugging until the next MZX release. There will be a Robotic Debugger in 2.84d. It's even been in the latest GIT for months, it just can't be released until I write debytecode support for it (:

[Graham]

Lachesis - That's good to know, thanks.
Lancer - That's useful, I've been thinking of creating a text log and seeing how you do it certainly helps, thanks a lot.

[Graham]

I forgot to mention another quick trick that I often use. If I need to keep an eye on the status of a counter, I'll add a robot to the board with a loop displaying the counter.

: "top
cycle 1
* "~f&counter&"
goto "top"

This way I can see how the robot controlling the counter is behaving. This is a real basic method though and I'm sure most everyone already does something similar to this.

[Dr Lancer-X]

A similar trick I like to use is:

: "l"
set "time" "(60+'counter')"
cycle 1
goto "l"

The trick here is that the timer uses the protected charset and palette, so you can see it even if you're using those chars for non-number-related purposes! The 60+ is so you get 01:## where ## is your counter (up to 59)- if you just use 'counter' it could hit zero and the timer-running-out event will occur.

[ThDPro]

I did a thing for awhile in MAR's development where I'd have error messages add to specific places on a string and then print it to a file with date and time in the string as well... I ended up abandoning it entirely for various reasons, it's application was terribly specific and the results took a little too much effort per gain. I can however, see that system working for someone.

: "l"
set "$ERROR" "A0B0C0D0E0"
. "just and example of a labeled error code, letters representing"
. "different errors and 0 or 1 being set at the error message writer"
set "$tmp" "$error"
. "setting $tmp to check if there were any errors by cross ref"
wait 1
goto "#TEST"
. "this can be anything really"
if "$error" != "$tmp" "#WRITE_ERROR"
goto "l"
: "#TEST"
if "counter" != "othercounter" "#ERROR_D"
goto "#return"
: "#ERROR_D"
set "$ERROR.(4*2)" 49
. "4 because it's triggering the fourth error, which in the string is D"
. "49 being char 1, signifying the error being triggered"
. "*2 because there are two chars per error"
goto "#return"
: "#write_error"
inc "$ERROR" "_&TIME_HOURS&:&TIME_MINUTES&:&TIME_SECONDS&"
set "errors.dat" "fwrite_append"
set "$error" "FWRITE"
set "" "fwrite_open"
goto "#return"

I did SOMETHING like this in MAR, it was pretty useful while I was using it, but it's... totally cumbersome and more or less useless to most applications. god I'm tired...

EDIT: I dunno if this is helpful in any way, and it's worth noting I only ever used this idea once and even then, it may have been badly misapplied.

This post has been edited by ThDPro: 11 July 2013 - 07:22 AM

[Risu2112]

I'll fix your bug. send it to me.

[Graham]

Thanks, I finally figured it out though. Basically if you save your game (mine saves through robotic commands) and you have less robots on the board then when you started it (because some died) then MegaZeux reorders the robots and some of them will have a different robot_id. This was a problem because robots were loading programs according to their robot_id leading to some of them no longer working. So the fix was to set a local counter to the robot_id and load from that.

[CJA]

I just add a bunch of message strings to loops with informative counters embedded in the message.