Created attachment 189934 [details] luajit-2.1.beta3.patch You might want to wait for 2.1.0 final release, but just throwing this out there — it works on arm64!
Hi Greg, thanks for the report. At first look the patch looks incomplete: PORTREVISION should be removed. Also, several ports depend on lang/luajit and should be updated with this change, this is why I've recommended to garga@ to raise a review in Phabricator.
benchmarks/wrk was fixed upstream: https://github.com/wg/wrk/issues/314 asked them for a release. editors/neovim fixed a non-fatal error, not related to the update but to arm64: https://github.com/neovim/neovim/issues/7879 Apparently "it doesn't seem like a final release [of LuaJIT 2.1] will be out anytime soon". Debian testing is shipping 2.1.0-beta3 already.
Could this included or is it out of time? bugs #191476.
bug #191476.
Created attachment 191436 [details] luajit-2.1.beta3.patch v2 (In reply to w.schwarzenfeld from comment #3) I'm not sure what exactly you meant, but I've included that pthread patch in this update. Plus fixes for dependent ports. I think most of them should work now…
Looks very good for me.
Created attachment 195982 [details] luajit-2.1.beta3.patch Updated with fixes for more dependent ports.
What's the status here? It would be nice to see luajit get updated.
ping
Sergey, are you planning on committing this?
Thanks for the new patch. Looks good for me. There are several ports are involved in this update. I believe we can test (do a build?) those propertly before we commit the change.
Created attachment 212216 [details] patch regen
Perhaps it would be worth looking at porting moonjit https://github.com/moonjit/moonjit or raptorjit https://github.com/raptorjit/raptorjit instead which seems to be much more active and make it default instead?
(In reply to daniel.engberg.lists from comment #13) Huh, moonjit is the integration fork I sent a PR to before it was called moonjit. https://github.com/moonjit/moonjit/pull/1 I'm for moonjit then. Though my interest in this has significantly lowered since neovim gained support for normal lua.. (and I switched to another editor later anyway lol)
Greg and Daniel, I really appreciate your input here! You know far more about this than I do. Do you have a feel for moonjit vs raptorjit? Also, is there a substantive benefit to luajit over lua in neovim?
(In reply to Adam Weinberger from comment #15) Moon expands portability (powerpc64, s390x), Raptor destroys portability ("removing #ifdef features that are not required for Linux/x86-64 e.g. Windows support, 32-bit heap support, and non-x86 backends"). Raptor is not suitable for replacing an OS package of luajit, Moon is.
any progress on this?
moonjit is dead so I'd suggest that we should point everything to openresty fork.
Hi, we'd probably need to close this PR since we have three ports of luajit: lang/luajit lang/luajit-openresty lang/luajit-devel The last one is recent version, i.e. 2.1.0-beta3. Please let me know your thoughts. Thank you.
(In reply to Sergey A. Osokin from comment #19) as long as lang/luajit is broken on aarch64 this PR must remain open.
(In reply to Mikael Urankar from comment #20) Thanks, Mikael. Any plans to backport aarch64 staff from luajit-devel?
...or just move every port to openresty like Alpine Linux? https://git.alpinelinux.org/aports/tree/main/luajit?h=master
(In reply to Sergey A. Osokin from comment #21) luajit is almost 5 years old. I don't see myself backporting 5 years worth of development just to support aarch64. We should just consider 2.1.beta3 as the latest release or move to openresty.
(In reply to Mikael Urankar from comment #23) Alright, that's exactly what I replied earlier, latest version of luajit 2.1.0-beta3 is available from lang/luajit-devel port.
(In reply to Sergey A. Osokin from comment #24) Sorry but I don't understand. Are you gonna use luajit-devel instead of luajit for all consumers and deorbit luajit?
(In reply to Mikael Urankar from comment #25) I'm on position to have options to choose, so I'd suggest to take a look on databases/redis, where it's possible to build three different flavors of the key-value database: lua, luajit, and luajit-openresty. Another idea is to create a framework as we have for four versions of lua.
(In reply to Sergey A. Osokin from comment #26) Is there a use case for luajit anymore? Per upstream, it will never see another actual release, and consumers tend to target openresty anyway. I don't think very many people would actually care to switch their luajit backend at will. I think the majority of people would just like a lua backend that works, receives updates, and is highly compatible. AFAIK, of all the lua options (PUC and JIT), that means just luajit-openresty.
(In reply to Adam Weinberger from comment #27) > Per upstream, it will never see another actual release luajit upstream is not dead anymore, Mike Pall is back, latest commits are 4 days ago: https://github.com/LuaJIT/LuaJIT/commits/v2.1
(In reply to Greg V from comment #28) Thanks, Greg, yeah, that's exactly what we have in lang/luajit-devel.
Looking at other distros and projects I think it makes most sense to use openresty for the tree as default and when/if there's a reasonable argument we can switch back instead of having ports pulling in different variants?