Hey!
yes and yes. It should be possible with a plugin, but would require extending the current API. I'll see if I can put a prototype together in the next few days.
I will be eagerly waiting for an update on this, then :D
I can't say for sure without knowing more about your system, but you may be surprised ;). I'm using ZBS to debug wxlua/wxwidgets applications that have somewhat similar architecture and it's also been used to debug scripts running a variety of environments from Nginx/OpenResty scripts to debugging multi-threaded embedded apps. The way it works is that the Lua state is blocked by the debugger, but the rest of the application can continue without any issues; the debugger also provides a callback that can be used during that "waiting period" to give ticks back to your application (this is used in event driven GUI applications to avoid showing "busy" status).
Wow, I am impressed that this could be possible for us. Maybe we will have a look at it, then. The following is a definite thread derailing, sorry ;D
Does the debugging still work if something tries to access and/or change the Lua state from C++ (which happens frequently in our program)? It would be slightly counter-productive if the C++ side would crash the program one frame after debugging starts by trying to set a Lua value.
What happens when there are numerous Lua states, all running on different threads (which also happens in our program)? For example a graphics thread with Lua-scripted UI, a gameplay thread with Lua-scripted gameplay, etc..
Does the usage of LuaJIT make any difference here (we use it for obvious performance reasons)?
As you see, I have a ton of questions, and due to all of these questions I always assumed that it was just not possible without very serious work on the engine itself. And if we would need to spend months on that feature, the time would probably be better spent on something else. After all, Lua already has fine error messages that are actually helpful. Most of the time, anyway.
