Automatic bind generator

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

Automatic bind generator

Gabriel Duarte
Hello people,

I'm writing a graphical toolkit (https://github.com/gabrield/stk) and now, I would like to bind it to Lua. I looked for some automatic bind generator,
that could read my .h 's and expose the API to Lua. I have alreary looked at http://lua-users.org/wiki/BindingCodeToLua but could not get much of it. Tips?

Regards
--
Gabriel Duarte
Linux User #471185
Rio de Janeiro / RJ
http://genericdev.wordpress.com/
Reply | Threaded
Open this post in threaded view
|

Re: Automatic bind generator

Dirk Laurie-2
2013/3/11 Gabriel Duarte <[hidden email]>:

> I'm writing a graphical toolkit (https://github.com/gabrield/stk) and
> now, I would like to bind it to Lua. I looked for some automatic bind
> generator, that could read my .h 's and expose the API to Lua. I have
> alreary looked at http://lua-users.org/wiki/BindingCodeToLua but could
> not get much of it. Tips?

You'll get advice from people who like `swig` etc, but please do not
take it.  Rather, consider the following opinion of David Heiko Kolf
from another recent thread.

> - Even more subjective and hard to define, but a module should show some
> "Lua-style".  Sometimes I see a module and it looks to me like raw C
> bindings and I keep thinking that the API might be a lot simpler in Lua.

For example, I see from your .h files that you have dozens of tiny
functions which of necessity have arguments that map easily to C.
In some cases, the parameters are typed but not named. That is not
going to be turned into pretty Lua-style bindings by swig etc.

A Lua-style interface might have only a few functions but exploit the
possibility of table arguments. The great thing about those is that
the key values themselves make the user program self-documenting.
Your call sequence could be something like

   widget:set{x=10,y=20,height=100,width=200,color=rgb(0,255,180)}

instead of four or five calls to little functions.

The only excuse for raw C bindings is that the original package is
huge but very well documented, like Qt for example, so that you then
do not need to write new documentation. Neither of those properties
apply to your project at this stage.

Reply | Threaded
Open this post in threaded view
|

Re: Automatic bind generator

Miles Bader-2
Dirk Laurie <[hidden email]> writes:
> You'll get advice from people who like `swig` etc, but please do not
> take it.  Rather, consider the following opinion of David Heiko Kolf
> from another recent thread.

Or rather, consider taking it, but do not approach the subject blindly.

The problem with SWIG is mainly that it can generate bloated output --
but one of the _reasons_ it does so is that SWIG does lots and lots
and lots of the grot work for you.  I imagine the same applies to
other binding generators in varying degrees.

The basic point of the cited opinion seems reasonable to me:
A binding mechanically generated from some other language may not feel
very "luaish."

But there are other ways to address that issue than avoiding binding
generators.

For instance: use SWIG (or whatever) to generate an internal module,
and then add a thin Lua module on top of that that exports the desired
Lua-ish interface, calling into the internal module to do the real
work.  The user will see the "nice" module, and this sort of glue is
very easy to write in Lua.

-miles

--
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

Reply | Threaded
Open this post in threaded view
|

Re: Automatic bind generator

William Ahern
On Mon, Mar 11, 2013 at 02:54:14PM +0900, Miles Bader wrote:

> Dirk Laurie <[hidden email]> writes:
> > You'll get advice from people who like `swig` etc, but please do not
> > take it.  Rather, consider the following opinion of David Heiko Kolf
> > from another recent thread.
>
> Or rather, consider taking it, but do not approach the subject blindly.
>
> The problem with SWIG is mainly that it can generate bloated output --
> but one of the _reasons_ it does so is that SWIG does lots and lots
> and lots of the grot work for you.  I imagine the same applies to
> other binding generators in varying degrees.
>
> The basic point of the cited opinion seems reasonable to me:
> A binding mechanically generated from some other language may not feel
> very "luaish."
>
> But there are other ways to address that issue than avoiding binding
> generators.
>
> For instance: use SWIG (or whatever) to generate an internal module,
> and then add a thin Lua module on top of that that exports the desired
> Lua-ish interface, calling into the internal module to do the real
> work.  The user will see the "nice" module, and this sort of glue is
> very easy to write in Lua.
>

I've taken to installing C bindings as module _foo.so. The Lua module,
foo.lua, then implements iterator interfaces, I/O polling, etc. I allow the
Lua code to insert or interpose class methods like

        local foo; foo = class.interpose("foo", function (self, ...))
                return foo(self, ...)
        end)

How do other people handle this? Just do it all using the Lua C API?


Reply | Threaded
Open this post in threaded view
|

Re: Automatic bind generator

Tangent 128
On 03/11/2013 02:09 AM, William Ahern wrote:

> <snip>
> I've taken to installing C bindings as module _foo.so. The Lua module,
> foo.lua, then implements iterator interfaces, I/O polling, etc. I allow the
> Lua code to insert or interpose class methods like
>
> local foo; foo = class.interpose("foo", function (self, ...))
> return foo(self, ...)
> end)
>
> How do other people handle this? Just do it all using the Lua C API?
>
>

I've seen that in your cqueues code (very nice socket/signal library for
5.2, I might add), and I admit it seemed a bit overcomplicated to me; my
preference is to just give an "ugly" name to the C functions needing a
Lua wrapper, and let the wrapper take the cleaner name. For instance,
cGrabClientSocket and cUnlink.

By my logic, if you are building a sandbox, then you'll be taking
specific whitelisted functions from the module anyways; if you don't
need a sandbox, then you can hopefully trust other code to not call
non-public-API functions. (Though I admit horror scenarios are easy
enough to envision.)

-Joseph Wallace

Reply | Threaded
Open this post in threaded view
|

Re: Automatic bind generator

Ezequiel García-2
In reply to this post by Gabriel Duarte
Hi Gabriel,

On Sun, Mar 10, 2013 at 9:08 PM, Gabriel Duarte <[hidden email]> wrote:
> Hello people,
>
> I'm writing a graphical toolkit (https://github.com/gabrield/stk) and now, I
> would like to bind it to Lua. I looked for some automatic bind generator,
> that could read my .h 's and expose the API to Lua. I have alreary looked at
> http://lua-users.org/wiki/BindingCodeToLua but could not get much of it.
> Tips?
>

When I started writing a directfb binding to Lua, I considered the several
automatic bindings generators. AFAIC-Rembember, the problems with those
are:

1. Not really automatic, you need some manual tweaking.
2. The C code produced looked like crap to my eyes.
3. The Lua binding was never Luaish enough, and I needed to tweak
that also, which was why point 2 was important.

Altogether these problems lead me to think that the best way (at least
for DirectFB)
was to write an ad-hoc script to parse the header and produce the binding.
I choose Perl for historical reasons, but you could choose Lua itself,
of course.

The result is that you have to work a bit at first, but then you have
full control
of your binding.

You can checkout my directfb-lua and see how nice the produced code is.
The generator script -I admit it- is not too readable, probably because
I'm not a Perl monk.

Note that in order for this to work, you have an special requirement:
your header
*must* be easily parseable. Fortunately for me, DirectFB's header are.

https://github.com/ezequielgarcia/directfb-lua/

Hope this helps,
--
    Ezequiel

Reply | Threaded
Open this post in threaded view
|

Re: Automatic bind generator

steve donovan
On Thu, Mar 14, 2013 at 2:14 PM, Ezequiel Garcia <[hidden email]> wrote:
> was to write an ad-hoc script to parse the header and produce the binding.
> I choose Perl for historical reasons, but you could choose Lua itself,
> of course.

There is another way, which is to write the module in a C-sort of
form, and process it into plain C.

For instance, this is the _source_ of winapi:

https://github.com/stevedonovan/winapi/blob/master/winapi.l.c

Looks just like C, until:

def set_encoding (Int e) {
  set_encoding(e);
  return 0;
}

which gets translated into (see the .c file in same directory) as

static int l_set_encoding(lua_State *L) {
  int e = luaL_checkinteger(L,1);
  #line 56 "winapi.l.c"
  set_encoding(e);
  return 0;
}

plus, l_set_encoding is bound to 'winapi.set_encoding' without any
tedious extra typing.

There's a 'class' construct which really cuts down on the amount of
boilerplate that needs to be typed as well.

This is done using LuaMacro (definitions in lc.lua).  The ironical
thing is that LM was written to preprocess Lua code, but I've mostly
used it to rewrite C ;)

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: Automatic bind generator

Justin Cormack
In reply to this post by Ezequiel García-2


On 14 Mar 2013 12:15, "Ezequiel Garcia" <[hidden email]> wrote:
>
> Hi Gabriel,
>
> On Sun, Mar 10, 2013 at 9:08 PM, Gabriel Duarte <[hidden email]> wrote:
> > Hello people,
> >
> > I'm writing a graphical toolkit (https://github.com/gabrield/stk) and now, I
> > would like to bind it to Lua. I looked for some automatic bind generator,
> > that could read my .h 's and expose the API to Lua. I have alreary looked at
> > http://lua-users.org/wiki/BindingCodeToLua but could not get much of it.
> > Tips?
> >
>
> When I started writing a directfb binding to Lua, I considered the several
> automatic bindings generators. AFAIC-Rembember, the problems with those
> are:
>
> 1. Not really automatic, you need some manual tweaking.
> 2. The C code produced looked like crap to my eyes.
> 3. The Lua binding was never Luaish enough, and I needed to tweak
> that also, which was why point 2 was important.
>
> Altogether these problems lead me to think that the best way (at least
> for DirectFB)
> was to write an ad-hoc script to parse the header and produce the binding.
> I choose Perl for historical reasons, but you could choose Lua itself,
> of course.
>
> The result is that you have to work a bit at first, but then you have
> full control
> of your binding.
>
> You can checkout my directfb-lua and see how nice the produced code is.
> The generator script -I admit it- is not too readable, probably because
> I'm not a Perl monk.
>
> Note that in order for this to work, you have an special requirement:
> your header
> *must* be easily parseable. Fortunately for me, DirectFB's header are.
>
> https://github.com/ezequielgarcia/directfb-lua/
>
> Hope this helps,
> --
>     Ezequiel
>

You can use clang (Lua bindings) to parse any headers not just ones that perl is happy with. See example here
https://github.com/justincormack/luacparse-example

Justin

Reply | Threaded
Open this post in threaded view
|

Re: Automatic bind generator

Hisham
In reply to this post by William Ahern
On 11 March 2013 03:09, William Ahern <[hidden email]> wrote:
> I've taken to installing C bindings as module _foo.so. The Lua module,
> foo.lua, then implements iterator interfaces, I/O polling, etc.
[...]
> How do other people handle this? Just do it all using the Lua C API?

The approach of writing modules with low-level parts in C and
high-level parts (including end-user API) in Lua is quite typical,
often with modules named "foo" for the Lua part and "foo.core" for the
C part (e.g. LuaSocket with socket and socket.core, mime and
mime.core; LuaLanes with lanes and lanes.core; lua-term with term and
term.core; to name a few). In terms of naming, even many pure-Lua
modules use the foo vs. foo.core namespacing for organizing public API
and "private" submodules.

-- Hisham
http://hisham.hm/