Lua
Q: Where can I learn more about Lua and LuaJIT?
Q: Where can I learn more about the compiler technology used by LuaJIT?
I'm planning to write more documentation about the internals of LuaJIT. In the meantime, please use the following Google Scholar searches to find relevant papers:
Search for: » Trace Compiler
Search for: » JIT Compiler
Search for: » Dynamic Language Optimizations
Search for: » SSA Form
Search for: » Linear Scan Register Allocation
And, you know, reading the source is of course the only way to enlightenment. :-)
Q: Why do I get this error: "attempt to index global 'arg' (a nil value)"?
Q: My vararg functions fail after switching to LuaJIT!
LuaJIT is compatible to the Lua 5.1 language standard. It doesn't support the implicit arg parameter for old-style vararg functions from Lua 5.0.
Please convert your code to the » Lua 5.1 vararg syntax.
Q: Sometimes Ctrl-C fails to stop my Lua program. Why?
The interrupt signal handler sets a Lua debug hook. But this is currently ignored by compiled code (this will eventually be fixed). If your program is running in a tight loop and never falls back to the interpreter, the debug hook never runs and can't throw the "interrupted!" error.
In the meantime you have to press Ctrl-C twice to get stop your program. That's similar to when it's stuck running inside a C function under the Lua interpreter.
Q: Why doesn't my favorite power-patch for Lua apply against LuaJIT?
Because it's a completely redesigned VM and has very little code in common with Lua anymore. Also, if the patch introduces changes to the Lua semantics, this would need to be reflected everywhere in the VM, from the interpreter up to all stages of the compiler.
Please use only standard Lua language constructs. For many common needs you can use source transformations or use wrapper or proxy functions. The compiler will happily optimize away such indirections.
Q: Lua runs everywhere. Why doesn't LuaJIT support my CPU?
Because it's a compiler — it needs to generate native machine code. This means the code generator must be ported to each architecture. And the fast interpreter is written in assembler and must be ported, too. This is quite an undertaking.
Currently only x86 CPUs are supported. x64 support is in the works. Other architectures will follow with sufficient demand and/or sponsoring.
Q: When will feature X be added? When will the next version be released?
When it's ready.
C'mon, it's open source — I'm doing it on my own time and you're getting it for free. You can either contribute a patch or sponsor the development of certain features, if they are important to you.