luajit - attempt to index global 'love' (a nil value)

[pgimeno]

Problem is the luajit does not include love functions. Eventually I understood that luajit is somewhat embedded into LOVE, that's why string.dump can exist, too.

That doesn't matter for compiling the code. I've tested under linux:

Code: Select all

$ cat > main.lua
function love.draw()
  love.graphics.print("Hello, world!")
end

$ luajit -b main.lua main2.lua
$ mv main2.lua main.lua
$ love .

and the code runs. The reason for having LuaJIT is only to ease compilation, allowing it to be automated with batch files or the like. Maybe you manage to install two versions, in order to package for LJ 2.0 or 2.1 at will.

[zorg]

It won't be faster just because it's compiled / dumped using any method.

[raidho36]

The bytecode will not run faster - it's the same code as Lua generates when it loads source code file as normal. It may be parsed faster because it needs no text processing, however as a bigger file it takes more time to read its contents. In practice the difference will be marginal as the script loading times would be well within a fraction of a second. Just like with other types of compiled code, you will have to produce its own binaries for every single target platform and version you intend to support, and distribute them separately. Also I don't believe minor Lua versions are compatible either, as well as major versions. Lua bytecode is not defined and every implementaiton is free to generate whatever code it pleases (or none at all), so it can change without notice.

It won't.

Replacing dll's for the more efficient ones is a common practice, such as replacing openal32.dll by Creative to the ALsoft one. Linux and Mac do it automatically when new versions of dynamic linked libraries come out. By using bytecode you specifically make it impossible to do an upgrade this way. In case of Mac and Linux, the game will just break and won't work again, not without having user to compile old versions themselves and then also write launch scripts that override system libraries. Can't vouch for Mac, but on Linux you can do all-in-one distributions, however while isolated from system dependencies, it's prone to breakage the same way if any part of the OS changes and those are not Linux-friendly in general.

[Marty]

That doesn't matter for compiling the code. I've tested under linux:

Code: Select all

$ cat > main.lua
function love.draw()
  love.graphics.print("Hello, world!")
end

$ luajit -b main.lua main2.lua
$ mv main2.lua main.lua
$ love .

and the code runs. The reason for having LuaJIT is only to ease compilation, allowing it to be automated with batch files or the like. Maybe you manage to install two versions, in order to package for LJ 2.0 or 2.1 at will.

Using luaJIT by myself would be the best for batch processes indeed. That's why I wanted to go for that route in the first place. Besides the fact that I also have problems with loading the bc.save module (I got a solution, but hadn't time to apply it), it won't work for me, that's why this thread exists.

I was able to compile the game with luapower (pre-compiled luaJIT 2.1 with all modules), but this won't work on Windows, obviously. (I should test this in Mobile, later). But using my own compiled luaJIT 2.0 without bc.save will throw that error "attempt to index global 'love' (a nil value)".

That's surprising to me.

Replacing dll's for the more efficient ones is a common practice, such as replacing openal32.dll by Creative to the ALsoft one. Linux and Mac do it automatically when new versions of dynamic linked libraries come out. By using bytecode you specifically make it impossible to do an upgrade this way. In case of Mac and Linux, the game will just break and won't work again, not without having user to compile old versions themselves and then also write launch scripts that override system libraries. Can't vouch for Mac, but on Linux you can do all-in-one distributions, however while isolated from system dependencies, it's prone to breakage the same way if any part of the OS changes and those are not Linux-friendly in general.

Fortunately, I will focus on mobile games ....

It won't be faster just because it's compiled / dumped using any method.

The bytecode will not run faster - it's the same code as Lua generates when it loads source code file as normal. It may be parsed faster because it needs no text processing, however as a bigger file it takes more time to read its contents. In practice the difference will be marginal as the script loading times would be well within a fraction of a second. Just like with other types of compiled code, you will have to produce its own binaries for every single target platform and version you intend to support, and distribute them separately. Also I don't believe minor Lua versions are compatible either, as well as major versions. Lua bytecode is not defined and every implementaiton is free to generate whatever code it pleases (or none at all), so it can change without notice.

.... and on this point, compiling my mobile game became very unattractive to me. On mobile games it's packed into an APK / IPA, so it's not too trivial to read the source. For curiosity I will try to use luaJIT 2.1 to test at, tho. Thanks for that information.

[raidho36]

Note that JIT is disabled by default on mobile - on iOS it's because JIT violates AppStore policy, and on Android it's because often enough performance will be many times worse than in interpreted mode.

If you want to improve performance, there is a number of tricks you can employ. Use FFI C structs instead of normal Lua objects, use C arrays of C structs instead of Lua tables of C structs. Cache Lua table entries into local variables or upvalues. Avoid creating strings, especially with concatenation operator. Try to keep your hot data in the same small chunk of memory, try to make the program access data in sequential fashion in RAM. Avoid branching i.e. "while", "if", "and", "or" statements. In JIT mode, avoid using "next" and "pairs". Avoid creating new objects, try reusing old ones. Don't use the array length operator excessively, it is slow and is slower for larger arrays. There is probably more but I can't recall.

[coffeecat]

Bytecode as generated by LuaJIT string.dump() is portable:

The generated bytecode is portable and can be loaded on any architecture that LuaJIT supports, independent of word size or endianess. However the bytecode compatibility versions must match.

If you always bundle the LuaJIT library with your game (may require custom build of LOVE), bytecode compatibility is also not a problem.

Bytecode generation is usually part of distributing process, and does not incur any cost during actual game development. Actually one has a more serious problem with source level compatibility, e.g. Lua 5.1 is not compatible with Lua 5.2. As we are using LuaJIT, it's possible that we are stuck at Lua 5.1 (plus part of Lua 5.2 features) forever.

[raidho36]

Well it's a given that bytecode generated for Lua 5.1 will not work with Lua 5.2 either, so that's not really an argument.

As far as I'm concerned, Lua 5.2 or 5.3 didn't add anything that LuaJIT 5.1 doesn't have.

[slime]

Bytecode as generated by LuaJIT string.dump() is portable:

The generated bytecode is portable and can be loaded on any architecture that LuaJIT supports, independent of word size or endianess. However the bytecode compatibility versions must match.

If you always bundle the LuaJIT library with your game (may require custom build of LOVE), bytecode compatibility is also not a problem.

love must use LuaJIT 2.1 on iOS and Android, in order to support 64 bit devices. It uses LuaJIT 2.0 on desktops but you can swap it out for the 2.1 beta if you want.

luajit 2.1 bytecode that works with 64 bit ARM is incompatible with 2.1 bytecode that works with 32 bit, as far as I know. The page you're quoting from only pertains to LuaJIT 2.0 which didn't have this split (GC64 versus not).

[coffeecat]

love must use LuaJIT 2.1 on iOS and Android, in order to support 64 bit devices. It uses LuaJIT 2.0 on desktops but you can swap it out for the 2.1 beta if you want.

luajit 2.1 bytecode that works with 64 bit ARM is incompatible with 2.1 bytecode that works with 32 bit, as far as I know. The page you're quoting from only pertains to LuaJIT 2.0 which didn't have this split (GC64 versus not).

Thanks for the information!