Setting up Lua Development Tools with Koneki, for local development

Recently, while looking for a better Lua IDE I tried the Lua Development Tools by the Koneki project. The Koneki project focusses on machine-2-machine (M2M) development and hence does not yet support local run and debug configurations. With a support link to some helpful pages (which didn’t work straight away), I fiddled around a bit and got it working through the ‘external tools’ workaround, though still with some quirks. Also not sure it all works as it should, especially adding command line parameters is something I’ll be needing to fix still.

[ad name=”468×60 Banner”]

Here’s how to set it up (on Windows that is, but with some scripting also on other platforms);

  1. Download and install the standalone version (that’s what I used)
  2. Start it and create a simple new project called ‘test’; menu File > New > Lua project
  3. Create a new external tool config; menu Run > External Tools > External Tools Configurations…
  4. On the left pane right-click ‘Program’ and select New, then configure it as follows;
  5. Obviously, ‘Location’ should point to your local Lua VM
  6. Now add a statement to your test project; print(“Hello world”) and click the ‘External Tools’ button and select ‘lua_run’ as configured in step 4.
    IMPORTANT: you must first select ‘main.lua’ in the script explorer or you’ll get an error;
  7. You should now see “Hello world” in the console window


[ad name=”468×60 Banner”]

Now that’s for running a Lua script directly, so how about debugging? The debug features go through a network connection to a remote device (or ‘localhost’), but it will require the script to be running with the Lua debugger modules loaded. So I created a batch file to do this.

  1. Download the debugger files (DBGP client) and store them in a folder ‘luadebug’ inside the directory where Eclipse is installed, for example; “C:\Program Files\EclipseLDT\debuglua”
  2. Download this batch file (downloaded 1227 times) and store it in the same directory as the debugger files
  3. Create another ‘external tool’ config as detailed above, with the following settings;
  4. The path to the Lua VM is now in the ‘Arguments’ pane, so make sure it is correct for your local Lua VM.
  5. Add a debug configuration via menu; Run > Debug configurations…
  6. Configure it with the following settings;
  7. Start the debugger by selecting ‘lua_debugger’ from the debug button drop-down;
  8.  Then start the application by selecting ‘lua_debug’ from the ‘External Tools’ button;
  9. The application will start with the debugger module loaded, it will connect to the debugger GUI within Eclipse.

In the debug configuration, a batch file is used. The batch file takes two parameters; a) path to the Lua VM, b) path to the debug target. The batch file will run the following steps;

  1. update the LUA_PATH environment variable such that the debugger modules will be in the search path
  2. start the Lua VM and initially execute the debugger modules
  3. then start the target Lua script
  4. after exiting it will restore the LUA_PATH variable

This approach prevents me from having to add the debugger code to the actual code. Though it is a windows batch file, it should be easy to port it to other platforms.

What’s to be improved still;

  • start debugger and debug target with a single click
  • allow for adding command line parameters to the target
  • having some sort of default start file, instead of manually having to select the correct file before starting it
  • the debugger requires a link to a specific project in its setup, so probably a specific setup is required per project (haven’t tested that yet)
  • the batch file does not support setting the remote debugger IP, port or IDE key, so it always uses the defaults (, 10000, luaidekey)

I’m interested in solutions to these, so if you find one let me know…

[ad name=”468×60 Banner”]


8 thoughts on “Setting up Lua Development Tools with Koneki, for local development

  1. Nice one Thij, this worked a treat. Only difference I had was to move the .bat file and debugger.lua files into my installed lua directory which would be something like C:\Program Files (x86)\Lua\5.1\lua. This probably works out as a better long term solution as well I guess in case there are any sneaky upgrades to Eclipse. The ‘nice to fix’ things you mentioned, I’ll have a look at for sure. Straight up it’s slightly annoying to debug + debug command to make it all start but it seems eclipse is good at some of those little annoyances. Well done, thanks again!

  2. I experienced an error it says Variable references empty selection: ${container_loc} what does that mean and how do I fix it.

    • See item 6 in the first list above (right where it says IMPORTANT); did you select the ‘Script explorer’ panel and within that the actual code file? It must have focus or else you’ll get an error like that.

  3. Hi Thijs!

    I appreciate your post but I do have an issue perhaps you can resolve. Everything works up until the Step 9 of the debugger portion.

    At that part I get this error:

    C:\Program Files (x86)\Lua\5.1\lua.exe: …clipse-SDK-4.2.1-win32\eclipse\luadebug\debugger.lua:1542: Cannot connect to : connection refused

    stack traceback:
    [C]: in function ‘error’
    …clipse-SDK-4.2.1-win32\eclipse\luadebug\debugger.lua:1542: in function
    (command line):1: in main chunk
    [C]: ?

    Do you have any insights?
    Thank you

    • What version did you use. Iirc I recently read an announcement that the latest version can do local debugging straight out-of-the-box. So this blog post would not be necessary anymore.
      Have you checked their documentation on how to do it?

  4. I actually read that comment and attempted it as well. I am using the very latest milestone (and I also tried “nightly”) version of LDT with the latest version of Eclipse. I also installed the latest version of Lua for Windows.

    It does not debug or run straight out of the box and their documentation is not particularly in depth. I did post on the Koneki forums though. We shall see if any insights come of it.


Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe without commenting