1. 16

    1. 8

      This is not (yet) a release, but I thought it was worth posting because LuaJIT 3.0 will be a big deal for people using Lua. (I don’t remember the details, but at one point I thought the main developer had decided that there would never be a v3. I may have that wrong though.)

      Edit: I think I had in mind that the main developer announced that it was time for him “to move on.” I’m not sure if that happened and he later began working on the project again or if he stepped back from running things but still contributes or what.

      1. 3

        I think there’s a bunch of issues / concerns:

        1. 3

          Last time I looked at LuaJIT, it had diverged from Lua before support for 64-bit integers was introduced. This was unfortunate when you wanted to expose things like inode numbers into a scripting language and meant that I stuck with the mainline. Did that change or is that one of the 5.3 changes that he hates?

          1. 3

            LuaJIT supports 64 bit ints as boxed cdata for FFI, basically the same thing as java.lang.Long. LL numeric suffix for literals. No automatic promotion as far as I know.

            > x=2LL
            > y=x^60
            > print(y)
            > z=1152921504606846976  
            > print(z)
        2. 3

          mike pall didn’t really like lua 5.2, but he hates lua 5.3

          Have any references about why? I’m curious; afaict the progression of Lua versions has been vaguely sensible.

          1. 3
          2. 3

            I found this though it sounds like this is only one issue he has with 5.3: https://www.freelists.org/post/luajit/Port-bitop-to-53,1

          3. 3

            From what I understand the main frustration is the compatibility breakage though he certainly doesn’t seem to agree with the semantics either

            The LuaJIT VM doesn’t use the numeric type model of Lua 5.3 and doesn’t use its mis-designed and slow bit operation semantics, either.