3 ms·

I hooked up LuaJIT to emacs for fun. Emacs recently released a new module system where you can build DLLs that are loaded dynamically: http://diobla.info/blog-a

I hooked up LuaJIT to emacs for fun. Emacs recently released a new module system where you can build DLLs that are loaded dynamically: http://diobla.info/blog-archive/modules-tut.html http://diobla.info/blog-archive/modules-tut.html Getting LuaJIT to work on 64-bit OS X required building a custom emacs with linker flags -pagezero_size 10000 -image_base 100000000. This is unfortunate since obviously users will not take the time to build an emacs with custom linker flags. But more generally, this is an issue any time you want to embed LuaJIT in an application plugin rather than the application itself. There's a bunch of scattered info about the issue: https://gist.github.com/nddrylliog/8722197 https://gist.github.com/nddrylliog/8722197 http://hacksoflife.blogspot.fr/2012/12/integrating-luajit-with-x-plane-64-bit.html http://hacksoflife.blogspot.fr/2012/12/integrating-luajit-wi... https://en.blog.nic.cz/2015/08/12/embedding-luajit-in-30-minutes-or-so/ https://en.blog.nic.cz/2015/08/12/embedding-luajit-in-30-min... http://luajit.org/install.html http://luajit.org/install.html I was hoping there might be a way of sidestepping the issue somehow. If anyone has any ideas, it would be appreciated. LuaJIT has some nice speed improvements compared to standard Lua, but more importantly it has a pretty amazing FFI library. The C declaration parser in particular is valuable. (Yes, I know it's pointless to hook LuaJIT to emacs. It's mostly a "just because" project.)

corsix 10y ago
The solution is included in 2.1.0-beta3: "LuaJIT for x64 can optionally be built for LJ_GC64 mode by enabling the -DLUAJIT_ENABLE_GC64 line in src/Makefile or via 'msvcbuild.bat gc64'." "This mode removes the 32 bit limitation for garbage collected memory on 64 bit systems." [0] [0] https://www.freelists.org/post/luajit/LuaJIT210beta3 https://www.freelists.org/post/luajit/LuaJIT210beta3
- sillysaurus3 10y ago
  Perfect! Thank you.
daurnimator 10y ago
> I was hoping there might be a way of sidestepping the issue somehow. If anyone has any ideas, it would be appreciated. LuaJIT has some nice speed improvements compared to standard Lua, but more importantly it has a pretty amazing FFI library. The C declaration parser in particular is valuable. Why use LuaJIT over plain Lua here? I can't imagine that you need the extra speed in a text editor. The ffi is available for normal lua too: https://github.com/facebook/luaffifb/ https://github.com/facebook/luaffifb/
- camperman 10y ago
  Because it's so easy. From the manual: So here's something to pop up a message box on Windows: local ffi = require("ffi") ffi.cdef[[ int MessageBoxA(void *w, const char *txt, const char *cap, int type); ]] ffi.C.MessageBoxA(nil, "Hello world!", "Test", 0) Bing! Again, that was far too easy, no? Compare this with the effort required to bind that function using the classic Lua/C API: create an extra C file, add a C function that retrieves and checks the argument types passed from Lua and calls the actual C function, add a list of module functions and their names, add a luaopen_* function and register all module functions, compile and link it into a shared library (DLL), move it to the proper path, add Lua code that loads the module aaaand ... finally call the binding function. Phew!
  - daurnimator 10y ago
    As I linked in the above post, the ffi is available for normal lua too: it's not exclusive to LuaJIT
  - sillysaurus3 10y ago
    In fairness, luaffifb seems to give the same feature. I think the main argument against Lua + luaffifb is that it might require an external dependency: luarocks. Whereas if someone were to theoretically provide Lua integration with emacs, it might be a good idea to offer the ffi library as a baseline feature. This is a weak argument, because it should be possible to embed luaffifb plus Lua inside of a linked library, with no need to depend on luarocks. It's probably best to explore both options.

corsix 10y ago

The solution is included in 2.1.0-beta3: "LuaJIT for x64 can optionally be built for LJ_GC64 mode by enabling the -DLUAJIT_ENABLE_GC64 line in src/Makefile or via 'msvcbuild.bat gc64'." "This mode removes the 32 bit limitation for garbage collected memory on 64 bit systems." [0] [0] https://www.freelists.org/post/luajit/LuaJIT210beta3 https://www.freelists.org/post/luajit/LuaJIT210beta3

sillysaurus3 10y ago
Perfect! Thank you.

daurnimator 10y ago

> I was hoping there might be a way of sidestepping the issue somehow. If anyone has any ideas, it would be appreciated. LuaJIT has some nice speed improvements compared to standard Lua, but more importantly it has a pretty amazing FFI library. The C declaration parser in particular is valuable. Why use LuaJIT over plain Lua here? I can't imagine that you need the extra speed in a text editor. The ffi is available for normal lua too: https://github.com/facebook/luaffifb/ https://github.com/facebook/luaffifb/

camperman 10y ago
Because it's so easy. From the manual: So here's something to pop up a message box on Windows: local ffi = require("ffi") ffi.cdef[[ int MessageBoxA(void *w, const char *txt, const char *cap, int type); ]] ffi.C.MessageBoxA(nil, "Hello world!", "Test", 0) Bing! Again, that was far too easy, no? Compare this with the effort required to bind that function using the classic Lua/C API: create an extra C file, add a C function that retrieves and checks the argument types passed from Lua and calls the actual C function, add a list of module functions and their names, add a luaopen_* function and register all module functions, compile and link it into a shared library (DLL), move it to the proper path, add Lua code that loads the module aaaand ... finally call the binding function. Phew!
- daurnimator 10y ago
  As I linked in the above post, the ffi is available for normal lua too: it's not exclusive to LuaJIT
- sillysaurus3 10y ago
  In fairness, luaffifb seems to give the same feature. I think the main argument against Lua + luaffifb is that it might require an external dependency: luarocks. Whereas if someone were to theoretically provide Lua integration with emacs, it might be a good idea to offer the ffi library as a baseline feature. This is a weak argument, because it should be possible to embed luaffifb plus Lua inside of a linked library, with no need to depend on luarocks. It's probably best to explore both options.