Early results of Lua 5.4.4 with Tecgraf's CD/IM/IUP toolkit...

[sur-behoffski <sur_behoffski@...>]

G'day,

I'm slowly working towards an 0.1-alpha5 release of my Assistant
to Assist running PUC-Rio's Tecgraf's scientific toolkit on a
number of GNU/Linux distributions.

The project (lglicua) is hosted on SourceForge, but there's a
big gulf between the last version (0.1-alpha4) and the
not-yet-released alpha5.

--

I've worked around a "number versus integer" glitch in CD's
line primitive:  In Lua 5.1, it coerces a "number" (double)
to integer; in Lua 5.3, a "number" that is not exactly an
integer causes the toolkit (CD; others?) to throw an exception.

--

I've upgraded LuaRocks from 3.7.0 to 3.8.0.  This version is
very good at having multiple Rocks trees, coded by Lua
version.  This means that the following code can be used to
switch to a new Lua+LuaRocks+Assistant Rocks profile:

    install$ ./i lua-install 5.4
    install$ ./i lua-select 5.4
    install$ ./i luarocks-install

However, this is insufficient to make some Lua-based changes
to the Assistant database, so instead of:

    install$ ./i lua-select 5.4 ; ./i luarocks-install

the installation provides a "force" command to do everything:

    install$ ./i lua-environment-force 5.4 CONFIRMATION
    install$ ./i reboot-now

(CONFIRMATION is "fer-real":  This hopefully reduces the
chances of inadvertent loss of valuable past
additions/deletion/changes to project data, since, in order
to reduce chances of incorrect code causing mayhem.)

(We access the relevant Lua rocks tree via the LUA_PATH and
LUA_CPATH environment variables, which are set during startup
in /dec/profile.d/17-LuaRocks-3.8.x-LUA_PATH-and-LUA_CPATH.sh:
Rebooting ensures all parties use the latest profile.)

--

For the Ubuntu (Debian?)-family distributions, I've moved towards
having Lua compiled and installed from source, rather than rely
on the package manager (almost all of which do not have entries
for Lua 5.4).

--

I'm currently working on a number of Red Hat distributions,
notably CentOS-7, CentOS-8, CentOS-8-Stream-8.5.2111, and
Rocky 8.5.  HOWEVER, CentOS-7 has Lua 5.1 (5.1.4+patches)
baked-in, and all the remainder are CentOS-8 variants, which
have Lua 5.3 (plus patches?) baked-in.

I'm concerned that many tools may assume that the baked-in
version is present, and (e.g. geeqie) fail to load, due to
an incompatible Lua dynamic shared-object version.  This may
end up letting the Assistant and the toolkit to operate, but
requiring a separate (virtual) machine due to the disruption.

--

My testing has not been comprehensive:  I've just run a
two-line "hello-world" Lua script, plus "cdpdf.lua" that
demonstrates how programmable code can be used to generate
non-trivial graphics in a PDF document.

The systems I've tried, with Lua 5.4.4, are:

- Ubuntu:
    - 18.04.3
    - 21.04

- Linux Mint:
    - 18.3
    - 19.3
    - 20.2
    - 20.3

- MX Linux:
    - MX21ahs

LM20.3 is a new release.  I've chosen to add MX Linux,
as it's popular, and my understanding is that it is 
ultimately descended from Ubuntu (or at least, Debian),
and derivatives of this family tree are generally
well-understood.

--

So, the main take-away at this stage is that Lua 5.4.4 looks
to be solid within the Assistant+Tecgraf framework, and this
is the first time any 5.4 version has been tried "in anger".

cheers,

sur-behoffski (Brenton Hoff)
programmer, Grouse Software