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';

Were you able to solve this issue? I'm currently running into the same problem and have not been able to find any solution.

No. This issue still occurs.

I'm trying to make syntax highlighting working in modules but apparently sth is missing. I have installed WikiEditor, SyntaxHighlight, CodeEditor and have done everything as said in manual. All installed extension are working , just seems it dosen't work with Scribunto, so I guess the problem must be sth else

wfLoadExtension( 'WikiEditor' );

wfLoadExtension( 'SyntaxHighlight_GeSHi' );

wfLoadExtension( 'CodeEditor' );

wfLoadExtension( 'Scribunto' );

$wgScribuntoDefaultEngine = 'luastandalone';

$wgScribuntoEngineConf['luastandalone']['key'] = 'value';

$wgScribuntoUseGeSHi = true;

$wgScribuntoUseCodeEditor = true;

http://escforumwiki.com/index.php?title=Module:Documentation

I do not see a solution and outcome here. I am having the same issue. We do not have CodeEditor installed though. Is that required?

Syntax highlighting is working on all other pages as expected. With the following should we see module syntax highlighting or do we need anything else?

$wgScribuntoDefaultEngine = 'luastandalone';

$wgScribuntoEngineConf['luastandalone']['key'] = 'value';

$wgScribuntoUseGeSHi = true;

wfLoadExtension( 'WikiEditor' );

wfLoadExtension( 'SyntaxHighlight_GeSHi' );

wfLoadExtension( 'Scribunto' );

Update: I just copied the Lua code from a Module window. Pasted it into a blank page and surrounded it with <syntaxhighlight lang="Lua">. When I click show demo it was all nice and colorful and matches how it looks on the same module on Wikipedia. So our SyntaxHighlight seems fine. The Module view just does not show it on our Wiki.

Five years on, has anyone found a solution to this problem of Scribunto seemingly failing to call CodeEditor and WikiEditor in the text editor? (I'm not referring to the SyntaxHighlight extension, which is a different topic). Or have any clues where to look for potential problems?

MW 1.39.6 | WikiEditor 0.5.3 | CodeEditor (no version number) | Scribunto (no version number, luastandalone), with Lua 5.1.5 and $wgScribuntoUseCodeEditor = true. I have tried playing with the order of the settings, to no avail. CodeEditor is working fine on JavaScript and CSS pages and so is WikiEditor.

Got it. An older extension I was using interfered with Scribunto because it neglected to abort the hook (it returned true). I removed it and CodeEditor works again.

Hi all. I am trying to debug some Scribunto modules but the log journal is not displayed when an error occurs.

As a consequence, you only get the details when everything goes right... and '''no''' details when it goes wrong.

This is frustrating and the opposite of what I expect.

Do you mean the red "Script error" error messages that get displayed on wiki pages? You can click on those, and they will give you more details of what went wrong.

Sorry I was not specific enough.

In the debugging console, when an error occurs, it displays the error and the call stack but '''not''' the log buffer where all the mw.log and mw.logObject messages are stored.

Hi. I was surprised to see that ''mw.loadJsonData'' actually changes string keys like "90" in JSON to a numeric key 90 in Lua.

That makes accessing the Lua table harder. There was only one type of keys in JSON (i.e string), and it becomes 2 incompatible types in Lua (string or number) which causes a more complex code to handle the data.

I know it is too late to change ''mw.loadJsonData'' behaviour now, but at least you could add an option to it so that every key can be kept as a string.

See T355763.

Hi. I cannot find a way of sorting a table containing French or German strings using table.sort( with or without a comparison function).

From the official Lua.org site: " Lua compares strings in alphabetical order, which follows the locale set for Lua". The locale seems to be set to English and I see no way to specify which locale I want.

How can I set the locale for sorting?

Example

local p = {}

function p.sortfr(frame)
	local tablefr = { -- In the correct order
		"aperçu",
		"déception",
		"déçu",
		"épicentre",
		"étonnament",
		"mæstro",
		"mais",
		"maïs",
		"maligne",
		"odomètre",
		"œillère",
		"oléoduc"
	}
	table.sort(tablefr)
	mw.logObject(tablefr)  -- Wrong result
	table.sort(tablefr, function (m,n) return mw.ustring.lower(m) < mw.ustring.lower(n) end )
	return mw.dumpObject(tablefr) -- Also wrong
end

return p

Result

table#1 { "aperçu", "déception", "déçu", "mais", "maligne", "maïs", "mæstro", "odomètre", "oléoduc", "épicentre", "étonnament", "œillère", }

I think there might possibly be a design problem in the frame object. The problem is that currently a Lua module can launch an infinity of templates, an infinity of parsers functions, but only 100 other modules. I explain the situation at :en:Wikipedia talk:Lua § Editing the args metatable of a child frame:

Module:Params offers the possibility to map or rename parameters using either helper templates or modules or parser functions. Currently, in the case of mapping_by_invoking and renaming_by_invoking, while iterating, a new child frame gets created for each parameter (#1, #2). This means that if the parameters to map or rename are more than about a hundred the code breaks, because, as the Scribunto-Lua manual says, “The number of frames that may be created at any one time is limited”.

I have tried to solve the problem in Module:Params/sandbox, but all my attempts at keeping only one child frame throughout the loop failed (#3, #4, #5, #6). The reason is that once the child frame object gets created I can no longer edit its .args metatable. Yet, I would need to do that, because each module invocation needs to receive different parameters.

Testcases are available at Module:Params/testcases/tmaps and Params/testcases/tmaps sandbox. Any idea on how to solve the problem and being able to map more than 100 parameters using a module?

Is any workaround possible?

To better understand the paradox, if I try to create 120 dummy parameters and map them using the {{replace}} template (which uses {{#invoke:string|replace}}), everything works well:

{{#invoke:params|imposing|120|foobar|filling_the_gaps|mapping_by_calling|replace|blindly|let|plain|false|3|foo|^.*$|test|for_each|[$#: $@]}}

But if I try to map these parameters using {{#invoke:string|replace}} directly, without calling the {{replace}} template (i.e. if I use mapping_by_invoking instead of mapping_by_calling),

{{#invoke:params|imposing|120|foobar|filling_the_gaps|mapping_by_invoking|string|replace|blindly|5|foo|^.*$|test||false|for_each|[$#: $@]}}

I get

Lua error: newChild: too many frames.

Isn't this a bit absurd?

@Grufo:

currently a Lua module can launch an infinity of templates, an infinity of parsers functions

If you ask me, that's the absurdity. For performance reasons, those should be limited as well. (And... aren't they, at least at Wikipedia? I'm pretty sure there's some configurable limit, and I thought it was set a lot lower than 100.)

@FeRDNYC

It is definitely absurd that the three things (i.e. template call, module call and parser function call) are treated differently. If you ask me if there should be a limit at all, I don't know. But if there were a limit, I would say that 100 would be too low; in the case of Module:Params, although rare, it is not unthinkable to have a template called with 120 parameters, and with a limit of 100 the module would not be able to map all the incoming parameters. Moreover, even with 35 parameters, a template might need to map each parameter more than once, and already three mappings would break the limit of 100. So, if you ask me, a limit should not be lower than 1000, if any.

Module:Params can also increase the number of parameters a template was called with, and if done automatically (see filling_the_gaps), there is a safety limit of 1024 parameters that can be automatically created in this way – so you will not be able to use this module to call other templates/modules millions of times in any case.

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.

Was there a solution to this?

The closest I saw to a solution was:

>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?)

@Vapblack One solution would be, like I said, to reverse the parts of Trappist's edit (starting at line 2039) that un-hardcoded the values, and store them directly in the code again. That way, there's no need to access external data.

The other solutions are to install Extension:JsonConfig on the wiki in question, and either:

• configure it to access https://commons.wikimedia.org/wiki/Data:CS1/Identifier_limits.tab for the values (@Tacsipacsi says the instructions for doing that are at Extension:JsonConfig#Supporting Wikimedia templates), or
• make a local copy of commons:Data:CS1/Identifier_limits.tab and configure it to pull data from the local copy.

It would be very useful if Scribunto could have access to the raw string of the calling #invoke (and, ideally, the parent frame template), as it's not currently possible to accurately reconstruct the raw wikitext which generated the frame.args and frame:getParent().args tables. Alternatively, access to the raw parameter array would work, too.

The problem I have in mind is English Wiktionary's en:wikt:Template:temp (powered by en:wikt:Module:template link), which is used to generate wikitext-style template/magic word links for documentation and discussions. Since the input can't be reconstructed, it has to normalise based on various assumptions, which sometimes leads to bad results:

• The template/magic word being parameter 1 leads to an unsolvable offset issue (e.g. the template call {{l|foo|bar|4=baz}} - a very common Wiktionary idiom - would (intuitively) take the input {{temp|l|foo|bar|4=baz}}, but template link misinterprets it as {{temp|l|foo|bar|baz}} since it can't know the difference between the fourth implicit argument received and one given explicitly with 4=. This is extremely confusing to a casual user.
• Much worse, when dealing with parser functions (which mainly treat their inputs as arrays), the input gets completely garbled: for instance, it has no way of knowing that "qux" must come after "bar=baz" when displaying {{temp|SWITCH:foo|bar=baz|qux}}.

There are workarounds to this, of course: we could change the syntax, but this would break continuity with a template that's been around since 2006, and is pretty ingrained to regular users. You can also pass everything under a nowiki tag to parameter 2, which is the only way to solve the SWITCH: issue at the moment, but this is awkward-at-best, unintuitive to most users, and undermines the convenience of the template in discussions.

Having the raw template string would solve all of these issues, with the added advantage of making parameter processing simpler, too.

I don't foresee any obvious security or isolation issues with this, but I'll defer to others on that point.

@Theknightwho Wikipedia's Template:Tlx (also present here at MediaWiki) has a similar functionality, and gets used all the time with complex arguments.

My solution for the SWITCH example you posted would be to call it as:

• {{tlx|SWITCH:foo|bar{{=}}baz|qux}} which produces: {{SWITCH:foo|bar=baz|qux}}.

Ditto the previous example:

• {{tlx|l|foo|bar|4{{=}}baz}} => {{l|foo|bar|4=baz}}.

Using {{=}} to turn named parameter assignments into positional parameters is a well-worn aspect of using template-linking templates that most Wikipedians seem to adopt pretty quickly, and which doesn't seem all that onerous.

The other issue is, if Wiktionary's en:wikt:Template:temp is anything like {{Tlx }}, it probably has a lot of parameters of its own, that it has to differentiate from the arguments to the linked template. I'm not sure how handing the module all of its parameters unparsed would make parameter processing simpler, because now it would have to do all of the processing to consume its own arguments. It feels like ultimately making one thing perhaps a bit easier, by making a lot of other stuff much harder.

@FeRDNYC So we've intentionally avoided giving it any parameters to avoid this issue, though we've never had any need for them anyway (with one exception, but en:wikt:Template:tempn fills that niche, which is the same but doesn't wrap the output in <code> tags).

The workaround you suggest works fine, and it's what people do, but I was just hoping we could make things a bit more user-friendly.

You make a good point about processing unparsed parameters, but what I didn't mention (though perhaps should have) is that we at Wiktionary have en:wikt:Module:template parser for that kind of thing, which abstracts away all the complexity of parsing raw template code.

However, I'm not sure it'd be necessary to do all that, as it would make more sense for the raw arguments to be given as an array. A PHP version of that array is actually what Scribunto uses to construct the argument table in the first place, so it shouldn't be too complex to make it available in Lua as well, which would mean no raw template parsing is necessary.

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.

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.