Can you read Pascal Raymond? If so I think I have a sample on my drive
some place.
Another solution is to give each script a library name, thus instead of:
function OnClick()
you get:
function MyLib:OnClick()
You still have to make sure that the lib's don't have conflicting names,
but that easier then making sure that you don't have globals that get
re-used :)
- Jeremy
"Help I suffer from the oxymoron Corporate Security."
> -------- Original Message --------
> Subject: Re: Global variables, local functions?
> From: "Raymond Jacobs" <raymondj@gmail.com>
> Date: Mon, July 10, 2006 10:47 pm
> To: "Lua list" <lua@bazar2.conectiva.com.br>
>
> David,
>
> Hmm, I need to do this all from C, I looked into a few functions, such as
>
> lua_newtable, lua_setfenv
>
> but it is all really confusing, I don't suppose you could be a bit
> more specific as to how I would do this in C?
>
> Thanks,
> -Raymond
>
> On 7/10/06, David Morris-Oliveros <david.morrisoliveros@teambondi.com> wrote:
> > This is the basic pseudo code is below:
> >
> > (the_thread == stack index index of lua_newthread())
> >
> > newmetatable = {}
> > newmetatable.__index = _G
> > threadtable = {}
> > threadtable._G = _G
> > threadtable._THIS = this
> > threadtable._THREAD = the_thread
> > setmetatable ( threadtable, newmetatable )
> > _G._THREADS[this] = threadtable
> > setfenv( the_thread, threadtable )
> >
> >
> > Raymond Jacobs wrote:
> > > David,
> > >
> > > That sounds like a plan, could you 'or anyone else' elaborate on how I
> > > would do the following 'im still pretty new to lua'.
> > >
> > > so how can i create a new table, and add _G to it, which points to the
> > > 'true' global environment, and then how do I set this new table as the
> > > co-routines environment.
> > >
> > > some sample code, or a list of the functions I need to investigate
> > > would be really helpful.
> > >
> > > Thanks again =)
> > >
> > > -Raymond
> > >
> > > On 7/10/06, David Morris-Oliveros <david.morrisoliveros@teambondi.com>
> > > wrote:
> > >> First of all, sorry about the chaotic email, it's still too early in the
> > >> morning for me :)
> > >>
> > >> You can try sandboxing the coroutine. That's what we do in our game.
> > >> Each coroutine gets it's own environment, but still with access to the
> > >> global env.
> > >>
> > >> You create a table, whose metatable is the global global, and set that
> > >> to be the local global's table, with an explicit entry to _G. That way,
> > >> you can create local and global stuff:
> > >>
> > >> local really_local_variable = 1
> > >> local_variable = 1
> > >> _G.global_variable = 1
> > >> function local_function () end
> > >> function _G.global_function () end
> > >>
> > >> Also, if you set the local global's metatable to be the global global,
> > >> you get everything else for free. That is, you can access all the
> > >> functions and variables defined in the global global as if they where
> > >> local:
> > >>
> > >> _G.fibonacci(5)
> > >> fibonacci()
> > >>
> > >> would be the same call (as long as you haven't created a new fibonacci()
> > >> function in you local global).
> > >>
> > >> From C, you can obtain the local global and then call the function by
> > >> name within that local global.
> > >>
> > >> We keep a table with all of these things:
> > >>
> > >> _G._THREADS = {}
> > >>
> > >> I then add each local global to that table using the C's substate
> > >> pointer's numerical value as key. That way it's easy to extract the
> > >> local global from C, and then call whatever.
> > >>
> > >> This way, you can easily set global variables ( _G.var = value ), or
> > >> local ones (but still have access to them from outside), and all will be
> > >> cleaned up on coroutine exit, because "local" functions exist only
> > >> within the local global table.
> > >>
> > >> Raymond Jacobs wrote:
> > >> > Hey all,
> > >> >
> > >> > In our game we utilize a single Lua_State, and create a co routine
> > >> > (initialized with the main lua_state) for each other script we run.
> > >> >
> > >> > It is great that the variables we create in these other scripts remain
> > >> > global and accessible from any other script we run, however, we run
> > >> > into this problem:
> > >> >
> > >> >
> > >> > if we load 'scriptA.lua' which contains the function onClick()
> > >> >
> > >> > and later load 'scriptB.lua' which doesn't contain an onClick()
> > >> > function, the previous onClick function still remains.
> > >> >
> > >> > so in short, when we run a script (through a co-routine) we would like
> > >> > to start a clean slate as far as functions are concerned, but we still
> > >> > want to be able to access all of the global variables we've created.
> > >> >
> > >> > now, i noticed it is seemingly valid to create functions with the
> > >> > 'local' prefix on them, to me this sounds like what we need (so that
> > >> > the functions don't get embedded into the global area) however I can't
> > >> > figure out how to call a local function from C (all of our co-routine
> > >> > creation, script loading, and function calling happens from C).
> > >> >
> > >> > I am pretty sure someone has run into this issue before, any help
> > >> > would be appreciated.
> > >> >
> > >> > Thanks for your time,
> > >> > Raymond Jacobs
> > >> > Owner,
> > >> > Ethereal Darkness Interactive
> > >> >
> > >>
> > >> --
> > >>
> > >> // david morris-oliveros
> > >> // camera & lua coder
> > >> // david@teambondi.com
> > >>
> > >>
> > >
> >
> > --
> >
> > // david morris-oliveros
> > // camera & lua coder
> > // david@teambondi.com
> >
> >
