add table created by lua_bundle to namespace

[kedorlaomer]

The name is @@@. Therefore, the table doesn't pollute the namespace
unless the programmer deliberately uses _ENV["@@@"] for his own
values.

This facility is helpful for interoperability with luaproc:
Every thread can decide to receive some or all values values from this table
and load them to access
functionality otherwise only available to the main thread.

Questions:

• Can this be implemented in a better or more generic way?
• Specifically, should one add a switch to enable or disable this feature?
• Or to choose the variable name?

[ers35]

Please give a code example of using this table with luaproc.

[kedorlaomer]

The main thread has a pure lua module module:

-- file module.lua
local M = {}
function M.some_function(arg1, arg2)
-- do something cool
end

return M

We load this module as module = require "module" and compile its source via luastatic into the bundle.

Now, several of my threads might want to use it, e. g. a function g that will later be called as luaproc.newproc(g).

function g()
-- oh no, how do I get access to `module`?
end

So we need to load the string representation of module:

local module_source = _ENV['@@@'].module
g = function() -- this is closed over the environment, can access module_source
    local module = load(module_source)()
    module.some_function("foo", "bar)
end

Caveats:

1. This could also be implemented by dumping (via string.dump) all functions from module, although constants need to be dumped in a different way. Of course, the solution via _ENV['@@@'] is a bit more elegant.
2. This doesn't work for C functions.

I am actually using the patched version in an internal project (which I will gladly point to once it's not too embarassing).

[kedorlaomer]

For future searches: There's a somewhat ugly solution for C functions. In luaproc/luaproc.c, there's a function luaproc_openlualibs where additional C libraries can be registered. (Sorry for spamming this issue.)