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.
Related
Has anyone got dxgettext running under Windows 10?
I installed dxgettext from the offical homepage under Windows 10, which worked fine.
But whenever I try to run some of the installed tools (e.g. msgfmt.exe), they don't really run, but call themselves again, generating thousands of processes and making the system crawl.
This is what happens:
I call msgfmt --help
the executable msgfmt hangs, blocking the command window
in the TaskManager I see houndreds of msgfmt.exe processes popping up
I think, I have to replace the gettext tools of the dxgettext package with some newer version but before trying to figure it out I first wanted to ask if someone else experienced similar problems and found a working solution.
My questions:
Has anyone got the tools coming with dxgettext running under Windows 10?
What steps have been necessary to get it to run?
I resolved the problem in the following way:
I downloaded https://github.com/mlocati/gettext-iconv-windows/releases/download/v0.19.8.1-v1.14/gettext0.19.8.1-iconv1.14-static-32.zip from https://mlocati.github.io/articles/gettext-iconv-windows.html
I replaced the following files from the installation directory of dxgettext with files from the zip archive:
msgattrib.exe
msgcat.exe
msgcmp.exe
msgcomm.exe
msgconv.exe
msgen.exe
msgexec.exe
msgfilter.exe
msgfmt.exe
msggrep.exe
msginit.exe
msgmerge.exe
msgunfmt.exe
msguniq.exe
xgettext.exe
Result:
Dxgettext and the tools, I use, seem to work fine. I found no problems with my workflow so far, with one exception:
If I use assemble to embed mo-files into an exe compiled with JvGnugettext.pas, I get the following error:
Pach code “6637DB2E-62E1-4A60-AC19-C23867046A89” was not found in .exe file. Are you sure the .exe file has been compiled with the correct libraries?
This may not be related to the original problem. However, it is resolved by replacing the original assemble.exe with the version from https://sourceforge.net/p/dzlib/code/HEAD/tree/buildtools/trunk/ (see answer by #dummzeuch).
The installer on the official home page is pretty old. Last time I looked it contained several outdated dlls and executables from the original gnugettext project that did not work correctly under recent Windows versions. You could take those from my buildtools repository on OSDN. These work for me. No guarantee that they work for you though.
https://osdn.net/projects/dzlib-tools/scm/svn/tree/head/buildtools/trunk/
I've been having these issues too with dxgettext 1.22, in Windows 10 1607. I changed some DLLs at first but kept having the bash.exe looping and hogging my PC to death.
So what I did was basically install latest Cygwin 32bit and replaced the appropiate DLLs. I kept the ones for gettext. Instructions:
Download and fresh install dxgettext-1.2.2.exe from http://dxgettext.po.dk/download as admin. Restart.
Download Cygwin 32bit from https://cygwin.com/install.html in a different folder from dxgettext (I took the default, c:\cygwin)
Run setup-x86.exe and select "Base" Package (Install). Next, Select Required packages just in case.
Move the following files from dxgettext folder to a backup folder (we'll use some DLL later):
cyg*.dll
bash.exe
Copy from c:\cygwin to the dxgettext folder the following files:
bash.exe (set to run as admin)
cygwin1.dll
cygiconv-2.dll
cygintl-8.dll
cygreadline7.dll
cyggcc_s-1.dll
cygncursesw-10.dll
Recover the file(s) below from the backup folder (See #4) and copy to the dxgettext folder.
cyggettextsrc-0-14-1.dll
cyggettextlib-0-14-1.dll
cygintl-3.dll
Running like this, you might get error 740 (requires elevation). So: Set ggmerge.exe,ggfmt.exe to run as admin
** EDIT** Found online this very interesting link, from a programmer who offers a free backup written in Delphi. The good thing is he adapted the dxgettext tools to run in Windows 10. This helped me a lot.
http://personal-backup.rathlev-home.de/translate.html
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.
I am a newb with python and just learning what to do.
I am using pyscripter and have been for a while whilst learning.
I am now going through an online course which is taught in 2.6, yet my pyscripter uses the latest.
I need to know how to change it to use an older version, I have seen replies about changing the PATH variable but not where it is or how to do it.
I have 3 versions of python on my machine, 25,26 and 33.
I don't know if this is the best way to do it, but those are the two ways I did it:
WAY 1 (The best of two)
Go to PyScripter>>Tools>>Options...>>Custom Parameters... and add the following values
1. PythonDir = C:\Program Files\CustomPythonInstallation
2. PythonExe = C:\Program Files\CustomPythonInstallation\python.exe
3. PythonVer = 3.3.3
Note: Adapt the Name = Value pairs above to your case.
And close the window with OK button.
Now select PyScripter>>Run>>Python Engine>>Remote and your are ready to go.
WAY 2 (The more temporary solution)
Go to PyScripter>>Run>>Configure External Run...
set the "Application:" field to your python.exe file
Close the window with OK button.
Make sure you run your scripts with PyScripter>>Run>>External Run (Alt+F9)
I hope this helped, good luck.
The easiest way I know (on Windows) is, having used the installer executable, I select from the Start menu's PyScripter folder whichever version of Python I want to run.
You can modify the PYTHONPATH (under Pyscripter>>Tools, for instance)
You can modify your External Python Interpreter with Pyscripter>>Modify Tools>>Python &Interpreter>>Modify
You can modify the default Python engine used with Pyscripter>>Options>>IDE Options>>Python Interpreter>>Python Engine Type
You can simply redirect Pyscripter to see the environment of a different Python distribution.
In Windows, do this by assigning PYTHONDLLPATH in the Pyscripter shortcut. You can r-click on the shortcut, access its properties and then set the target to:
[Pyscripter executable dir] --PYTHONDLLPATH [Python distribution dir]
See this image to help you out:
setting a shortcut target
For example, in my Win10 64-bit computer I have a Python 2.7.8 installation back from when I installed ArcGIS, which is automatically recognized by my 32-bit Pyscripter installation.
In the same computer, I also have Anaconda installed with two environments that feature two 64-bit Python distributions:
2.7.14 in "C:\ProgramData\Anaconda2"
3.6 in "C:\Users\bouzi\AppData\Local\conda\conda\envs\py3"
When I installed a 64-bit version of Pyscripter, that Pyscripter version couldn't even open, as it couldn't find the conda distributions. I had to point them to it by replacing the shortcut target to:
"C:\Program Files\PyScripterx64\PyScripter.exe" --PYTHONDLLPATH "C:\ProgramData\Anaconda2"
You can create three Pyscripter shortcuts that point to these different installations of Python within your system. It's probably not the optimal way to deal with this but it works, and allows you to combine Anaconda environments with Pyscripter.
You can also read more on opening non-standard python distributions with PyScripter from this link.
Run->Python Versions -> setup Python Versions -> Add... select folder
p.s.
python 3.7.3 - ok,
still python 3.10.5 could not be identified by PyScripter in such a way (actually works with WAY_1 Solution in this thread but pip install under such env. not succeed afterwards)
First some background. I recently installed some software (TeX live actually), and the binaries were placed by the installer in a non-standard location (/usr/local/texlive/2011/bin/x86_64-linux). No problem, because I can change the $PATH in to include this directory. However, I use latex inside Makefiles, and Make said it could not find 'latex'. I eventually realized that Make asks the kernel to run latex in a shell-independent way. Thus I moved all my latex executables to /usr/local/bin and everything works, presumably because the kernel can now see the executables.
If this is correct, my question is: where does the kernel look for executables when asked to run a program when this is independent of a shell?
The kernel doesn't look for executables - it is always told the (absolute or relative) path. All program executions (I believe) basically come down to calling the execve() function, which needs to be told the path of the executable.
When you call programs using just their names, it's up to whatever is interpreting your commands (shell, make) to locate the program. Alternatively, library functions such as execlp() can be used, which do the path resolution themselves (see "Special semantics").
According to http://fadeyev.net/2010/06/19/lessjs-will-obsolete-css/ I should be able to set up a "watch" feature for less.
I mainly work directly on remote servers. Either through opening up file directly through FTP or using a server found through a network.
Will this still work? Or do the files have to be local to be "watched"?
I'm using Windows if that makes a difference.
Many thanks
The watch feature is something that happens on your own local development computer. You could run it on your server, but it would have to run constantly in the background, so it's probably not the best option. The watch options is not a feature of less.js, but instead of other LESS CSS compliers. A compile operation is usually a one-time operation, i.e. you call the compiler, it compiles and returns you to the shell prompt. With the -w or --watch switch, your LESS compiler will watch your specified .less file(s) and convert them as soon as they change.
This watching features is a design-time live compiler option, whereas with less.js your less files are converted at run-time. Another alternative is a compile-time operation where you invoke a less compiler as part of a build step (like with Ant).
Ruby
If you do gem install less with Ruby installed, you get the old command-line Ruby compiler. It isn't kept up by Cloudhead anymore, so it's mostly unsupported and doesn't get any new features, etc. When you run it, you can call lessc input.less output.css -w. Without the -w switch at the end, LESSC will compile it one time and return you to your prompt. With the -w switch, it will continue to watch the file for changes and recompile it each time you edit the file.
.NET
If you have DotLessCSS, (you're probably on windows) you can type dotless.Compiler input.less output.css --watch which does the same thing.
PHP
If you are using LESSPHP, you can also call that from the command line with plessc -w input.less output.css, again, the -w will do the same thing.
Mac
If you are on a mac, you can use LESS.Air. Specify which files you want the app to look at, tell it you want it to keep watching those files, and it will compile in the background without the command line.
Air
On Windows, Mac or Linux, you can use this less parser which is a clone of LESS.Air. It works the same way, but is cross-compatible and uses less.js under the hood.