how working on bugs feels like in codea

funny video :joy: reminded me of codea instantly

Hah, if only it weren’t so true. One day we’ll have a proper debugger

they real benefit having a debugger for me would be having the ability to see inside a variable, i found a clever printTable function but it doesn’t work on any other types like touch, contact, etc

function printTable( t )
  local printTable_cache = {}
  local function sub_printTable( t, indent )
    if ( printTable_cache[tostring(t)] ) then
      print( indent .. "*" .. tostring(t) )
      printTable_cache[tostring(t)] = true
      if ( type( t ) == "table" ) then
        for pos,val in pairs( t ) do
          if ( type(val) == "table" ) then
            print( indent .. "[" .. pos .. "] => " .. tostring( t ).. " {" )
            sub_printTable( val, indent .. string.rep( " ", string.len(pos)+8 ) )
            print( indent .. string.rep( " ", string.len(pos)+6 ) .. "}" )
          elseif ( type(val) == "string" ) then
            print( indent .. "[" .. pos .. '] => "' .. val .. '"' )
            print( indent .. "[" .. pos .. "] => " .. tostring(val) )
          print( indent..tostring(t) )
  if ( type(t) == "table" ) then
    print( tostring(t) .. " {" )
    sub_printTable( t, "  " )
    print( "}" )
    sub_printTable( t, "  " )

@skar If you want an easy way to print the values of a table, try table.concat(tablename,”
”). This only works for simple tables.

@skar There’s a simple debug option now. Run the code below and just above the keyboard on the left side are the words “type a command”. Tap on them and then key in print(a) and press return. It will print the value of “a”. Type it again and you’ll see the value increased. I’m not sure of all the commands that will work there, but you can see the value of variables while the code is running. Ignore the => nil that prints.

function setup()
function draw()

@dave1707 thanks for that tip, it will come in handy!

Mostly I make do with inline prints … and of course I recommend micro tests with CodeaUnit wherever practical, but that can take some learning. Worth it to some, probably not to others.

The print from console can be handy, especially if you put a tostring on your objects. Because our code is mostly executing 30,60, 120 times a second, a debugger would need to stop the draw clock. I guess if that happened, the screen would stay however it was.

I can imagine some simple debugging would be possible if Codea provided a pause function that stopped the draw clock, and remembered the location of the pause. For best results, it would retain current scope. Then we could print some stuff, then a continue command in the console would start things running again.

However … it would just stop again one zillionth of a second later. But wait!? What if a pause was associated with a boolean parameter, and the parameter automatically reset to false when the pause hit. Then continue would let the program run normally. It should even be possible to have the program do some logic and set the flag when it wants to be debugged.

I think there’s an idea here, for a simple-enough pause feature. Let’s see if we can flesh it out and propose an improvement. I haven’t searched the web for Lua debugging ideas, but there might be some good ones out there to fold in to a proposal.

Starter idea:

Pause Statement:

pause(aBoolean, reset)

if aBoolean is true, stops the draw clock and pauses execution at the location of the pause. (Ideally, the scope seen by the pause statement would be visible to console prints.) The boolean is set to the value of reset if provided, i.e. true or false.

When the user types go <expr> into the console, the pause function returns the value of <expr> and execution continues from that location.

P.S. If assert could return via console command, we’d almost have this.