Debugger

[bjornbytes]

To investigate/consider: add debugger.lua to the nogame bundle and add a debug REPL to the error screen. See love-debugger for an example of how it could be integrated into lovr.errhand. It seems like it would be way too convenient to be able to inspect variables, see source code around the error, and evaluate expressions in the error screen.

[bjornbytes]

Even if we don't want to use debugger.lua, it might be easy/useful to add some basic controls like pressing up/down on a keyboard/controller to navigate the stack frame, showing the source code around the line number and values of local variables.

[bjornbytes]

Yeah, I think a debugger is overkill, since execution stuff like step/continue/finish aren't needed. A stack trace inspector is more appropriate, and smaller in scope.

[jmiskovic]

It's a great idea! I'm going to adopt the debugger REPL in errhand, make it a library.

I wouldn't put it in the framework though. When runtime error happens you don't expect the framework to "leak" the code to end-users / players.

[bjornbytes]

Hm, the source display could be disabled in fused mode. Or, the fancy error screen could go in the nogame bundle, so it would get stripped out when packaging a fused project.

[bjornbytes]

I saw that @snowkittykira made love-error-explorer for LÖVE. It's pretty much exactly what I was thinking!

[jmiskovic]

Here's implementation of the debugger integration.

https://gist.github.com/jmiskovic/2a9e1a8eafe4b09398778b7c4d82f673

It's tucked away in a gist for now because it's not battle tested (but works really well so far) and it uses the colortable printing that only works on very recent dev.

[bjornbytes]

Nice, love the colors + readline stuff, I made 2 small edits:

--- errhand.lua
+++ errhand.lua
@@ -160,10 +160,9 @@
     if pass then
       pass:setDepthTest(nil)
       pass:setDepthWrite(false)
-      pass:setColor(0.05, 0.05, 0.05)
+      pass:setClear(0.05, 0.05, 0.05)
       local w, h = lovr.system.getWindowDimensions()
       pass:setProjection(1, mat4():orthographic(w, h))
-      pass:plane(0, 0, 0.5, w, h)
       pass:setColor(1, 1, 1, 1)
       local colored_text = get_render_text(line, cursor_pos)
       local fontSize = 20
@@ -178,6 +177,7 @@
   dbg.write('\n' .. prompt)
   local line = ""
   local pos = 1
+  lovr.system.setKeyRepeat(true)
   lovr.system.pollEvents()
   while true do
     if lovr.system then lovr.system.pollEvents() end

Also the up and down commands weren't recognized for some reason. Honestly I think it would be okay to add something like this to etc/nogame. Maybe boot.lua could require errhand from the fused zip if it exists, to override the default error handler.

I still want to try the "stack inspector" idea too, maybe after I'm done with audio stuff. Any reason to prefer debugger.lua style to love-error-explorer style? I think the advantages are:

• You can type an expression into the prompt instead of hunting through a tree view for a variable. On the other hand, error-explorer requires less keys, so it might be easier to navigate it with a VR controller or hand tracking
• You can call functions with p. It's nice to do p collider:isKinematic() or whatever. This isn't possible with the error explorer.

[jmiskovic]

I think the u and d work as well as they can. I checked against original debugger.lua, I could go as far up/down with them in both environments. A confusing thing is that the gravity works different from GDB, here going down means going to caller function.

Yeah I agree, an interactive stack explorer would be lighter and more suitable to integrate into framework as the default option. The explorer can be simple and complete, instantly familiar to everyone. The REPL should either be a 3rd party lib (like for LÖVE) or an opt-in feature.

For my own flow though the stack explorer is not too useful, doesn't bring anything new. I'd rather get error output in SublimeText so I can doubleclick the filename:linenumber and go fix the typo.

The debugger can actually give me fine control over execution. I can pause the runtime (if lovr.system.wasKeyPressed('f12') then require'repl'() end), change internal state or step through the code, and let it continue from where it paused. Seeing this all happen within the same LÖVR desktop window feels very satisfying.