Re: [ANN] WinLua Binary Distribution, Release 3 (alpha) - now with LuaRocks and OP

On Mon, Jan 6, 2020 at 6:38 PM Jonathan Goble <jcgoble3@gmail.com> wrote:

On Sun, Jan 5, 2020 at 1:24 PM Russell Haley <russ.haley@gmail.com> wrote:
Hi,

I'm pleased to announce an alpha build of the WinLua Release 3 installer that now includes LuaRocks. https://github.com/WinLua/bin

(NOTE: Download Release 3! Release 1 is a bare bones Lua install with no LuaRocks).

The WinLua installer is a Windows binary release of the latest available Lua, plus a smattering of external tools to help developers write Lua scripts and Lua modules. WinLua Release 3 includes:
- Lua 5.3.5 patched with the DevCat Studios OP_HALT patch variant. The patch can be used in conjunction with Visual Studio Code and the DevCat debugger for an improved debugging experience. Special thanks to DevCat Studios, Seungjae Lee and Dan Tull.
- LuaFileSystem - Included in the base package for convenience.[1]
- LuaRocks 3.2.1 - LuaRocks is the de-facto package manager for Lua and provides a means for building and installing Lua modules.
- Sol2 3.20.0 - Sol2 is a header only C++ library for integrating Lua into C++ applications
- LibreSSL 3.0.2 - LibreSSL is an OpenSSL fork that also provides a more modern TLS API. See https://ftp.openbsd.org/papers/linuxconfau2017-libtls/ for more information.
- JamPlus - A build system that can be used to write build scripts in Lua.

The new installer is possible thanks to the work of the LuaRocks team creating a single LuaRocks (and admin) executable. I've hacked the configuration script out of the LuaRocks install.bat file and use it to configure LuaRocks during installation. Thank you LuaRocks team!

The README.md file provides information on installing a compiler - the FREE VC++ toolchain - and configuring PowerShell to use the appropriate Environment Variables for said VC++ tools. Also, WinLua targets Windows 10. Though the VC++ redist is available (and noted in the readme) I am not supporting issues related to running on Windows 8 or 7.

Finally: Please note this is an ALPHA release and will likely have issues. It's been tested on a whopping 2 computers. Any and all feedback is welcome here on on the GitHub site.

I played around with it a bit. Every LuaRocks command I run gives me this warning:

Access is denied.
Warning: Could not find a Lua 5.3 interpreter in your PATH. Modules may not install with the correct configurations. You may want to specify the path prefix to your build of Lua 5.3 using --lua-dir

LUA_DIR is correctly configured, and packages seem to install correctly (not extensively tested) despite this. Attempting to set lua_dir from the command line with either `luarocks --lua-dir` or `luarocks config lua_dir` and a pointer to the correct directory fails with, first, "Access is denied.", followed by a long list of attempted executable names, from which the actual name of the Lua interpreter executable is conspicuously missing. If I copy lua.exe to its parent folder, the next attempt to run the config command prints two "Access is denied." messages and then a list of attempted names from which both real executables are missing. All of this happened both with everything first installed to the default locations (inside "C:\Program Files (x86)"), and then again after uninstalling and reinstalling to a newly created folder in the root of the C:\ drive. As previously said, it appears on the surface that packages install correctly anyway (I installed two C modules and successfully called require() on both), so this is likely more annoying than anything else.

Thanks for the report. My bungling of binary files and haphazard testing has possibly found a bug in luarocks 3.2.1. If you download LuaRocks all-in-one version 3.0.3 (only version tested) and replace the installed files, the error goes away.

I had accidentally been running 3.0.3 with the installer for my much of my testing and only discovered the mistake at the end. I updated to 3.2.1 but didn't re-test adequately.

I'll log a bug with LuaRocks.

Thank you for testing. I really appreciate it!

Russ

Merry Christmastide and a Happy New Year!
Russell

[1] Note: Using LuaRocks will pull in another version of LFS for use with the Rocks. LuaRocks pulling in LFS in no way affects WinLua at the moment, though I am unsure which library is actually being used when calling `require()`.

I can't find an LFS pulled in automatically by LuaRocks, but nevertheless, using package.searchpath() confirms that the DLL alongside lua.exe is the one being used.

Notably, if you explicitly run `luarocks install luafilesystem`, `require("lfs")` still uses the one alongside lua.exe, not the new one. It appears there is no way to override the included LFS with an updated version from LuaRocks (e.g. the latest git master, which contains a semi-recent bugfix commit) other than manually deleting the included lfs.dll.