Investigate offering PUC Lua version of luvi

[creationix]

Migrated from luvit/luv#147

[mythay]

i think supporting PUC lua is a good idea, because it seems that luajit would never be compatible with new features, and Mike had left the development team, the future is not clear.
and i think luvit should do something different from nodejs, maybe it can focus on IoT solution. for example, the hardware running openwrt don't have enough resource to run nodejs, if luvit can run and support some popular IoT protocols such as alljoyn, mqtt, thread, what a wonderful thing.

[joerg-krause]

At least it is possible to build luvi with PUC Lua 5.1. You have to adjust the CMakeLists.txt to get luvi linked against the Lua libraries (instead of the LuaJIT libraries).

[creationix]

I recently made some changes to the lua in luvi to make it less dependent on luajit extensions.

@mythay what would a lua 5.3 version of luvi give you that the luarocks version of luv compiled for lua doesn't?

The main things luvi adds on top of luv are:

1. pre-compiled lua engine embedded into binary
2. openssl bindings embedded (crypto/hashes)
3. miniz bindings embedded (inflate/deflate/zip file I/O)
4. pcre bindings embedded (popular regexp)
5. lpeg embedded (advanced pattern matching)
6. bootstrap logic with zip file asset loading.

The various embedded bindings can just be added to a luv project as normal dependencies along-side the luv dependency in your project. All the embedded libraries in luvi only make sense if you want a single binary that you can deploy to devices as your runtime. The bootstrap logic lets you even bundle your lua code in a zip file and append it to the single binary for even easier deployments.

[creationix]

As far as "supporting" PUC lua, this would mean two things:

1. Distribute pre-built binaries of luvi using normal lua in addition to luajit. For IoT I only build armv6 and armv7 for raspberry PI. Everything else is desktop/server class.
2. Test every patch to ensure it doesn't break the lua 5.3 configuration.

The first piece would be helpful for Raspberry PI users though they are already more than powerful enough to run luajit.

The second piece would be great for anyone doing their own custom build of luvi to just make sure I don't break their stuff when I change things.

[joerg-krause]

We have to clarify that you can build luv with LuaJIT or PUC Lua 5.1/5.2/5.3.

On the other hand you can build luvi with LuaJIT or PUC Lua 5.1. Trying to build luvi with PUC Lua 5.2 or 5.3 will fail because of their different ABI resulting in undefined references. Building luvi with PUC Lua 5.1 needs some modifications in CMakelists.txt.

So, for now you can choose between LuaJIT and PUC Lua 5.1.

Are there any LuaJIT extensions used in luvi?

[creationix]

I was using jit.os to know if we're in windows or not, but that's since been changed to work without it.

luvi/src/lua/luvipath.lua

Lines 4 to 9 in a87ab12

	local isWindows
	if _G.jit then
	isWindows = _G.jit.os == "Windows"
	else
	isWindows = not not package.path:match("\\")
	end

I think that was the last luajit extension being used by luvi itself. The unit test will check to make sure the lua 5.2 compat flag was compiled into luajit, but that can be disabled if we're building against lua 5.1, for example.

[joerg-krause]

I see!

One more comment about building luvi: it is possible to link against LuaJIT or PUC Lua 5.1, but you need LuaJIT for building the executable binary image. This means that you not necessarily need LuaJIT to be installed on the target.

So the question leaves us whether to support building against PUC Lua 5.2/5.3.

[creationix]

Oh, I forgot the other luajit feature we use. Luvi's lua scripts are embedded as pre-compiled luajit bytecode into the binary (as opposed to normal lua files in the zip archive appended by a user) I'm pretty sure this can be done using lua 5.1/5.2/5.3 bytecode instead, it would just require some changes to the build scripts.

The embedded bytecode needs to match the embedded lua vm. I suppose we could embed just lua strings, but that is actually a lot harder that expected when I tried it.

[mythay]

great, i like the recent improvement

[mythay]

i heard that the lua byte code are different between little endian and big endian cpus, if i generate the byte code in x86 but run it on big endian MIPS, what's happen.

[creationix]

@mythay that's not going to be a problem since the bytecode is embedded along with the native binary.

On a side note, I think that lua bytecode (luajit for sure) is actually portable as long as both programs are using the same version of lua, even if they are different endianess.

[joerg-krause]

Oh, I forgot the other luajit feature we use. Luvi's lua scripts are embedded as pre-compiled luajit bytecode into the binary (as opposed to normal lua files in the zip archive appended by a user) I'm pretty sure this can be done using lua 5.1/5.2/5.3 bytecode instead, it would just require some changes to the build scripts.

I see! I am able to link luvi against the Lua 5.1 library, but cannot run it, because luvi is not finding init.lua.

For me it is not a big deal at the moment, because LuaJIT is just fine and maybe there will a version 2.1 soon.

[creationix]

See luvit/lit#155 for progress on making luvit's ecosystem more compatible with stock lua.

[daurnimator]

I think that lua bytecode (luajit for sure) is actually portable as long as both programs are using the same version of lua, even if they are different endianess.

They are not.

[creationix]

According to http://luajit.org/extensions.html

The generated bytecode is portable and can be loaded on any architecture that LuaJIT supports, independent of word size or endianess. However the bytecode compatibility versions must match.

This may not be true for other lua engines.

[daurnimator]

Indeed. I was talking about lua bytecode, not luajit.

[creationix]

Indeed. I was talking about lua bytecode, not luajit.

Good to know, though in this case it doesn't matter either way since the final binary also has non-portable native code from the luvi half.

[zhaozg]

fully support PUC Lua now.