[PATCH] Lua: Improve LuaJIT / Lua 5.1 compatibility

[Christian Storm]

LuaJIT has defined luaL_newlib() which Lua 5.1 hasn't. However,
LuaJIT identifies itself as Lua 5.1. Hence, make luaL_newlib()
definition conditional.

Also introduce LuaJIT / Lua 5.1 compatibility for
luaL_checkversion() and
lua_rawlen().

Signed-off-by: Christian Storm <christi...@siemens.com>
---
include/lua_util.h | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/include/lua_util.h b/include/lua_util.h
index a38a735..1cefc88 100644
--- a/include/lua_util.h
+++ b/include/lua_util.h
@@ -31,7 +31,9 @@ int lua_notify_debug(lua_State *L);

#if !defined(LUA_VERSION_NUM) || LUA_VERSION_NUM == 501
#define LUA_OK 0
+#if !defined(luaL_newlib)
#define luaL_newlib(L, l) (lua_newtable((L)),luaL_setfuncs((L), (l), 0))
+#endif
void luaL_setfuncs(lua_State *L, const luaL_Reg *l, int nup);
void luaL_requiref(lua_State *L, char const* modname, lua_CFunction openf, int glb);

@@ -64,6 +66,9 @@ void luaL_buffinit(lua_State *L, luaL_Buffer_52 *B);

#define luaL_pushresult luaL_pushresult_52
void luaL_pushresult(luaL_Buffer_52 *B);
+
+#define luaL_checkversion(L) ((void)0)
+#define lua_rawlen(L, i) lua_objlen(L, i)
#endif

#else
--
2.28.0

[Stefano Babic]

Hi Christian,

On 24.09.20 10:51, Christian Storm wrote:
> LuaJIT has defined luaL_newlib() which Lua 5.1 hasn't. However,
> LuaJIT identifies itself as Lua 5.1. Hence, make luaL_newlib()
> definition conditional.
>
> Also introduce LuaJIT / Lua 5.1 compatibility for
> luaL_checkversion() and
> lua_rawlen().
>
> Signed-off-by: Christian Storm <christi...@siemens.com>

There is no problem to merge this, and I'll do. Anyway, I am asking if
it makes sense to try to remain compatible with LuaJIT, when this
project seems dead and it is still fixed to Lua5.1.

SWUpdate integrates itself the Lua interpreter, and this is updated (in
OE) form version to version. It is not very important that an update
must be very fast, it must be reliable, and the advantages to run a Lua
Script inside SWUpdate with the JIT compiler...well, I think they are
negligible.

So as I said, I will merge this: but does it makes sense to maintain
compatibility to LuaJIT ? Are there use cases ?

Regards,
Stefano

> ---
> include/lua_util.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/lua_util.h b/include/lua_util.h
> index a38a735..1cefc88 100644
> --- a/include/lua_util.h
> +++ b/include/lua_util.h
> @@ -31,7 +31,9 @@ int lua_notify_debug(lua_State *L);
>
> #if !defined(LUA_VERSION_NUM) || LUA_VERSION_NUM == 501
> #define LUA_OK 0
> +#if !defined(luaL_newlib)
> #define luaL_newlib(L, l) (lua_newtable((L)),luaL_setfuncs((L), (l), 0))
> +#endif
> void luaL_setfuncs(lua_State *L, const luaL_Reg *l, int nup);
> void luaL_requiref(lua_State *L, char const* modname, lua_CFunction openf, int glb);
>
> @@ -64,6 +66,9 @@ void luaL_buffinit(lua_State *L, luaL_Buffer_52 *B);
>
> #define luaL_pushresult luaL_pushresult_52
> void luaL_pushresult(luaL_Buffer_52 *B);
> +
> +#define luaL_checkversion(L) ((void)0)
> +#define lua_rawlen(L, i) lua_objlen(L, i)
> #endif
>
> #else
>


--

=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[James Hilliard]

On Thu, Sep 24, 2020 at 3:40 AM Stefano Babic <sba...@denx.de> wrote:
>
> Hi Christian,
>
> On 24.09.20 10:51, Christian Storm wrote:
> > LuaJIT has defined luaL_newlib() which Lua 5.1 hasn't. However,
> > LuaJIT identifies itself as Lua 5.1. Hence, make luaL_newlib()
> > definition conditional.
> >
> > Also introduce LuaJIT / Lua 5.1 compatibility for
> > luaL_checkversion() and
> > lua_rawlen().
> >
> > Signed-off-by: Christian Storm <christi...@siemens.com>
>
> There is no problem to merge this, and I'll do. Anyway, I am asking if
> it makes sense to try to remain compatible with LuaJIT, when this
> project seems dead and it is still fixed to Lua5.1.

I wouldn't say having a project fixed to Lua5.1 means it's dead as it seems
rather common for projects to freeze the Lua ABI, for example redis does
this with their embedded Lua5.1.

>
> SWUpdate integrates itself the Lua interpreter, and this is updated (in
> OE) form version to version. It is not very important that an update
> must be very fast, it must be reliable, and the advantages to run a Lua
> Script inside SWUpdate with the JIT compiler...well, I think they are
> negligible.
>
> So as I said, I will merge this: but does it makes sense to maintain
> compatibility to LuaJIT ? Are there use cases ?

I can think of one for the buildroot case, currently buildroot only supports
a single Lua interpreter at any one time, so if another package being
built depends on LuaJIT swupdate can only be built with LuaJIT, at
least without first adding support for multiple Lua interpreters.

> --
> You received this message because you are subscribed to the Google Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to swupdate+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/swupdate/3d2b1641-4f81-467a-7242-9bf81deffc54%40denx.de.

[Christian Storm]

> > > LuaJIT has defined luaL_newlib() which Lua 5.1 hasn't. However,
> > > LuaJIT identifies itself as Lua 5.1. Hence, make luaL_newlib()
> > > definition conditional.
> > >
> > > Also introduce LuaJIT / Lua 5.1 compatibility for
> > > luaL_checkversion() and
> > > lua_rawlen().
> > >
> > > Signed-off-by: Christian Storm <christi...@siemens.com>
> >
> > There is no problem to merge this, and I'll do. Anyway, I am asking if
> > it makes sense to try to remain compatible with LuaJIT, when this
> > project seems dead and it is still fixed to Lua5.1.
> I wouldn't say having a project fixed to Lua5.1 means it's dead as it seems
> rather common for projects to freeze the Lua ABI, for example redis does
> this with their embedded Lua5.1.

It's not that dead anymore, see https://github.com/LuaJIT/LuaJIT with
lots of recent activity. I guess LuaJIT 2.1 is about to be pushed out
eventually/finally. LuaJIT is actually a hybrid between Lua 5.1 and Lua
5.2 with some stuff from 5.2 but identifying itself as 5.1. This is why
it needs some special treatment for the 5.2 "backports"...

> > SWUpdate integrates itself the Lua interpreter, and this is updated (in
> > OE) form version to version. It is not very important that an update
> > must be very fast, it must be reliable, and the advantages to run a Lua
> > Script inside SWUpdate with the JIT compiler...well, I think they are
> > negligible.
> >
> > So as I said, I will merge this: but does it makes sense to maintain
> > compatibility to LuaJIT ? Are there use cases ?
> I can think of one for the buildroot case, currently buildroot only supports
> a single Lua interpreter at any one time, so if another package being
> built depends on LuaJIT swupdate can only be built with LuaJIT, at
> least without first adding support for multiple Lua interpreters.

This also applies to having multiple liblua{,jit}.so files lying around
for no good reason if you're bound to use LuaJIT for some particular use
case. I do agree that "JIT speed" is probably not the primary target for
SWUpdate's Lua usage. However, we do have a use case of using LuaJIT for
speed-sensitive workloads and then it's suggestive to also use it for
SWUpdate.

That said, I do think that keeping LuaJIT compatibility is not a lot
more effort on top than keeping Lua 5.1 compatibility. Granted, the most
testing and usage goes to the latest and greatest Lua versions (due to
OE version bumps) leaving older Lua versions (or LuaJIT for that matter)
a bit behind.
So as long as we do support Lua 5.1, I'm in favor of keeping LuaJIT
support as well ― within reasonable efforts ― even if it's not as well
supported as the latest and greatest Lua versions.


Kind regards,
Christian

--
Dr. Christian Storm
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Otto-Hahn-Ring 6, 81739 München, Germany

[Stefano Babic]

Thanks Christian and James - I am applying the patch.

Best regards,
Stefano