@dave1707, @RonJeffries, about my breakpoints, I should be very clear: this is a bad solution.
It’s extremely kludgey; it’s a huge cheat that runs around Codea’s back and twists it into shapes it wasn’t meant to go.
It is no replacement for what people are calling for in this thread, which is a nice built-in, system-level set of basic debugging tools. I want to be really clear that I don’t think my breakpoints make the need for those tools any smaller at all._ Out of desperation I made something that served my needs just barely, and I really think this is not the way things should be done.
That said, a few explanations: there are two separate things happening here: the breakpoints, and the diagnostics. I invented the breakpoint system but the diagnostics are all native lua. Lua’s debug.sethook system is primitive but it allows you to declare a function that gets run at either every line, every function call, every return from a function call, or some combination of those.
So native lua, without any help from me, can provide line-by-line analysis of code. You can run it and then look at a big list of print statements, or however you stored the data you collected. The only thing it can’t do is provide it live. That’s what I did; the part I’m adding is the step-by-step.
The way I enable step-by-step is essentially put an infinite loop after every line. I use the sethook command to activate an infinite loop that does only one thing: monitor keyboard input.
This is a cheat. Codea is essentially broken at this point. You can’t interact with anything. Buttons don’t work, touches don’t get processed. You can’t use the console. It acts just like it would if it were actually stuck in a loop… because it is.
The one thing it can do is respond to keyboard input. I searched and searched for a way to break out of an infinite loop and found nothing until I looked at the keyboard API. You can’t make anything happen asynchronously in Codea (even http calls don’t get processed in parallel) except for responses to keyboard events.
So what’s happening in my step system is the sethook function processes a line, then my code hangs the whole system until the right keyboard keys are pressed, then sethook processes another line, and my code hangs the system again, and etc etc.
Now as limited as this is, it can still be extremely useful. For one thing, it prints out the function name and line number at every step. So you can watch command flow as it happens. That right there helped me enormously.
And with the function that gets passed to sethook you can perform any diagnostics you want, mostly. You can print out variables. You can do math. You can even run unit tests (in theory, I haven’t tried it). You can do anything you can do in a function. The one catch is scope. In my system you can only access global variables. You could write your own lua debugging code if you want, and include it in the callbacks my system does, because with lua’s built in tools it is possible to examine variables that are only in the scope of the current line, it’s just tricky and I don’t really know how to do it.
But with those caveats, you can do at diagnostics you want, line by line, live. This again, though limited, was extremely helpful to me. Any variables I needed to monitor I just made global temporarily.
So again my breakpoint system is no replacement for real debugging tools. It cannot (at least in any way I can figure out) let you interact with your program while you step through it. It can however expose control flow, which is extremely useful, and it can run any diagnostic function you write, live, line-by-line, which is also extremely useful—at least it was for me.
And that said, it’s a big big big big +1 from me to the call for real, baked-in, not-cheating diagnostic tools.
