[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 11:37:29 -0700
----- Original Message -----
From: Hadriel Kaplan
Date: 2/14/2013 11:29 AM
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.
On Feb 14, 2013, at 12:27 PM, Joshua Jensen <firstname.lastname@example.org> 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?
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.