Awesome: incompatibility with lua5.4

[multiSnow]

Lua 5.4 was released on 29 Jun 2020.

math.randomseed should be integer in lua5.4, which is g_random_int() + g_random_double() in awesome.c, cause luaA_panic:

...
2020-06-30 10:48:28 W: awesome: luaA_panic:860: restarting awesome
2020-06-30 10:48:28 W: awesome: luaA_panic:855: unprotected error in call to Lua API (bad argument #1 to 'math.randomseed' (number has no integer representation))
2020-06-30 10:48:28 W: awesome: luaA_panic:859: dumping backtrace
...

[bittin]

Had this problem too and fighted for 2 hours and had to downgrade lua to get my wm working

[psychon]

Since #3124 is just about making AwesomeWM work with Lua 5.4: Anyone wants to do the work of adding Lua 5.4 to Travis CI?

[actionless]

do the work of adding Lua 5.4 to Travis CI?

i can do, but i dunno which testsuites (and other env vars) to choose to be running for that setup

[psychon]

Well... you could start from what was done in .travis.yml before b67e0a123cb2c013f6b4665cb6030717a1463422 (back then, we built Lua 5.3 ourselves on Travis).
Most of that is "to get things working". -ULUA_COMPAT_5_2 is to disable compatibility, so that more things break which would otherwise only break later. Same for -DLUA_USE_APICHECK -Dlua_assert=assert: Enable as many consistency checks as possible to find bugs.

Anyway, testing AwesomeWM with Lua 5.4 is blocked by LGI working on Lua 5.4. I don't know what the state there is (but I would expect things not to work out of the box due to API changes in lua...?

[actionless]

you right, @psychon , while luarocks is working:

Configuring LuaRocks version 3.0.4...

Lua interpreter found: /usr/bin/lua

Checking if /usr/bin/lua is Lua version 5.4... yes

lua.h found: /usr/include/lua5.4/lua.h

lgi is failing to build:

gcc -fPIC  -O2 -fPIC -I/usr/include/lua5.4 -pthread -I/usr/include/gobject-introspection-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -Wall -Wextra -O2 -g -c -o callable.o callable.c

callable.c: In function ‘closure_callback’:

callable.c:1237:13: error: too few arguments to function ‘lua_resume’

       res = lua_resume (L, NULL, npos);

             ^

In file included from lgi.h:11:0,

                 from callable.c:12:

/usr/include/lua5.4/lua.h:300:15: note: declared here

 LUA_API int  (lua_resume)     (lua_State *L, lua_State *from, int narg,

               ^

https://github.com/awesomeWM/awesome/pull/3127

https://travis-ci.com/github/awesomeWM/awesome/jobs/357360445

[alerque]

@actionless Luarocks‌ 3.3.1 works better where Lua 5.4 is involved.

[Aire-One]

Hello,

After facing these issues in the last few months, I found (nearly) all the places where we should update the lua interpreter reference to use lua5.3 instead of the default lua installed (which is lua5.4 on archlinux btw).

Unfortunately, I run a git rebase and reseted by local repo because I wanted it clean... So I removed all my changes, including fixes for lua version... To not make this error again, I wrote a script to apply all the necessary changes to make awesome buildable and tests runnable. You can find it as a gist at https://gist.github.com/Aire-One/d14bad0f4b22d86b829baea18b7ae6ed 🎉

BTW, I remember @psychon said he was working on a separate branch to make Awesome work with lua5.4. Is there any update on this? (https://github.com/awesomeWM/awesome/pull/3127)

[psychon]

I remember @psychon said he was working on a separate branch to make Awesome work with lua5.4.

Huh? Sorry, but I definitely did not do anything in that direction. Before I try to make AwesomeWM with Lua 5.4, I'd first make LGI work properly and I gave up on https://github.com/pavouk/lgi/issues/247.

After facing these issues in the last few months, I found (nearly) all the places where we should update the lua interpreter reference to use lua5.3 instead of the default lua installed (which is lua5.4 on archlinux btw).

Sounds like we need to accept something like a $LUA env var to decide which Lua version to use. (Or have a CMake option to configure the Lua interpreter and then pass this on to "everything" via such an env var.) Once upon a time I had the idea to build our own Lua interpreter and use that. That should make 100% sure that during build we use the same Lua version as awesome will be using at run time. However, CMake really does not want us to compile binaries at configure time and so this idea does not work.

[Aire-One]

I remember @psychon said he was working on a separate branch to make Awesome work with lua5.4.

Huh? Sorry, but I definitely did not do anything in that direction. Before I try to make AwesomeWM with Lua 5.4, I'd first make LGI work properly and I gave up on pavouk/lgi#247.

Oops! Sorry about that, I've probably over-interpreted what you said on this other discussion...

Sounds like we need to accept something like a $LUA env var to decide which Lua version to use. (Or have a CMake option to configure the Lua interpreter and then pass this on to "everything" via such an env var.)

It seems there is a start in this direction with the latest PR https://github.com/awesomeWM/awesome/pull/3279!

Once upon a time I had the idea to build our own Lua interpreter and use that. That should make 100% sure that during build we use the same Lua version as awesome will be using at run time. However, CMake really does not want us to compile binaries at configure time and so this idea does not work.

I think I'm missing something, but:

Why couldn't we have another build step to build the awesome lua interpreter (let's say alua)? The build of awesome would depend on the alua build step, and basically, that's done.

I mean, if we build our own lua version (alua), why should it be done at configure time?

However, I'm not sure of what would be involved in "build our own lua version for awesome". We would need to maintain it, I'm afraid it would be too much additional work...

[psychon]

Oops! Sorry about that

No problem. Sorry for giving up.

It seems there is a start in this direction with the latest PR #3279!

I didn't see that one yet. Nice.

why should it be done at configure time?

Because currently we already execute quite a lot of stuff at cmake configure time IIRC.

Hm, apparently we already moved some of that from cmake-configure-time to cmake-build-time. There are only four calls to execute_process and the only relevant one is in tests/example/CMakeLists.txt running the example tests. So only this one / these two cases are problematic.

There are also not many places running Lua at build time, it seems:

$ git grep COMMAND\ lua
awesomeConfig.cmake:        COMMAND lua ${SOURCE_DIR}/docs/06-appearance.md.lua
awesomeConfig.cmake:        COMMAND lua ${SOURCE_DIR}/docs/build_rules_index.lua
awesomeConfig.cmake:        COMMAND lua ${SOURCE_DIR}/docs/05-awesomerc.md.lua
awesomeConfig.cmake:        COMMAND lua ${SOURCE_DIR}/docs/sample_theme.lua ${BUILD_DIR}/script_files/
tests/examples/CMakeLists.txt:execute_process(COMMAND lua -e "p = package.path:gsub(';', '\\\\;'); io.stdout:write(p)"

Making the Lua interpreter to use configurable still sounds simpler.

We would need to maintain it, I'm afraid it would be too much additional work...

This just takes like 5 lines of code: Load the standard modules, for each command line tell Lua to execute that file, print something on errors. It would not be very complicated, but it would definitely be the same Lua version that we later run against.