Extension talk:Scribunto/2023

• 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

Special:WantedModules?

Is there any way to generate an equivalent to Special:WantedTemplates to show missing modules? Peculiar Investor (talk) 17:15, 6 January 2023 (UTC)

I thought S:WantedTemplates already listed modules, but after testing, much to my surprise it does not. It looks like the relevant Phab ticket is phab:T104002. 「ディノ奴千？！」^{☎ Dinoguy1000} 09:05, 7 January 2023 (UTC)

I'm surprised that would even work, with Modules. A missing module results in a Script error: No such module... message from Scribunto, not a redlink. (Redlinks are how the other "Wanted ..." lists get populated.)

I'd have expected the issue to be that Scribunto itself needs to track missing modules. After all, {{#invoke:}} will never be missing as long as Scribunto itself is installed. But, maybe it already knows how to track those script failures as "module redlinks". FeRDNYC (talk) 00:09, 12 January 2023 (UTC)

Yes, it does and should track script failures as redlinks – treating them as readlinks ensures that the script failures go away once the module is created, otherwise the parse result with the script error could get stuck in the cache. Tacsipacsi (talk) 23:23, 12 January 2023 (UTC)

Intermittent "open_basedir restriction" errors

I have a private wiki and while I don't have root access to the server, I do have SSH credentials which allowed me to install and set up Scribunto/Lua.* Scribunto is working most of the time, but it is on the odd occasion, probably after an edit, that I get the infamous error message:

proc_open(): open_basedir restriction in effect. File(/dev/null) is not within the allowed path(s): [...] in [...]/extensions/Scribunto/includes/engines/LuaStandalone/LuaStandaloneInterpreter.php on line 154

The error reports I found all point to basic installation issues (forgetting to chmod stuff, not having access to SSH, etc.), but in my case, the error message is both sporadic and temporary.

• P.S. in Plesk, I had already set open_basedir to {WEBSPACEROOT}{/}{:}{TMP}{/}{:}/dev/null{:}/bin/bash Cavila 09:40, 26 January 2023 (UTC)

How to spot scripting errors when there is no error message?

Wiki pages with unresolved issues relating to their use of modules are automatically added to "Category:Pages with script errors", which is quite helpful. There are, however, wiki pages in the same category that show no sign of anything being incorrect, whether in the module itself or in the way it is used. No error messages appear on the page, so how do we learn what's happening. Or are there perhaps kmown issues with false positives? Cavila 09:11, 2 February 2023 (UTC)

P.S. The category label is visible at the bottom of pages with visible errors but invisible on pages with invisible errors, although the latter are listed on the category page and do show the category when inspected through SMW's Special:Browse. I'm beginning to suspect that this might just be an issue with MediaWiki categories lagging behind. Cavila 08:53, 3 February 2023 (UTC)

Error when switching to Luasandbox: Scribunto_LuaInterpreterNotFoundError

I installed a new Instance of MediaWiki 1.39 on a Debian 11 server with PHP 8.2.2. I installed the Scribunto extension (and its dependencies) with Luastandalone binaries at first and it worked. A script that we would like to use seems to meant for Luasandbox, though, so I wanted to switch to Luasandbox.

I followed the instructions from Extension:Scribunto and LuaSandbox. Because the prepackaged installation with "sudo apt-get install php-luasandbox" only seems to be able to get packages for php7.4 I used the manual installation.

Following the installation php -ini lists:

luasandbox

luasandbox support => enabled

and php -m contains:

luasandbox

In the LocalSettings.php I removed the other Scribunto entries and added

$wgScribuntoDefaultEngine = 'luasandbox';

instead.

The Special:Version page continued to list Scribunto as an active extension but when a script is invoked, it failes with an Internal Error:

Fatal exception of type "Scribunto_LuaInterpreterNotFoundError"

Does anybody know why this happens or have any pointers on how to diagnose the issue further? How can I make sure Scribunto looks in the right place? (i.e. the location where I downloaded and compiled the luasandbox files as described in the installation instructions) Are there any additional log files I could check? Lumenalbum (talk) 16:04, 12 February 2023 (UTC)

Error: Call to undefined function

Hi!

Recently I upgraded mediawiki from 1.39.1 to 1.39.3. Initially there was no problems but Now I'm getting this error on most of my pages:

Error: Call to undefined function MediaWiki\Extension\Scribunto\Engines\LuaStandalone\shell_exec()

Backtrace:

from /home/escforumwiki/public_html/extensions/Scribunto/includes/engines/LuaStandalone/LuaStandaloneEngine.php(89)

#0 /home/escforumwiki/public_html/extensions/Scribunto/includes/engines/LuaStandalone/LuaStandaloneEngine.php(49): MediaWiki\Extension\Scribunto\Engines\LuaStandalone\LuaStandaloneEngine->getClockTick()

#1 /home/escforumwiki/public_html/extensions/Scribunto/includes/Hooks.php(305): MediaWiki\Extension\Scribunto\Engines\LuaStandalone\LuaStandaloneEngine->reportLimitData(ParserOutput)

#2 /home/escforumwiki/public_html/includes/HookContainer/HookContainer.php(338): MediaWiki\Extension\Scribunto\Hooks::reportLimitData(Parser, ParserOutput)

#3 /home/escforumwiki/public_html/includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook(string, array, array, array)

#4 /home/escforumwiki/public_html/includes/HookContainer/HookRunner.php(2946): MediaWiki\HookContainer\HookContainer->run(string, array)

#5 /home/escforumwiki/public_html/includes/parser/Parser.php(828): MediaWiki\HookContainer\HookRunner->onParserLimitReportPrepare(Parser, ParserOutput)

#6 /home/escforumwiki/public_html/includes/parser/Parser.php(767): Parser->makeLimitReport()

#7 /home/escforumwiki/public_html/includes/content/WikitextContentHandler.php(301): Parser->parse(string, Title, ParserOptions, boolean, boolean, integer)

#8 /home/escforumwiki/public_html/includes/content/ContentHandler.php(1721): WikitextContentHandler->fillParserOutput(WikitextContent, MediaWiki\Content\Renderer\ContentParseParams, ParserOutput)

#9 /home/escforumwiki/public_html/includes/content/Renderer/ContentRenderer.php(47): ContentHandler->getParserOutput(WikitextContent, MediaWiki\Content\Renderer\ContentParseParams)

#10 /home/escforumwiki/public_html/includes/Revision/RenderedRevision.php(266): MediaWiki\Content\Renderer\ContentRenderer->getParserOutput(WikitextContent, Title, integer, ParserOptions, boolean)

#11 /home/escforumwiki/public_html/includes/Revision/RenderedRevision.php(237): MediaWiki\Revision\RenderedRevision->getSlotParserOutputUncached(WikitextContent, boolean)

#12 /home/escforumwiki/public_html/includes/Revision/RevisionRenderer.php(221): MediaWiki\Revision\RenderedRevision->getSlotParserOutput(string, array)

#13 /home/escforumwiki/public_html/includes/Revision/RevisionRenderer.php(158): MediaWiki\Revision\RevisionRenderer->combineSlotOutput(MediaWiki\Revision\RenderedRevision, array)

#14 [internal function]: MediaWiki\Revision\RevisionRenderer->MediaWiki\Revision\{closure}(MediaWiki\Revision\RenderedRevision, array)

#15 /home/escforumwiki/public_html/includes/Revision/RenderedRevision.php(199): call_user_func(Closure, MediaWiki\Revision\RenderedRevision, array)

#16 /home/escforumwiki/public_html/includes/poolcounter/PoolWorkArticleView.php(91): MediaWiki\Revision\RenderedRevision->getRevisionParserOutput()

#17 /home/escforumwiki/public_html/includes/poolcounter/PoolWorkArticleViewCurrent.php(97): PoolWorkArticleView->renderRevision()

#18 /home/escforumwiki/public_html/includes/poolcounter/PoolCounterWork.php(162): PoolWorkArticleViewCurrent->doWork()

#19 /home/escforumwiki/public_html/includes/page/ParserOutputAccess.php(299): PoolCounterWork->execute()

#20 /home/escforumwiki/public_html/includes/page/Article.php(714): MediaWiki\Page\ParserOutputAccess->getParserOutput(WikiPage, ParserOptions, MediaWiki\Revision\RevisionStoreCacheRecord, integer)

#21 /home/escforumwiki/public_html/includes/page/Article.php(528): Article->generateContentOutput(User, ParserOptions, integer, OutputPage, array)

#22 /home/escforumwiki/public_html/includes/actions/ViewAction.php(78): Article->view()

#23 /home/escforumwiki/public_html/includes/MediaWiki.php(542): ViewAction->show()

#24 /home/escforumwiki/public_html/includes/MediaWiki.php(322): MediaWiki->performAction(Article, Title)

#25 /home/escforumwiki/public_html/includes/MediaWiki.php(904): MediaWiki->performRequest()

#26 /home/escforumwiki/public_html/includes/MediaWiki.php(562): MediaWiki->main()

#27 /home/escforumwiki/public_html/index.php(50): MediaWiki->run()

#28 /home/escforumwiki/public_html/index.php(46): wfIndexMain()

#29 {main} SANtosito (talk) 11:00, 12 April 2023 (UTC)

I removed this line from /LuaStandaloneEngine.php

self::$clockTick = intval( shell_exec( 'getconf CLK_TCK' ) );

All seems to work now fine, but don't know if this will not cause more problems. SANtosito (talk) 11:25, 12 April 2023 (UTC)

I did the same 103.197.69.195 (talk) 03:15, 10 June 2023 (UTC)

lua error: internal error: the interpreter exited with status 1

I'm reaching out to seek assistance with a persistent issue I'm encountering on my MediaWiki installation. I have been experiencing a Lua error with the following message: "Internal error: The interpreter exited with status 1." Despite reinstalling Scribunto, allowing necessary permissions, and confirming the functionality of my Lua 5.1 interpreter through the command line, I have been unable to resolve the issue. The debug logs haven't provided much helpful information, and I couldn't find any specific errors related to this problem. 5.28.186.248 (talk) 11:52, 15 May 2023 (UTC)

The filename, directory name, or volume label syntax is incorrect.

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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? Headmate (talk) 20:58, 19 May 2023 (UTC)

@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. FeRDNYC (talk) 10:57, 3 June 2023 (UTC)

(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.) FeRDNYC (talk) 10:58, 3 June 2023 (UTC)

Having heard no response in almost a year, regretfully re-resolving. FeRDNYC (talk) 16:30, 7 April 2024 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Lua error: Internal error: The interpreter exited with status 1. on infobox

hi i was making it but i get error Lua error: Internal error: The interpreter exited with status 1. on infobox and i am using windows when i looked at the internet they are not helpful how do i fix this crap? 112.209.33.235 (talk) 06:53, 17 June 2023 (UTC)

The fact you're using Windows aides me in giving help. There should be a line that says: {{code

| lang = php|$cmd = '"' . $cmd . '"';

}} in this extension's {{code

| inline = 1|/includes/engines/LuaStandalone/LuaStandaloneInterpreter.php

}}. For the extension to work, comment out the line (i.e. prepend {{code

| lang = php

| inline = 1|#

}} or {{code

| lang = php

| inline = 1|//

}}). C.Ezra.M (talk) 07:12, 17 June 2023 (UTC)

yes i went to the line but its only

(string)( $options['cpuLimit'] + 1 ), 112.209.33.235 (talk) 07:20, 17 June 2023 (UTC)

oh there is 112.209.33.235 (talk) 07:20, 17 June 2023 (UTC)

nope still did not 112.209.33.235 (talk) 07:22, 17 June 2023 (UTC)

infobox took long to load 112.209.33.235 (talk) 07:29, 17 June 2023 (UTC)

fixed

but need some templates

( ͡° ͜ʖ ͡°) 112.209.33.235 (talk) 07:37, 17 June 2023 (UTC)

how did you get this to work? I have the same issue. Chubbuck3 (talk) 21:53, 19 June 2023 (UTC)

Lua Error: Internal error: the interpreter exited with status 1 on infobox

I'm using Windows, and I am having this error. When I setup the log file, I saw that the error was that apparently the directory where Lua is installed cannot be found.

I've searched around. Anyone have any leads? Chubbuck3 (talk) 21:55, 19 June 2023 (UTC)

Can Scribunto do anything for the client other than generate static text?

I was looking for scripting capabilities along the lines of client-side dynamics, with the ability to change its own generated text on the fly. I understood that there would be limits to functionality for security reasons, but it seems like Scribunto can't actually do anything above and beyond what could be done with ParserFunctions, which is to generate some text on page load. Am I missing something or is that really all it does? Ham Pastrami (talk) 21:26, 25 June 2023 (UTC)

That is really all it does. If you need reader-facing dynamic content you'll need to look at Javascript (though you might end up using Scribunto to generate the page structures that the JS makes dynamic). 「ディノ奴千？！」^{☎ Dinoguy1000} 22:31, 25 June 2023 (UTC)

To be fair, when browsing the web, "generat[ing] some text on page load" is how everything is done. Any functionality provided by a web service is the result of the particular HTML source payload (AKA "some text") that the server sends back in response to a client request.

Granted, Scribunto doesn't have access to even a fraction of that power, since it can't inject arbitrary code into the response, or cause anything to be run on the client side. For very good reason: A truly dynamic page, one where the content depends on the requesting client in any way, wouldn't be cacheable. Keep in mind that the primary focus for Scribunto has always been to script the process of generating-to-cached-static-content for high-volume sites like the various Wikipediae. If the Module code that generates an article's content had to be executed in full each and every time the page is requested, the added server load would take those sites down almost instantly.

It's not really true that Scribunto adds nothing over ParserFunctions, though. Primarily, with Scribunto you have access to real looping and recursion, meaning that you're no longer limited to a fixed set of template parameters that all have to be processed explicitly. Instead, you can just loop over the parameter list until you reach the end. One of the first things people used Modules for was to replace all of these tedious templates:

{{#if: {{{1|}}}|Handle {{{1}}}
}}{{#if: {{{2|}}}|Handle {{{2}}}
}}{{#if: {{{3|}}}|Handle {{{3}}}
}}<!--etc...-->

...with module implementations that only have to write the "Handle {{{n}}}" part once, and can loop over an arbitrary number of parameters instead of being hard-limited to however many times the template author replicated the code for incrementally higher parameter IDs.

(And it works just as well with named parameters. Thanks to en:Module:Citation/CS1, Wikipedia's {{cite web}} and friends now technically support an infinite-length set of |lastn=, |firstn= parameters for author names (limited only by the Lua process' memory constraints). They're processed iteratively, the code just keeps incrementing the n value and checking parameters until it sees two consecutive n values where |lastn= and |firstn= are both undefined, at which point it decides it's finished and breaks out of the loop.

(It also collects the values from all of the author parameters it does find, and stores the entire (sanitized and homogenized) list of authors as a Lua table. So, once it's done a single pass over all of the separate parameters, the data's stored in a structured form that can be passed between functions and easily dereferenced as needed. It never accesses the original |lastn=, |firstn= parameter values past that point.)

ParserFunctions can do a lot, but they can't do anything that requires storing data or keeping state across multiple invocations. Lua brings quite a bit to the table, even if its scripting is still limited to server-side content generation. FeRDNYC (talk) 14:32, 11 July 2023 (UTC)

This is technically true*, but it's also almost completely unrelated to the problem Ham Pastrami is trying to solve.

* Except for Lua keeping state across invocations; page-global statefulness is not intended and is always removed when someone finds a way to do it, since it would break the linear parsing model that Parsoid is moving to. 「ディノ奴千？！」^{☎ Dinoguy1000} 00:28, 12 July 2023 (UTC)

@Dinoguy1000: Yeah, sorry, I worded that badly. I wasn't talking about Lua preserving state across Module invocations, only within them. A Lua script's internal storage/state represents the "moral equivalent" of state being preserved across ParserFunction invocations, since a single Lua call can generally replace an entire template packed with dozens or even hundreds of separate ParserFunctions (all of which were completely isolated and had no ability to share state).

...I still feel like I'm not wording that great, but hopefully it's at least better. FeRDNYC (talk) 06:50, 12 July 2023 (UTC)

Aah, yeah, that makes more sense. 「ディノ奴千？！」^{☎ Dinoguy1000} 10:38, 12 July 2023 (UTC)

it seems like Scribunto can't actually do anything above and beyond what could be done with ParserFunctions, which is to generate some text on page load. In my opinion, Scribunto's purpose on Wikipedia is to provide a way to organize template logic code like actual program code, instead of a bunch of un-indented spaghetti. Anytime a template starts getting complicated, I am always tempted to re-write it in Lua. It is much more readable and maintainable. Hope this helps to explain its purpose. –Novem Linguae (talk) 01:25, 12 July 2023 (UTC)

LogicException: This ParserOutput contains no text!

In our MediaWiki instance, Scribunto runs fine. The problem is when the code is displayed through SyntaxHighlight. The internal error in the topic title appears on the page for every Lua module. This problem began once MediaWiki was updated to 1.39.3.

Partial backtrace:

from /var/www/prole/includes/parser/ParserOutput.php(363)

#0 /var/www/prole/extensions/Scribunto/includes/ScribuntoContentHandler.php(224): ParserOutput->getRawText()

#1 /var/www/prole/extensions/Scribunto/includes/ScribuntoContentHandler.php(193): MediaWiki\Extension\Scribunto\ScribuntoContentHandler->highlight()

Context of MediaWiki's ParserOutput.php (361–367):

public function getRawText() {
	if ( $this->mText === null ) {
		throw new LogicException( 'This ParserOutput contains no text!' );
	}
	return $this->mText;
}

Context of includes/ScribuntoContentHandler.php (212–230, without comments):

protected function highlight( $text, ParserOutput $parserOutput, ScribuntoEngineBase $engine ) {
	global $wgScribuntoUseGeSHi;
	$language = $engine->getGeSHiLanguage();
	if (
		$wgScribuntoUseGeSHi && $language && ExtensionRegistry::getInstance()->isLoaded( 'SyntaxHighlight' )
	) {
		$status = SyntaxHighlight::highlight( $text, $language, [ 'line' => true, 'linelinks' => 'L' ] );
        	if ( $status->isGood() ) {
		$parserOutput->addModuleStyles(['ext.pygments']);
		$parserOutput->addModules( ['ext.pygments.linenumbers'] );
		$parserOutput->setText( $parserOutput->getRawText() . $status->getValue() );
		return true;
		}
	}
        return false;
}

Also, our MediaWiki instance runs multiples languages. For some odd reason, this problem only happens on the English instance. Marx.FelipeForte (talk) 12:24, 5 July 2023 (UTC)

Vote for LuaSandbox on Plesk

Apologies for cross-posting

For anyone who is on Plesk hosting, or considering to move to Plesk, and is sad to miss out on all the wonderfulness that is Lua because of shared hosting restrictions and what not, don't give up but please vote for the following feature request:

https://plesk.uservoice.com/forums/184549-feature-suggestions/suggestions/46899301-add-luasandbox-for-mediawiki

Lua/Scribunto is not only incredibly useful, but may become one of few viable alternatives when Parsoid has made the move to parallel parsing and extensions like Variables and Arrays are no longer guaranteed to work.

Let's not 'miss the boat' and please make your voice heard. Rand(1,2022) (talk) 12:38, 7 July 2023 (UTC)

Script error: Lua error: Internal error: The interpreter has terminated with signal "-129".

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 (talk) 15:00, 7 July 2023 (UTC)

@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. FeRDNYC (talk) 12:51, 11 July 2023 (UTC)

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). Tim Starling (talk) 02:37, 27 November 2023 (UTC)

Is that possible to get raw wikitext by Lua?

I find out frame.args will receive parsed wikitext, so how to get raw wikitext without using <nowiki> tag? Cirno.Tim (talk) 04:04, 15 July 2023 (UTC)

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. — Mr. Stradivarius ^{♪ talk ♪} 00:15, 16 July 2023 (UTC)

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. Tacsipacsi (talk) 00:37, 16 July 2023 (UTC)

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>. FeRDNYC (talk) 22:50, 20 July 2023 (UTC)

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. Tim Starling (talk) 00:55, 28 November 2023 (UTC)

That would be phab:T322513, reported a year ago. * Pppery * _{it has begun} 02:17, 28 November 2023 (UTC)

Logo

Is there any logo for Scribunto, from Wikimedia Commons, to include in the page? BoldLuis (talk) 08:46, 4 August 2023 (UTC)

Not that I'm aware of. One of the hidden categories on the extension page is Category:Extensions without an image. FeRDNYC (talk) 17:19, 21 August 2023 (UTC)

Two questions about parsing

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) Rand(1,2022) (talk) 20:17, 14 September 2023 (UTC)

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. Rand(1,2022) (talk) 13:35, 22 September 2023 (UTC)

The interpreter has terminated with signal "11"

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? Redheadkelly (talk) 06:17, 26 November 2023 (UTC)

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? Tim Starling (talk) 01:53, 27 November 2023 (UTC)

Error: Call to undefined function

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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} Lost Student (talk) 06:26, 4 December 2023 (UTC)

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. Lost Student (talk) 06:50, 4 December 2023 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Lua error: Internal error: The interpreter exited with signal 5

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. Hurohukidaikon (talk) 14:06, 6 December 2023 (UTC)

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

$wgScribuntoEngineConf['luastandalone']['memoryLimit'] = 200_000_000; Tim Starling (talk) 10:40, 7 December 2023 (UTC)

@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 :-) Hurohukidaikon (talk) 13:39, 14 December 2023 (UTC)