Extension talk:Scribunto

• This page uses "Structured Discussions".
• It has most recently started discussions at the top.
• The page loads dynamically, meaning you can't tell how much more you will see when you scroll down

Previous page history was archived for backup purposes at Extension talk:Scribunto/LQT Archive 1 on 2015-06-10.

I would love to use Scribunto modules, but any time I try to invoke (or even view a module page) I get an error:

Fatal exception of type "MediaWiki\Extension\Scribunto\Engines\LuaCommon\LuaInterpreterNotExecutableError"

Is there some troubleshooting steps I could take to help me determine what I'm missing?

Version information is:

• MediaWiki 1.41.0
• PHP 8.3.4 (litespeed)
• Scribunto – (4b702cb) 21:44, 19 December 2023 (came packaged with MW)

PhpInfo says:

• PCRE 10+
• mbstring enabled

And I set permissions on extensions/Scribunto/includes/Engines/LuaStandalone/binaries/<all OS>/lua to 755

Localsettings.php says

wfLoadExtension( 'Scribunto' ); 
$wgScribuntoDefaultEngine = 'luastandalone';

Hello. I imported w:Template:Cite book to my wiki but when I tried to use it I got:

Lua error in Module:Citation/CS1/Configuration at line 2058: attempt to index a boolean value.

Backtrace:

Module:Citation/CS1/Configuration:2058: in function "init"
package.lua:103: ?
(tail call): ?
mw.lua:496: in function "executeModule"
mw.lua:768: in function "loadData"
Module:Citation/CS1:4394: in function "chunk"
mw.lua:527: ?
[C]: ?

Here are lines 2048-2060:

--[[--------------------------< I D _ L I M I T S _ D A T A _ T >----------------------------------------------

fetch id limits for certain identifiers from c:Data:CS1/Identifier limits.tab.  This source is a json tabular 
data file maintained at wikipedia commons.  Convert the json format to a table of k/v pairs.

The values from <id_limits_data_t> are used to set handle.id_limit.

]]

local id_limits_data_t = {};
for _, limit_t in ipairs (mw.ext.data.get ("CS1/Identifier limits.tab").data) do
	id_limits_data_t[limit_t[1]] = limit_t[2];									-- <limit[1]> is identifier; <limit[2]> is upper limit for that identifier
end

Line 2058 is:

for _, limit_t in ipairs (mw.ext.data.get ("CS1/Identifier limits.tab").data) do

I'm guessing it's something to do with it not being able to pull the data from c:Data:Cs1/Identifier limits.tab. But I'm not really sure how to fix it?

It's actually at c:Data:CS1/Identifier limits.tab (note the capital "S"), and that page does exist... however, it's possible your wiki isn't configured for the same interwiki access that MediaWiki modules would have automatically enabled. (That's a guess, but it seems likely as you'll note the identifier in the source is simply "CS1/Identifier limits.tab" — how would the code know to access that data from https://commons.wikimedia.org/wiki/Data:CS1/Identifier_limits.tab, when it's running on your wiki?)

The data page was only created in January, the discussion about is at w:Help talk:Citation Style 1/Archive 93#Limits. I'm not sure if anyone considered the implications for importing the modules to other wikis. The edit that added its use is this one. Prior to that change, the values were simply hardcoded into the module. Trappist the monk might have some insights into the external-wiki issues with the data import, and how/if your wiki can access the data directly from Commons.

The simplest solution might be to just edit the module to re-hardcode the values. Or, you could try importing the data page into your wiki, if you're set up for a Data namespace and the Tabular.JsonConfig content model, and changing the code to load the data locally from your newly-imported page.

The lua documentation for fetching tabular data is at en:mw:Extension:Scribunto/Lua_reference_manual#mw.ext.data. There are links to more information about tabular data there. I doubt that making a local copy will work because I suspect that the mw.ext.data() function is hard-coded to look for the data in the Data namespace at commons.

Shockingly enough (at least to me), mw.ext.data is the thinnest of wrappers around JsonConfig's PHP code. Any call to mw.ext.data.get() is essentially invoking the JCLuaLibrary.php public function get.

The salient points here are probably that:

1. The entirety of mw.ext.data is supplied by the JsonConfig extension, not by Scribunto.
2. From the error message displayed, it's not clear whether JsonConfig is installed on the wiki in question. (I don't see any sign the mw.ext.data.get function itself is being executed.)
3. If JsonConfig isn't installed, that'd definitely break things.
4. (If it is, it may just need to be configured.)

(None of this changes the fact that re-hardcoding the data — essentially undoing the parts of Trappist's edit that add the lookup code, or replace numbers with data from the external table — is still a viable option for solving this without having to install an entire other extension to the wiki.)

From the error message displayed, it's not clear whether JsonConfig is installed on the wiki in question. (I don't see any sign the mw.ext.data.get function itself is being executed.)

I think if the function wasn’t installed, it resulted in a nil somewhere, not a boolean value. JCLuaLibrary::get(), on the other hand, seems to indeed return false if the content is not found. So probably JsonConfig is installed, but not properly configured.

I doubt that making a local copy will work because I suspect that the mw.ext.data() function is hard-coded to look for the data in the Data namespace at commons.

The problem is exactly that it isn’t hardcoded to use Commons. See Extension:JsonConfig#Supporting Wikimedia templates for how to configure it to use Commons.

Unknown resolution.

This message is occurring no matter what I do. I've made sure that the path is indeed correct, and it is. This is my LocalSettings.php:

$wgScribuntoEngineConf['luastandalone']['luaPath'] = 'C:\xampp\htdocs\w\extensions\Scribunto\includes\engines\LuaStandalone\binaries\lua5_1_5_Win64_bin\lua5.1.exe';

I can't find anything wrong with this, and I can't find anything else by myself, so I'm asking for help. Any ideas?

@La48: I notice that you marked this as "resolved" — presumably that means you were able to correct the issue? It'd be helpful if you posted a quick note regarding how you resolved the issue, for the benefit of future users who are experiencing the same issue, and who might find this topic in a search. Just knowing that it's been fixed for you, without knowing how, isn't really helpful to anyone else.

(You can also use the "Summarize" tool, under the three-dots menu for the thread, to post a quick note about the outcome of the thread, which is helpful because it will be shown even with the collapsed version of the thread.)

Having heard no response in almost a year, regretfully re-resolving.

Help please:

I try to get Lua running in the local version of my Wiki. (Details see below)

I try to create a Module with the "HelloWorld-Example" as copied from different sources. But on saving I get "Lua error: Internal error: The interpreter exited with status 1". Even trying to save an empty Module gives me that error.

In 'C:/xampp/htdocs/LuaError.log I read:

Der Befehl """C:\xampp\htdocs\WRWikiTest\extensions\Scribunto\includes\Engines\LuaStandalone" ist entweder falsch geschrieben oder konnte nicht gefunden werden.

The directory to the Lua files is inprinciple OK - The name of the file to execute is missing. What mean the 2 extra quotes in front of that path which cause the error message?

How do I tell Scribunto/Lua the correct name for the command it shold use here?

-----------------------

Windows 10 Home 22H2

XAMPP for Windows 8.2.12

Mediawiki 1.40.1

Scribunto from Mediawiki Bundle (New Download with GIT works only with the not yet existent MW 1.42!!)

PCRE Library Version 10.40 2022-04-14

PCRE Unicode Version 14.0.0

Multibyte Support enabled

Multibyte string engine libmbfl

libmbfl version 1.3.2

PHP's proc_open function is not restricted.

proc_terminate and shell_exec are not disabled in PHP.

in localsetting.php:

wfLoadExtension( 'Scribunto' );

$wgScribuntoDefaultEngine = 'luastandalone';

$wgScribuntoEngineConf['luastandalone']['errorFile'] = 'C:/xampp/htdocs/LuaError.log';

Thank for any help!

Ernst

I don't know what "MediaWiki Bundle" you're referring to. Maybe try using Scribunto from Special:ExtensionDistributor or the MediaWiki release tarball. The configuration for the path to the Lua binary is $wgScribuntoEngineConf['luastandalone']['luaPath'], and I suspect it's somehow an empty string for you.

Thank you Tim

By "MediaWiki Bundle" I mean the Tarball for 1.40.1

I entered the path-Variable as you propose : $wgScribuntoEngineConf['luastandalone']['luaPath'] = 'C:\xa..." but still "Interner Lua-Fehler: Der Interpreter beendet sich mit dem Status 1."

The message in the ErrorLog File : Der Befehl """C:\xamp... shows an empty string before the correct path. What should be there? The name of the interpreter I guess - how could I enter it?

---

Trying to save a first Module I read in the Debug-Information below the unsaved Module:

...

• [rdbms] LCStoreDB::get [0s] localhost: SELECT lc_value FROM `l10n_cache` WHERE lc_lang = 'de' AND lc_key = 'messages:scribunto-doc-page-name' LIMIT 1
• [ContentHandler] Registered handler for Scribunto: MediaWiki\Extension\Scribunto\ScribuntoContentHandler

and some 50 Lines later:

• [Scribunto] MediaWiki\Extension\Scribunto\Engines\LuaStandalone\LuaStandaloneInterpreter::__construct: creating interpreter: ""C:\xampp\htdocs\WRWikiTest\extensions\Scribunto\includes\Engines\LuaStandalone" "C:\xampp\htdocs\WRWikiTest\extensions\Scribunto\includes\Engines\LuaStandalone/mw_main.lua" "C:\xampp\htdocs\WRWikiTest\extensions\Scribunto\includes" "0" "8""
• [rdbms] Wikimedia\Rdbms\LoadBalancer::reuseOrOpenConnectionForNewRef: reusing connection for 0/wrwikitest
• [rdbms] LCStoreDB::get [0s] localhost: SELECT lc_value FROM `l10n_cache` WHERE lc_lang = 'de' AND lc_key = 'messages:scribunto-luastandalone-exited' LIMIT 1
• [EditConstraintRunner] Checked EditFilterMergedContentHookConstraint, got result: constraint-failed
• [rdbms] Wikimedia\Rdbms\LoadBalancer::reuseOrOpenConnectionForNewRef: reusing connection for 0/wrwikitest

and some 100 lines more.

Can you detect my Problem?

Thank you for your Help.

Greetings from Switzerland Ernst

The incorrect binary path in the log message rules out anything after LuaStandaloneInterpreter.php line 146. I installed MediaWiki 1.40.2 (on Linux) and confirmed that nothing obviously weird is going on. I patched it so that it uses Windows shell escaping, and set the path in LocalSettings.php, with no problems.

It could still be a configuration issue. If you could paste in the rest of the luaPath line from your LocalSettings.php, including the part that you omitted last time, that would help rule out a couple of things.

You could try adding at line 44 of extensions/Scribunto/includes/Scribunto.php

wfDebug( var_export( $wgScribuntoEngineConf, true ) );

Then find the resulting log message and copy it here.

New PC - Windows 11 - New XAMPP - Mediawiki 1.41: Barebone all Extensions enabled

Try to Create Module:Test with "Hello Word" from Lua reference manual results in: "Lua error: Internal error: The interpreter exited with status 1."

On reddit skizzerz means 10 mo ago: "The interpreter shipped with the extension only works on Linux" Is that true? - Hard to believe!

I think installing MediaWiki on Windows could be a fun hobby for a power user, but if you're doing something serious, or if you don't have the ability to collaborate on fixing the problems you encounter, you should just stick to Linux. The last time I installed MediaWiki on Windows was in 2021, but I didn't test Scribunto at the time. The current Windows binaries date back to 2015 and were compiled by our security team and tested up to Windows 10. It's not safe to use unpatched Lua 5.1.5 binaries since there was no release for CVE-2014-5461.

Hello. When I was imported some template and modules for Infobox on my project, I got a error message bellow.

Lua エラー: 内部エラー: インタープリターはシグナル「5」により終了しました。

This means "Lua error: Internal error: The interpreter exited with signal 5". And I get this message in log file.

assertion failed [!mmap_result.is_error && mmap_result.value == kSlabAllocatorInterval.left]: Could not mmap data for the VMTracker slab allocator: 12 (VMAllocationTracker.cpp:278 init)

My environment is MediaWiki 1.38.7 working on Docker and the machine is MacBook Air M2. Others info are bellow.

MediaWiki	1.38.7
PHP	8.0.29 (apache2handler)
MariaDB	11.1.2-MariaDB-1:11.1.2+maria~ubu2204
ICU	67.1
Lua	5.1.5
Pygments	2.11.2

I was searched it, then the cause may related with ARM64 architecture but not sure.

What should I do for fixing this issue? If you need any additional info, I'll be happy to give it.

Thank you.

You probably need to raise the memory limit. In LocalSettings.php try

 $wgScribuntoEngineConf['luastandalone']['memoryLimit'] = 200_000_000;

@Tim Starling

Thank you for replying. I tried it, and edited some files. Then this error was fixed. All steps are bellow.

Copy /usr/local/etc/php/php.ini-production in virtual machine to local. And rename it to php.ini.

Edit php.ini.

memory_limit = 256M.

Add following code in Dockerfile.

COPY php.ini /usr/local/etc/php

RUN apt-get -y update && apt-get -y install lua5.1

Add following code in LocalSettings.php.

$wgScribuntoEngineConf['luastandalone']['luaPath'] = '/usr/bin/lua5.1';

$wgScribuntoEngineConf['luastandalone']['memoryLimit'] = 268435456; # bytes

$wgMaxShellMemory = 262144; # KB

Hope this to help someone :-)

Lua shell_exec() function needed to be enabled in hosting configuration

I installed this extension and am getting this error: Error: Call to undefined function MediaWiki\Extension\Scribunto\Engines\LuaStandalone\shell_exec().

The extension version I have is: – (9eeb97d) 02:13, November 28, 2023

The only configuration line in LocalSettings.php is $wgScribuntoDefaultEngine = 'luastandalone';.

Here is the system setup:

Installed software

Product	Version
MediaWiki	1.39.5
PHP	8.1.26 (fpm-fcgi)
MariaDB	10.4.20-MariaDB-1:10.4.20+maria~buster-log
ICU	65.1
Lua	5.1.5

Is this a common error? Any help is appreciated!

Edit: in case it helps, here is the backtrace:

Backtrace:
from <redacted>/public_html/w/extensions/Scribunto/includes/Engines/LuaStandalone/LuaStandaloneEngine.php(89)
#0 <redacted>/public_html/w/extensions/Scribunto/includes/Engines/LuaStandalone/LuaStandaloneEngine.php(49): MediaWiki\Extension\Scribunto\Engines\LuaStandalone\LuaStandaloneEngine->getClockTick()
#1 <redacted>/public_html/w/extensions/Scribunto/includes/Hooks.php(305): MediaWiki\Extension\Scribunto\Engines\LuaStandalone\LuaStandaloneEngine->reportLimitData()
#2 <redacted>/public_html/w/includes/HookContainer/HookContainer.php(338): MediaWiki\Extension\Scribunto\Hooks::reportLimitData()
#3 <redacted>/public_html/w/includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook()
#4 <redacted>/public_html/w/includes/HookContainer/HookRunner.php(2947): MediaWiki\HookContainer\HookContainer->run()
#5 <redacted>/public_html/w/includes/parser/Parser.php(827): MediaWiki\HookContainer\HookRunner->onParserLimitReportPrepare()
#6 <redacted>/public_html/w/includes/parser/Parser.php(766): Parser->makeLimitReport()
#7 <redacted>/public_html/w/includes/content/WikitextContentHandler.php(301): Parser->parse()
#8 <redacted>/public_html/w/includes/content/ContentHandler.php(1721): WikitextContentHandler->fillParserOutput()
#9 <redacted>/public_html/w/includes/content/Renderer/ContentRenderer.php(47): ContentHandler->getParserOutput()
#10 <redacted>/public_html/w/includes/EditPage.php(4535): MediaWiki\Content\Renderer\ContentRenderer->getParserOutput()
#11 <redacted>/public_html/w/includes/EditPage.php(4438): EditPage->doPreviewParse()
#12 <redacted>/public_html/w/includes/EditPage.php(3144): EditPage->getPreviewText()
#13 <redacted>/public_html/w/includes/EditPage.php(779): EditPage->showEditForm()
#14 <redacted>/public_html/w/includes/actions/EditAction.php(73): EditPage->edit()
#15 <redacted>/public_html/w/includes/actions/SubmitAction.php(38): EditAction->show()
#16 <redacted>/public_html/w/includes/MediaWiki.php(542): SubmitAction->show()
#17 <redacted>/public_html/w/includes/MediaWiki.php(322): MediaWiki->performAction()
#18 <redacted>/public_html/w/includes/MediaWiki.php(904): MediaWiki->performRequest()
#19 <redacted>/public_html/w/includes/MediaWiki.php(562): MediaWiki->main()
#20 <redacted>/public_html/w/index.php(50): MediaWiki->run()
#21 <redacted>/public_html/w/index.php(46): wfIndexMain()
#22 {main}

Okay, after further Googling, I figured out that shell_exec() is a PHP function. I went to my host settings and saw it was disabled. I enabled it and the error went away.

I find out frame.args will receive parsed wikitext, so how to get raw wikitext without using <nowiki> tag?

You can get the unparsed wikitext of an entire page using title:getContent(). I don't think there's a way to get unparsed wikitext of just the template arguments.

It’s definitely impossible at the moment, and I don’t even think it would be possible at all to implement it in Scribunto: by design, the MediaWiki parser only allows getting expanded (parsed) contents of template/parser function arguments.

If you think about it, it's kind of a logistical impossibility — how can a module possibly ask the parser to supply anything without first... well... parsing it? The wikitext containing the {{#invoke:... }} has to be parsed for the interpreter to even identify that a Lua module is being called; which one, specifically; and how the remainder of the text up to the closing }} represents any arguments to the call.

The ‎<nowiki>...‎</nowiki> feature exists specifically because that IS the method of telling the parser, "hands off this chunk of content, I want it to be preserved in an unparsed state as it moves through the parse tree" — or to put it another way, to "get raw wikitext". Without those tags, you're gonna get the results of the parser doing its job on whatever it finds.

It'd require direct modifications to the wikitext parser itself, for it to also store and make available the unparsed version of the child content at each node in the parse tree without needing to use ‎<nowiki>...‎</nowiki>.

Maybe you should read the code before so confidently declaring it impossible. It seems pretty straightforward to me.

Arguments (apart from the first argument which has the module name) are stored as a node in a parse tree. You can recover the original wikitext by calling PPFrame::expand() on the node with the PPFrame::RECOVER_ORIG flag. Reversibility is a strong requirement for the preprocessor due to its use in pre-save transform. When you save wikitext, the preprocessor is taking it apart, expanding subst tags, and then putting it back together again.

We could add say frame:getRawArgument() which would pass a flag up to LuaEngine::getExpandedArgument(). Then add a flags parameter to PPFrame::getArgument() and call it with RECOVER_ORIG.

Maybe request it in Phabricator if you want something like this.

That would be phab:T322513, reported a year ago.

Hello ! On a mediawiki installed on web host (https://www.ovhcloud.com/en-gb/web-hosting/professional-offer/ ) I have this error when i try to open Module or Template using modules.

this is my specs :

Produit	Version
MediaWiki	1.39.3
PHP	7.4.33 (fpm-fcgi)
MySQL	5.7.42-log
ICU	63.1
Lua	5.1.5

according to Extension:Scribunto :

• pcre: 10.35 2020-05-09 (>8.33)
• pcntl: no (but not "requirement removed in Scribunto for MediaWiki 1.29.")
• mbstring: yes
• `function_exists("proc_open")` on php file retruns `true`

• `$wgScribuntoDefaultEngine = 'luastandalone';` on LocalSettings.php

• I did `chmod 755 /path/to/extensions/Scribunto/includes/engines/LuaStandalone/binaries/lua5_1_5_linux_64_generic/lua` on ssh (because `uname -m` returns `x86_64`)

• `uname -r` returns `5.15.80-ovh-vps-grsec-zfs-classid`

does anyone have any idea where this might come from? Is it coming from the web hosting environment? How to test if Lua can be executed on the server? (I tried a simple "./lua" and it gives "segmentation fault")

@Marcellinjobard:

I tried a simple "./lua" and it gives "segmentation fault"

Well, that's probably a bad sign, as it should start an interactive lua session, displaying a > prompt and waiting for input. If it's crashing when you run it from a shell, there's a good chance it's crashing when PHP tries to run it too. But as to why it's crashing... tricky to say.

Some things you can try (assuming your current directory is .../extensions/Scribunto/includes/engines/LuaStandalone/binaries/lua5_1_5_linux_64_generic/):

1. It's possible the crash is only in the interactive interpreter; perhaps it's having trouble accessing the terminal for some reason. In that case, executing a lua statement defined in the arguments might have a different outcome. Here's a simple one you can try:

   ./lua -e 'print(math.pi)'
   

   On my system that outputs 3.1415926535898.
2. If that also segfaults, and ldd is available in the environment, you can check what libraries the dynamic loader is resolving for the binary. But its dependencies are pretty minimal, and unlikely not to be met. On my Fedora 38 system:

   $ ldd ./lua
    linux-vdso.so.1 (0x00007ffced7d1000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f4bb40dd000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f4bb3c22000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f4bb4206000)
   

3. If gdb is available, you could run the binary in the debugger, so you'd at least get a stack trace when it segfaults. To do that, you'd:

   # Run the debugger and load the lua binary
   $ gdb ./lua
   # When you get a '(gdb)' prompt, gdb is waiting for debugger commands
   
   # First, run that same math.pi test
   (gdb) run -e 'print(math.pi)'
   
   # When the program segfaults and drops you back to the debugger again,
   # collect a stack trace
   (gdb) bt
   

Unfortunately, you won't have any debugging symbols loaded, so that stack trace is going to be pretty incomprehensible. Still, it might at least give us a hint of whether the crash is occurring on a lua binary instruction, or if it's something deeper down inside one of the system libraries.

We depend on the stability of the glibc ABI for these binaries to keep working. But I was able to get a prompt with the current Lua binary (compiled in 2015) and glibc 2.38 (the latest stable).

Does anyone have any other suggestions for the 'The interpreter has terminated with signal "11"' error?

I'm using Scribunto with Semantic Mediawiki. I just upgraded to MW 1.39.5. I'm using it with SMW 4.1.2. Every time I upgrade I have to navigate getting SMW working again. It's never a smooth transition.

I set /wiki/extensions/Scribunto/includes/engines/LuaStandalone/binaries/lua5_1_5_linux_64_generic/lua to 755 so it is executable.

I have '$wgScribuntoDefaultEngine = 'luastandalone';' in LocalSettings.php.

The only other suggestion that is everywhere on the internet is the: require_once "$IP/extensions/Scribunto/Scribunto.php"; $wgScribuntoDefaultEngine = 'luastandalone'; $wgScribuntoEngineConf['luastandalone']['luaPath'] = '/opt/lua/bin/lua';

But I feel like it should just work as it was intended without all that and I've managed to make it work before. I'm just not sure now what I did. Is there something else that typically needs to be done?

Signal 11 is a segmentation fault, but that's not enough information to isolate this problem. What is your operating system and/or what version of libc are you using? Does that binary give you a prompt when you run it from the command line?

Question moved from the Lua manual talk page

Dear community, I have two questions, which are about parsing on both the input and output side of using #invoke:

- Is there a way to pass content as an argument to "invoke" without having it parsed first? From what I read I suspect not but I may have overlooked something. For instance, I tried to write a Lua equivalent to Page Forms's #arraymap parser function, but ended up creating one that would only accept a 'masked' version of wiki syntax.

- Is there a way to output content from a module leaving it unparsed so that, for instance, it can be passed to/reused by other parser functions? Something similar to using a parser function with the appropriate ishtml/noparse settings. (I know there's another way, which is to call those other parser functions within Lua, but that's not quite what I'm asking)

In the meantime, I found that the answer to both these questions is yes and that <code>mw.text.nowiki</code> is what provides the solution.