Lua 5.3

[Hexenhammer]

Lua 5.3 is about to be released and I wonder about the LÖVE dev team's attitude about that.

Lua 5.3 and LuaJIT are not compatible so the choice seems to be to stick to the currently used common subset of Lua 5.2 and LuaJIT 2 or port to Lua 5.3 and drop LuaJIT.

[undef]

Well, I don't think anyone would want to drop LuaJIT...
Would you?

[Hexenhammer]

Well, I don't think anyone would want to drop LuaJIT...
Would you?

No, I think Lua 5.3 offers nothing to game developers. The support for 64-bit integers only makes things more complicated and slower for those who do not need them. I can see why the Lua devs did it though. 64-bit integers are becoming more and more common in business / system data. However I see little use for 64-bit integers in games.

However LÖVE did not use LuaJIT for the longest time, making it the default was a relatively recent change. So the option to drop LuaJIT support is not unrealistic at all.

Semi-OT but I am pretty sad about Lua and LuaJIT parting ways. Such a small language community really does not need a schism.

[undef]

I would love to use 5.3 if there was a good JIT for it, even 5.2 has some nice advantages over 5.1.
But I don't know if that's going to happen anytime soon...

[Hexenhammer]

I would love to use 5.3 if there was a good JIT for it, even 5.2 has some nice advantages over 5.1.
But I don't know if that's going to happen anytime soon...

Now that Mike Pall has put LuaJIT in maintenance mode we are pretty much stuck with what we have. How many people have the necessary skills to continue the development of LuaJIT? It is a damn small group I think. The chance of one of those guys actually deciding to do it: practically zero

[slime]

Lua 5.3 is about to be released and I wonder about the LÖVE dev team's attitude about that.

Several of Lua 5.3's new features and changes are useful for game development, but LuaJIT's faster interpreter, JIT compiler, and FFI are more useful.
It's not at all out of the question for Mike Pall to integrate many or all of Lua 5.3's features into LuaJIT, although one of Lua 5.2's features (__gc for regular tables) won't be implemented until after LuaJIT's new garbage collector is implemented.

However LÖVE did not use LuaJIT for the longest time, making it the default was a relatively recent change.

LuaJIT 2 was released after LÖVE 0.8.0 and before LÖVE 0.9.0, so the official builds of LÖVE 0.8.0 and below don't use it and 0.9+ do.

Now that Mike Pall has put LuaJIT in maintenance mode we are pretty much stuck with what we have. How many people have the necessary skills to continue the development of LuaJIT? It is a damn small group I think. The chance of one of those guys actually deciding to do it: practically zero

The pace of LuaJIT's development isn't as fast as previous years, but LuaJIT 2.1 is definitely being actively developed. It has some new features (including a built-in profiling API) and many more aspects of Lua have JIT-compiled cases.

[Hexenhammer]

It's not at all out of the question for Mike Pall to integrate many or all of Lua 5.3's features into LuaJIT, although one of Lua 5.2's features (__gc for regular tables) won't be implemented until after LuaJIT's new garbage collector is implemented.

..which would be never: http://luajit.org/sponsors.html

Please note: The main LuaJIT author (Mike Pall) is working on unrelated projects and cannot accept new sponsorships at this time.

Even if someone finally showed up to sponsor the new GC's development Mike Pall would not do it. As I said LuaJIT is no longer in active development.

The pace of LuaJIT's development isn't as fast as previous years, but LuaJIT 2.1 is definitely being actively developed. It has some new features (including a built-in profiling API) and many more aspects of Lua have JIT-compiled cases.

That all happened before Pall stopped accepting sponsorships and put the project in maintenance mode. Look at more recent commits. He does not do anything but small fixes / changes anymore.

[undef]

Well, I guess we can only hope that someone with Mike Pall's technical expertise will step up and continue development...

[slime]

..which would be never: http://luajit.org/sponsors.html

Please note: The main LuaJIT author (Mike Pall) is working on unrelated projects and cannot accept new sponsorships at this time.

'At this time' is quite different from 'never.'

That all happened before Pall stopped accepting sponsorships and put the project in maintenance mode. Look at more recent commits. He does not do anything but small fixes / changes anymore.

This was 11 days ago: http://repo.or.cz/w/luajit-2.0.git/comm ... a2962ad750
This was 3 days ago: http://www.freelists.org/post/luajit/Tr ... to-sponsor

[Related: a 64-bit ARM port of LuaJIT is necessary for new iOS apps, starting in February.]

Mike Pall also does accept code submissions for LuaJIT as well. While there might not be anyone exactly like him, there are many talented programmers with similar skillsets, some of whom have contributed already.

[Hexenhammer]

'At this time' is quite different from 'never.'

I wish I could share you optimism. The new GC was getting nowhere before this and when an open source programmer puts a project on hiatus, he usually never returns to it.

This was 11 days ago: http://repo.or.cz/w/luajit-2.0.git/comm ... a2962ad750

And? That is "small stuff" (for Mike Pall). I myself write more code in an hour. Adding support for a new machine code target is nothing (look at how little code the commit actually contains) compared to big tasks like say supporting Lua 5.3 integers.

While there might not be anyone exactly like him, there are many talented programmers with similar skillsets, some of whom have contributed already.

I have followed LuaJIT development quite closely and somehow I missed that. There have been very few outside contributions and none of them going deeply into the nasty insides of LuaJIT. Have you ever looked at the code? I consider myself a good C programmer and the code bases of most C projects do not scare me at all. LuaJIT's however is *nasty* and requires so much domain specific low-level knowledge that I strongly doubt anyone but Mike Pall himself can seriously develop that code base. Read that warning from Pall where he tells you to always use his build scripts and never attempt to write your own build script for LuaJIT? He goes on and justifies this warning by saying that every other programmer who has tried to write his own build script has failed, resulting in subtly broken LuaJIT builds. That is how bad it is - others have not even succeeded in getting the build process right. Without Pall LuaJIT is as good as dead.

In 5 years from now there will still be no support for Lua 5.3 and there will be no new GC either. I am willing to bet on that.