On Mon, Feb 22, 2016 at 02:08:23PM +0100, John Paul Adrian Glaubitz wrote: > On 02/22/2016 01:05 PM, James McCoy wrote: > > It's currently possible to build without LuaJIT, as long as you don't > > want to run tests. However there are plans to embed LuaJIT into neovim. > > The moment they start embedding LuaJIT into neovim, the package needs > to be patched or it will be removed out of Debian.
That's a bit of an overreaction. What I meant was what's typically meant when talking of embedding a language[0][1][2] (especially with Lua), using the language's functionality from the application. [0]: https://docs.python.org/3/extending/index.html#embedding-the-cpython-runtime-in-a-larger-application [1]: https://metacpan.org/pod/perlembed [2]: http://www.lua.org/manual/5.1/manual.html#3 > > Given that, I don't see it worthwhile to try and workaround the issue. > > LuaJIT needs to be supported. > > I still don't see what warrants the requirement of LuaJIT in a text > editor which could not replaced by the regular Lua interpretor. As I mentioned earlier, LuaC doesn't provide FFI which is something they apparently want to use. Also, one of the major purposes they're looking at for using Lua(JIT) is translating VimL to Lua and then executing that. The thought is that using Lua itself instead of LuaJIT would make that too slow. Some more information on what has been under discussion can be seen in <https://github.com/neovim/neovim/issues/801>. Regardless, I don't see why you're having such a strong reaction to this. It's their design choice and just because it limits what architectures they'll be able to run on it isn't reason enough to consider this a bug. There are plenty of applications in Debian which don't run on all the supported architectures/kernels. Bram took extreme efforts to keep compatibility with arcane and mostly unused computers/OSes and that's something the Neovim folks have decided not to continue, for better or worse. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <james...@debian.org>
