Re: FFI and Objective C

[Eric Wing <ewmailing@...>]

On 11/18/16, Chris Jones <cmsj@tenshu.net> wrote:
> Hey Eric
>
> Thanks for the reply. I hadn't spotted that LuaCocoa could use a
> pre-existing state. I'm having a quick go at integrating it into
> Hammerspoon at the moment, although there are some compatibility issues to
> work through since we're using Lua 5.3 :)
>
> Many thanks,
> Chris
>
> On 18 November 2016 at 13:26, Eric Wing <ewmailing@gmail.com> wrote:
>
>> On 11/18/16, Chris Jones <cmsj@tenshu.net> wrote:
>> > Hey
>> >
>> >> On 18 Nov 2016, at 10:24, Simon Cozens <simon@simon-cozens.org> wrote:
>> >> Yep, my NSLua (https://github.com/simoncozens/NSLua - heavily based on
>> >> EasyLua) gives you a bidirectional bridge between Lua and ObjC.
>> >>
>> >> What exactly are you looking for? Are you embedding Lua in an ObjC
>> >> app,
>> >> or something else?
>> >
>> > Thanks for the swift reply!
>> >
>> > I currently maintain Hammerspoon (http://www.hammerspoon.org/) which
>> uses
>> > Lua to expose a whole raft of OS X APIs to users (window management
>> > being
>> > probably the most used part).
>> >
>> > Right now I'm investigating how reasonable it would be to allow users
>> > to
>> > interact directly with ObjC objects from Lua (effectively allowing new
>> > OS
>> > API plugins to be written in pure Lua). What potentially makes this
>> harder
>> > is that we already have a homegrown NSObject wrapper around Lua
>> > (https://github.com/Hammerspoon/hammerspoon/tree/master/LuaSkin), which
>> > provides some interfacing between the two, but not anything like FFI
>> (mainly
>> > around converting data back and forth). I had looked at some of the
>> > Lua<->Cocoa bridges before, but since they generally also want to
>> > manage
>> the
>> > lua_State object, it's not a simple drop-in thing :)
>> >
>> > Cheers,
>> > Chris
>> >
>>
>> You might also check out LuaCocoa. It uses libffi under the hood for
>> some things. Maybe it could give you some ideas.
>>
>> Or maybe you might be able to use it. While not perfect (some things I
>> would like to clean up), LuaCocoa does very hard to adhere to the Lua
>> philosophy of "mechanisms, not policy" and not impose on you to
>> conform to it (be a library and not a framework). LuaCocoa does allow
>> you to use a lua_State that you created yourself.
>>
>> LuaCocoa uses BridgeSupport (which is part of Mac OS X) to fully and
>> automatically and correctly bridge all APIs on the system.
>>
>> http://playcontrol.net/opensource/LuaCocoa/
>>
>> I gave a talk on its design last month at the Lua Workshop. The videos
>> are supposed to go up soon.
>>
>> -Eric
>>
>>
>
>
> --
> Cheers,
>
> Chris
>


I've been interested in moving to Lua 5.3. So I'd love to incorporate
your changes. Lua 5.3 integers removes the need for the LNUM patch I
currently use.

I have an updated version of my Lua patch (now for 5.3) to make it use
Objective-C exception handling for pcall. Just to get things basically
working, you won't need it immediately, but you'll want it for any
real shipping product on any Apple platforms. My new one still isn't
heavily tested so I haven't posted it yet. But when you get to that
point, let me know.

FYI, until the video gets posted, these are the slides from my
LuaCocoa talk at the Lua Workshop 2016.
http://playcontrol.net/tempdownload/video/LuaCocoa.pdf

-Eric