On Upgrading CC: Tweaked to Lua 5.2

[JackMacWindows]

In the past few weeks I've been working on getting Cobalt, the Lua runtime for CC: Tweaked, updated for Lua 5.2. Even though most of the libraries are already in place, a few language features don't exist yet: the main ones being actual _ENV environments (not just the _ENV global placed in by CraftOS) and goto statements.

I finished porting Lua 5.2 last week, and it now passes all tests. Currently it is open as a pull request on the Cobalt repository. It also boots CraftOS successfully, and passes all tests in the CC: Tweaked test suite. I've set it up so that there are very few backwards-compatibility concerns: Lua 5.1 bytecode loading is retained, the old functions removed in 5.2 are still in place, and goto is still a valid name, only being used as a statement when it's used in the form "goto <name>".

However, there are concerns with backwards compatibility and how it makes the VM much more messy. Specifically, the 5.1 bytecode loader has a lot of duplicate code, and keeping it in place may hinder maintaining the VM. I can easily remove 5.1 bytecode, but at that point I'd likely remove the old Lua 5.1 functions as well. These can be reimplemented on the Lua side in CC:T. But then there's also the idea of making the long-standing disable_lua51_features config option set to true by default, which could break programs that use the old functions.

In short: how important are the Lua 5.1 features that would be removed in 5.2? I see three different scenarios for how to do this:

• Keep it all as-is, allowing loading 5.1 bytecode and using 5.1 functions (implemented in Java)
• Remove 5.1 bytecode support, but keep 5.1 functions (recreated in the BIOS) available by default (loadstring, setfenv, getfenv, math.log10, table.maxn)
• Remove all 5.1 support by default, and have the old functions available by disabling "disable_lua51_features"

I doubt breaking bytecode loading has any real effect on most things, but there may be a few programs that rely on it. I'm much more concerned about removing old functions, as I've seen plenty of normal programs using them. In fact, a lot of my more complex things use setfenv/getfenv extensively. Luckily, I'd guess most of the incompatibilities would come from loadstring being missing, and that can easily be replaced with load. However, I'd like to hear from the community on what the best strategy is.

Feel free to leave your comments either on this post, or on the pull request. I'm open to other suggestions as well, so if you have an alternative strategy on this I'm happy to hear it.

[Lupus590]

I can definitely foresee a bunch of people being confused as to why their program suddenly stops working due to the removed features. Having them implemented in BIOS sounds consistent with how CC has done forwards/backwards compatibility before and so seems like an acceptable solution to me. While keeping 5.1 bytecode would be nice, the number of programs using it for non-nefarious purposes are probably very few.

Even if the intent is to eventually remove 5.1 entirely, I would still have the option to enable 5.1 features for a while as a transition period. That said, if they are easy to maintain in the bios then why not keep them (and doc them as obsolete)?

[MerithTK]

Also question about updating to 5.2, would this indicate that CC:T would get a new major version? IE: `2.X.Y` instead of `1.X.Y`?

[Lupus590]

Also question about updating to 5.2, would this indicate that CC:T would get a new major version? IE: `2.X.Y` instead of `1.X.Y`?

I believe that @SquidDev mentioned that he wants to do it over an MC version change, so maybe.