lua design thoughts

[Mattn]

cool - awesome. I only wonder what the binary is we need for that and whether this binary works everywhere (tm) - or whether we have to compile it from somewhere on our own. (because we of course would not push the generated boilerplate code to the git repo but generate it as a pre-build step).

[xray]

SWIG is open source and binaries are available for various platforms, among these various linux distro's and windows. Also the SWIG website makes mention that it is part of several linux distro's so if you're using linux as development platform it is probably already available.

[Mattn]

so we should add that as pre-build-step to the codeblocks projects and put the binary into https://github.com/ufoai/ufoai.codeblocks

I will take care of the Makefile based-build system once we merge the pull request.

[xray]

so we should add that as pre-build-step to the codeblocks projects and put the binary into https://github.com/ufoai/ufoai.codeblocks

I will take care of the Makefile based-build system once we merge the pull request.

Actually, I was quite pleased to see that the GNU compiler definition in CodeBlocks already recognizes the SWIG .i file and correctly launches the corresponding rule. Check out the compiler settings, then go to the advanced settings and in the file extension drop down, select the .i extension.

[xray]

A new design thought. About renaming. The process of exposing ufo's C functions to lua will force you to use the C naming scheme inside lua. So typically you'll end up writing lua code like this:

Code: [Select]

function myLuaCode ()
    local msg = "hello, I'm a lua string"
    ufoai.Com_Printf("lua: %s\n", msg)
    ...
end

Now for the given example, the result might be okay. However this will also apply to structures (e.g. uiNode_t), enums, constants. Everything will have the original C naming. Now SWIG has the option to rename an identifier in the process. So there is an option to rewrite the above sample to:

Code: [Select]

function myLuaCode ()
    local msg = "hello, I'm a lua string"
    ufoai.print("lua: %s\n", msg)
    ...
end

This will make the code more in line with the lua syntax. As a side benefit, the code gets another layer isolating it from changes in the C API which is always a good idea. Of course the price to pay is having a more complex SWIG interface file, since each identifier being exposed has to be renamed.

[xray]

Following up on the question:

i've checked your branch a little bit - can you explain how this swig stuff will work for us? what is needed in order to generate the bindings and stuff like that?

As it turns out, the default usage of SWIG is to provide a lua script access to a C program. This is not what I had in mind. Like the lua integration for the AI, I wanted to call from the C program into a specific lua function. More to the point: I want to call a lua function in a script that, using C functions, creates uiNode_t nodes and then returns this structure back to the C program. Technically this is called embedding and the hard part is because the returned value isn't a primitive value.

SWIG has some utility functions, however they where located in the generated .cpp file. That is, until I finally figured out how to get to these functions without actually copying the signature into my own header. Luckily the guys building SWIG have added an option to expose the utility functions using a generated header file. To do this, call once:

Code: [Select]

swig -c++ -lua -external-runtime swig_lua_runtime.h

The generated header file can now be used to convert values, wrapped by SWIG and passed on into lua, back to the original C values. I've attached a zip-file with a test project showing how this is done. The line above is attached as a prebuild step.

I'm posting the description to make sure it is documented for the future, since it took me really some time to figure this out.

xray

[Mattn]

great. i will keep that in mind when doing the makefile based buildsystem for that stuff.

about the renaming: yes, please hide the c api

[Mattn]

I've researched a little bit on swig and co - https://github.com/vinniefalco/LuaBridge looks cool, too.

Headers-only: No Makefile, no .cpp files, just one #include!

[xray]

I've researched a little bit on swig and co - https://github.com/vinniefalco/LuaBridge looks cool, too.

Yes, I've looked at that one too. Also checked out ooLua and toLua++. All tools have their pro's/con's. However in my opinion SWIG has two major advantages over the other tools:
1. Multiple targets. So if, in the future, we decide to skip with lua and replace it by something else we can reuse the interface files to generate the new binding.
2. Again multiple targets. This makes the tool more attractive to a broader user group. So the tool will be better tested, has more support etc.

Anyway, these were my thoughts.

xray

[Mattn]

awesome. it wasnt meant as a replacement, not even a suggestion for ufoai. i have no clue about swig or any other binding lib because i havent done anything with them. so dont give anything on my oppinion about this topic

[xray]

One small step...

I've managed to set the basic framework for lua embedding. It is now possible to create a .ufo script containing lua code. The lua code is then loaded. In the code it is possible to register a function with ufo that is called after the direct loading by lua. The intended use is that this function will be responsible for creating a ui-node tree. So in future, a typically lua ui script will look like this:

Code: [Select]

--!usr/bin/lua

.. code you write to support creating the ui node tree ..
 
function my_awesome_ui_create_function ()
  -- ufo.print is actually calling Com_Printf(..)
  ufo.print("inside onload callback: this function should return a ui node tree to ufo\n")
end

-- here we register the function "my_awesome_ui_create_function" as a callback
ufoui.register_onload (my_awesome_ui_create_function)


Up to now, creating nodes is not yet possible, only writing to the log window is possible. But it's a start. You can check out the progress on http://github.com/rxadmin/ufoai.

xray

[Mattn]

awesome. i will check it out. thanks a lot.

[xray]

Just back from a vacation, added a small but significant step to the code. I've actually managed to create a window in lua and open it from the main ui (using old style scripting).

In lua the window was created using the following code (see: test_lua.ufo)

Code: [Select]

function load ()
ufo.print("inside test_lua.ufo: calling load\n")
-- create a window node with name 'lua_test'
local w = ufoui.create_window ("window", "lua_test", nil)
-- return the window node to the game
return w
end

In the main.ufo (old style) a test button was added that popped the lua-created window.

Code: [Select]

button test
{
pos "190 720"
string "_Testing"
tooltip "_Testing ui lua integration"
size "70 20"
color "0 0.8 0 1"
selectcolor "1 1 1 1"
padding 0
onClick { cmd "ui_push lua_test;" }
}

Even though the window was empty, it is quite satisfying to see the old-style/new-style work together like this.
If you like details, check out http://github.com/rxadmin/ufoai.

xray

[Mattn]

awesome. thats cool. i will check it out

[Internecivus]

Looks promising.
Hope we'd have automatic convertor from old-style to new style