Re: Lua compatibility between versions 5.1 and 5.3 -- using LuaRocks

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: Lua compatibility between versions 5.1 and 5.3 -- using LuaRocks

[As always, sorry for not threading... digest mumble mumble.]

[ All the stuff is GNU/Linux based -- your Windows(R) mileage may
vary....  I do not have a Windows environment to test on...]

[I haven't checked any of this with Lua 5.4.x, sorry.]

I've come up with the following "standard incantation" that relies
on the LuaRocks std.normalize and std.strict:

1. Each script brings in its Rocks (mostly following the documentation):

        -- Use rocks to (a) Normalize Lua 5.1/5.2/5.3 version differences; and
        -- (b) Do some simple dynamic checking of variable references.
        local _ENV   = require("std.normalize"){}
        local strict = require("std.strict")

        -- [...] require other things; I load standard libraries (e.g.
        -- "debug", "io", "math", "os", "string", "table" etc into local
        -- variables, to document which libraries I use, and also to fit in
        -- with "std.strict").

2. I make the scripts smart about being executed from the command shell,
   versus being invoked as a chunk loaded by another script:


        -- "Global" constants: Args, ScriptName and ShellInvocation.
        -- (Note also Lua-provided "arg".)
        local Args
        local ScriptName
        local ShellInvocation
        Args = {...}
        ScriptName = debug.getinfo(1, "S").short_src
        ShellInvocation = ScriptName == arg[0]

In particular, if the first argument of "{...}" is not a string (e.g. a
table), then we know we've been invoked from another script.  The
boolean flag ShellInvocation reports this distinction concisely -- arg[0]
will be the name of the first-run script from the shell, and ScriptName
will be the filename of the chunk.  If loadfile() is used, and the
resulting chunk is executed, they differ.

This is very handy for debugging:  I can have a project database for
a family of Subversion repositories (e.g. the Tecgraf projects
IM, ftgl, pdflib7, CD and IUP... the five projects spread over the
IM/CD/IUP SourceForge repositories), and load them either from a
single control script, or load them directly via "svn-checkout.lua".
The command-line version currently allows the user to specify the
revision (useful for "bisect"ing a commit that introduces a defect), or
the default is the repository HEAD.  (The specific revision can be a
parameter for at least the shell invocation, e.g.

        $ ./svn-checkout.lua iup r5820

Where the first argument is a string, the script knows to independently
load the database... otherwise the database is exchanged between the
parent chunk and the child chunk, quite possibly with changes flowing
in each direction.


Hope this helps,

s-b etc etc