Modern Lua binding library

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

Modern Lua binding library

jose marin2
Hi!


What's the best/easier/faster Lua binding library, in your opinion?

Thanks


Jose


Reply | Threaded
Open this post in threaded view
|

Re: Modern Lua binding library

Nagaev Boris
On Sun, Mar 13, 2016 at 5:42 PM, Jose Marin <[hidden email]> wrote:

> Hi!
>
>
> What's the best/easier/faster Lua binding library, in your opinion?
>
> Thanks
>
>
> Jose
>
>

Lua C API.


--


Best regards,
Boris Nagaev

Reply | Threaded
Open this post in threaded view
|

Re: Modern Lua binding library

ThePhD
In reply to this post by jose marin2
If you're looking for Binding C++ to Lua, I just finished Sol2[1], a fast AND easy Lua <-> C++ binding library. We have documentation now too, and examples. Feel free to  take a look: I was going to make an announcement here, but... well, this is a really timely post you've made!


On Sun, Mar 13, 2016 at 10:42 AM, Jose Marin <[hidden email]> wrote:
Hi!


What's the best/easier/faster Lua binding library, in your opinion?

Thanks


Jose



Reply | Threaded
Open this post in threaded view
|

Re: Modern Lua binding library

Abhijit Nandy
There is luabind-deboostified which does not need to link with boost, but uses templates, so longer compilation times.

https://github.com/decimad/luabind-deboostified

On Sun, Mar 13, 2016 at 8:22 PM, ThePhD <[hidden email]> wrote:
If you're looking for Binding C++ to Lua, I just finished Sol2[1], a fast AND easy Lua <-> C++ binding library. We have documentation now too, and examples. Feel free to  take a look: I was going to make an announcement here, but... well, this is a really timely post you've made!


On Sun, Mar 13, 2016 at 10:42 AM, Jose Marin <[hidden email]> wrote:
Hi!


What's the best/easier/faster Lua binding library, in your opinion?

Thanks


Jose




Reply | Threaded
Open this post in threaded view
|

Re: Modern Lua binding library

Andrew Starks-2
In reply to this post by Nagaev Boris

On Sun, Mar 13, 2016 at 09:51 Nagaev Boris <[hidden email]> wrote:
On Sun, Mar 13, 2016 at 5:42 PM, Jose Marin <[hidden email]> wrote:
> Hi!
>
>
> What's the best/easier/faster Lua binding library, in your opinion?
>
> Thanks
>
>
> Jose
>
>

Lua C API.


--


Best regards,
Boris Nagaev


IMHO this is the only correct answer, if you are new to Lua. Sooner, not later, you are going to run into something that requires you to understand what is going on. Any binding generator is going to be built upon the C API and without a working understanding of how that works, you're likely to be lost.

You'll "get" it quickly. You may hate how tedious it feels at first, but you're likely to get a feel for how to avoid the tediousness or at least understand it, in short order.

To contrast, The C API is simple whereas binding generators attempt to make things easy. Start with simple, if you need to be successful.

- Andrew

Reply | Threaded
Open this post in threaded view
|

Re: Modern Lua binding library

Shunsuke Shimizu
In reply to this post by Abhijit Nandy
Hi,
Luwra [1] is another great library.
Now it supports C++11 compliant compilers, though only C++14 had been
supported once (shameless plugging: this C++11 support is my contribution.)
In contrast to other libraries, with Luara, there is no need to
duplicate method names to bind a C++ class to Lua; which is achieved by
preprocessor macro magic. The following is an example (copied from [1]).

// Register the metatable and constructor
luwra::registerUserType<Point(double, double)>(
    lua,

    // Constructor name
    "Point",

    // Methods need to be declared here
    {
        LUWRA_MEMBER(Point, scale),
        LUWRA_MEMBER(Point, x),
        LUWRA_MEMBER(Point, y)
    },

    // Meta methods may be registered aswell
    {
        LUWRA_MEMBER(Point, __tostring)
    }
);

Even though, Luwra is boost-free and not very complex, especially when
compared to luabind.

Cheers,
Shunsuke.

[1] https://github.com/vapourismo/luwra


On 03/14/2016 12:08 AM, Abhijit Nandy wrote:

> There is luabind-deboostified which does not need to link with boost,
> but uses templates, so longer compilation times.
>
> https://github.com/decimad/luabind-deboostified
>
> On Sun, Mar 13, 2016 at 8:22 PM, ThePhD <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     If you're looking for Binding C++ to Lua, I just finished Sol2[1], a
>     fast AND easy Lua <-> C++ binding library. We have documentation now
>     too, and examples. Feel free to  take a look: I was going to make an
>     announcement here, but... well, this is a really timely post you've
>     made!
>
>     [ 1 ] Reddit Post -
>     https://www.reddit.com/r/cpp/comments/4a8gy7/sol2_lua_c_binding_framework/
>
>     On Sun, Mar 13, 2016 at 10:42 AM, Jose Marin
>     <[hidden email] <mailto:[hidden email]>> wrote:
>
>         Hi!
>
>
>         What's the best/easier/faster Lua binding library, in your opinion?
>
>         Thanks
>
>
>         Jose
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Modern Lua binding library

Sleepers Tang
Hi,
Lua is NOT C++ :D. These "AutoBinding Library or Helper Functions" only help if you already had a C++ project, and you wish to import Lua.  In other words, if you were start to design your application, the Lua C API is just enough. 

2016-03-14 13:57 GMT+08:00 Shunsuke Shimizu <[hidden email]>:
Hi,
Luwra [1] is another great library.
Now it supports C++11 compliant compilers, though only C++14 had been
supported once (shameless plugging: this C++11 support is my contribution.)
In contrast to other libraries, with Luara, there is no need to
duplicate method names to bind a C++ class to Lua; which is achieved by
preprocessor macro magic. The following is an example (copied from [1]).

// Register the metatable and constructor
luwra::registerUserType<Point(double, double)>(
    lua,

    // Constructor name
    "Point",

    // Methods need to be declared here
    {
        LUWRA_MEMBER(Point, scale),
        LUWRA_MEMBER(Point, x),
        LUWRA_MEMBER(Point, y)
    },

    // Meta methods may be registered aswell
    {
        LUWRA_MEMBER(Point, __tostring)
    }
);

Even though, Luwra is boost-free and not very complex, especially when
compared to luabind.

Cheers,
Shunsuke.

[1] https://github.com/vapourismo/luwra


On 03/14/2016 12:08 AM, Abhijit Nandy wrote:
> There is luabind-deboostified which does not need to link with boost,
> but uses templates, so longer compilation times.
>
> https://github.com/decimad/luabind-deboostified
>
> On Sun, Mar 13, 2016 at 8:22 PM, ThePhD <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     If you're looking for Binding C++ to Lua, I just finished Sol2[1], a
>     fast AND easy Lua <-> C++ binding library. We have documentation now
>     too, and examples. Feel free to  take a look: I was going to make an
>     announcement here, but... well, this is a really timely post you've
>     made!
>
>     [ 1 ] Reddit Post -
>     https://www.reddit.com/r/cpp/comments/4a8gy7/sol2_lua_c_binding_framework/
>
>     On Sun, Mar 13, 2016 at 10:42 AM, Jose Marin
>     <[hidden email] <mailto:[hidden email]>> wrote:
>
>         Hi!
>
>
>         What's the best/easier/faster Lua binding library, in your opinion?
>
>         Thanks
>
>
>         Jose
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Modern Lua binding library

Shunsuke Shimizu
Thanks.
I agree that auto-binding doesn't always make sense, and Lua C API
itself is clean and easy to use. But if you are working on C++, template
oriented libraries still can be helpfull, even if you don't need binding
to C++ class. Those provide a type-safer and more concise way to work
with Lua. Caring Lua's stack with the C API is often just tedious.

Anyway "the best/easier/faster Lua binding library" may be Lua C API,
and I also recommend it to beginners, while it is is not a "modern Lua
binding library" at all.

On 03/14/2016 03:28 PM, Sleepers Tang wrote:

> Hi,
> Lua is NOT C++ :D. These "AutoBinding Library or Helper Functions" only
> help if you already had a C++ project, and you wish to import Lua.  In
> other words, if you were start to design your application, the Lua C API
> is just enough.
>
> 2016-03-14 13:57 GMT+08:00 Shunsuke Shimizu <[hidden email]
> <mailto:[hidden email]>>:
>
>     Hi,
>     Luwra [1] is another great library.
>     Now it supports C++11 compliant compilers, though only C++14 had been
>     supported once (shameless plugging: this C++11 support is my
>     contribution.)
>     In contrast to other libraries, with Luara, there is no need to
>     duplicate method names to bind a C++ class to Lua; which is achieved by
>     preprocessor macro magic. The following is an example (copied from [1]).
>
>     // Register the metatable and constructor
>     luwra::registerUserType<Point(double, double)>(
>         lua,
>
>         // Constructor name
>         "Point",
>
>         // Methods need to be declared here
>         {
>             LUWRA_MEMBER(Point, scale),
>             LUWRA_MEMBER(Point, x),
>             LUWRA_MEMBER(Point, y)
>         },
>
>         // Meta methods may be registered aswell
>         {
>             LUWRA_MEMBER(Point, __tostring)
>         }
>     );
>
>     Even though, Luwra is boost-free and not very complex, especially when
>     compared to luabind.
>
>     Cheers,
>     Shunsuke.
>
>     [1] https://github.com/vapourismo/luwra
>
>
>     On 03/14/2016 12:08 AM, Abhijit Nandy wrote:
>     > There is luabind-deboostified which does not need to link with boost,
>     > but uses templates, so longer compilation times.
>     >
>     > https://github.com/decimad/luabind-deboostified
>     >
>     > On Sun, Mar 13, 2016 at 8:22 PM, ThePhD <[hidden email] <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >
>     >     If you're looking for Binding C++ to Lua, I just finished Sol2[1], a
>     >     fast AND easy Lua <-> C++ binding library. We have documentation now
>     >     too, and examples. Feel free to  take a look: I was going to make an
>     >     announcement here, but... well, this is a really timely post you've
>     >     made!
>     >
>     >     [ 1 ] Reddit Post -
>     >     https://www.reddit.com/r/cpp/comments/4a8gy7/sol2_lua_c_binding_framework/
>     >
>     >     On Sun, Mar 13, 2016 at 10:42 AM, Jose Marin
>     >     <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>>
>     wrote:
>     >
>     >         Hi!
>     >
>     >
>     >         What's the best/easier/faster Lua binding library, in your
>     opinion?
>     >
>     >         Thanks
>     >
>     >
>     >         Jose
>     >
>     >
>     >
>     >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Modern Lua binding library

Philipp Janda
Am 14.03.2016 um 07:48 schröbte Shunsuke Shimizu:

> Thanks.
> I agree that auto-binding doesn't always make sense, and Lua C API
> itself is clean and easy to use. But if you are working on C++, template
> oriented libraries still can be helpfull, even if you don't need binding
> to C++ class. Those provide a type-safer and more concise way to work
> with Lua. Caring Lua's stack with the C API is often just tedious.
>
> Anyway "the best/easier/faster Lua binding library" may be Lua C API,
> and I also recommend it to beginners, while it is is not a "modern Lua
> binding library" at all.

What is a "modern Lua binding library" supposed to look like? Anyway,
let's mention my own C binding library called "moon"[1] (very original
name, I know). It's basically a higher-level replacement for
`luaL_newmetatable()`, `lua_newuserdata()`, and `luaL_checkudata()`.
It's most useful if you have lots of different userdata types that may
depend on or inherit from each other. So far I've used it for bindings
to APR, SDL, and FLTK. The latter is also on GitHub[2].

And finally here[3] is the mandatory link to the relevant wiki page.
There may be some abandoned projects listed, but it's usually safe to
assume that if Lua 5.3 is supported, it's still used/maintained.

Philipp


   [1]: https://github.com/siffiejoe/lua-moon
   [2]: https://github.com/siffiejoe/lua-fltk4lua
   [3]: http://lua-users.org/wiki/BindingCodeToLua

>
> On 03/14/2016 03:28 PM, Sleepers Tang wrote:
>> Hi,
>> Lua is NOT C++ :D. These "AutoBinding Library or Helper Functions" only
>> help if you already had a C++ project, and you wish to import Lua.  In
>> other words, if you were start to design your application, the Lua C API
>> is just enough.
>>



Reply | Threaded
Open this post in threaded view
|

Re: Modern Lua binding library

Peter Pimley
In reply to this post by Andrew Starks-2
"Sooner, not later, you are going to run into something that requires you to understand what is going on."

I agree.  The C API looks big and scary at first, but once you get the fundamentals you'll find (if you're comfortable with C) that it's actually quite easy to use and incredibly well thought out.  You'll soon be able to write a quick C function to perform some function without really having to stop and think.

On 13 March 2016 at 17:20, Andrew Starks <[hidden email]> wrote:

On Sun, Mar 13, 2016 at 09:51 Nagaev Boris <[hidden email]> wrote:
On Sun, Mar 13, 2016 at 5:42 PM, Jose Marin <[hidden email]> wrote:
> Hi!
>
>
> What's the best/easier/faster Lua binding library, in your opinion?
>
> Thanks
>
>
> Jose
>
>

Lua C API.


--


Best regards,
Boris Nagaev


IMHO this is the only correct answer, if you are new to Lua. Sooner, not later, you are going to run into something that requires you to understand what is going on. Any binding generator is going to be built upon the C API and without a working understanding of how that works, you're likely to be lost.

You'll "get" it quickly. You may hate how tedious it feels at first, but you're likely to get a feel for how to avoid the tediousness or at least understand it, in short order.

To contrast, The C API is simple whereas binding generators attempt to make things easy. Start with simple, if you need to be successful.

- Andrew


Reply | Threaded
Open this post in threaded view
|

Re: Modern Lua binding library

ThePhD
Dear Everyone,

I STRONGLY disagree with always defaulting to the C API. While it's good for quick things and hobby projects, the C API lacks the ability to scale. Writing large applications where you're writing -- and re-writing (or copy-pasting) -- the same code over and over again with slight tweaks just to call a function or something is not okay. For example, consider some basic lua code to call a function:

function f ( a, b, c )
    print("adding b and c, and string arg " .. a)
    return b + c
end

f( "bark", 2.5, 3.5 )

From the Lua Reference Manual (http://www.lua.org/manual/5.3/manual.html#lua_call), this turns into this:

     lua_getglobal(L, "f");                  /* function to be called */
     lua_pushliteral(L, "bark");                       /* 1st argument */
     lua_pushnumber(L, 2.5);                          /* 3rd argument */
     lua_pushnumber(L, 3.5);                          /* 3rd argument */
     lua_call(L, 3, 1);     /* call 'f' with 3 arguments and 1 result */
"Well, that's not so bad".

Yeah, it's not so bad!

Then you add that you don't want to call it with plain literals, you want to use an element from a lua table. So, you need to add 2 more function calls... IF your table is accessible as a global. If it's not, prepare to tunnel... oh, and then you need to make sure you remove everything off the stack BUT the argument you want. That's a lua_remove... Oooh, but you don't want to remove everything, because the table `t` you were digging into gets used later, too! Yeah, well, lua_rotate doesn't exist in the 5.1 API.... And don't forget, if you want to pull out an integer from the 5.3 API, you can't set a double and then pull out an integer, because lua checks that internally now and returns you a hefty 0 if you specifically pushed an integer from somewhere else in the C API...

And we haven't even started on how to deal with multiple return values or setting the value of that return into something else.

Now, because you don't feel like re-typing all of that a bunch of times.... well, just copy-paste it. Enter 2 or 3 or 4 off-by-one errors, doing you and everyone else about 0 favors and wasting your time as you keep smacking yourself in the forehead for forgetting to remember to up the number of arguments you're calling the function with from 3 to 4.

We haven't even gotten on how you would call anything more complex than a C free function that adheres to lua's strict conventions.

This is BAD. It's error-prone. It's sluggish. It's just not what you want out of an API. If I can do

f("hi", 24, 56)

In Lua, I deserve something that allows me to do

f("hi", 24, 56)

In C++. We can tote how easy it is to use the Lua C API -- and it's fine for implementing things quickly or being the underpinnings of a library -- but it is NOT ideal. It is NOT the best we can do. We can do better. And we do deserve to have libraries that make it better. Libraries that allow us to do [ Selfish plug ]:

sol::function f = table["f"];
f("hi", 24", 56);

Sincerely,
ThePhD

On Mon, Mar 14, 2016 at 6:25 AM, Peter Pimley <[hidden email]> wrote:
"Sooner, not later, you are going to run into something that requires you to understand what is going on."

I agree.  The C API looks big and scary at first, but once you get the fundamentals you'll find (if you're comfortable with C) that it's actually quite easy to use and incredibly well thought out.  You'll soon be able to write a quick C function to perform some function without really having to stop and think.

On 13 March 2016 at 17:20, Andrew Starks <[hidden email]> wrote:

On Sun, Mar 13, 2016 at 09:51 Nagaev Boris <[hidden email]> wrote:
On Sun, Mar 13, 2016 at 5:42 PM, Jose Marin <[hidden email]> wrote:
> Hi!
>
>
> What's the best/easier/faster Lua binding library, in your opinion?
>
> Thanks
>
>
> Jose
>
>

Lua C API.


--


Best regards,
Boris Nagaev


IMHO this is the only correct answer, if you are new to Lua. Sooner, not later, you are going to run into something that requires you to understand what is going on. Any binding generator is going to be built upon the C API and without a working understanding of how that works, you're likely to be lost.

You'll "get" it quickly. You may hate how tedious it feels at first, but you're likely to get a feel for how to avoid the tediousness or at least understand it, in short order.

To contrast, The C API is simple whereas binding generators attempt to make things easy. Start with simple, if you need to be successful.

- Andrew



Reply | Threaded
Open this post in threaded view
|

Re: Modern Lua binding library

Jonathan Goble
On Mon, Mar 14, 2016 at 5:06 PM, ThePhD <[hidden email]> wrote:
> Dear Everyone,
>
> [long rant]

I agree. Although I've not dug into it much, and not tried to write
any code for it, I prefer Python's C API over Lua's, because Python
defines a `PyObject *` pointer that can be used to point to an
arbitrary Python value, without need for complicated stack operations.
And building on that, Python functions written in C receive their
positional arguments as a `PyObject *` tuple passed directly as an
actual argument to the C function. (The method of unpacking that tuple
into C values is a bit clunky, but in my uneducated opinion, worth the
trade-off.)

I'd love to see something similar to that for Lua.

Reply | Threaded
Open this post in threaded view
|

Re: Modern Lua binding library

Sean Conner
In reply to this post by ThePhD
It was thus said that the Great ThePhD once stated:
> Dear Everyone,
>
> I *STRONGLY *disagree with always defaulting to the C API. While it's good
> for quick things and hobby projects, the C API lacks the ability to scale.
> Writing large applications where you're writing -- and re-writing (or
> copy-pasting) -- the same code over and over again with slight tweaks just
> to call a function or something is not okay.

  I've found that I rarely ever call more than one Lua function from C code,
and that's usually to start the Lua code running.  The C code exists to do
those things that I cannot do from Lua (create a socket, convert an Xlib
event to a Lua table, etc).  The main application is written in Lua.  If I
wanted to write an application in C, I know where to find it.

> This is *BAD*. It's error-prone. It's sluggish. It's just not what you want
> out of an API. If I can do
>
> f("hi", 24, 56)
>
> In Lua, I deserve something that allows me to do
>
> f("hi", 24, 56)
>
> In C++. We can tote how easy it is to use the Lua C API -- and it's fine
> for implementing things quickly or being the underpinnings of a library --
> but it is NOT ideal. It is NOT the best we can do. We can do better. And we
> do deserve to have libraries that make it better. Libraries that allow us
> to do [ Selfish plug ]:
>
> sol::function f = table["f"];
> f("hi", 24", 56);

  Okay, so does your binding library handle this?

        sol::function f = table["g"];
        g(lua_variable_x,cpp_variable_y);

(and just in case it isn't clear, "lua_veriable_x" is a variable defined in
the given Lua state, and cpp_variable_y is a C++ variable).

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: Modern Lua binding library

Coda Highland
In reply to this post by Jonathan Goble
On Mon, Mar 14, 2016 at 2:22 PM, Jonathan Goble <[hidden email]> wrote:

> On Mon, Mar 14, 2016 at 5:06 PM, ThePhD <[hidden email]> wrote:
>> Dear Everyone,
>>
>> [long rant]
>
> I agree. Although I've not dug into it much, and not tried to write
> any code for it, I prefer Python's C API over Lua's, because Python
> defines a `PyObject *` pointer that can be used to point to an
> arbitrary Python value, without need for complicated stack operations.
> And building on that, Python functions written in C receive their
> positional arguments as a `PyObject *` tuple passed directly as an
> actual argument to the C function. (The method of unpacking that tuple
> into C values is a bit clunky, but in my uneducated opinion, worth the
> trade-off.)
>
> I'd love to see something similar to that for Lua.
>

I built something that approximates that as long as the value stays on
the stack or in the registry (and can copy the value into the registry
if it needs it but ONLY if it does). It was super nice... but I don't
have that code anymore because I wrote it for a former employer.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Modern Lua binding library

Jonathan Goble
On Mon, Mar 14, 2016 at 5:47 PM, Coda Highland <[hidden email]> wrote:

> On Mon, Mar 14, 2016 at 2:22 PM, Jonathan Goble <[hidden email]> wrote:
>> On Mon, Mar 14, 2016 at 5:06 PM, ThePhD <[hidden email]> wrote:
>>> Dear Everyone,
>>>
>>> [long rant]
>>
>> I agree. Although I've not dug into it much, and not tried to write
>> any code for it, I prefer Python's C API over Lua's, because Python
>> defines a `PyObject *` pointer that can be used to point to an
>> arbitrary Python value, without need for complicated stack operations.
>> And building on that, Python functions written in C receive their
>> positional arguments as a `PyObject *` tuple passed directly as an
>> actual argument to the C function. (The method of unpacking that tuple
>> into C values is a bit clunky, but in my uneducated opinion, worth the
>> trade-off.)
>>
>> I'd love to see something similar to that for Lua.
>
> I built something that approximates that as long as the value stays on
> the stack or in the registry (and can copy the value into the registry
> if it needs it but ONLY if it does). It was super nice... but I don't
> have that code anymore because I wrote it for a former employer.
>
> /s/ Adam

Thanks for confirming that it's possible as a meta-library. If I ever
get some more free time, I may look into implementing it, but that
won't happen anytime soon.

Reply | Threaded
Open this post in threaded view
|

Re: Modern Lua binding library

ThePhD
In reply to this post by Sean Conner
Dear. Mr. Conner,

My main application is C++, and it embeds lua (though sometimes it relinquishes full control to a lua loop), so I needed something a bit strong to handle my needs.

Thusly, Yes[1]. Given this lua code:

    function f (num_value, a)
        return num_value * 2, a:bark()
    end
    nested = { variables = { no = { problem = 10 } } }


And a sprinkling of C++ code that we'd like to call from Lua that has the exact same behavior:

    struct A {
        int a = 0xA;
        virtual int bark() { return 1; }
    };

    std::tuple<int, int> bark(int num_value, A* a) {
        return std::tuple<int, int>( num_value * 2, a->bark() );
    }

You can start things off and do the following, which creates lua state and sets up a new userdata to behave as you would expect from the given lua:

    sol::state lua;
    lua.script( script_string );
    // can also do lua.script_file( file_name ); too
    lua.new_usertype<A>( "A",
        "bark", &A::bark
    ); // have a struct and its functions set into this table (coincidentally, it's the global table)

    // set the C++ function "bark" to lua identifier "g"
    lua.set_function("g", bark);

The following code will do (I believe) what you ask for, calling both a lua function and a C++ function with the (table-nested) lua variable and the C++ variable:
   
    sol::function cpp_bark = lua["f"];
    sol::function lua_bark = lua["g"];
    sol::reference lua_variable_x = lua["nested"]["variables"]["no"]["problem"];
    A cpp_variable_y;
    std::tuple<int, int> cppresult = cpp_bark(lua_variable_x, cpp_variable_y);
    std::pair<int, int> luaresult = lua_bark(lua_variable_x, cpp_variable_y);


This returns the correct result for both cppresult, which calls the C++ function, and luaresult, which handles multiple returns from lua and returns those as well (expected: a pairing of { 20, 1 }). The example here is a bit squished since I wanted to pack it dense, but I can guarantee you the amount of code you'd write in the plain C API would be a bit of a heartbreaker to achieve the same effect.

Note that the actual code actually "registers" the usertype "A" into lua. If you wanted this code to be tiny, you could remove that part of the example and .

- ThePhD

[1] And here's the code running: http://i.imgur.com/nJDfLHw.png

But you don't have to believe the image, give it a whirl if you like!
Repo - https://github.com/ThePhD/sol2

On Mon, Mar 14, 2016 at 5:22 PM, Sean Conner <[hidden email]> wrote:
It was thus said that the Great ThePhD once stated:
> Dear Everyone,
>
> I *STRONGLY *disagree with always defaulting to the C API. While it's good
> for quick things and hobby projects, the C API lacks the ability to scale.
> Writing large applications where you're writing -- and re-writing (or
> copy-pasting) -- the same code over and over again with slight tweaks just
> to call a function or something is not okay.

  I've found that I rarely ever call more than one Lua function from C code,
and that's usually to start the Lua code running.  The C code exists to do
those things that I cannot do from Lua (create a socket, convert an Xlib
event to a Lua table, etc).  The main application is written in Lua.  If I
wanted to write an application in C, I know where to find it.

> This is *BAD*. It's error-prone. It's sluggish. It's just not what you want
> out of an API. If I can do
>
> f("hi", 24, 56)
>
> In Lua, I deserve something that allows me to do
>
> f("hi", 24, 56)
>
> In C++. We can tote how easy it is to use the Lua C API -- and it's fine
> for implementing things quickly or being the underpinnings of a library --
> but it is NOT ideal. It is NOT the best we can do. We can do better. And we
> do deserve to have libraries that make it better. Libraries that allow us
> to do [ Selfish plug ]:
>
> sol::function f = table["f"];
> f("hi", 24", 56);

  Okay, so does your binding library handle this?

        sol::function f = table["g"];
        g(lua_variable_x,cpp_variable_y);

(and just in case it isn't clear, "lua_veriable_x" is a variable defined in
the given Lua state, and cpp_variable_y is a C++ variable).

  -spc



Reply | Threaded
Open this post in threaded view
|

Re: Modern Lua binding library

ThePhD
Typo: and drastically reduce what the example was showing off*.

I need a nap.

On Mon, Mar 14, 2016 at 6:41 PM, ThePhD <[hidden email]> wrote:
Dear. Mr. Conner,

My main application is C++, and it embeds lua (though sometimes it relinquishes full control to a lua loop), so I needed something a bit strong to handle my needs.

Thusly, Yes[1]. Given this lua code:

    function f (num_value, a)
        return num_value * 2, a:bark()
    end
    nested = { variables = { no = { problem = 10 } } }


And a sprinkling of C++ code that we'd like to call from Lua that has the exact same behavior:

    struct A {
        int a = 0xA;
        virtual int bark() { return 1; }
    };

    std::tuple<int, int> bark(int num_value, A* a) {
        return std::tuple<int, int>( num_value * 2, a->bark() );
    }

You can start things off and do the following, which creates lua state and sets up a new userdata to behave as you would expect from the given lua:

    sol::state lua;
    lua.script( script_string );
    // can also do lua.script_file( file_name ); too
    lua.new_usertype<A>( "A",
        "bark", &A::bark
    ); // have a struct and its functions set into this table (coincidentally, it's the global table)

    // set the C++ function "bark" to lua identifier "g"
    lua.set_function("g", bark);

The following code will do (I believe) what you ask for, calling both a lua function and a C++ function with the (table-nested) lua variable and the C++ variable:
   
    sol::function cpp_bark = lua["f"];
    sol::function lua_bark = lua["g"];
    sol::reference lua_variable_x = lua["nested"]["variables"]["no"]["problem"];
    A cpp_variable_y;
    std::tuple<int, int> cppresult = cpp_bark(lua_variable_x, cpp_variable_y);
    std::pair<int, int> luaresult = lua_bark(lua_variable_x, cpp_variable_y);


This returns the correct result for both cppresult, which calls the C++ function, and luaresult, which handles multiple returns from lua and returns those as well (expected: a pairing of { 20, 1 }). The example here is a bit squished since I wanted to pack it dense, but I can guarantee you the amount of code you'd write in the plain C API would be a bit of a heartbreaker to achieve the same effect.

Note that the actual code actually "registers" the usertype "A" into lua. If you wanted this code to be tiny, you could remove that part of the example and .

- ThePhD

[1] And here's the code running: http://i.imgur.com/nJDfLHw.png

But you don't have to believe the image, give it a whirl if you like!
Repo - https://github.com/ThePhD/sol2

On Mon, Mar 14, 2016 at 5:22 PM, Sean Conner <[hidden email]> wrote:
It was thus said that the Great ThePhD once stated:
> Dear Everyone,
>
> I *STRONGLY *disagree with always defaulting to the C API. While it's good
> for quick things and hobby projects, the C API lacks the ability to scale.
> Writing large applications where you're writing -- and re-writing (or
> copy-pasting) -- the same code over and over again with slight tweaks just
> to call a function or something is not okay.

  I've found that I rarely ever call more than one Lua function from C code,
and that's usually to start the Lua code running.  The C code exists to do
those things that I cannot do from Lua (create a socket, convert an Xlib
event to a Lua table, etc).  The main application is written in Lua.  If I
wanted to write an application in C, I know where to find it.

> This is *BAD*. It's error-prone. It's sluggish. It's just not what you want
> out of an API. If I can do
>
> f("hi", 24, 56)
>
> In Lua, I deserve something that allows me to do
>
> f("hi", 24, 56)
>
> In C++. We can tote how easy it is to use the Lua C API -- and it's fine
> for implementing things quickly or being the underpinnings of a library --
> but it is NOT ideal. It is NOT the best we can do. We can do better. And we
> do deserve to have libraries that make it better. Libraries that allow us
> to do [ Selfish plug ]:
>
> sol::function f = table["f"];
> f("hi", 24", 56);

  Okay, so does your binding library handle this?

        sol::function f = table["g"];
        g(lua_variable_x,cpp_variable_y);

(and just in case it isn't clear, "lua_veriable_x" is a variable defined in
the given Lua state, and cpp_variable_y is a C++ variable).

  -spc




Reply | Threaded
Open this post in threaded view
|

Re: Modern Lua binding library

Sean Conner
In reply to this post by ThePhD
It was thus said that the Great ThePhD once stated:

> Dear. Mr. Conner,
>
> My main application is C++, and it embeds lua (though sometimes it
> relinquishes full control to a lua loop), so I needed something a bit
> strong to handle my needs.
>
> Thusly, Yes[1]. Given this lua code:
>
>     function f (num_value, a)
>         return num_value * 2, a:bark()
>     end
>     nested = { variables = { no = { problem = 10 } } }
>
> The following code will do (I believe) what you ask for, calling both a
> lua function and a C++ function with the (table-nested) lua variable and
> the C++ variable:
>
>     sol::function cpp_bark = lua["f"];
>     sol::function lua_bark = lua["g"];
>     sol::reference lua_variable_x = lua["nested"]["variables"]["no"]["problem"];
>     A cpp_variable_y;
>     std::tuple<int, int> cppresult = cpp_bark(lua_variable_x, cpp_variable_y);
>     std::pair<int, int> luaresult = lua_bark(lua_variable_x, cpp_variable_y);
>

  That's impressive.

  -spc (Thanks for the example)

> [1] And here's the code running: http://i.imgur.com/nJDfLHw.png


Reply | Threaded
Open this post in threaded view
|

Re: Modern Lua binding library

Hisham
In reply to this post by Jonathan Goble
On 14 March 2016 at 18:22, Jonathan Goble <[hidden email]> wrote:

> On Mon, Mar 14, 2016 at 5:06 PM, ThePhD <[hidden email]> wrote:
>> Dear Everyone,
>>
>> [long rant]
>
> I agree. Although I've not dug into it much, and not tried to write
> any code for it, I prefer Python's C API over Lua's, because Python
> defines a `PyObject *` pointer that can be used to point to an
> arbitrary Python value, without need for complicated stack operations.
> And building on that, Python functions written in C receive their
> positional arguments as a `PyObject *` tuple passed directly as an
> actual argument to the C function. (The method of unpacking that tuple
> into C values is a bit clunky, but in my uneducated opinion, worth the
> trade-off.)
>
> I'd love to see something similar to that for Lua.

Python's C API looks much simpler on surface, indeed, but it has one
complication that breaks the deal: garbage collection. This is the one
thing that Lua's stack oriented API gives you for free, and it's its
killer feature. Ask anyone who has coded significantly with Python's C
API and the one thing they'll complain you about is having to deal
explicitly with reference counting for GC.

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: Modern Lua binding library

Coda Highland


On Mar 14, 2016 9:49 PM, "Hisham" <[hidden email]> wrote:
>
> On 14 March 2016 at 18:22, Jonathan Goble <[hidden email]> wrote:
> > On Mon, Mar 14, 2016 at 5:06 PM, ThePhD <[hidden email]> wrote:
> >> Dear Everyone,
> >>
> >> [long rant]
> >
> > I agree. Although I've not dug into it much, and not tried to write
> > any code for it, I prefer Python's C API over Lua's, because Python
> > defines a `PyObject *` pointer that can be used to point to an
> > arbitrary Python value, without need for complicated stack operations.
> > And building on that, Python functions written in C receive their
> > positional arguments as a `PyObject *` tuple passed directly as an
> > actual argument to the C function. (The method of unpacking that tuple
> > into C values is a bit clunky, but in my uneducated opinion, worth the
> > trade-off.)
> >
> > I'd love to see something similar to that for Lua.
>
> Python's C API looks much simpler on surface, indeed, but it has one
> complication that breaks the deal: garbage collection. This is the one
> thing that Lua's stack oriented API gives you for free, and it's its
> killer feature. Ask anyone who has coded significantly with Python's C
> API and the one thing they'll complain you about is having to deal
> explicitly with reference counting for GC.
>
> -- Hisham
>

I just wrapped PyObject in a C++ class and got it for free. >.>

/s/ Adam

12