Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LuaJIT support? #56

Open
happen23 opened this issue Oct 9, 2014 · 8 comments
Open

LuaJIT support? #56

happen23 opened this issue Oct 9, 2014 · 8 comments
Labels

Comments

@happen23
Copy link

happen23 commented Oct 9, 2014

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

@Rapptz
Copy link
Owner

Rapptz commented Oct 9, 2014

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 Rapptz added the question label Oct 9, 2014
@happen23
Copy link
Author

happen23 commented Oct 9, 2014

So could you add the LuaJIT support in sol?

@Rapptz
Copy link
Owner

Rapptz commented Oct 9, 2014

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

@ThePhD
Copy link
Contributor

ThePhD commented Oct 30, 2014

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
Copy link
Contributor

ThePhD commented Oct 30, 2014

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
Copy link
Contributor

ThePhD commented Oct 30, 2014

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

@ghost
Copy link

ghost commented Nov 29, 2014

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.

@ThePhD
Copy link
Contributor

ThePhD commented May 25, 2015

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants