lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

----- 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
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.