Updating Cobalt and CC: Tweaked for Lua 5.2

[MCJack123]

I've been taking a look at upgrading Cobalt for Lua 5.2. As it stands now, there aren't many things that Cobalt is missing to be able to support 5.2. The main things I can think of are _ENV environments, labels and goto, and Lua 5.2 bytecode support (and uservalues, but I'm not sure how that applies to Cobalt yet). So far, I have made a fork of Cobalt that adjusts the VM to use 5.1 and 5.2 instructions, allowing both 5.1 and 5.2 bytecode to be loaded; as well as adding rudimentary _ENV support. However, it's currently missing 5.2 bytecode generation (it still outputs for 5.1), as well as labels & goto; and it's very broken and needs much more work to be functional.

I'm thinking that for Minecraft 1.17, CC: Tweaked could be updated with this new Cobalt version (once complete) to officially support Lua 5.2. (This could be associated with a bump to 2.0.0?) To accommodate transition and try to keep compatibility:

• Keep getfenv/setfenv, using alternatives in Lua or Java that set the _ENV upvalue
• Keep other deprecated functions if disable_lua51_features is false (implementing in Lua if necessary)
• Support loading both Lua 5.1 and 5.2 bytecode, with 5.1 globals being converted to 5.2 environment references and inserting _ENV upvalues for each function
• If necessary, add some way to generate 5.1 bytecode or something? (Probably more than is necessary, but some things may rely on 5.1 bytecode)

I'd be willing to put some time into this project to get it working fully. However, it's going to take a lot of work, and I'd like to see what people think about it before I fully commit. I'm probably also going to need some help with getting things fully integrated/cleaned up, as well as beta tests with the new Cobalt to make sure everything works properly. I'm not very acquainted with Lua 5.2 itself, too, so getting some advice on its differences from 5.1 would be helpful.

Thoughts on Lua 5.2 support in CC:T?

[Jonson26]

Question is, how would this impact compatibility with existing CC software? There's a lot of older stuff that would be a shame to lose, but the original devs are no longer active.

[SkyTheCodeMaster]

You can test that by enabling disable_lua51_features in the config folder.
(As far as I'm aware, atleast.)

[Lemmmy]

I'm not looking forward to there being a bunch of poorly written (yet somehow popular) programs out there using goto, and then people coming to SwitchCraft and complaining about it being unavailable

[plt-amy]

this is literally the definition of :D:

[SquidDev]

Obligatory

[SquidDev]

Thanks for looking into this! I know how horrific a) the Lua 5.1 -> 5.2 changes re and b) Cobalt's code base is. This is one of those fun issues where I want to do it, but absolutely petrified of how much it's going to break. I guess we'll need a lot of compatibility tests.

Question is, how would this impact compatibility with existing CC software? There's a lot of older stuff that would be a shame to lose, but the original devs are no longer active.

I've been very obsessive about backwards compatibility (or not), and I don't think that will change here. I think it's unavoidable that CC will live in a weird hybrid land of 5.1-5.2 (or more in the future).

That said, things are going to break. It's always going to be possible to write a program which behaves differently before/after 5.2, the hard thing will just be minimising the damage in such a way it doesn't affect any reasonable user program.

---

Anyway, haven't really got anything concrete to say, just going to go on one of my regularly scheduled rambles...

Keep getfenv/setfenv, using alternatives in Lua or Java that set the _ENV upvalue.

Support loading both Lua 5.1 and 5.2 bytecode, with 5.1 globals being converted to 5.2 environment references and inserting _ENV upvalues for each function

Environments are going to be impossible to handle correctly, I think we just need to find a scheme which minimises breakage.

Running 5.1 bytecode is probably an edge case (does anything but JVML-JIT use it?), so I don't want to get too bogged down (though it still would be good to support it). Instead of inserting upvalues for these bytecode functions, I wonder if we can have two versions of LuaInterpretedFunction (and LuaInterpreter), one for 5.1 and one for 5.2. Then the 5.1 actually has a notion of global environment.

Then getfenv/setfenv would do something like the following:

• getfenv:

  • Lua 5.1 functions -> Return the environment.
  • Lua 5.2 functions -> Return the _ENV upvalue, or nil if absent.
  • (debug version only) Coroutines/Global functions -> Return _G?

• setfenv:

  • Lua 5.1 functions -> Set the environment.
  • Lua 5.2 functions -> Set the _ENV upvalue, do nothing if absent.
  • (debug version only) Coroutines/Global functions -> Do nothing?

Not sure whether we want to fail hard in some of those cases instead of returning dummy values/doing nothing.

Don't know, haven't put too much thought into it. May just be bikeshedding.

[sir-maniac]

Environments are going to be impossible to handle correctly, I think we just need to find a scheme which minimises breakage.

Just a small suggestion. Though I'm both an outsider and late to the party, so feel free to ignore.

Maybe new code can be marked with something, like a hash-bang or a comment like #!/rom/programs/lua5.2, #! lua5.2or -- lua-5.2 .

Edit: Rationale: This way older programs can be run as-is, but breaking changes can be introduced for anything new.

[MCJack123]

There's been some changes and more conversation at cc-tweaked/Cobalt#50; you can take a look at the current status and comment there.

[sir-maniac]

Okay, thanks.