I am making a script that requires lmapm, but I'm not quite sure how to install it. I have 4 files,
lmapm.c
test.lua
README
Makefile
And I'm not sure how to use them in my lua environment. Lua 5.1 is installed on my desktop in a folder called "5.1", and it was installed with LuaRocks (If that matters) I know lua libraries are used with require, but this is a c file, not a lua file.
How can I install/use lmapm in my lua programs?
Upon reading the readme it tells me to run make, but makefile is just a "file" on my computer, there is nothing I can run it with.
README: Short description of what you got and how to install & use the module at the end.
test.lua: Lua script to test the module/sample of usage.
lmapm.c: C source code and the module in raw/still unusable form. Needs to get compiled and linked to a dynamic library of target platform.
Makefile: Automatic build instructions to compile&link lmapm.c to what you finally use in Lua.
Makefile serves as a macro which makes building easier with minimal input by users. To run this file, you need program make (comes with GNU toolchain; on Unix install package build-essential, on Windows MSYS). Before you have to fix the path to your Lua and MAPM installation (as mentioned in the official build instructions). Furthermore you need the C compiler and linker (which you already installed on Unix together with make and have to install on Windows by f.e. MinGW).
The result is a dynamic library/Lua C module which you can require simply by its filename. To put it in the scope of Lua, move it in the application or (better) in the Lua modules directory.
Related
I am running a MediaWiki (1.34.1) on a Windows server. The wiki contains some Lua modules which are executed by the Scribunto extension running Lua 5.1.4.
Up to now I am using the luastandalone but I would like to use the luasandbox engine (should be faster).
With the lastest PHP luasandbox release 4.0.2 PECL provides a Windows DLL (https://pecl.php.net/package/LuaSandbox/4.0.2/windows).
With this DLL is it possible to run luasandbox under Windows?
How can I install/configure the PHP/MediaWiki/Scribunto environment to use this DLL?
Yes, it is possible to use LuaSandbox under Windows with IIS, and is in fact an especially convenient way to do so, You simply install the necessary Lua binary as a PHP extension into your existing PHP interpreter (which you know is working, because MediaWiki is implemented in PHP).
I discuss this at some length in this conversation on the MediaWiki page Extension Talk:Scribunto but I'll provide the essentials here as well:
I did finally get Lua working under IIS on Windows 10, with PHP 8.0. The trick was, I abandoned the luaStandalone binary entirely, and instead downloaded the (just released less than 2 months ago) PHP luaSandbox extension from PECL:
https://pecl.php.net/package/LuaSandbox
Click on "DLL", then choose the build that matches your PHP install (for me it was PHP 8.0, x64, non-thread safe — the details are at the very top of the long, long output of php.exe -i from a command line), and download the provided zip file. After extraction, only two files are important:
php_luasandbox.dll, a PHP extension module that goes wherever the rest of your extensions are. (For me, C:\Program Files\PHP\v8.0\ext\.)
lua5.1.dll, an embeddable Lua interpreter that gets installed in the directory where the php.exe binary lives. (For me that was C:\Program Files\PHP\v8.0\, the parent directory of the extension location).
After that, just edit your php.ini to add:
extension=php_luasandbox.dll
and edit LocalSettings.php to include:
$wgScribuntoDefaultEngine = 'luasandbox';
(making sure to remove or comment out any lines about luaStandalone).
Relaunch IIS, and that should be that. If you have MediaWiki working at all, you've already got PHP running, so using Lua that way, as a PHP extension, just makes eminent amounts of sense.
As I note in the MediaWiki discussion, there's some degree of controversy over this because the Lua developers themselves are sort of down on the notion of a "sandboxed Lua". They do not believe it to be a technically viable method of restricting Lua's access to and consumption of system resources. But on Windows, most of the restrictions they recommend imposing on the standalone binary are not available from the OS anyway, making the situation even more confusing/unclear.
When writing luarocks install gumbo
In the location/directory of my luarocks file in cmd, I am getting the following error
Warning: Could not find Lua 5.3 in 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
Installing https://luarocks.org/gumbo-0.5-1.src.rock
Error: Failed finding Lua library. You may need to configure LUA_LIBDIR.
I've added lua53.exe to the same directory, and added the file both to my user variables and system variables in control panel.
Not sure if worth mentioning, but when running lua53.exe and trying to use luarocks install gumbo from there,
the lua53 cmd-like window responds with stdin:1: syntax error near 'install'
I was hoping to do some web scraping with lua, and later on building a World of Warcraft addon that utilizes gumbo to show certain helpful information within the WoW client, but I can't seem to even get the most basic stuff to work...
Setting up LuaRocks on Windows is annoying and I'm not familiar with it myself. If you added both the LuaRocks and Lua 5.3 Windows binaries (Executables and Includes) to your Path system variable:
luarocks path prints the commands for setting up the LUA_PATH and LUA_CPATH system variables.
The config.lua file tells you what your variables.LUA_LIBDIR value is. You can check it with luarocks config. For me that file would be in:
C:/Users/Ketho/AppData/Roaming/luarocks/config-5.3.lua
otherwise you can create an empty file there and put in this line to point it to wherever your Lua folder is:
variables.LUA_LIBDIR = "C:/lua-5.3.5_Win32_bin"
variables.LUA_INCDIR = "C:/lua-5.3.5_Win32_bin/include"
As for using gumbo to show information within WoW, the addon environment is sandboxed. Unless you meant you just want to get the data to hardcode into your addon.
I've started to really get into using Lua, and a few months ago I've figured out on how to turn .lua files into executables.
It's been working great so far, until I started to compile lua scripts that use 'socket.http'. It seems to be missing some DLLs of some sort, and I don't know how I would be able to add them into the same folder.
Where would I find these such DLLs to add into the same folder of my executable, so that I could be able to run Lua executables using socket.http?
socket.http module doesn't come as DLL; it comes as a pure-lua module. Usually there is socket.lua and socket\http.lua files (as well as socket\core.dll), so you'd need to package all of them and make them available to your script to make it work.
You can find the Lua files in the luasocket repository, but make sure that they match the API for the binaries (socket/core.* files) you are using.
I'm trying to compile PyPy for use on an OpenWrt configuration, but I am having a really hard time doing it.
My main problems are:
Each time I change the Makefile I am forced to start the translating process of PyPy again. Is there a way to avoid this?
Would copying just the compiled pypy-c and lib*.so binaries do it, or would I have to copy everything from the compiled files of PyPy?
Here is the directory structure after running make on the files.
How do I specify the version of GCC to use? I've tried to do this without success.
How would I get the interpreter to run after installing it on OpenWrt?
One can also compile PyPy using PyPy itself, which gives a .tar file with a different structure (no Makefile, pypy executable etc). Can I use that instead of building it from the source?
Here is my Makefile.
include $(TOPDIR)/rules.mk
PKG_NAME:=PyPy
PKG_VERSION:=5.8.0
PKG_RELEASE:=1
PKG_MD5SUM:=504c2d522595baf8775ae1045a217a2b120732537861d31b889d47c340b58bd5
PKG_SOURCE_NAME:=pypy2
PKG_SOURCE_URL:=https://bitbucket.org/pypy/pypy/downloads/
PKG_SOURCE:=$(PKG_SOURCE_NAME)-v$(PKG_VERSION)-src.tar.bz2
PKG_BUILD_DEPENDS:=python
PKG_CAT:=bzcat
PKG_BUILD_DIR:=$(BUILD_DIR)/$(BUILD_VARIANT)$(PKG_SOURCE_NAME)-v$(PKG_VERSION)-src
include $(INCLUDE_DIR)/package.mk
$(call include_mk, python-package.mk)
define Package/PyPy
SECTION:=utils
CATEGORY:=Utilities
TITLE:=PyPy
URL:=https://pypy.org/index.html
DEPENDS:=+libffi +libexpat +libunwind
endef
define Package/PyPy/description
PyPy is an alternate implementation of the Python programming language written in Python.
This distribution is for Linux architecture, using Python 2.
endef
define Package/PyPy/install
$(INSTALL_DIR) $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/pypy-c $(1)/usr/bin
$(CP) (PKG_BUILD_DIR)/*.so $(1)/usr/lib
$(INSTALL_BIN) $(PKG_BUILD_DIR)/pypy/bin/* $(1)/usr/bin
endef
define Build/Compile
$(MAKE) -C $(PKG_BUILD_DIR)
endef
$(eval $(call BuildPackage,PyPy))
I would need to see the entire process: the part of the Makefile above, the other pieces such as rules.mk, package.mk, command line arguments and environmental variables in order to understand what is not working
The Makefile in question is not supported, the developers do not use it, and as you discovered it does not work well. As described in the build page, building PyPy from source is a four part process, and the Makefile mashes three of those stages together so any changes currently require restarting from 0. Note that the underlying build process uses PYPY_USESSION_DIR, PYPY_USESSION_BASENAME, and a numbering system to ensure that each time the first stage (translation from RPython to C) puts the results in a new, clean directory. For this reason if you restart the process you will lose your previous work.
Python is both a binary interpreter and a stdlib of "battery included" modules. If you wish to use the binary interpreter, you need to install the binary and the stdlib support files together since they work as a unit. That is why we specify a fourth step in the build page, packaging. Please read that section carefully for methods of using the interpreter+stdlib
PyPy does not really support cross compiling, one method that used to work is described in the documentation of RPython. PyPy does support native gcc and/or clang. What compiler are you trying to use on what hardware?
Run the interpreter as you would any python interpreter; specify the path to the executable file, which (as stated above) needs to know how to find the support files such as the stdlib and the site-packages directory of third-party modules installed specifically for PyPy.
Using PyPy to build PyPy should be no different than using CPython to build PyPy, except it will be much faster. The differences you see must be an artifact of how you are building.
I would recommend you NOT use the unsupported Makefile until you understand the build, compile, package, install process, and then once you have a working installation help the PyPy project improve the process until it can be automated into a Makefile
If you are running OpenWRT on supported hardware and operating system, you would be much happier using a binary distribution and not compiling from source. In this case your Makefile should download a binary distribution and simply install it.
If you are using a different CPU, chances are PyPy will not work out-of-the-box on your hardware, you will have to run tests to make sure the JIT will actually make things faster.
Generally, when a Perl module installs an executable script, it somehow changes the #!/usr/bin/perl line to point to the appropriate Perl path. For example, if I used the perl installed at /usr/local/bin/perl to install the module, then the shebang line will be changed to #!/usr/local/bin/perl, so that the installed script will always use the version of perl that installed it.
What does this, and how can I do it in my own modules that install scripts?
Edit
Note that I am specifically talking about executable perl scripts that are distributed as part of a Perl module. Since a module is installed to a specific version of Perl, any scripts installed by that module must use that same version, so #!/usr/bin/env perl is wrong.
From http://metacpan.org/pod/ExtUtils::MakeMaker
EXE_FILES
Ref to array of executable files. The files will be copied to the INST_SCRIPT directory. Make realclean will delete them from there again.
If your executables start with something like #!perl or #!/usr/bin/perl MakeMaker will change this to the path of the perl 'Makefile.PL' was invoked with so the programs will be sure to run properly even if perl is not in /usr/bin/perl.