Lua 5.2 compatibility needs improvement

[SoniEx2]

I don't mean it as in running ZBS from 5.2 (I never tried that btw), I mean running 5.2 code from ZBS.

When running ZBS with stock Lua 5.1, you're unable to use 5.2 syntax (labels, goto, etc) because it tries to loadstring() the code. You need LuaJIT compiled with 5.2 compat features for this.

When running Lua 5.2, the package.cpath is inherited from ZBS, so if the ZBS interpreter has /usr/local/lib/lua/5.1/* on the cpath, Lua 5.2 will also have /usr/local/lib/lua/5.1/* on the cpath.

[pkulchenko]

When running ZBS with stock Lua 5.1, you're unable to use 5.2 syntax (labels, goto, etc) because it tries to loadstring() the code. You need LuaJIT compiled with 5.2 compat features for this.

I'm not sure what you expect for this item: you either need to run ZBS using 5.2 or use LuaJIT with Lua5.2 compatibility turned on. It's also possible to disable compilation step before running/debugging an application by setting skipcompile = true parameter of the interpreter.

When running Lua 5.2, the package.cpath is inherited from ZBS, so if the ZBS interpreter has /usr/local/lib/lua/5.1/* on the cpath, Lua 5.2 will also have /usr/local/lib/lua/5.1/* on the cpath.

This can be improved; the current version inherits the environment set for ZBS itself, which is partially invalid for Lua 5.2. There are several changes needed:

• ignore the current package.path/.cpath as it's set for Lua 5.1;
• use LUA_PATH/_CPATH as configured (including LUA_PATH_5_2/CPATH_5_2);
• add ;; to the PATH/CPATH to be replaced by the default path.

[SoniEx2]

When running ZBS with stock Lua 5.1, you're unable to use 5.2 syntax (labels, goto, etc) because it tries to loadstring() the code. You need LuaJIT compiled with 5.2 compat features for this.

I'm not sure what you expect for this item: you either need to run ZBS using 5.2 or use LuaJIT with Lua5.2 compatibility turned on. It's also possible to disable compilation step before running/debugging an application by setting skipcompile = true parameter of the interpreter.

I was thinking of something like external compilers, or more precisely, interpreter-specific compiler functions. (so for example moonscript could have a compiler function that compiles to Lua on the same thread and stuff, and someone could write a 5.2 compiler in Lua, etc -- if this makes any sense)

[pkulchenko]

I was thinking of something like external compilers, or more precisely, interpreter-specific compiler functions. (so for example moonscript could have a compiler function that compiles to Lua on the same thread and stuff, and someone could write a 5.2 compiler in Lua, etc -- if this makes any sense)

Yes, it should be possible, but it's not much different from using skipcompile to disable the (forced) compilation and running the script itself (as it's going to be compiled first anyway). I added having pluggable "compiler" to the list (to replace current loadstring handling), but this is probably not related to Lua 5.2 compatibility.

[pkulchenko]

@SoniEx2, pushed several changes to lua52compat branch for better compatibility. Take a look if these work for you. I'll test on my OSX/Linux tomorrow.