Re: Decoda Lua IDE has become Open Source

[Joshua Jensen <josh.jjensen@...>]

----- Original Message -----
From: Paul K
Date: 2/14/2013 7:09 PM
> Hi Joshua,
Hi.  Just to say up front, I think ZeroBrane Studio is *fantastic*. I 
just wish I could use it; there are a few dangling issues that prevent 
me from deploying it within my current project.
> > 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.
The big differences here are as follows:

* C/C++ allocations can be put in an alternate 'debug' heap away from 
existing game allocations.  This avoids fragmenting the main game when 
the debugger is active.
* C/C++ allocations can be freed immediately.

Anything allocated within a Lua state for something like mobdebug (by 
debug.getinfo or otherwise) will be allocated using the same allocator 
that everything else within the Lua state uses.  It isn't possible to 
separate mobdebug's allocations into a 'debug-only' heap.  Further, any 
allocations performed by the use of mobdebug (incoming/outgoing data to 
luasocket is included her) will be subject to garbage collection.  Yes, 
it will clean itself up eventually, but the timing of that clean up is 
dependent on factors outside of mobdebug's control.
> 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).
Embedded engines generally do not do LUA_INIT processing.  They would 
have to separately have to process mobdebug first before executing the 
rest of the scripts for the state.
> > 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.
We need to talk about this support offline.  This is the biggest reason 
why we can't use ZeroBrane Studio.  :)
> > 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,
I have used the interface in HavokScript from within Visual Studio. As I 
vaguely recall, it has a Lua States window (not necessarily called 
that).  When you select a state, all of the coroutine and variable views 
update.

There are better user interfaces, of course, but this style is good 
enough for me.
> 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.
We use the Tilde debugger at this point, and it requires opening up 
multiple instances, too.  Our users generally find that a pain.

Thanks!

Josh