Boolsheet wrote:Don't confuse Lua's versions with the versions of LuaJIT.
My bad. I meant LuaJIT 2.0.0.
Boolsheet wrote:The reason you won't see official builds is because Lua 5.1 has proven to be very stable for the last 6 years and LuaJIT 2.0.0 still has to come out of beta.
I agree. But I think it is reasonable to expect that LuaJIT 2.0.0 will be stable much before LÖVE 0.10.0 is even considered. That's my bet, anyway.
bartbes wrote:And it's already possible, easy, and done. LuaJIT is old news .
I'm not sure we are talking about the same thing. I am aware that some fringe conspirators have managed to compile versions of LÖVE with Luajit support.
I was talking about supporting it on the main branch. It could be 0.10.0, or later; I see no need to rush things. But I feel that the changes required to transition to Lua 5.2 in the "oficial branch" are likely to be similar to the ones for transitioning to Luajit. The community has expressed interest in both (or, as you have pointed out, in some cases they have implemented it themselves). It would be logical to study both options, when the time comes. With emphasis on studyand both. It could very well happen that luajit is deemed not worthy of LÖVE, at least on the standard version. But the same could happen to Lua 5.2. Maybe we find a good reason to stay in Lua 5.1 standard. My point is, some discussion here is needed.
I am aware that I have no say in the matter, and I will respect what the core team decides to do. I have no particular need to use 5.2 or Luajit. Please consider all of the above as just suggestions.
bartbes wrote:And it's already possible, easy, and done. LuaJIT is old news .
I'm not sure we are talking about the same thing. I am aware that some fringe conspirators have managed to compile versions of LÖVE with Luajit support.
I was talking about supporting it on the main branch. It could be 0.10.0, or later; I see no need to rush things. But I feel that the changes required to transition to Lua 5.2 in the "oficial branch" are likely to be similar to the ones for transitioning to Luajit. The community has expressed interest in both (or, as you have pointed out, in some cases they have implemented it themselves). It would be logical to study both options, when the time comes. With emphasis on studyand both. It could very well happen that luajit is deemed not worthy of LÖVE, at least on the standard version. But the same could happen to Lua 5.2. Maybe we find a good reason to stay in Lua 5.1 standard. My point is, some discussion here is needed.
I am aware that I have no say in the matter, and I will respect what the core team decides to do. I have no particular need to use 5.2 or Luajit. Please consider all of the above as just suggestions.
LuaJIT is a drop-in replacement for Lua 5.1. It's as easy to compile LÖVE with LuaJIT as it is to compile it with Lua 5.1. No source changes (for the LÖVE source or games using LÖVE) are needed. This is not the case with Lua 5.2. Additionally, Lua 5.2 provides few benefits to justify breaking compatibility, especially considering LuaJIT 2 will continue to support Lua 5.1. Mike Pall has this to say:
Mike Pall wrote:
Many users of LuaJIT, especially those with big code bases, have a
heavy investment in Lua 5.1-compatible infrastructure, tools,
frameworks and in-house knowledge. Understandably, they don't want
to throw away their investment, but still keep up with the newest
developments.
As I've previously said, Lua 5.2 provides few tangible benefits.
LuaJIT already includes the major new features, without breaking
compatibility. Upgrading to be compatible with 5.2, just for the
sake of a higher version number, is neither a priority nor a
sensible move for most LuaJIT users.
To protect the investment of my users and still provide them with
new features, LuaJIT 2.1 will stay compatible with Lua 5.1.
bartbes wrote:But it is! There's nothing we need to do code-wise, and the linux build system can find and link against luajit (and llvm-lua) instead of lua.
Well, I was thinking about a more "official" stuff - like including it in the binaries, etc.
I didn't know it required no code changes. That is nice.