Re: multiple global contexts

["Dylan Cuthbert" <dylan@...>]

Your example 2 seems the best bet, I could get my job despatcher to
re-configure the global space.

Unfortunately though, I need to create access to all libraries again in that
global space don't I?  or at least the libraries I want the user to be able
to access.  I suppose that prevents common script writers having access to
all that nasty "rawget" stuff though which is good.  I could create a
cleaner wrapped library and put some kind of handle into the default
"global" space per object.

What's the overhead for that kind of "setting up" of a variable list? (if
the objects already exist elsewhere in the system I presume its not that
costly)

Cheers

---------------------------------
Q-Games, Dylan Cuthbert.
http://www.q-games.com


Nick Trout Rote:
--------------------------------- Example 2 ------------------------

Now we move into "foospace". Here we create our global variable space
"vars" and a function getg to control access. We first look in our
"local global" space for our variable and then fall back on the real
global space if a variable isn't found there (i.e. "return
rawget(vars,n) or rawget(_G,n)")

g = 1

function foospace()
    local vars = { g=100 }
    local getg = function(t,n) return rawget(vars,n) or rawget(_G,n) end
    local foo = function ()
        local a = 1
        g2 = 200 -- new global
        while a<=3 do
            print('co', a, g, g2)  -- output
            coroutine.yield()
            a = a+1
            g = g+1
        end
    end
    setfenv(foo, setmetatable(vars, { __index=getg }))
    foo()
end

co = coroutine.create(foospace)
while coroutine.resume(co) do
end
print(g,g2) -- see if global scope changed.


Output is:
co 1 100 200
co 2 101 200
co 3 102 200
1 nil  -- ie. We didn't touch the real global scope.

You can pretty much set up any environment you could imagine really. The
great thing is you can create function to create your coroutine and it
returns it tailored to its use. You could restrict creation of new
objects using __newindex. I'm pretty new to setfenv() since it's not
really been in the scope of our project. So using the above style you
wouldn't need multiple lua_States - which may or may not be a
disadvantage. We're using one lua_State for each (mutually exclusive)
"mission" which allows easy tidy up and the mission shouldn't really be
affecting the global world state - and if so you should know about it.

I've been working on a tutorial. Hope the following material is useful:
http://lua-users.org/wiki/MetamethodsTutorial
http://lua-users.org/wiki/ObjectOrientationTutorial

and more generally:

http://lua-users.org/wiki/TutorialDirectory


> Also, if this is possible, what kind of overhead (memory
> footprint/creation
> time) does the lua_state structure have? (I presume I'll need
multiples of
> these)

They're quite small. I don't know what's more efficient, multiple
lua_States or one lua_State with multiple coroutines. One might be more
memory efficient and the other less computationally expensive?

> Bear in mind this stuff might be in the documentation and I just
haven't
> got
> there yet, be kind with me. :-)

Have a look at the tutorial and if there's anything missing give me a
shout.

Nick