Jump to content




On Upgrading CC: Tweaked to Lua 5.2


1 reply to this topic

Poll: On Upgrading CC: Tweaked to Lua 5.2

What degree of backwards-compatibility would be best for Lua 5.2 in CC:T?

You cannot see the results of the poll until you have voted. Please login and cast your vote to see the results of this poll.
Vote Guests cannot vote

#1 JackMacWindows

  • Members
  • 24 posts

Posted 16 April 2021 - 11:13 PM

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:
  • Ke ep 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)
  • Remo ve 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.

#2 Lupus590

  • Members
  • 2,027 posts
  • LocationUK

Posted 16 April 2021 - 11:30 PM

Voting here but I've commented on the new forums.





2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users