sol icon indicating copy to clipboard operation
sol copied to clipboard

LuaJIT support?

Open happen23 opened this issue 11 years ago • 8 comments

LuaJIT (a lot of uses) is Lua 5.1 syntax and API interface compatible, could sol support it ?

happen23 avatar Oct 09 '14 01:10 happen23

It doesn't seem like LuaJIT is 100% API compatible with Lua 5.2 according to this page. I could be wrong though. If LuaJIT is API compatible with it, i.e. #include <lua.hpp> and all the luaL_* and lua_* functions work as expected then I don't see why it wouldn't support it. However it seems like LuaJIT is 100% 5.1 only with a thin 5.2 compatibility layer.

Rapptz avatar Oct 09 '14 02:10 Rapptz

So could you add the LuaJIT support in sol?

happen23 avatar Oct 09 '14 08:10 happen23

Dropping down to Lua 5.1 would be a massive pain, unfortunately.

Rapptz avatar Oct 09 '14 09:10 Rapptz

I haven't finished building against the latest LuaJIT yet, but they have a flag for 5.2 compatibility that might allow sol to build since we don't make use of _ENV or setenv, which is one of the biggest splits / gripes between the two C APIs.

The more glaring issue, however, is that it seems like LuaJIT doesn't support GC on tables, only on userdata and friends. All of the magic we do in sol to make sure there's no memory leaks is predicated on user data, but I'd need to go through the codebase to make sure we don't end up in the situation displayed here.

ThePhD avatar Oct 30 '14 16:10 ThePhD

The compiler errors say that we would need to figure out the Lua 5.1 equivalents of the following:

lua_tounsigned
luaL_setfuncs
luaL_requiref
lua_rawlen

unsigned, we can replace with a raw cast to unsigned from double (hacky, but it will work just fine). luaL_setfuncs is somewhat replacable by luaL_openlibs (I think) luaL_requiref, I'm not sure what the analogous is there... (@Rapptz, any ideas?) lua_rawlen, we can probably swap out for a less useful length function that invokes metamethods (lua_objlen, lua_len)

The following built-in libraries would be missing and thus unopenable for lua:

bit32 -- luaopen_bit32
coroutines -- luaopen_coroutine

LuaJIT has the first one built on, so that should be #ifdef'd out, and the second one can be replaced by Coco, but quite honestly I would rather just #ifdef that one out as well and let users manually pick the library of their choice to require and use with lua.

We'd also need to figure out how to replace LUA_RIDX_GLOBALS for luajit to be happy with getting the global table (is this what _ENV was for?).

ThePhD avatar Oct 30 '14 17:10 ThePhD

Ultimately, however, my recommendation would be to wait for Mike Pall to update LuaJIT to work with 5.2 and upcoming 5.3.

ThePhD avatar Oct 30 '14 17:10 ThePhD

If you are really interested in supporting 5.1, I would suggest looking into the compatability files for lua-intf by @SteveKChiu. Specifically, this and this.

ghost avatar Nov 29 '14 10:11 ghost

@SkyMarshal @happen23 This took a while, but the pull requests referencing this issue has LuaJIT 5.1 support. Once it's evaluated by @Rapptz it should be good to go.

Good luck.

ThePhD avatar May 25 '15 01:05 ThePhD