On Wed, Feb 3, 2010 at 8:48 AM, Fabio Mascarenhas <
mascarenhas@acm.org> wrote:
> Hi,
> I can add a compile-time option to Rings to replace the current
> initialization (just a call to luaL_openlibs) with anything you want, so you
> could define a function like
> static void myapp_initializestate(lua_State *L) {
> luaL_openlibs(L);
> /* do stuff with loaders, preload etc. */
> }
> and then compile rings with -DRINGS_INITIALIZE=myapp_initializestate. What
> do you think?
> --
> Fabio Mascarenhas
>
>
> On Tue, Feb 2, 2010 at 9:07 AM, Папенков Николай <
papenkov@t-i-l.ru> wrote:
>>
>> Ok, thanks for fast reply. I forget to say preferred solution would be the
>> one that do not modify source code neither Lua itself nor Rings, for example
>> using only their public API. Anyway, I get the idea of your solution. There
>> are chances that it'll be a base for our solution.
>>
>> It seems to me that non-standard Lua loaders written in C is not
>> comaptible with Rings without some form of 'source code hacking'. Am I
>> right? Is this by design?
>>
>> On 02.02.2010 14:20, Wesley Smith wrote:
>>>
>>> We solved this problem in our app by providing a function to init
>>> package.preload Every slave state created by rings gets this run on
>>> it and consequently has access to all of the C Lua modules embedded in
>>> our app. To make this more concrete, here's the code that gets run on
>>> every state:
>>>
>>> void luaav_install_modules(lua_State * L) {
>>>
>>> std::map<std::string, lua_CFunction>::iterator it;
>>>
>>> // main libs:
>>> for (it = mainmodules.begin(); it != mainmodules.end(); it++) {
>>> const char * name = it->first.c_str();
>>> lua_CFunction func = it->second;
>>> lua_pushcfunction(L, func);
>>> lua_pushstring(L, name);
>>> if (lua_pcall(L, 1, 1, 0))
>>> printf("loadlib error: %s", lua_tostring(L, -1));
>>> lua_settop(L, 0);
>>> }
>>> lua_settop(L, 0);
>>>
>>> // opt libs:
>>> for (it = optmodules.begin(); it != optmodules.end(); it++) {
>>> const char * name = it->first.c_str();
>>> lua_CFunction func = it->second;
>>> lua_getglobal(L, "package");
>>> lua_getfield(L, -1, "preload");
>>> lua_pushcfunction(L, func);
>>> lua_setfield(L, -2, name);
>>> lua_settop(L, 0);
>>> }
>>> lua_settop(L, 0);
>>>
>>> }
>>>
>>> On Tue, Feb 2, 2010 at 4:05 AM, Папенков Николай<
papenkov@t-i-l.ru>
>>> wrote:
>>>
>>>>
>>>> Hello, list!
>>>>
>>>> That's the problem we are facing some time ago.
>>>>
>>>> Some time ago we decided to embed Kepler in Windows application to
>>>> provide
>>>> web access to it. We embedded Kepler sources (and all dependencies) as
>>>> resources in the application. To support loading such modules from
>>>> resources
>>>> we supply new loader which replace standard loaders. That loader written
>>>> in
>>>> C because it uses WinAPI to access resources in executable.
>>>>
>>>> And this is where the problem arise. Slave Lua states, which created by
>>>> Rings, do not have our loaders. That's breaks loading of needed modules
>>>> for
>>>> slave state.
>>>>
>>>> Is there any means to put new loader in slave state? That's not a
>>>> problem if
>>>> loader written in Lua. Is it possible to transfer 'package.loaders'
>>>> table
>>>> from master state to a slave state? Any solution or workaround?
>>>>
>>>> Thanks in advance, and sorry for English )
>>>>
>>>> P.S. It'll be very sorry if we must change from Kepler to anything
>>>> else...
>>>>
>>>>
>
>
