[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Decoda Lua IDE has become Open Source
- From: Joshua Jensen <josh.jjensen@...>
- Date: Thu, 14 Feb 2013 10:27:01 -0700
----- 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.