ide:ExecuteCommand() weirdness

[sduensin]

First, feel free to tell me this isn't your problem...

I'm continuing to work on my plugin to integrate ZB with my Singe game engine. Remote debugging of Singe games works fine if I launch Singe myself from the command line. When launching it via ide:ExecuteCommand() it produces the following:

-------------------------------------------------------------------------------
./Singe-v2.10-Linux-x86_64 -l 0 -k -x 800 -y 600 -d data -v Singe/menuBackground.mkv Test/Sprite.singe

error loading module 'socket.core' from file '/opt/zbstudio/bin/linux/x64/clibs/socket/core.so':
    dynamic libraries not enabled; check your Lua installation
-------------------------------------------------------------------------------

I THINK what is happening is that Singe is attempting to load LuaSocket dynamically from the ZB installation... Which it shouldn't because it's linked to Singe statically and should be automatically "loaded" via a searcher that is in Singe.

Is there anything in the ZB environment that would cause this? Can I prevent it? Am I totally wrong with what is happening?

Thanks for any insight you can provide.

[pkulchenko]

I agree that it is indeed strange, as I'd expect the statically compiled executable to use the library that is compiled in instead of trying to resolve the links dynamically.

The only difference between launching outside of the IDE and from it is that the environment variables are set differently. Can you try running wx.wxUnsetEnv('LUA_CPATH') before calling ExecuteCommand? It will have to be restored after the call, so it's working for other calls, but it will allow you at least to check if it helps with this issue or not.

[sduensin]

That was the secret! I'll dig some more to see if I can change the behavior of Singe to make more sense, but for now, that fixed it.

Thank you!

[sduensin]

For anyone reading this later, here's how I finally really fixed it...

My embedded Lua instance and it's embedded modules used the searcher code I found here:

https://leiradel.github.io/2020/03/01/Embedding-Lua-Modules.html

That adds the new searcher to the end of the package searcher table. I modified the code to put it at the head:

    // Get the package global table
    lua_getglobal(L, "package");
    // Get the list of searchers in the package table
    lua_getfield(L, -1, "searchers");
    // Get the number of existing searchers in the table
    length = lua_rawlen(L, -1);
    // Shift existing elements to make room for ours
    for (i=length+1; i>1; i--) {
        lua_rawgeti(L, -2, i - 1);
        lua_rawseti(L, -2, i);
    }
    // Add our own searcher to the front of the list
    lua_pushcfunction(L, luaSearcher);
    //lua_rawseti(L, -2, length + 1);
    lua_rawseti(L, -2, 1);
    // Remove the seachers and the package tables from the stack
    lua_pop(L, 2);

[pkulchenko]

@sduensin, that's an interesting approach; thank you for sharing! I would have simply used https://www.lua.org/manual/5.4/manual.html#luaL_requiref, but, as described in the post, it's a good way to solve this problem (by only loading what's actually used).