Lua Update
#1
I talked about this in a different thread, but how wise is it to update Lua?

Advantages
Disadvantages
  • Parts of more advanced plugins may break
  • Is tolua++ compliant?
  • Is the lua API same enough for our purposes?
  • More?
Reply
Thanks given by:
#2
The Lua's C API has changed a bit, too, and we'd need someone to actually evaluate whether those changes break anything or not.
Reply
Thanks given by:
#3
With my extensive knowledge of the Lua C API (/sarcasm) I managed to make it compile, but it crashes directly afterwards :| I also had to do allot of things manualy copying a x86 version of tolua++ so that Visual Studio would actualy continue compiling.
Reply
Thanks given by:
#4
I'd say that if we are going to update lua we should also look at replacing tolua++. At the moment we basically have to maintain it ourselves and it is not setup to handle more modern c++. Updating lua would necessitate that we rewrote the library and I suspect it would be less work to just replace it.
Unfortunately there isn't much that could replace it that uses a similar style of parsing headers so I suspect the easiest option would be to use a template based library like https://github.com/SteveKChiu/lua-intf . Transferring would be tough but I suspect the APIDump plugin could be used to generate the initial definition files.
Reply
Thanks given by:
#5
There's one feature of ToLua that will be quite difficult to achieve in other libraries: overloaded functions. We use that mostly for constructors (cItem()), but for normal functions as well (cEntity:SetSpeed()). I haven't found any info in lua-intf about whether it supports overloads or not, I suspect it doesn't.

EDIT: I've looked through the lua-intf code and I'm now pretty sure it doesn't support overloads.
Reply
Thanks given by:
#6
I forgot to check that and by the looks of that library doesn't support it. That causes problems as I couldn't find a library that meets all our criteria so we would have to build our own or modify an existing library. The template approach has trouble with overloads but it might be feasible to modify a template library to support it. Otherwise we might want to take something like SWIG and add support for lua 5.3, though SWIG in particular has some license issues that would cause problems with our current library distribution approach.
Reply
Thanks given by:
#7
Here are links to the changes in the C API between Lua 5.1 and 5.2, and here are the they between 5.2 and 5.3
Reply
Thanks given by:
#8
Well for a start we'd have to patch tolua's libs, as it depends on LUA_GLOBALSINDEX which was removed in 5.2. So we'd be completely supporting our own version of tolua. So how do people feel about maintaining a c++ parser Smile.
Reply
Thanks given by:
#9
Why don't we export the plugin interface for plugins written in c++? The loader would then take dynamic libraries and execute the code inside.
Reply
Thanks given by:
#10
Because if I want to create a plugin I don't want to compile it for Windows, Linux, Linux ARM, etc.
Reply
Thanks given by:




Users browsing this thread: 7 Guest(s)