Re: merging lua files

[Jim Jennings <jennings.durham.nc+lua@...>]

On Sat, 3 Jul 2010 14:42:40 +0200, Valerio Schiavoni
<valerio.schiavoni@gmail.com> wrote:

> I wonder how this tool behaves if the imported modules are native libraries.

While squish might or might not solve your problem, it was designed to
do so.  And I don't know how to answer your concerns about line
numbers or native libraries.

You have not specified very many constraints on acceptable solutions,
so if you do some research on Lua, you may find a variety of
approaches in addition to those already offered on this list.

In general, re-using the same vm to run independent 'jobs' can expose
you to a surprising number of ways in which one piece of Lua code can
interfere with another.  This is due to Lua's greatest strength (imo)
which is that it allows you to modify how it works (metatables,
environments are tables, get/setfenv, loadstring, package.*, etc.).
If you must re-use the same vm for many jobs, you should consider
locking down the Lua environment in which each job runs, in order to
create a predictable final state when one job finishes and you are
ready to start another.

I have a need for isolation (non-interference) between modules and
'main' programs alike, so I wrote a layer on top on Lua's module
system to provide this.  See http://lua-users.org/wiki/JimJennings for
information and source code (pure Lua) for the Darwin module system.
You get to control what access is granted to each Darwin module.  And
if you grant access to, e.g. _G (or any module), then your code
accesses a COPY of _G, so it cannot interfere with other code.

And your code does not have to be written in any special way at all to
be used as a Darwin module.  Just write a simple module descriptor
that references your files of code, and Darwin will load your code
into its own isolated environment.  When your code is finished, you
can delete the module in which it was running, and all of its
resources will be garbage collected.

Jim