sur-behoffski
unread,Feb 5, 2026, 7:09:11 PM (5 days ago) Feb 5Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to lua-l
G'day,
Not surprisingly, some Rocks are not compatible with Lua 5.5. I don't
know if there's a program to decide yes/no/maybe on support for
individual rocks.
The list I see is from my habitual use, which closely coincides with
the lglicua package.
The disruption I see is:
- std.normalise [no results matching...]
- std.strict [no results matching...]
- luaposix [dependency luabitop >= 1.0.2 fails...]
- bit32 [no results matching...]
---------------------
Part of the problem is that I've adopted a Lua-5.4-standard preamble,
which strives to allow me to switch between Lua-5.[1234] versions
quite easily, as long as I stay within a conservative subset of the
language features.
> -- Use rocks to (a) Normalize Lua 5.1/5.2/5.3/5.4 differences; and
> -- (b) Do some simple dynamic checking of variable references.
> local _ENV = require("std.normalize"){}
> local strict = require("std.strict")
> _ENV = strict.strict(_ENV)
> if rawget(_G, 'setfenv') ~= nil then -- If 5.1, use careful code.
> setfenv(1, _ENV)
> end
I recognise that the new global/local scoping mechanism, added as part
of Lua 5.5, affects things like std.strict.
---------------------
I require at least luaposix [needs luabitop >= 1.0.2] in order to work.
This is because I try to take a very, very restrictive stance in dealing
with shells and command invocation, trying to avoid "shell-special"
characters that might provide an opportunity for a malicious user to
manipulate a shell into performing unwanted actions.
----
I've been in contact with Hisham over the last couple of months, and he
has been helpful. However, I don't know the best protocol for dealing
with the entire database of Rocks supported by LuaRocks.
--
Thanks for reading this far!
best, b