Move to NLua/KeraLua

[CasualPokePlayer]

This is a moonshot update to our NLua, which now uses KeraLua / native Lua 5.4. Some things work here, a lot of things just crash horribly. A bit of refactoring might be needed here? See #2260 and #2261

• I, the committer, have read the licensing terms for contributors (last updated 2022-07-15) and am compliant

[CasualPokePlayer]

Most things seem to work fine now? I had to remove a yield that was placed in stop that resolved some earlier issue, as it now just causes NREs (something NativeWindow callback was garbage collected? not sure what's going on). May not be needed anymore (need to check).

There seems to be an interesting quirk with the console window. If you put in print("foo") (or some other printing command), it prints foo out then nil. Internally this is actually console.log(print("foo")). In old Lua print returns nothing, and outputs is null, and thus that console.log doesn't output anything. But now with newer lua versions outputs contains 1 element with simply null, and thus nil is outputted. Not sure what's the proper way to deal with this, should we treat outputs with one null the same as no return?

[vadosnaprimer]

How does it directly print tables now?

[YoshiRulz]

should we treat outputs with one null the same as no return

Lua does not have void returns, so yes.

[YoshiRulz]

How does it directly print tables now?

before:

> memory.read_bytes_as_array(0xABCD, 10)
"1": "33"
"10": "253"
"2": "159"
"3": "53"
"4": "47"
"5": "184"
"6": "61"
"7": "193"
"8": "127"
"9": "38"

> memory.read_bytes_as_dict(0xABCD, 10)
"43981": "33"
"43982": "159"
"43983": "53"
"43984": "47"
"43985": "184"
"43986": "61"
"43987": "193"
"43988": "127"
"43989": "38"
"43990": "253"

(both kinds have an extra blank line)
after:

> memory.read_bytes_as_array(0xABCD, 10)
33	159	53	47	184	61	193	127	38	253
> memory.read_bytes_as_dict(0xABCD, 10)
47	184	61	193	127	38	253	33	159	53

(those are tabs)

[vadosnaprimer]

Was the table dumper our custom thing? Regular lua can't unwrap tables when printing, and something similar seems to be the case with that new thing.

[CasualPokePlayer]

The table dumper was custom in hawk. The outputs of the Log function would contain a raw LuaTable, which we have custom code to turn that into a string.

It seems however that outputs just contains only the values of a LuaTable rather than the raw LuaTable itself, so NLua might be unpacking it now?

[CasualPokePlayer]

Seems the unpacking stuff is just "normal" upstream behavior, not unpacking seems to be something tacked on by @zeromus. The source of the hacked NLua doesn't seem available, so not sure what exactly we could even submit to upstream to "fix" this.

[zeromus]

should be here
https://github.com/TASEmulators/nlua

[CasualPokePlayer]

Hmm, suppose might be a good idea to just keep forking off NLua and just update our fork. I'd like to PR some of these changes anyways to upstream and hopefully have them accepted to we can just NuGet them and not worry about maintaining a fork, although no telling when they do their next release.

@zeromus Could I be given write access to our NLua fork?

[zeromus]

done

[CasualPokePlayer]

Turns out most of our changes in NLua are already implemented upstream/not needed in NLua/irrelevant, only the Lua table unpacking differs in our fork. Probably easy enough to swap over to NuGet after upstream has that fixed (I plan on making a PR to add a switch for disabling that unpacking) and a new release is out.

Still, what's here should suffice for our purposes, although might want to do some checking before merging this here.

[YoshiRulz]

I'd like to see regression tests implemented on master before merging this.