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

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
User avatar
pgimeno
Party member
Posts: 3672
Joined: Sun Oct 18, 2015 2:58 pm

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

Post by pgimeno »

modiX wrote: Thu Feb 15, 2018 12:16 am 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.
User avatar
zorg
Party member
Posts: 3468
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

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

Post by zorg »

It won't be faster just because it's compiled / dumped using any method.
Me and my stuff :3True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
User avatar
raidho36
Party member
Posts: 2063
Joined: Mon Jun 17, 2013 12:00 pm

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

Post by 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.
User avatar
Marty
Citizen
Posts: 89
Joined: Mon Dec 04, 2017 1:47 am
Location: Germany

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

Post by Marty »

pgimeno wrote: Thu Feb 15, 2018 12:29 am 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.
raidho36 wrote: Thu Feb 15, 2018 6:43 am 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 ....
zorg wrote: Thu Feb 15, 2018 12:54 am It won't be faster just because it's compiled / dumped using any method.
raidho36 wrote: Thu Feb 15, 2018 6:43 am 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.
Visual Studio Code TemplateRichLÖVE Mobile (AdMob+UnityAds+PlayGamesServices+GameCenter)Add me on Discord

───▄▀▀▀▄▄▄▄▄▄▄▀▀▀▄───
───█▒▒░░░░░░░░░▒▒█───
────█░░░░░░░░░█────
▄▄──█░░░▀█▀░░░█──▄▄
█░░█▀▄░░░░░░░▄▀█░░█
User avatar
raidho36
Party member
Posts: 2063
Joined: Mon Jun 17, 2013 12:00 pm

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

Post by 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
Prole
Posts: 29
Joined: Sun Sep 13, 2015 4:10 pm

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

Post by 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.
User avatar
raidho36
Party member
Posts: 2063
Joined: Mon Jun 17, 2013 12:00 pm

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

Post by 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.
User avatar
slime
Solid Snayke
Posts: 3166
Joined: Mon Aug 23, 2010 6:45 am
Location: Nova Scotia, Canada
Contact:

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

Post by slime »

coffeecat wrote: Fri Feb 16, 2018 3:43 am 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
Prole
Posts: 29
Joined: Sun Sep 13, 2015 4:10 pm

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

Post by coffeecat »

slime wrote: Fri Feb 16, 2018 9:51 pm 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! :)
Post Reply

Who is online

Users browsing this forum: Amazon [Bot], Bing [Bot] and 6 guests