Re: Writing extensions which interact (is not fun)

[Doug <douglas.linder@...>]

Oh, thats a very clever idea.

It's fairly high impacting on the lua code though... hm...

I'm definitely going to experiment with creating a xlua library,
consisting of something along the lines of:

1) xlua.h with struct xlua_State { lua_State *L; struct { ... //
pointers }; } containing function pointers to all the public api
functions.

2) xlauxlib.h with a series of functions:

  xlua_getglobal(struct xlua_State *L, name);

3) xlua_setup(lua_State *L)

   That can be invoked as a minimal-impact change to the host
application, attaches the function pointers and
   then binds the new xlua_State instance to the global table as [xlua].

My extension can link against its own copy of lua, and a its own copy
of xlua; it uses the lua code only once, in read-only mode, to read
the userdata xlua_State object (which would have to be passed to the
extension manually at least once; like:

  x = require("blah")
  x.init(_G['xlua'])

...but the actual application code uses the xlua_* function set to do
things, the implementation of which runs the function pointer; which
should point to the correct symbol in the host application.

Not sure if that'll work... but it's certainly the best suggestion
I've had so far. Thanks!

cheers,
Doug.

On Sun, Aug 5, 2012 at 2:19 AM, Thomas Harning Jr. <harningt@gmail.com> wrote:
> On Aug 4, 2012 7:10 AM, "Carsten Fuchs" <carsten.fuchs@cafu.de> wrote:
>>
>> Am 2012-08-04 11:12, schrieb Doug:
>>>
>>> Binding everything up and statically linking the extension to the
>>> binary does seem to be the only way to make it work properly.
>>> [...]
>>>
>>> Deeply frustrating to work with.
>>
>>
>> Exactly my experience, too.
>>
>> It would help if Lua kept no internal static state, but it seems that the
>> real problem is that DLLs under Windows and SOs under Linux (my main
>> platforms, can't say much about others) are different enough so that
>> "portable" support in an advanced application/setting for both is very
>> problematic.
>> Especially "mixing" is difficult: Linking everything statically or linking
>> "everything" dynamically seems to work out relatively naturally, but linking
>> the main application statically and using DLLs/SOs only for
>> extensions/"plugins" comes with an astonishing number of platform-specific
>> differences, and it is very hard to deal with all of them combined.
>>
> One thing that I have done in the past is to alter Lua such that its
> functions were all lumped into a function table in the "extra space" behind
> the Lua state pointer. A set of altered headers were used by extensions that
> I needed to dynamically link in.
> This made it so that no matter what method by which the Lua state came into
> existence, all external code could get a handle on the same codebase running
> the VM. Though of course all extensions to use it required being built with
> the special headers. It also solves the potential problems that could arise
> if you wrote an extension for some other software and didn't want to
> possibly have symbol/dll-naming collision problems.
> Someday I may set out to construct an open-source project to do this ... But
> it’s not on my schedule at the moment.