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!

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

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.

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

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