Embedding Lua twice?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Embedding Lua twice?

Soni "They/Them" L.
Hi! Is there any way to have Lua 5.1 (actually LuaJIT) and Lua 5.2 (LuaJIT doesn't support _ENV) on the same program?
-- 
Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.
Reply | Threaded
Open this post in threaded view
|

Re: Embedding Lua twice?

Oliver Kroth
Hello Thiago,


Hi! Is there any way to have Lua 5.1 (actually LuaJIT) and Lua 5.2 (LuaJIT doesn't support _ENV) on the same program?

should be possible, as long as you wrap each interpreter into a module that hides its internal symbol references from the global name space.
Otherwise the linker will get confused when it tries to build your main program.

--
Oliver


Reply | Threaded
Open this post in threaded view
|

Re: Embedding Lua twice?

Soni "They/Them" L.

On 27/11/14 12:51 PM, Oliver Kroth wrote:
Hello Thiago,


Hi! Is there any way to have Lua 5.1 (actually LuaJIT) and Lua 5.2 (LuaJIT doesn't support _ENV) on the same program?

should be possible, as long as you wrap each interpreter into a module that hides its internal symbol references from the global name space.
Otherwise the linker will get confused when it tries to build your main program.
Uhh... what? (kinda C noob)

--
Oliver



-- 
Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.
Reply | Threaded
Open this post in threaded view
|

Re: Embedding Lua twice?

Oliver Kroth
Hi! Is there any way to have Lua 5.1 (actually LuaJIT) and Lua 5.2 (LuaJIT doesn't support _ENV) on the same program?

should be possible, as long as you wrap each interpreter into a module that hides its internal symbol references from the global name space.
Otherwise the linker will get confused when it tries to build your main program.
Uhh... what? (kinda C noob)

When a module is linked, all symbol references that are resolved within the files of the module, can be hidden, leaving only the unresolved ones visible (external references)
How this actually is commanded, depends on compiler / linker. ld does this with a version script.

--
Oliver


Reply | Threaded
Open this post in threaded view
|

Re: Embedding Lua twice?

Luiz Henrique de Figueiredo
In reply to this post by Soni "They/Them" L.
> Hi! Is there any way to have Lua 5.1 (actually LuaJIT) and Lua 5.2
> (LuaJIT doesn't support _ENV) on the same program?

I don't know about LuaJIT but you can have two versions of Lua in the
same program by building custom versions using one.c and a header file
that redefines all external symbols to have a different prefix, such
as lua51 and lua52. You'll need to compile your program modules with
the header files for each version. See this:
        http://lua-users.org/lists/lua-l/2014-07/msg00164.html

Reply | Threaded
Open this post in threaded view
|

Re: Embedding Lua twice?

Soni "They/Them" L.

On 27/11/14 06:24 PM, Luiz Henrique de Figueiredo wrote:
>> Hi! Is there any way to have Lua 5.1 (actually LuaJIT) and Lua 5.2
>> (LuaJIT doesn't support _ENV) on the same program?
> I don't know about LuaJIT but you can have two versions of Lua in the
> same program by building custom versions using one.c and a header file
> that redefines all external symbols to have a different prefix, such
> as lua51 and lua52. You'll need to compile your program modules with
> the header files for each version. See this:
> http://lua-users.org/lists/lua-l/2014-07/msg00164.html
>
Uhh so if I have some Lua .so's I can't dlopen them?

--
Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Embedding Lua twice?

Sean Conner
It was thus said that the Great Thiago L. once stated:

>
> On 27/11/14 06:24 PM, Luiz Henrique de Figueiredo wrote:
> >>Hi! Is there any way to have Lua 5.1 (actually LuaJIT) and Lua 5.2
> >>(LuaJIT doesn't support _ENV) on the same program?
> >I don't know about LuaJIT but you can have two versions of Lua in the
> >same program by building custom versions using one.c and a header file
> >that redefines all external symbols to have a different prefix, such
> >as lua51 and lua52. You'll need to compile your program modules with
> >the header files for each version. See this:
> > http://lua-users.org/lists/lua-l/2014-07/msg00164.html
> >
> Uhh so if I have some Lua .so's I can't dlopen them?

  Here's the issue:  you have foo.so, a Lua module.  You have your magic Lua
interpreter that manages to include both LuaJIT and Lua 5.2.  foo.so wants
to call the function lua_load().  LuaJIT, being compatible with Lua 5.1, has
lua_load() defined as:

        int lua_load(
                lua_State *L,
                lua_Reader reader,
                void *data,
                const char *source
        );

Whereas Lua 5.2 defines lua_load() as:

        int lua_load(
                lua_State *L,
                lua_Reader reader,
                void *data,
                const char *source,
                const char *mode
        );

The call to dlsym() is:

        void *dlsym(void *handle,const char *symbol);

(where handle is the result of dlopen()).  All that dlsym is given is
"lua_load".  That's it.  No other information (return type, parameters, etc)
is given, just the name "lua_load".  dlsym() will have to pick one, and
given the way linking works [1] (and assuming you get a program to link with
two different versions of the same function, which isn't impossible [2]) you
only stand a 50/50% chance of getting the right version of the function (or
a 50/50% chance of a core dump depending upon your outlook).

  -spc (And notice that I gave no indication of which Lua version foo.so was
        compiled against ... )

[1] For way more than you probably wanted to know about linking:      
                http://www.iecc.com/linker/

[2] The ELF executable format, used by most modern Unix systems, do
        allow for multiple versions of the same function, but there's some
        deep compiler and linker magic [1] required to get it working, and
        foo.so would need to be recompiled using said compiler and linker
        magic to even have a hope of working.

Reply | Threaded
Open this post in threaded view
|

Re: Embedding Lua twice?

Sean Conner
In reply to this post by Soni "They/Them" L.
It was thus said that the Great Thiago L. once stated:
> Hi! Is there any way to have Lua 5.1 (actually LuaJIT) and Lua 5.2
> (LuaJIT doesn't support _ENV) on the same program?

  I just realized that this question can be interpreted in two ways:

        1. Can I have a Lua interpreter that includes both LuaJit and Lua
           5.2?

        2. Can I write Lua code that runs under LuaJIT and Lua 5.2?

  The answers so far have been for #1, but for #2, it gets a bit klunky,
but:

        if _VERSION == "Lua 5.1" then
                if _G.jit then
                        -- do LuaJIT specific code
                else
                        -- do Lua 5.1 specific code
                end
        elseif _VERSION == "Lua 5.2" then
                -- do Lua 5.2 specific code
        else
                -- do Lua 5.3 specific code
        end

  -spc



Reply | Threaded
Open this post in threaded view
|

Re: Embedding Lua twice?

Soni "They/Them" L.
In reply to this post by Sean Conner

On 28/11/14 01:46 AM, Sean Conner wrote:

> It was thus said that the Great Thiago L. once stated:
>> On 27/11/14 06:24 PM, Luiz Henrique de Figueiredo wrote:
>>>> Hi! Is there any way to have Lua 5.1 (actually LuaJIT) and Lua 5.2
>>>> (LuaJIT doesn't support _ENV) on the same program?
>>> I don't know about LuaJIT but you can have two versions of Lua in the
>>> same program by building custom versions using one.c and a header file
>>> that redefines all external symbols to have a different prefix, such
>>> as lua51 and lua52. You'll need to compile your program modules with
>>> the header files for each version. See this:
>>> http://lua-users.org/lists/lua-l/2014-07/msg00164.html
>>>
>> Uhh so if I have some Lua .so's I can't dlopen them?
>    Here's the issue:  you have foo.so, a Lua module.  You have your magic Lua
> interpreter that manages to include both LuaJIT and Lua 5.2.  foo.so wants
> to call the function lua_load().  LuaJIT, being compatible with Lua 5.1, has
> lua_load() defined as:
>
> int lua_load(
> lua_State *L,
> lua_Reader reader,
> void *data,
> const char *source
> );
>
> Whereas Lua 5.2 defines lua_load() as:
>
> int lua_load(
> lua_State *L,
> lua_Reader reader,
> void *data,
> const char *source,
> const char *mode
> );
>
> The call to dlsym() is:
>
> void *dlsym(void *handle,const char *symbol);
>
> (where handle is the result of dlopen()).  All that dlsym is given is
> "lua_load".  That's it.  No other information (return type, parameters, etc)
> is given, just the name "lua_load".  dlsym() will have to pick one, and
> given the way linking works [1] (and assuming you get a program to link with
> two different versions of the same function, which isn't impossible [2]) you
> only stand a 50/50% chance of getting the right version of the function (or
> a 50/50% chance of a core dump depending upon your outlook).
>
>    -spc (And notice that I gave no indication of which Lua version foo.so was
> compiled against ... )
>
> [1] For way more than you probably wanted to know about linking:
> http://www.iecc.com/linker/
>
> [2] The ELF executable format, used by most modern Unix systems, do
> allow for multiple versions of the same function, but there's some
> deep compiler and linker magic [1] required to get it working, and
> foo.so would need to be recompiled using said compiler and linker
> magic to even have a hope of working.
>
So basically just use DBus or something?

--
Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Embedding Lua twice?

Andrew Starks
In reply to this post by Sean Conner

[1]     For way more than you probably wanted to know about linking:
                http://www.iecc.com/linker/



This is an excellent read, so far (chapter 2 and slow going).  Thank you for sharing this and if you have any more articles / posts like this that you want to share, please do! On or off list. 

-Andrew 
Reply | Threaded
Open this post in threaded view
|

Re: Embedding Lua twice?

Sean Conner
In reply to this post by Soni "They/Them" L.
It was thus said that the Great Thiago L. once stated:

>
> On 28/11/14 01:46 AM, Sean Conner wrote:
> >It was thus said that the Great Thiago L. once stated:
> >>On 27/11/14 06:24 PM, Luiz Henrique de Figueiredo wrote:
> >>>>Hi! Is there any way to have Lua 5.1 (actually LuaJIT) and Lua 5.2
> >>>>(LuaJIT doesn't support _ENV) on the same program?
> >>>I don't know about LuaJIT but you can have two versions of Lua in the
> >>>same program by building custom versions using one.c and a header file
> >>>that redefines all external symbols to have a different prefix, such
> >>>as lua51 and lua52. You'll need to compile your program modules with
> >>>the header files for each version. See this:
> >>> http://lua-users.org/lists/lua-l/2014-07/msg00164.html
> >>>
> >>Uhh so if I have some Lua .so's I can't dlopen them?
> >
> >Here's the issue:  you have foo.so, a Lua module.  You have your magic
> >Lua interpreter that manages to include both LuaJIT and Lua 5.2.  foo.so
> >wants to call the function lua_load().  LuaJIT, being compatible with Lua
> >5.1, has

  [ snip ]

> So basically just use DBus or something?

  DBus is a message-passing framework to allow arbitrary processes (that use
DBus) to communicate with each other using a variety of message passing
methods (one-to-one, one-to-many, etc).  I'm not sure how using DBus will
help you in having LuaJIT and Lua 5.2 in the same program.

  Aside from the "I want to use Lua 5.2 but with the speed of LuaJIT," what
problem are you tryting to solve where "Lua 5.2 and LuaJIT in the same
program" is the answer?

  -spc




Reply | Threaded
Open this post in threaded view
|

Re: Embedding Lua twice?

Soni "They/Them" L.

On 28/11/14 09:00 PM, Sean Conner wrote:

> It was thus said that the Great Thiago L. once stated:
>> On 28/11/14 01:46 AM, Sean Conner wrote:
>>> It was thus said that the Great Thiago L. once stated:
>>>> On 27/11/14 06:24 PM, Luiz Henrique de Figueiredo wrote:
>>>>>> Hi! Is there any way to have Lua 5.1 (actually LuaJIT) and Lua 5.2
>>>>>> (LuaJIT doesn't support _ENV) on the same program?
>>>>> I don't know about LuaJIT but you can have two versions of Lua in the
>>>>> same program by building custom versions using one.c and a header file
>>>>> that redefines all external symbols to have a different prefix, such
>>>>> as lua51 and lua52. You'll need to compile your program modules with
>>>>> the header files for each version. See this:
>>>>> http://lua-users.org/lists/lua-l/2014-07/msg00164.html
>>>>>
>>>> Uhh so if I have some Lua .so's I can't dlopen them?
>>> Here's the issue:  you have foo.so, a Lua module.  You have your magic
>>> Lua interpreter that manages to include both LuaJIT and Lua 5.2.  foo.so
>>> wants to call the function lua_load().  LuaJIT, being compatible with Lua
>>> 5.1, has
>    [ snip ]
>
>> So basically just use DBus or something?
>    DBus is a message-passing framework to allow arbitrary processes (that use
> DBus) to communicate with each other using a variety of message passing
> methods (one-to-one, one-to-many, etc).  I'm not sure how using DBus will
> help you in having LuaJIT and Lua 5.2 in the same program.
>
>    Aside from the "I want to use Lua 5.2 but with the speed of LuaJIT," what
> problem are you tryting to solve where "Lua 5.2 and LuaJIT in the same
> program" is the answer?
There's a LuaJIT plugin for a C API, and I'm writing a Lua 5.2 program
that implements that API.
>
>    -spc
>
>
>
>

--
Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Embedding Lua twice?

aryajur
I think LJX (https://github.com/katlogic/ljx) does 5.2 with LuaJIT but may not be very well supported as I gather from the warning on the main page!

Milind

On Fri, Nov 28, 2014 at 3:02 PM, Thiago L. <[hidden email]> wrote:

On 28/11/14 09:00 PM, Sean Conner wrote:
It was thus said that the Great Thiago L. once stated:
On 28/11/14 01:46 AM, Sean Conner wrote:
It was thus said that the Great Thiago L. once stated:
On 27/11/14 06:24 PM, Luiz Henrique de Figueiredo wrote:
Hi! Is there any way to have Lua 5.1 (actually LuaJIT) and Lua 5.2
(LuaJIT doesn't support _ENV) on the same program?
I don't know about LuaJIT but you can have two versions of Lua in the
same program by building custom versions using one.c and a header file
that redefines all external symbols to have a different prefix, such
as lua51 and lua52. You'll need to compile your program modules with
the header files for each version. See this:
        http://lua-users.org/lists/lua-l/2014-07/msg00164.html

Uhh so if I have some Lua .so's I can't dlopen them?
Here's the issue:  you have foo.so, a Lua module.  You have your magic
Lua interpreter that manages to include both LuaJIT and Lua 5.2.  foo.so
wants to call the function lua_load().  LuaJIT, being compatible with Lua
5.1, has
   [ snip ]

So basically just use DBus or something?
   DBus is a message-passing framework to allow arbitrary processes (that use
DBus) to communicate with each other using a variety of message passing
methods (one-to-one, one-to-many, etc).  I'm not sure how using DBus will
help you in having LuaJIT and Lua 5.2 in the same program.

   Aside from the "I want to use Lua 5.2 but with the speed of LuaJIT," what
problem are you tryting to solve where "Lua 5.2 and LuaJIT in the same
program" is the answer?
There's a LuaJIT plugin for a C API, and I'm writing a Lua 5.2 program that implements that API.

   -spc





--
Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.