Re: Decoda Lua IDE has become Open Source

[Paul K <paulclinger@...>]

Hi Joshua,

> longer use that code, but it is possible to do.  You just have to remain in
> C/C++ and do all of your memory manipulations and string and socket
> operations there.

This would definitely be faster, but I'm not sure how much this would
change in terms of memory interactions (and heap requirements). There
is clearly some processing that is done on every command, but it's not
much and mobdebug should release all the memory it uses. In fact, I'd
argue that most of that allocation is already on the C/C++ side; for
example, for Lua tables that are returned by various debug.getinfo
calls.

This is not to say that there is nothing to improve. In fact, I used
the idea from Stephen Nichols who re-wrote some of the Lua calls that
return tables in C for better performance and integrated it with
mobdebug, but the result is tied to a particular platform (whether
dll, so, or dylib), and even to a particular engine, which has its own
downsides.

On requiring changes to embedded scripts, it may be possible to use
LUA_INIT to include mobdebug.start() call without making any changes
to the app, but it doesn't quite work yet (also, I'm not sure if
embedded engines do LUA_INIT processing).

> mobdebug and company are harder to employ in this context.  They definitely
> eat more memory and create a lot of garbage.

I'm not sure about "a lot of garbage" ;). I've been quite careful
about what variables to use, but clearly there is some overhead simply
because it accounts for many more situations than you may care about.
For example, there is a check for luajit you may not be using, or data
structures that keep track of coroutines you are debugging, which may
not apply if you don't need them and so on. You can easily trim some
of that to customize it for your case, but the idea is that you drop
mobdebug into your environment, call start() and should be able to
debug your Lua app whether embedded or standalone. I'd say with the
addition of Lua 5.2/LuaJIT support and cross-platform file system
mapping, it gives you a lot of coverage in terms of what you can debug
with it.

You can also use off()/on() calls to disable and re-enable debugging,
which turns off debug hook to give you normal Lua performance.

> Also of note with Decoda is that it is the only multi-state Lua debugger I
> know of outside of HavokScript.  Hopefully, one of the others will one day
> have that.

I'm not exactly sure how multi-state debugging interface would look
from the user side, but you should be able to emulate this with two
mobdebug sessions. You can open two ZeroBrane Studio instances (you
need to disable single instance check for the second instance)
listening on two ports and call require("mobdebug").start(nil, port1)
and ...start(nil, port2) from different Lua states to get two
connections. You should then be able to debug them independently. It
may be possible to use one instance of the IDE (in fact, there is an
explicit check to avoid establishing multiple debugging sessions), but
I couldn't come up with a proper UI for it and there has been no
demand for this type of functionality.

Paul.

On Thu, Feb 14, 2013 at 10:37 AM, Joshua Jensen <josh.jjensen@gmail.com> wrote:
> ----- Original Message -----
> From: Hadriel Kaplan
> Date: 2/14/2013 11:29 AM
>>
>> On Feb 14, 2013, at 12:27 PM, Joshua Jensen <josh.jjensen@gmail.com>
>> wrote:
>>
>>> 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.
>>
>> Sure, but the reason you may have a "constrained memory heap" is because
>> your Lua-using program is on another system, like in an embedded appliance.
>> LDT and ZBS let you access that remotely - i.e., true remote debugging,
>> rather than just local other-process debugging.  To get true remote
>> debugging, you have to make some change in that appliance's code
>> somewhere/somehow, for example if just to open a socket and run a remote
>> debugger/API protocol to it (e.g., DGBP).
>>
>> Although I suppose if your remote appliance is actually running Windows
>> you could use Decoda on it remotely and remote-desktop in or whatever.  But
>> isn't running Windows contradictory with the notion of a constrained memory
>> heap?
>> ;)
>>
> The reason you may have a constrained memory heap is because you are a video
> game.  Windows or not, those tend to have limitations on memory usage, as
> the same code is shared across platforms.
>
> LuaPlus' old remote debugger code allowed you to remotely debug into the
> running Lua state without affecting any of the internal memory usage.  I no
> longer use that code, but it is possible to do.  You just have to remain in
> C/C++ and do all of your memory manipulations and string and socket
> operations there.
>
> Tilde's remote debugger code is written in C++, and it does modify internal
> Lua state, but it is nowhere near as bad as full Lua implementations of
> remote debugger code.
>
> mobdebug and company are harder to employ in this context.  They definitely
> eat more memory and create a lot of garbage.
>
> Also of note with Decoda is that it is the only multi-state Lua debugger I
> know of outside of HavokScript.  Hopefully, one of the others will one day
> have that.
>
> -Josh
>