Tasks | ||
---|---|---|
![]() |
![]() |
|
Concepts | Updating This Document |
You can set breakpoints at a particular file/line, you can do it with the regular double-click on margin:
You can optionally indicate conditions to stop execution only under specific circumstances:
Once a breakpoint has been hit, and the execution has actually stopped, you can use the Step Into, Step Over and Step Return commands.
{{message|{{#if:{{{1|}}}|' Coroutine handling'<BR>}}{{#if:{{{2|}}}|When the current instruction is a coroutine.yield or a coroutine.resume step over will jump over the coroutine until the next resume or yield whereas step into will go into the coroutine and re-break as soon as possible.}}|image=Idea.png|bgcolor=#def3fe|bdcolor=#c5d7e0}}
When a breakpoint is reached, you can see any variable visible from any stack frame (local, upvalue and global variables). You can also change values to another.
{{message|{{#if:{{{1|}}}|' New values are expressions'<BR>}}{{#if:{{{2|}}}|When you set a new value, it is evaluated as an expression, so math.sqrt will be evaluated to a function, if you want to put a literal string, use Lua syntax: "math.sqrt". In particular you can change an entire table by another table expression. This is sometimes powerful and sometimes dangerous, be careful with that.}}|image=Idea.png|bgcolor=#def3fe|bdcolor=#c5d7e0}}
Some special values can also be displayed such as metatables or function environments (if it is different from global environment). You can also change these values.
In addition to variable view, you have two other useful tools to evaluate some code snippets: expressions view and interactive console.
{{message|{{#if:{{{1|}}}|' Always on top level'<BR>}}{{#if:{{{2|}}}|Due to a limitation in the DBGp protocol, the interactive console and expressions are always mapped to the top stack frame}}|image=Warning2.png}}
The DBGp Server (IDE) and the DBGp client (running application) need to communicate about source files.
E.g. When you set a breakpoint, the IDE need to say to the running application on which file the breakpoint must be added.
E.g. When the running application stops on a breakpoint of a file, the IDE must retrieve the file and open it.
The problem is that the file executed in your Lua VM could be physically different than the source file in your IDE (in your workspace). For example, in the case where your code is executed on a different host or just if your executed code is duplicated in another folder.
To resolve this problem, LDT proposes to you different strategies, each with advantages and drawbacks :
This way to resolve the source mapping is the more simple and the more reliable. Both client and server works with absolute path. The IDE will search only in its buildpath a file which have the given absolute path. This means that executed file should be in your workspace (in your buildpath more exactly). So you can not use it to debug code on a remote host.
Both IDE and application have their own way to retrieve a module from its name. So we could use the module name has file ID instead of path.
With this mode, you could do remote debugging without settin a list of path mapping.
The limitation is that you should use the standard lua_path way to load module.
Another problem is that we could not really retrieve the module name at client side, because the Lua debug api uses source path. The module name is retrieved from the path (from debug.getinfo) and the lua_path (package.path). so with ambiguous lua_path you could have insolvable conflict.
''E.g: with package.path = "/foo/bar/?.lua, /foo/?.lua"
and debug.getinfo="@/foo/bar/baz.lua"
the possible module name is bar.baz or baz ''
There are no way to know the real module name, in this case the debugger will use the shorter one, but the ideal is to avoid ambiguous lua_path with this mode.
This mode is a fallback. If the two previous one don't fit your needs, you could try it.
In this mode, client talks with absolute path and server (IDE) uses relative path (relative to the buildpath).
A path must be set in launchconfiguration to move from one world to another.
''e.g: You set path with "/foo/bar/".
when file path is sent from client (/foo/bar/baz/qux.lua), path will be removed (baz/qux.lua) and a file with this relative path will be searched in your buildpath.
when file path is sent from server (baz/qux.lua), path will be add (/foo/bar/baz/qux.lua) and the absolute path will be sent to the client ''
The problem is that you could set only one path.
The path comparison is case sensitive (even on windows).
On windows, you should prefix your path with "/" (e.g. /C:/foo/bar/)
In all case, if file is not found in the workspace, the source code is sent via the DBGp protocol
The dynamic code is not supported, it means that any code that is loaded with load, loadstring will not be supported. The debugger will step over it just like a C function.
The debugger is officially supported for Lua VM 5.1. Any other implementation (Lua 5.2, LuaJIT, ...) is not guaranteed to work at this time.
![]() |
![]() |
![]() |
Concepts | Updating This Document |