4 ms·

> 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

> 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 9y 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 9y ago
  As I linked in the above post, the ffi is available for normal lua too: it's not exclusive to LuaJIT
- sillysaurus3 9y 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.
  - shalabhc 9y ago
    Well, LuaJIT will also JIT compile Lua code operating on C structures - so speed could be another big argument.
- spc476 9y ago
  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.c https://github.com/spc476/lua-conmanorg/blob/master/src/tcc.... [2] https://github.com/spc476/lua-conmanorg/blob/master/lua/cc.lua https://github.com/spc476/lua-conmanorg/blob/master/lua/cc.l... [3] https://github.com/spc476/LPeg-Parsers/blob/json-1.0.0/json.lua https://github.com/spc476/LPeg-Parsers/blob/json-1.0.0/json....
_pmf_ 9y ago
> 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.
versteegen 9y ago
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.

camperman 9y 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 9y ago
As I linked in the above post, the ffi is available for normal lua too: it's not exclusive to LuaJIT
sillysaurus3 9y 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.
- shalabhc 9y ago
  Well, LuaJIT will also JIT compile Lua code operating on C structures - so speed could be another big argument.
spc476 9y ago
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.c https://github.com/spc476/lua-conmanorg/blob/master/src/tcc.... [2] https://github.com/spc476/lua-conmanorg/blob/master/lua/cc.lua https://github.com/spc476/lua-conmanorg/blob/master/lua/cc.l... [3] https://github.com/spc476/LPeg-Parsers/blob/json-1.0.0/json.lua https://github.com/spc476/LPeg-Parsers/blob/json-1.0.0/json....

_pmf_ 9y ago

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

versteegen 9y ago

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.