Comment by sillysaurus3 | Hacker News Reader

Comment by sillysaurus3 | Hacker News Reader

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

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

http://hacksoflife.blogspot.fr/2012/12/integrating-luajit-wi...

https://en.blog.nic.cz/2015/08/12/embedding-luajit-in-30-min...

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.)

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

Perfect! Thank you.

> 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/

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!

As I linked in the above post, the ffi is available for normal lua too: it's not exclusive to LuaJIT

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.

Well, LuaJIT will also JIT compile Lua code operating on C structures - so speed could be another big argument.

I did write a Lua binding to TCC [1] and used that to write a Lua module to load Lua modules written in C directly from source code [2], which I used in an older version of my JSON decoder [3], which contains the C code embedded right in the Lua source code.

On the down side, TCC doesn't support all the architectures I use, so I mostly use it for proof-of-concept and throw away code.

One thing I keep thinking is to possibly use TCC (or parts of it) to parse C header files directly, so it would be easier to use an FFI in Lua.

[1] https://github.com/spc476/lua-conmanorg/blob/master/src/tcc....

[2] https://github.com/spc476/lua-conmanorg/blob/master/lua/cc.l...

[3] https://github.com/spc476/LPeg-Parsers/blob/json-1.0.0/json....

> 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.

My mouth was hanging open when I discovered that you could literally a verbatim header with packed structs and use it and it would work. Then I looked at the source to find out what they were using as a compiler frontend; it's all hand written. Incredible.

As an emacs user, I would love if its lisp interpreter were sped up or replaced with something faster. There's a lot of computationally expensive stuff written in elisp. Even for text editing, it can be laggy when parsing large files of source code for IDE purposes.

Reply on news.ycombinator.com