Thanks a lot for this great tool! Until now I haven't been able to figure out how to do variable assignment e.g. a=5 in the debugger environment. Is this a valid functionality?

Quick highlight of the proposed changes:

• New q[uit] command to stop executing the program immediately.
• New S[top] command to disable all breakpoints.
• New pretty printing functionality redesigned for inspecting long/complex tables and subtables; handles recursion and custom __tostring metamethods gracefully.
• New o[ption] <name> <val> command to set debugger options. Primarily used to control the new pretty printing.
• l[ocals] view no longer expands tables, for readability reasons. Using the 'le' form re-enables this. (Note: the printing depth will have to be set to 2 or greater (via o depth 2 for this.)
• New dbg.on/dbg.off functions, used to enable/disable breakpoints.
• New dbg.opt function, used as an alternative to 'o ' every time the debugger is loaded.
• New dbg.install function, places the debugger object in the global namespace as dbg.
• Chunk compilation has been patched to allow expressions that cannot be prefixed with a return statement.
• Any non-command statement is now treated as an implicit p[rint] <exp> statement. This results in a much improved debugging workflow.

It also now supports using Antirez's Linenoise, via my bindings.

Any comments?

Previously, an error call would prevent calls to repl because the stack offset wasn't being reset properly.

This commit fixes that by setting the offset to -1 when an error call is encountered, which allows hook_factory instances to call repl on the next encountered Lua line.

Also, the repl function is now called only when a "line" event is for a Lua function. This means the repl is never used to inspect a C function (which is pointless).

Assignment is done as you would expect: foo = bar + 2

• No command required
• Locals, upvalues, and globals can be used in the expression
• Locals and upvalues are mutable
• You can do tuple assignment: x, y = 1, 2

Assignment of an undeclared or global variable does the following:

• declare the variable in the REPL environment
• that variable is only accessible via the REPL

You can always mutate a global variable with _G.foo = 2

This commits removes cmd_eval, but you may have a good reason to keep it around. Let me know!

From an email:

Thanks for writing the Lua debugger. I use it in my control program for my model trains.

It was trivial to install and by overwriting the dbg.* functions, I was able to seamless integrate it into my program.

I did come across one odd behavior. I had this function in my code:

   function cleanup(Engine, TIU)
            -- this function is called once when the user presses the [STOP] button
            --print(os.date("cleanup()  %d %b %Y   %X"));
            return true;            -- false=cleanup failed, true=cleanup succeeded
   end

A commented out "print()" command that I had for testing only.

I entered the debugger with "dbg()" and then used the "s(tep)" command to step into this function and through it.As I stepped through lines 68 an then line 69 I got this error message:

68 -- this function is called once when the user presses the [STOP] button Error 2 running function cleanup() : E:\Projects\RTC\lua\debugger.lua:110: bad argument #3 to 'format' (no value)

Here is the dbg_writeln() in debugger.lua that I overwrote (I don't need the "\n"):

   local function dbg_writeln(str, ...)
      if select("#", ...) == 0 then
            -- mcd change for RTC Debugging
            --dbg.write((str or "<NULL>").."\n")
            dbg.write((str or "<NULL>"))
            -- mcd change for RTC Debugging
      else
            -- mcd change for RTC Debugging
            --dbg.write(string.format(str.."\n", ...))
            dbg.write(string.format(str, ...))                      ------- this is line 110 refered to in the error       
            -- mcd change for RTC Debugging
      end
   end

I appears that the "%" in the commented out print() statement is confusing the string.format() call inside of dbg_writeln().

I set "dbg.auto_where = 2" for the line tracing.

This can be worked around but you might want to fix it.

Thanks again, Mark

Probably this debugger was not even meant to work with love2d, but I'm reporting here because it would be great to be able to get it working there!

When running dbg(), I get the Loaded for LuaJIT 2.0.5 message in the terminal and after that the program keeps running instead of the debugger kicking in. Also, the program runs with very poor performance after this, as if it's doing something in the background.

Edit: forgot to mention love version: 11.1

Let's say I moved up the stack by a frame. Now, I want to skip to the (n)ext line of the frame I'm inspecting. The current behavior simply skips the line of the bottom frame (even if I moved up a frame).

Would this be easy to implement? 😄

Hi, could you choose and publish a license for this project? I want to use it in my game, but our packaging requirements require that all files have an explicit license from the author.

If you don't particularly care, I'd suggest the MIT license since it's compatible with nearly every organization's licensing requirements.

Great work on the library, hope to get a response soon.

This bug is not related to your code but maybe you know how to fix it.

It happens on Xubuntu 20.04, xfce4-terminal, on any lua version (5.1-5.4), including luajit.

In debugger.lua prompt I can't use arrow keys. When I press them, it types annoying bullshit like this: "^[[D^[[A^[[C^[[B".

With this commit, the up and down commands hop over any C function calls. This provides a better experience, since you can't do anything on C frames anyway.

The trace command will continue to show C function calls, though.

I squashed the commits by @churay that add a where command that print the lines of code surrounding the current breakpoint.

debugger.lua> w
58	             stream.headers = headers
59	           else
60	             return stream:shutdown(), app:onerror(err)
61	           end
62	           dbg()
63	=>         local res = setmetatable({
64	             headers = http_headers.new()
65	           }, res_mt)
66	           local _list_0 = app.pipes
67	           for _index_0 = 1, #_list_0 do
68	             local _continue_0 = false
debugger.lua> w 7
56	           local headers, err = stream:get_headers()
57	           if headers then
58	             stream.headers = headers
59	           else
60	             return stream:shutdown(), app:onerror(err)
61	           end
62	           dbg()
63	=>         local res = setmetatable({
64	             headers = http_headers.new()
65	           }, res_mt)
66	           local _list_0 = app.pipes
67	           for _index_0 = 1, #_list_0 do
68	             local _continue_0 = false
69	             repeat
70	               local pipe = _list_0[_index_0]
debugger.lua> w1
62	           dbg()
63	=>         local res = setmetatable({
64	             headers = http_headers.new()

As you can see, the default line count is 5 on each side of the breakpoint.

You can customize the line count by adding a number after the command. The space between is optional.

It would be really cool to add syntax highlighting in the future.

trying to run the debugger_lua.c.lua file from within the embed folder will result in "attempt to index a nil value" errors, which are not obvious, as to why they happen. by reading through the readme, I've then found out that this file needs to be run from the main folder, which will allow "io.open('debugger.lua')" to not return nil.

I've added a comment at the top of the file to make that obvious.

I come from a Ruby background and am used to pry and byebug as my main debuggers, and spent a good 20mins wondering why I couldn't inspect variables with this debugger when stepping/moving worked fine.

I was doing variations of this:

debugger.lua> transitions
debugger.lua> src_state
debugger.lua> print src_state
debugger.lua> locals
debugger.lua> l
	dest_state => "Ready"
	src_state => "Not Ready"
	transitions => {"Not Ready" = {}}

I realize that l prints all the locals out, but I'm wondering how I can inspect individual variables...

And then out of frustration I type in:

debugger.lua> asdfasdf
debugger.lua>

And notice that the prompt doesn't react and then I'm like ohhh when it doesn't understand a command it just pretends like nothing happened.

Cue these attempts:

debugger.lua> pp(transitions)
debugger.lua> p
Error: command 'p' not recognized.
Type 'h' and press return for a command list.
debugger.lua> pp
debugger.lua> h
[.. help output ..]
debugger.lua> p transitions
transitions => {"Not Ready" = {}}

I was expecting the output of p and pp to tell me what arguments they were expecting.

Even more confusing is that when you do type in the right single character command but with the wrong arguments, it says Error: command 'p' not recognized - which is arguably even more misleading 🤣

Anyway. Just throwing my 2 cents in here. ~I'm still too much of a lua noob to attempt to fix this myself, but if you think it's a worthy addition, I can make an attempt.~

Edit: Turned out to be an easy fix - I created a PR.

Windows 10 anniversary update added ENABLE_VIRTUAL_TERMINAL_PROCESSING flag to console mode, which can be used to enable ANSI color codes. This can be enabled for LuaJIT environment (where FFI is available). Below is my way to enable it.

https://github.com/MikuAuahDark/livesim2/blob/master/logging.lua#L59-L63

When inspecting a table, it sometimes has a property whose value is a long string that fills up the terminal. This is often too noisy. If I wanted to see the entire string, I would inspect that specific property.

Truncation would replace the end of the string with ... (# = 1000). This could be colored so it's clear this isn't the string's real value.

What would be a good length for truncation?

It would be great if using finish or next within a coroutine would avoid triggering the REPL outside that coroutine (unless the coroutine dies). You can always use step if you want to follow yields.