LUA_USERSTATE

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

LUA_USERSTATE

Jim Mathies-2
So after using this a little and also in lea of the discussion on
libraries - wouldn't a functional interface be a better
solution? One that can accept multiple user contexts referenced
by id? I'm also having to include lstate.h so I can reference my 
user context. (I'm using the first work release) 

as an alternate solution - for example:

id = lua_setuserctx( L, (void*) p );

p (mycontext*) = lua_getuserctx( L, id );

and in the state structure something like:

#define MAXUSERCTX 10

lua_State {
..
void* userctx[MAXUSERCTX];
};

Jim




Reply | Threaded
Open this post in threaded view
|

RE: LUA_USERSTATE

Nick Trout-4
> So after using this a little and also in lea of the discussion on
> libraries - wouldn't a functional interface be a better
> solution? One that can accept multiple user contexts referenced
> by id? I'm also having to include lstate.h so I can reference my 
> user context. (I'm using the first work release) 
> 
> as an alternate solution - for example:
> 
> id = lua_setuserctx( L, (void*) p );
> 
> p (mycontext*) = lua_getuserctx( L, id );
> 
> and in the state structure something like:
> 
> #define MAXUSERCTX 10
> 
> lua_State {
> ..
> void* userctx[MAXUSERCTX];
> };


Ooop, sorry I didnt get this the first time I read it but after thinking
about your previous post, I can see what you're talking about!!

I think something like this is more flexible.

id = lua_registercontext(L);
lua_setcontextdata(L,id,data);

...

data = lua_getcontextdata(L,id);

Nick

Reply | Threaded
Open this post in threaded view
|

RE: LUA_USERSTATE

Roberto Ierusalimschy-5
> > So after using this a little and also in lea of the discussion on
> > libraries - wouldn't a functional interface be a better
> > solution? One that can accept multiple user contexts referenced
> > by id? [...]
> >
> > id = lua_setuserctx( L, (void*) p );
> >
> > p (mycontext*) = lua_getuserctx( L, id );
> >

What about this?

  lua_pushuserdata(L, p);
  id = lua_ref(L);
  ...
  lua_getref(L, id);
  p = (mycontext*)lua_touserdata(L, -1);


Too slow?

-- Roberto


Reply | Threaded
Open this post in threaded view
|

RE: LUA_USERSTATE

Curt Carpenter
In reply to this post by Jim Mathies-2
> I think something like this is more flexible.
>
> id = lua_registercontext(L);
> lua_setcontextdata(L,id,data);
>
> ...
>
> data = lua_getcontextdata(L,id);

What's wrong with:

    class MyData
    {
    public:
        SomeType GetData(SomeType id);
        void SetData(SomeType id, SomeType data);
    Private:
        SomeDataStructure allthedata;
    };

    #define LUA_USERSTATE MyData mydata;
    
    ...
    
    L.mydata.SetData(id, data);
    
    ...
    
    Data = L.GetData(id);
    
? 

Or of course a struct instead of a class for C users. I like the
ultimate flexibility the way it is.

Curt

Reply | Threaded
Open this post in threaded view
|

RE: LUA_USERSTATE

Nick Trout-4
In reply to this post by Jim Mathies-2
> What's wrong with:
> 
>     class MyData
>     {
>     public:
>         SomeType GetData(SomeType id);
>         void SetData(SomeType id, SomeType data);
>     Private:
>         SomeDataStructure allthedata;
>     };
> 
>     #define LUA_USERSTATE MyData mydata;
>     
>     ...
>     
>     L.mydata.SetData(id, data);
>     
>     ...
>     
>     Data = L.GetData(id);
>     
> ? 
> 
> Or of course a struct instead of a class for C users. I like the
> ultimate flexibility the way it is.


You're just wrapping whats there. How do you add more per library state data
at runtime?

N

Reply | Threaded
Open this post in threaded view
|

Re: LUA_USERSTATE

Jim Mathies-2
In reply to this post by Nick Trout-4
That looks great to me. Curious what the Lua authors think
of this?

Regards,
Jim


----- Original Message ----- 
From: "Nick Trout" <[hidden email]>
Subject: RE: LUA_USERSTATE


| > So after using this a little and also in lea of the discussion on
| > libraries - wouldn't a functional interface be a better
| > solution? One that can accept multiple user contexts referenced
| > by id? I'm also having to include lstate.h so I can reference my 
| > user context. (I'm using the first work release) 
| > 
| 
| I think something like this is more flexible.
| 
| id = lua_registercontext(L);
| lua_setcontextdata(L,id,data);
| 
| ...
| 
| data = lua_getcontextdata(L,id);
| 
| Nick
| 
| 


Reply | Threaded
Open this post in threaded view
|

Re: LUA_USERSTATE

Jim Mathies-2
In reply to this post by Roberto Ierusalimschy-5
If it involves a hash lookup, imho, yes. 

Your LUA_USERSTATE is already in there, and works, and
is useful. This was just a suggestion on a more user friendly 
interface to it. 

Regards,
Jim

----- Original Message ----- 
From: "Roberto Ierusalimschy" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Thursday, January 31, 2002 9:26 AM
Subject: RE: LUA_USERSTATE


| > > So after using this a little and also in lea of the discussion on
| > > libraries - wouldn't a functional interface be a better
| > > solution? One that can accept multiple user contexts referenced
| > > by id? [...]
| > >
| > > id = lua_setuserctx( L, (void*) p );
| > >
| > > p (mycontext*) = lua_getuserctx( L, id );
| > >
| 
| What about this?
| 
|   lua_pushuserdata(L, p);
|   id = lua_ref(L);
|   ...
|   lua_getref(L, id);
|   p = (mycontext*)lua_touserdata(L, -1);
| 
| 
| Too slow?
| 
| -- Roberto
| 
| 
| 


Reply | Threaded
Open this post in threaded view
|

RE: LUA_USERSTATE

Nick Trout-4
In reply to this post by Jim Mathies-2
> > You're just wrapping whats there. How do you add more per library
> state data at runtime?
> 
> Use a data structure that supports your needs, such as a stl::map.

I think Jim is suggesting that the default behaviour is changed as this
behaviour is required out of the box so extra libs can be easily added etc.

Regards,
Nick


Reply | Threaded
Open this post in threaded view
|

RE: LUA_USERSTATE

Curt Carpenter
In reply to this post by Jim Mathies-2
> You're just wrapping whats there. How do you add more per library
state data at runtime?

Use a data structure that supports your needs, such as a stl::map.

Curt

Reply | Threaded
Open this post in threaded view
|

Re: LUA_USERSTATE.. doesn't work

Jim Mathies-2
In reply to this post by Curt Carpenter
|         SomeDataStructure allthedata;
|     };
|     #define LUA_USERSTATE MyData mydata;
|     ...
|     L.mydata.SetData(id, data);
|     ...
|     Data = L.GetData(id);
| 
| Or of course a struct instead of a class for C users. I like the
| ultimate flexibility the way it is.
| Curt

The main problem is the required recompile of the Lua library to use
LUA_USERSTATE, and the fact that if your compiling more than one
external library that makes use of LUA_USERSTATE you run into
problems. I wouldn't consider this very flexible.

Speed in accessing the info is needed (in some cases) because your 
usually accessing the custom state info on every wrapper callback. 

Now in thinking about it, i see a problem with the id as a reference
method, since where would you store the id when your programming 
context (non-static data) libraries!   arrgh.

The only thing I can come up with is :

#define myid 1 (in the header so it can be changed)

lua_setcontextdata(L,myid,data);
...
data = lua_getcontextdata(L,myid);

and the state has 10 or so default spaces for contexts. this seems a bit 
too complex though. hmm. :/ Maybe  LUA_USERSTATE is the best,
but not perfect solution...

Regards,
Jim




Reply | Threaded
Open this post in threaded view
|

Re: LUA_USERSTATE.. doesn't work

Thatcher Ulrich
On Jan 31, 2002 at 10:54 -0600, [hidden email] wrote:
> |         SomeDataStructure allthedata;
> |     };
> |     #define LUA_USERSTATE MyData mydata;
> |     ...
> |     L.mydata.SetData(id, data);
> |     ...
> |     Data = L.GetData(id);
> | 
> | Or of course a struct instead of a class for C users. I like the
> | ultimate flexibility the way it is.
> | Curt
> 
> The main problem is the required recompile of the Lua library to use
> LUA_USERSTATE, and the fact that if your compiling more than one
> external library that makes use of LUA_USERSTATE you run into
> problems. I wouldn't consider this very flexible.

MHO: this is in the "bells and whistles" category for add-in modules;
most modules don't need a LUA_USERSTATE.  Ones that really do can use
a Lua table lookup instead, at some run-time cost.  If this proves to
be a practical problem, then we revisit it, after we have a working
standardized module system.

Premature optimization being the root of all evil, and all...

-- 
Thatcher Ulrich <[hidden email]>
http://tulrich.com

Reply | Threaded
Open this post in threaded view
|

RE: LUA_USERSTATE.. doesn't work

Curt Carpenter
In reply to this post by Jim Mathies-2
> The main problem is the required recompile of the Lua library to use
LUA_USERSTATE, and the fact that if your compiling more than one
external library that makes use of LUA_USERSTATE you run into problems.
I wouldn't consider this very flexible.

Yeah, that's true. It doesn't really bother me, but I can see how it
would bother some people. 

> Speed in accessing the info is needed (in some cases) because your 
> usually accessing the custom state info on every wrapper callback. 

Well, yeah, agreed, that's why letting the host app manage it ensures
that the app can optimize it how it likes, which Lua can't do in a
general way for all desired forms of user data.

Curt