gdr_LuaState

OZApps

Is there a way that @Atilim could offer us developers a handle to the lua_State that Gideros works with? Plug-ins can allow us to register the functions with a Lua module or the global, would it be possible to get the lua_state maybe when the

gdr_initialize

is called? so that standard functions can be added without using a plug-in.

I know @ar2rsawseen, that why not use a plug-in when it can be; that would be your question. The answer to which is there is a lot of overhead that goes with a plug-in, including the require statements, etc. where as if there was a lua_State that was used by Gideros, we could simply add a couple of functions directly without the code overheads and initialize, de-initialize etc.

The plug-in method works perfectly fine for now.

ar2rsawseen

@OZApps, actually I don't think you need that much of a plugin to get a Lua state in the C part. All the other boiler plate code is only to properly handle events in Lua and create proper classes, etc.

But if you only need it on C part, all you have to do is to create dummy.c (or dummy.mm if you are going to use objective C) inside Plugins directory (might also work in some main existing files, I have not tried), with these contents:

static lua_State *L = NULL;   static void g_initializePlugin(lua_State *L) { ::L = L; }   static void g_deinitializePlugin(lua_State *L) { ::L = NULL; }   REGISTER_PLUGIN("DummyPlugin", "1.0")

and then when you will be using it, just check if it is not NULL

OZApps

@ar2rsawseen, it will also require the

luaL_register(L, "string", table);

and the actual function to register.

If we could get the Lua State using something like gdr_getLuaState() or something then all it would require is just a couple of lines to add some stuff to the Lua state in the

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions

I am creating a minimal plug-in, but just discussing the options...

ar2rsawseen

@OZApps sorry I don't understand.

You can obtain the lua state in the way I've showed in the example and use the same code you would have used in application didFinishLaunchingWithOptions. I don't see the difference

Additionally it would logically divide your code (separating mini plugin from main code source, for better reuse)

If you need reference to main application or root view, you can obtain it using:

//main application [UIApplication sharedApplication]; //root view controller g_getRootViewController();

or do any Objective-C compliant messaging stuff

but maybe I misunderstand something, so please clarify

OZApps

@ar2rsawseen,
The point where we are off tangent is that I am trying to avoid a plug-in architecture and instead of an additional file am trying to place everything in the appdelegate.m itself.

can we have initializePlugin in the appdelegate.m? I thought that was to support a plug-in architecture only.

there is nothing wrong in having a plug-in separate .mm file or a .c file. however there are issues in compiling and distributing and then using these compiled static libraries with the app. (separate question -> Want to write up a simple way to convert a .mm file with tit's non-specific code into a library that can be added to the app while compiling the final app.)

ar2rsawseen

So you want to extend Gideros functionality without the plugin architecture. Ok

Well something like g_getLuaState won't work, because lua state may change over the time, that is why g_initializePlugin and g_deinitializePlugin provide the way to keep track of valid Lua context

If you ask if you can use it in AppDelegate file, probably yes, but I haven't tried. Only as you will be mixing c and ios you should rename it .mm file and add needed headers