Robert Gabriel Jakabosky

This can't be fixed without some type of change to how LuaJIT searchs for libraries when ffi.load("zmq") is called.

this issue should be fixed now with the removal of directly loading the libzmq.so file from the FFI bindings.

This is an issue with luvit. Luvit needs to provide some way to get the module's full path when the module is loading: https://github.com/luvit/luvit/pull/37#issuecomment-3063364

It looks like those are only provided to Lua modules not C modules. The C module needs it's path/filename during this call: https://github.com/luvit/luvit/blob/master/lib/luvit.lua#L229 The lua-zmq module is C module that...

I have created a new pull request to luvit that puts a place-holder value in the package.loaded table before C modules are intialized. https://github.com/Neopallium/luvit/pull/1 That 'shim' wrapper script would require...

oops, somehow I messed up that pull request, here is the correct one: https://github.com/luvit/luvit/pull/57 Also I will be travelling for the rest of this month so I will not be...

Just pushed an update to the path detection logic the will make zmq work with the latest luvit code (see commit luvit/luvit@6c596f48).

The second call to ffi.load() is required on Windows since it is not possible to access the symbols from libzmq.dll through zmq.dll For the time being use your patch to...

Could use a feature flag. A lot of games will most likely be using `bevy_rapier` already. I think it would be a nice feature for this library. I haven't worked...

Sorry there isn't a parser for C/C++ headers. The `.nobj.lua` files are hand written. The main benefit of using LuaNativeObjects is that it can generate most of the C code...