11–20 of 28 posts
There is no faster way to make a fork the de facto standard version than to break everyone's CI builds.
[1] https://luajit.org/download.html
LuaJIT.org stopped publishing release tarballs [1] which caused leafo's GH actions builds [2] to suddenly stop working. The workaround was to start testing against OpenResty's distribution of LuaJIT [3] which is incompatible with LuaJIT.org's version. There is no faster way to make a fork the de facto standard version than to break everyone's CI builds. [1] https://luajit.org/download.html [2] https://github.com/leaf…
If they could do that, why can't they just pull from the LuaJIT repo?
Earlier quoted context omitted.
Why do you think that?
None of the items listed there have been ticked off in the time since the ticket was opened, not even the “create v3 branch” one. Mike also has had plans for v3 for at least the last decade too. So, I’m sure it’ll get worked on when he can, and it’ll be great when it’s done, but it doesn’t look like there’s active development on it and it doesn’t look like it will happen any time soon. I hope in wrong, of course, but…
For example there is a new higher-performance GC (https://github.com/LuaJIT/LuaJIT/issues/38#issuecomment-1696...) since a year ago (in fact, at least 3 people over the years have taken a stab at writing a new GC!)
And a full port to (certain flavours of) RISC-V was finished a couple months ago and awaiting merge (https://github.com/LuaJIT/LuaJIT/pull/1267), and might be merged separately into the OpenResty fork (https://github.com/openresty/luajit2/pull/236).
LuaJIT.org stopped publishing release tarballs [1] which caused leafo's GH actions builds [2] to suddenly stop working. The workaround was to start testing against OpenResty's distribution of LuaJIT [3] which is incompatible with LuaJIT.org's version. There is no faster way to make a fork the de facto standard version than to break everyone's CI builds. [1] https://luajit.org/download.html [2] https://github.com/leaf…
The workaround for LuaJIT moving to Github was to... clone a fork of it? If they could do that, why can't they just pull from the LuaJIT repo?
The thing is they stopped numbering and publishing releases, it's all a rolling release without any name or number, so you cannot snapshot I'm certain version.
But OpenResty fork does create tag versions with date, so they can build or test against certain concrete snapshot frozen in time.
Earlier quoted context omitted.
None of the items listed there have been ticked off in the time since the ticket was opened, not even the “create v3 branch” one. Mike also has had plans for v3 for at least the last decade too. So, I’m sure it’ll get worked on when he can, and it’ll be great when it’s done, but it doesn’t look like there’s active development on it and it doesn’t look like it will happen any time soon. I hope in wrong, of course, but…
Actually there is some progress. For example there is a new higher-performance GC ( https://github.com/LuaJIT/LuaJIT/issues/38#issuecomment-1696... ) since a year ago (in fact, at least 3 people over the years have taken a stab at writing a new GC!) And a full port to (certain flavours of) RISC-V was finished a couple months ago and awaiting merge ( https://github.com/LuaJIT/LuaJIT/pull/1267 ), and might be merged se…
Earlier quoted context omitted.
Actually there is some progress. For example there is a new higher-performance GC ( https://github.com/LuaJIT/LuaJIT/issues/38#issuecomment-1696... ) since a year ago (in fact, at least 3 people over the years have taken a stab at writing a new GC!) And a full port to (certain flavours of) RISC-V was finished a couple months ago and awaiting merge ( https://github.com/LuaJIT/LuaJIT/pull/1267 ), and might be merged se…
From what I understood Mike does not want to merge someone else’s implementation of a new ISA but would rather be sponsored and do it himself. Can’t be bothered to source this claim at the moment so feel free to treat it as “came to me in a dream” level authenticity until proven otherwise. Seems reasonable though, I would also be paranoid about merging a sensitive complicated JIT implementation from an unknown contri…
Though, it is possible that he changed his mind after having to review thousands of lines of assembly written by 25 year olds. :)
Earlier quoted context omitted.
Actually there is some progress. For example there is a new higher-performance GC ( https://github.com/LuaJIT/LuaJIT/issues/38#issuecomment-1696... ) since a year ago (in fact, at least 3 people over the years have taken a stab at writing a new GC!) And a full port to (certain flavours of) RISC-V was finished a couple months ago and awaiting merge ( https://github.com/LuaJIT/LuaJIT/pull/1267 ), and might be merged se…
From what I understood Mike does not want to merge someone else’s implementation of a new ISA but would rather be sponsored and do it himself. Can’t be bothered to source this claim at the moment so feel free to treat it as “came to me in a dream” level authenticity until proven otherwise. Seems reasonable though, I would also be paranoid about merging a sensitive complicated JIT implementation from an unknown contri…
> Is the sponsor prepared to sponsor the initial review and integration into the LuaJIT default code base by me?
> Is the sponsor prepared to sponsor the inevitable initial bug fixes and the extra effort for continued maintenance that a new architecture entails?
Also, I should have been clearer about the new GC I linked to: I have not seen Mike say anything about it, and I wouldn't be surprised in the least if he rejects it and (wishes to) write his own, because he's had his own plans for many years. It seems impossible to get anything past him without modification. (I think it's a pity to see someone send a PR with a highly informative commit message and he replaces the body with "Thanks to X. #987")
[1] https://github.com/LuaJIT/LuaJIT/issues/628#issuecomment-716...
Earlier quoted context omitted.
From what I understood Mike does not want to merge someone else’s implementation of a new ISA but would rather be sponsored and do it himself. Can’t be bothered to source this claim at the moment so feel free to treat it as “came to me in a dream” level authenticity until proven otherwise. Seems reasonable though, I would also be paranoid about merging a sensitive complicated JIT implementation from an unknown contri…
I was a part of the team that contributed a few of the ports actually. For example, you can take a look at vm_mips64.dasc file header for the contributor list. Though, it is possible that he changed his mind after having to review thousands of lines of assembly written by 25 year olds. :)
Earlier quoted context omitted.
I was a part of the team that contributed a few of the ports actually. For example, you can take a look at vm_mips64.dasc file header for the contributor list. Though, it is possible that he changed his mind after having to review thousands of lines of assembly written by 25 year olds. :)
Kudos! Was it difficult to get it accepted? I've seen ports rejected.