Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

For example "void glutDisplayFunc( void (func)(void) ):"

ffi.cdef[[ void glutDisplayFunc(void (func)(void)); ]]

glut = ffi.load( "glut.dll/so/dylib/etc" ) glut.glutDisplayFunc( you_cant_put_lua_callback_function_here )

There are probably some ways using coroutines (as Mike explained), or later if luajit allows libffi to build the trampoline (but Mike said that right now luajit -> C -> luajit would not work for the same luajit context). But maybe a different context would work, and luajit can create different luajit context using itself through the FFI.

All this as altnernative to the natural lua "C" binding way described in the article.

Right now everything I'm doing is without any such binding. It's purely experimental right now.

I've also did some small port of the zile editor (lua version) to directly use curses (curses.dll) instead of bindings

github.com/malkia/luajit-zile

the curses.dll is not there yet.



Ah, I see, that's a different thing than I've been doing. I have a bridge for Cocoa that lets Lua post and observe NSNotifications, and so I have a stub class in ObjC that can call back into Lua in response to receiving a notification. I'm not using FFI at all.

The way I do it is, there's a C function that takes a Lua function as an argument (through the stack) and sticks it in the Lua registry, then stores the (int) index that it's stored at. Later on I can pull the function back out into the Lua stack and pcall it.


Thanks for the ideas!! I have to try it out...


I'm still writing it, but my plan is, have all communication between Lua and everything else go through NSNotifications, to enforce the idea that the game logic (I'm writing a game) should be in Lua and the animations / etc. in ObjC. If you'd like to look at the bridge, it's here:

https://github.com/randrews/ballmaze/blob/master/Ballmaze/Lu...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: