 |
lua-l archive |
|
|
||
|
----- Original Message ----- From: Paul K Date: 2/14/2013 10:19 AM
One of the best features of this is that it (theoretically... I've never looked myself) would not cause any additional garbage to be created for Lua to collect. When you are working within constrained memory heaps, I want to debug my Lua code in the same state that it would ship in. Most remote debuggers like mobdebug end up loading additional stuff into the Lua state and causing additional memory usage.In ZBT's case, it looks like the program being debugged needs to be modified in order to be debugged by putting `require("mobdebug").start()` somewhere near the start of the Lua code. In Decoda's case, absolutely zero modifications are needed.True; although as I understand you'd still need to have debugging symbols for your executable available for Decoda, which means you may need to recompile the project anyway.
There is another interesting theoretical Decoda feature that hooking the remote process may offer. (Again, I haven't looked at the code.) Decoda probably did not set up a line hook, as it wouldn't necessarily have rights to add executable code to your process. Line hooks are horribly slow; in fact, Adobe posted a patch on the mailing list for Lua 5.1 that added real breakpoints and allowed the Lua code to run at full speed otherwise. If they are just monitoring the Lua state from the Decoda process, then the Lua state can run at 'full' speed.
I look forward to perusing their source code soon. -Josh