Extension talk:Scribunto

Jump to navigation Jump to search

About this board

  • 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

Error running LuaStandalone on Windows

7
GerardNL3 (talkcontribs)

(I'm still new to Wiki, so excuses if this is the wrong forum/format/question, but please bare with me.)

I have a fresh install of WikiMedia version 1.35, running on IIS (Windows 2016. It can't be avoided to run on Windows). After installing the usual extensions, I run into a problem with Scribunto. As per the manual, I have in my LocalSettings.php:

wfLoadExtension( 'Scribunto' );

$wgScribuntoDefaultEngine = 'luastandalone';

error_reporting( -1 );

ini_set( 'display_errors', 1);

$wgShowExeptionDetails = true;

$wgDebugLogFile = "D:/log/debug-{$wgDBname}.log";

$wgScribuntoEngineConf['luastandalone']['errorFile'] = 'D:/log/scribunto.log';


On a page I have the line below in the source (without the tildes, or that would be interpreted here):

~{~{\#invoke:main|main~}~}


When viewing the page, I get the error: Lua error: Internal error: The interpreter exited with status 1.


In the log file I see this:

[Scribunto] Scribunto_LuaStandaloneInterpreter::__construct: creating interpreter: ""D:\wwwroot\kb\extensions\Scribunto\includes\engines\LuaStandalone/binaries/lua5_1_5_Win64_bin/lua5.1.exe" "D:\wwwroot\kb\extensions\Scribunto\includes\engines\LuaStandalone/mw_main.lua" "D:\wwwroot\kb\extensions\Scribunto\includes" "0" "8""

As you can see, there is a mix of slashes and backslashes which may the cause of the error (?)


Doing some searching in the code, it seem to come from: LuaStandaloneInterpreter.php

In particular the lines:

$options['luaPath'] = __DIR__ . "/binaries/$path";

and:

__DIR__ . '/mw_main.lua',


Where __DIR__ has the value: "D:\wwwroot\kb\extensions\Scribunto\includes\engines\LuaStandalone", while the code seems to expect to be "D:/wwwroot/kb/extensions/Scribunto/includes/engines/LuaStandalone"

I don't see where __DIR__ gets initialized, so the problem could be in a different PHP file?


I have also tried to add the below line to my LocalSettings.php:

#$wgScribuntoEngineConf['luastandalone']['luaPath'] = 'D:/wwwroot/kb/extensions/Scribunto/includes/engines/LuaStandalone/binaries/lua5_1_5_Win64_bin/lua5.1.exe';


After which the page still doesn't work and logs shows this:

[Scribunto] Scribunto_LuaStandaloneInterpreter::__construct: creating interpreter: ""D:/wwwroot/kb/extensions/Scribunto/includes/engines/LuaStandalone/binaries/lua5_1_5_Win64_bin/lua5.1.exe" "D:\wwwroot\kb\extensions\Scribunto\includes\engines\LuaStandalone/mw_main.lua" "D:\wwwroot\kb\extensions\Scribunto\includes" "0" "8""

So that only partially fixed the problem, but the filepath to mw_main.lua still has mixed slashes.


I have made some changes to LuaStandaloneInterpreter.php by hardcoding the path (just for testing). The log now shows:

[Scribunto] Scribunto_LuaStandaloneInterpreter::__construct: creating interpreter: ""D:/wwwroot/kb/extensions/Scribunto/includes/engines/LuaStandalone/binaries/lua5_1_5_Win64_bin/lua5.1.exe" "D:/wwwroot/kb/extensions/Scribunto/includes/engines/LuaStandalone/mw_main.lua" "D:/wwwroot/kb/extensions/Scribunto/includes" "0" "8""


But I still get the same error on the page and in the Scribunto.log file shows this:

'""D:' is not recognized as an internal or external command, operable program or batch file.

Which seems to indicate that it doesn't like the drive letter?


Removing the drive letter from the code, gives a similar output as above (without the drive letter) but the Scribunto.log files shows:

'""' is not recognized as an internal or external command, operable program or batch file.


After extensive Googling and trying different options, I don't know what else to do, but hopefully, the above informaiton will make more sense to an expert? Thanks for your help in advance!!


Ps. I have checked that all folders and files mentioned here exist and the process has access to it.

FeRDNYC (talkcontribs)

I know it's been almost a month, but... ¯\_(ツ)_/¯.

I believe __DIR__ is simply the current directory in PHP, IOW __DIR__ . "/binaries/$path" is just a way to build a relative path. If it mixes the slashes, then I assume it can interpret them either way and that's not actually the problem at all. If you notice, your output before and after the change is exactly the same:

[Scribunto] Scribunto_LuaStandaloneInterpreter::__construct: creating interpreter: ""D:\wwwroot\kb\extensions\Scribunto\includes\engines\LuaStandalone/binaries/lua5_1_5_Win64_bin/lua5.1.exe" "D:\wwwroot\kb\extensions\Scribunto\includes\engines\LuaStandalone/mw_main.lua" "D:\wwwroot\kb\extensions\Scribunto\includes" "0" "8""

vs.

[Scribunto] Scribunto_LuaStandaloneInterpreter::__construct: creating interpreter: ""D:/wwwroot/kb/extensions/Scribunto/includes/engines/LuaStandalone/binaries/lua5_1_5_Win64_bin/lua5.1.exe" "D:/wwwroot/kb/extensions/Scribunto/includes/engines/LuaStandalone/mw_main.lua" "D:/wwwroot/kb/extensions/Scribunto/includes" "0" "8""

Aside from the mixed slashes, those are identical. So, changing it only "fixed the problem" if the slashes were the problem. (That's also assuming forward slashes would be the correct format to use, which isn't clear at all so far.)

The problem is likely not the drive letter, or the slashes; it looks like it's the quoting. If you parse the log messages you posted carefully, what they're saying is, respectively:

  • ""D: is not recognized as an internal or external command, etc...
  • "" is not recognized as an internal or external command, etc...

Something seems to be causing your commands and/or command args to get double-doublequoted, in a way that's breaking... something else, whether it's PHP, MediaWiki, Scribunto, or lua5.1.exe. And then only the contents up to the first slash are being interpreted... which may be a symptom of the bad quoting, it could be a sign of possibly-now-wrong slashes, or there may be some other issue entirely. At this point things are so muddled that it's hard to say.

You can try following the advice given to Vapblack below, and install an external version of Lua somewhere, then set $wgScribuntoEngineConf['luastandalone']['luaPath'] to the path to that Lua executable in your site config. But even if you do that, you should also completely reinstall Scribunto to ensure that any changes you made are reversed.

As this blog post indirectly makes clear, MediaWiki and Scribunto both work fine running under IIS, it's just a matter of properly configuring everything. But you don't need to modify its source code to do that. Any changes you made are more likely to interfere with getting it to work, even after you've got the configuration right. (And because of that, how could you even tell if it's correctly configured, once it is?)

Raikkonso (talkcontribs)

I'm having a similar issue to GerardNL3 (did you manage to solve it?). I did a fresh install of Mediawiki 1.35.2 and am running on Windows 10 & xampp 8.0.6.

MediaWiki 1.35.2
PHP 8.0.6 (apache2handler)
MariaDB 10.4.19-MariaDB
Lua 5.1.5

Whenever i type the {{}} syntax, I get the message - Lua error: Internal error: The interpreter exited with status 1. I have added the following to LocalSettings.php

wfLoadExtension( 'Scribunto' );

$wgScribuntoDefaultEngine = 'luastandalone';

$wgScribuntoEngineConf['luastandalone']['errorFile'] = "$IP/images/temp/lua-error.log";

wfLoadExtension( 'ParserFunctions' );

$wgPFEnableStringFunctions = true;


I have tried to add $wgScribuntoEngineConf['luastandalone']['luaPath'] = "$IP/extensions/Scribunto/includes/engines/LuaStandalone/binaries/lua5_1_5_Win64_bin/lua5.1.exe"; as according to the suggestion above, but somehow it simply does not work. Similar to GerardNL3, I have double double-quotations

The error log would indicate:

'""D:\xampp\htdocs\wiki' is not recognized as an internal or external command, operable program or batch file.


If i remove that line from the LocalSettings.php, then the error log would indicate:

'""D:\xampp\htdocs\wiki\extensions\Scribunto\includes\engines\LuaStandalone' is not recognized as an internal or external command, operable program or batch file.


It seems that by adding the luaPath to LocalSettings.php, it stopped navigating to the extensions\Scribunto.....\LuaStandalone folder. It simply stopped at $IP (contents up to the first slash - as mentioned in FeRDNYC's post), so I removed that line.


I also checked the LuaStandaloneInterpreter.php. I tried changing lines 82 & 92 to point it to the lua5.1.exe file, but no matter what combinations I try, it just does not seem to work.

                   $path = 'lua5_1_5_Win64_bin/lua5.1.exe';

           $options['luaPath'] = __DIR__ . "/binaries/$path";

I also tried copying the file into the /extensions/Scribunto/includes/engines/LuaStandalone/ folder and changing line 92 to __DIR__ . "/lua5.1.exe"; but it still does not work.


I tried saving the page with the {{}} code, and the error showed:

[487f59ff3f43638788ef7c01] /wiki/index.php?title=Test&action=submit MWException from line 95 of D:\xampp\htdocs\wiki\extensions\Scribunto\includes\engines\LuaStandalone\LuaStandaloneInterpreter.php: The lua binary (D:\xampp\htdocs\wiki\extensions\Scribunto\includes\engines\LuaStandalonelua5.1.exe) is not executable.


I noted that the "LuaStandalonelua5.1.exe" had a missing \. Line 95 of LuaStandaloneInterpreter.php shows:

               throw new MWException(

What's wrong with this line?

Lonepointe (talkcontribs)

Hey just comment out line 132 in $wiki/extensions/Scribunto/includes/engines/LuaStandalone/LuaStandaloneInterpreter.php

looks like this: //$cmd = '"' . $cmd . '"';

It might break something somewhere, but it made it work for me. I probably don't have spaces in the filename; it might break if you do.

(this eliminates the double quote problem)

63.245.160.132 (talkcontribs)

I did a clean install of Mediawiki 1.36 with new extensions and new LocalSettings.php. I imported my database and images only from my previous wiki version 1.34. I was getting this same issue. I tried all different ways to put the path into the LocalSettings.php following the other posts I have seen about this, and nothing worked.

SOLVED.

Commenting out line 132 as the above person wrote, did work. Why this changed between 1.34 and 1.36, I don't know. Looks like this would only be a problem for those installing on a windows server (NT type OS).


As the previous poster wrote, I hope this doesn't break anything else.

Raikkonso (talkcontribs)

OMG!! It looks like it worked! Thank you Lonepointe! Thank you 63.245.160.132!

FeRDNYC (talkcontribs)

The thing of it is, that line of code has actually been in Scribunto for nine years already (ever since this commit), the only changes have been to move which source file it's located in. And enclosing the entire command string with double-quotes has long been an accepted workaround for bugs in PHP's handling of cmd.exe subprocesses.

So, either the "what's changed" is elsewhere (a change in the method used to launch the Lua interpreter?), or something external — a newer version of PHP that finally fixes this, perhaps? Or maybe PowerShell has finally replaced cmd.exe, as the subshell for external processes?

Reply to "Error running LuaStandalone on Windows"

Lua error: Internal error: The interpreter exited with status 2.

1
Zuul (talkcontribs)

you're also getting the error message above if you're using the wrong type of binary.

I've tried on an RaspberryPi the default Lua installation and got the status 2 error message. I enabled the Lua debugging by setting

$wgScribuntoEngineConf['luastandalone']['errorFile'] = '/var/www/html/lua.log' in LocalSettings.php


I've got the message "/var/www/html/extensions/Scribunto/includes/engines/LuaStandalone/lua_ulimit.sh: 1: exec: /var/www/html/extensions/Scribunto/includes/engines/LuaStandalone/binaries/lua5_1_5_linux_32_generic/lua: Exec format error"


what leads me to the <code>file</code> command

The <code>file</code> command returns on the default binaries for Linux

lua: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.9, not stripped

What is on an ARM architecture definitely not right


I downloaded the lua source code and compiled the source with the default configuration and installed the resulting binary to the lua binary directory

The error 2 disappeared.

verified the lua binary using <code>file</code> and the result look good

lua: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=cee7e1f55815ff1832378947c0b0c4e3a8af6bd3, stripped


solved <br />

~~~~

Reply to "Lua error: Internal error: The interpreter exited with status 2."

"require_once" instructions

10
Hv (talkcontribs)

Under "Installation", the page says:

The instructions above describe the new way of installing this extension using wfLoadExtension(). If you need to install this extension on these earlier versions (MediaWiki 1.29 and earlier), instead of wfLoadExtension( 'Scribunto' );, you need to use:
require_once "$IP/extensions/Scribunto/Scribunto.php";

.. however the "current" version (aimed at 1.35) does not ship with a Scribunto.php, and the only previous version listed (aimed at 1.31) which does ship with one immediately fails with a "requires >= 1.31.0" error.

Unless there's some way to acquire an older version, I suspect this is no longer installable on Mediawikis earlier than 1.31, and this section should be replaced with a notice to that effect - I'm on 1.27.4, the dist version for Ubuntu Bionic Beaver. Hv (talk) 16:55, 19 May 2021 (UTC)

Tacsipacsi (talkcontribs)

Any older version can be downloaded from Gerrit (tgz link) or GitHub (Code → Download ZIP). However, please note that Wikimedia support for MW 1.27 ended quite a while ago, so it can potentially contain publicly known, unfixed security holes. You should update as soon as possible at least to 1.31—its support will also end in a few weeks, but that’s the last LTS version to support PHP 7.2; using APT pinning, I think you should be able to install 1.31 from the focal (20.04 LTS) APT repository. (The best solution however would be upgrading the whole server to focal, which contains PHP 7.4, and then upgrading MW further to 1.35.)

Hv (talkcontribs)

Thanks, that's hugely helpful. This is not a publicly accessible installation, but I should upgrade it regardless. Hv (talk) 14:20, 21 May 2021 (UTC)

FeRDNYC (talkcontribs)

Hrm. So Focal (the current Ubuntu LTS) includes MW 1.31, which is itself supposed to be EOL'd in a month. Whereas Focal will be supported by Ubuntu until 2025?

What an incredibly unfortunate accident of timing, to have created this situation. Focal was released just a few months before MW 1.35. And because there was no newer MW LTS release, Focal contains a MW release — 1.31 — that was already nearly 2 years old at that time.

Since a huge part of MW's ecosystem is its wide array of extensions, and since those extensions can't reasonably be expected to continue supporting MW versions that have reached their EOL date (irrespective of Ubuntu's own support timeline), I wonder if there's a case to be made for a Stable Release Updates exception (or at least a backport) so that Focal can be updated to MW 1.35, to ensure that it remains compatible with available extensions?

The alternative would seem to be for Ubuntu to also package MW extensions for their LTS releases, so they can be frozen at a version compatible with the frozen MW release.

Dinoguy1000 (talkcontribs)

That text is boilerplate added by a template; I don't know if the template supports customizing or removing the text for one specific extension. That being said, MediaWiki 1.27 (the last LTS version prior to 1.31) has been unsupported for almost two years now, and MediaWiki 1.31 (the current LTS version) is scheduled to become unsupported next month; I'm curious whether the template should just be changed to omit this text by default and require a per-page opt-in to include it again.

Tacsipacsi (talkcontribs)

Yes, it supports with |registration=required (instead of |registration=Yes), but I agree that the default should probably be registration-only (unless a newer version is specified in |no-registration-version= and unless it doesn’t support registration at all).

FeRDNYC (talkcontribs)

At least the 1.31 download (which is selectable from the download link for the other versions) still contains Scribunto.php, so presumably that would still be useful for users on older versions as well.

That being said, if MW <= 1.29 are all completely unsupported at this point, and extensions are being shipped without the files indicated by that old boilerplate, then IMHO those instructions should definitely at least be hidden by default. (We could stick them inside a collapsed DIV, "Instructions for older installations", or something... and include a mention in there that it might be necessary to download an older version of the extension source, to use the require_once installation method.)

Tacsipacsi (talkcontribs)

As the OP said, the REL1_31 version contains Scribunto.php, but still explicitly refuses to work if extension registration is not available in the MW version used.

FeRDNYC (talkcontribs)

(Also, a slight correction to @Dinoguy1000):

MediaWiki 1.31 (the current LTS version) is scheduled to become unsupported next month

Using the terminology from Version lifecycle , MediaWiki 1.35 is current LTS version; 1.31 was the previous LTS, and current "legacy support version" (whatever that means). It would be weird for the current LTS to suddenly go unsupported next month.

FeRDNYC (talkcontribs)
Reply to ""require_once" instructions"
68.49.56.122 (talkcontribs)

Hello,

I'm managing a wiki that had the Scribunto extension installed for some time but really wasn't used much except on a couple of test pages. I'm upgrading the wiki now (from 1.28 to 1.31) and have removed the Scribunto extension. However, when I run the scripts to populate the CirrusSearch index, I get the following traceback:

<code>

[7c132a3761cb626266d8cab6] [no req]   MWUnknownContentModelException from line 306 of /var/www/html/mediawiki-1.31.0/includes/content/ContentHandler.php: The content model 'Scribunto' is not registered on this wiki.

See https://www.mediawiki.org/wiki/Content_handlers to find out which extensions handle this content model.

Backtrace:

#0 /var/www/html/mediawiki-1.31.0/includes/content/ContentHandler.php(243): ContentHandler::getForModelID(string)

#1 /var/www/html/mediawiki-1.31.0/includes/Title.php(4984): ContentHandler::getForTitle(Title)

#2 /var/www/html/mediawiki-1.31.0/includes/parser/Parser.php(892): Title->getPageLanguage()

#3 /var/www/html/mediawiki-1.31.0/includes/parser/Parser.php(2126): Parser->getTargetLanguage()

#4 /var/www/html/mediawiki-1.31.0/includes/parser/Parser.php(2091): Parser->replaceInternalLinks2(string)

#5 /var/www/html/mediawiki-1.31.0/includes/parser/Parser.php(1318): Parser->replaceInternalLinks(string)

#6 /var/www/html/mediawiki-1.31.0/includes/parser/Parser.php(443): Parser->internalParse(string)

#7 /var/www/html/mediawiki-1.31.0/includes/content/WikitextContent.php(323): Parser->parse(string, Title, ParserOptions, boolean, boolean, integer)

#8 /var/www/html/mediawiki-1.31.0/includes/content/AbstractContent.php(516): WikitextContent->fillParserOutput(Title, integer, ParserOptions, boolean, ParserOutput)

#9 /var/www/html/mediawiki-1.31.0/includes/content/ContentHandler.php(1324): AbstractContent->getParserOutput(Title, integer, ParserOptions)

#10 /var/www/html/mediawiki-1.31.0/extensions/CirrusSearch/includes/Updater.php(363): ContentHandler->getParserOutputForIndexing(WikiPage, ParserCache)

#11 /var/www/html/mediawiki-1.31.0/extensions/CirrusSearch/includes/Updater.php(204): CirrusSearch\Updater->buildDocumentsForPages(array, integer)

#12 /var/www/html/mediawiki-1.31.0/extensions/CirrusSearch/maintenance/forceSearchIndex.php(218): CirrusSearch\Updater->updatePages(array, integer)

#13 /var/www/html/mediawiki-1.31.0/maintenance/doMaintenance.php(94): CirrusSearch\ForceSearchIndex->execute()

#14 /var/www/html/mediawiki-1.31.0/extensions/CirrusSearch/maintenance/forceSearchIndex.php(679): require_once(string)

#15 {main}

</code>

I found a few phabricator tickets that appear to be related but haven't yet found a workaround beyond reinstalling the Scribunto extension. Is there one? Is there a way to remove the Scribunto content model and/or references to it?

68.49.56.122 (talkcontribs)

Additionally, I thought if I did an XML dump of all pages and revisions I would find a page using "<model>Scribunto</model>" but I don't seem to have any pages with that.

2620:11E:1000:120:1792:B56B:4655:6029 (talkcontribs)

Okay, I think I got it fixed. It turns out that if pages exist in the database in a namespace that mediawiki doesn't know about, there is no way to display them and they don't show up in an XML export either. I was able to reset the page content model of the single interfering page in the database like so:

UPDATE page SET page_content_model = 'wikitext' WHERE page_content_model = 'Scribunto';

217.236.248.190 (talkcontribs)

You are my hero; just had the exact same problem. Thank you _very_ much for posting the problem and the solution. I've never installed or run Scribunto, so never occurred to me to check for it.

#GrayanOne

86.165.83.48 (talkcontribs)

Thanks for this!! I also had to run UPDATE content SET content_model = 1 WHERE content_model = 11 and delete the Scribunto row from the content_model table before the error would go away.

Tenbergen (talkcontribs)

Two small things...

  • I think I use a default install of mediawiki, and the table names are prefixed with "mw_", so I had to modify the two queries accordingly.
  • * for me the content_model was "3", not "11", so I suspect that is variable depending on what else is installed on your wiki.

Here is what I had to do:

  • Run the following to get the content mode ID:
    • SELECT * FROM mw_content_models WHERE model_name = 'Scribunto';
    • note the model_id and use it in the next SQL queries
  • Delete the Scribunto line from content model
    • DELETE FROM mw_content_models WHERE model_name = 'Scribunto';
  • Replace all lines in content where content model was ID of Scribunto with ID of wikitext
    • UPDATE mw_content SET content_model = 1 WHERE content_model = <the id you retrieved in the first query>
  • Replace all lines with Scribunto in the page table with wikitext
    • UPDATE mw_page SET page_content_model = 'wikitext' WHERE page_content_model = 'Scribunto';

I have added this to a section "Uninstalling Scribunto" on the extension page, so if you find corrections, please update there as well.

Kolept (talkcontribs)

Do you know what is the impact of uninstalling Scribunto? It came out of the box and it is slow. Do you know about how to install luasandbox to improve performance?

Reply to "Uninstalling Scribunto"

lang:formatNum returns 0 in some languages for small numbers (starting with 4 zeroes)

4
MarMi wiki (talkcontribs)

I don't know if this is the right place, but:

In some languages (en, de, ...) formatNum returns 0 instead of the formatted number when the number starts with 4 zeros (ex. 0.00001). But when called with noCommafy option, the number is formatted just fine (into exponential notation). From the lua module dev console:

mw.log(mw.language.new( 'en' ):formatNum( 0.000020004))

0

mw.log(mw.language.new( 'en' ):formatNum( 0.000020004, { noCommafy = true } ))

2.0004E−5

For some other languages (at least for pl) the formatted number is returned for both cases.

Context: :en:Template_talk:Round#Bug_in_rounding_0.000020004?.

FeRDNYC (talkcontribs)

The problem seems to have everything to do with the output of scientific-notation values in locales that use . separators; same issue if the input is expressed in scientific notation:

mw.log(mw.language.new( 'es' ):formatNum( 9.04E-8 ))
9,004E−8
mw.log(mw.language.new( 'en' ):formatNum( 9.004E-8 ))
0
mw.log(mw.language.new( 'zh_CN' ):formatNum( 9.004E-8 ))
0

I also feel like the commafy feature (when not turned off) is breaking the output of languages that use comma decimal separators, as well. Like, why are these different? (I'm not even sure which one is correct, TBH, but I feel like they shouldn't be different.)

mw.log(mw.language.new( 'es' ):formatNum( 1.0E20, {noCommafy = true} ))
1.0E+20
mw.log(mw.language.new( 'es' ):formatNum( 1.0E20 ))
1,0E+20

And then there's this:

mw.log(mw.language.new( 'en' ):formatNum( 1.0E20 ))
100,000,000,000,000,000,000
mw.log(mw.language.new( 'en' ):formatNum( 1.0E20, {noCommafy = true} ))
1.0E+20
MarMi wiki (talkcontribs)

In general, this could be a fault in regional settings, not in Scribunto.


About noCommafy (second example) - both are correct. First (with noCommafy) prints number in the format used internally by wikipedia (dot separator), the second one (without noCommafy) apply formatnum:.


Last example - I noticed that too, but it's not that big of a deal (the number is still parseable) - although it can suggest that the number is "exact", when sometimes it isn't (because it exceeded the precision):

mw.log(mw.language.new( 'en' ):formatNum( 1999999999999999))
1,999,999,999,999,999

mw.log(mw.language.new( 'en' ):formatNum( 19999999999999990))
20,000,000,000,000,000

mw.log(mw.language.new( 'en' ):formatNum( 1999999999999999, {noCommafy=1} ))
1999999999999999

mw.log(mw.language.new( 'en' ):formatNum( 19999999999999990, {noCommafy=1} ))
2.0E+16

FeRDNYC (talkcontribs)

Yeah, as I read up a bit more on :formatNum and the original {{formatnum}} parser function that preceded it, I realized that noCommafy was equivalent to the old |NOSEP parameter to {{formatnum}}, which exhibits the same behavior.

It's a bit disconcerting, though, I'll admit. I would've expected |NOSEP (and thus noCommafy) to turn off thousands-separator insertion, but not localization of the decimal mark. IOW, to be the difference between...

  • English: 1,000,000.123 and 1000000.123
  • Spanish: 1 000 000,123 and 1000000,123

But that's not how it works a'tall. #NowIKnow

Reply to "lang:formatNum returns 0 in some languages for small numbers (starting with 4 zeroes)"

Lua scribunto error on many pages (status 127)

11
Vapblack (talkcontribs)

Okay guys, I've been surfin fixing errors and all that. I got to a point where I just dont know what to do next.

First I'm using Mediawiki 1.24 on a centos server.

I'm using scribunto (18e738d) (if that matters)

and on a lot of my templates Im getting the dreaded "script error" when I click it, it says "Lua error: Internal error: The interpreter exited with status 127."


When I go to the error logs I get this: /home/worldafr/public_html/wiki/extensions/Scribunto/engines/LuaStandalone/binaries/lua5.1: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory

I installed readline locallally, is there a way I can direct it to the libraries?

Jackmcbarn (talkcontribs)

Do you have $wgScribuntoEngineConf['luastandalone']['luaPath'] set? If so, please unset it, and ensure that if you created/moved/edited/deleted any files in the extensions/Scribunto/engines/LuaStandalone/binaries directory or its subdirectories, that you undo any changes you made there.

Vapblack (talkcontribs)

Thanks. I just did that. now, I get "Lua error: Internal error: The interpreter has terminated with signal "11".". I found from reading that it's becasue the version of lua that shps with scribunto crashes. therefore, what I did was put a binary in the folder and direct it there.

Just to make sure, I deleted scribuntu, and uploaded a fresh copy and php update.php.

Jackmcbarn (talkcontribs)

The version of Lua that ships with Scribunto is fine. If it's crashing for you, you should figure out why, since otherwise your binary will likely not work either. Is there anything in the debug log when the built-in version crashes?

Vapblack (talkcontribs)

No.. When I go to the error log, it doesn't say anything. I guess I can try to reinstall mediawiki/

Jackmcbarn (talkcontribs)

That's almost certainly not going to help. Try installing Lua 5.1 via your package manager, and then point $wgScribuntoEngineConf['luastandalone']['luaPath'] to the path that it installed to.

Vapblack (talkcontribs)

wow. that worked. For anyone watching I did the following:

downloaded lua 5.1

uploaded it via FTP to my server

connected to my server via SSH

CD to the lua5.1 dir

typed make linux (which is the OS of my server)

and then added "$wgScribuntoEngineConf['luastandalone']['luaPath'] to the path that it installed to." to my localsettings.php file

Thanks JAckmcbarn

Allaze-eroler (talkcontribs)

care to tell us where to download this lua 5.1 version? it's hard to find the right place to download it...

thank you.

Vapblack (talkcontribs)
Vapblack (talkcontribs)

I just got this error again. I haven't changed anything in a very long time. Don't even know where to start now.

Mayurbhatt (talkcontribs)
Reply to "Lua scribunto error on many pages (status 127)"

I need help installing the wikibase. I'm stuck please

1
Innocentuzo (talkcontribs)

Please can some one help me with wikibase installation. I'm stuck. Please Help!!!!

Reply to "I need help installing the wikibase. I'm stuck please"

Lua error in Module:Authority_control at line 779: attempt to index field 'wikibase' (a nil value).

5
Summary last edited by Dinoguy1000 04:01, 11 March 2021 3 months ago

Wikibase needed to be installed.

Jamiehutber (talkcontribs)
Dinoguy1000 (talkcontribs)
Jamiehutber (talkcontribs)

Thank you sir!


All fixed now.

Innocentuzo (talkcontribs)

I need help installing the wikibase. I'm stuck please

Dinoguy1000 (talkcontribs)

@Innocentuzo: Please create a new topic instead of commenting on an old unrelated topic.

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

3
Mastergalen (talkcontribs)

Trying to add http://en.wikipedia.org/w/index.php?title=Module:Navbox to my wiki.

When I edit Module:Navbox and try to save the code, it returns the error:

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

Nothing is written to the error file either; only a blank file is created.

Edit:

Simple code such as:

local p = {}
 
function p.hello( frame )
    return "Hello, world!"
end
 
return p

results in the same error.

Mastergalen (talkcontribs)

I finally fixed the issue with help from User:anomie on the #wikimedia-dev IRC channel. Signal 11" would tend to indicate that the standalone Lua interpreter that is shipped with the extension has crashed.

Instead, run the Lua interpreter that should already be pre-installed on your server. For some reason the Lua binaries packaged in the extension do not seem to work.

Run the lua command via SSH. Check that your server is running version 5.1.x. Note that for Scribunto the version has to be 5.1.x.

Lua's default installation path is in /usr/bin/lua.

Then in your LocalSettings.php set:

   $wgScribuntoEngineConf['luastandalone']['luaPath'] = '/usr/bin/lua';

to fix the issue.


If running the Lua command shows it as undefined, then you could try installing it with yum install lua, though I am not sure if the version would still be 5.1.x

Bluedreamer1 (talkcontribs)
Reply to "Script error: Lua error: Internal error: The interpreter has terminated with signal "11"."

Undefined Offset in LuaStandaloneInterpreter.php

1
Jtodd1973 (talkcontribs)

I've suddenly started getting this notice message, repeated hundreds of times at the top of each page. Sometimes the page loads properly after the long list of repeated (identical) errors; othertimes, the notices simply repeat to the end of the screen:

Notice: Undefined offset: 1 in [...]/extensions/Scribunto/includes/engines/LuaStandalone/LuaStandaloneInterpreter.php on line 326

I'm unable to figure out what is causing the notice, although it did start after importing a number of templates from Wikipedia that are connected to the Main Page. Line 326 is the return command for the getStatus function:

public function getStatus() {
     $result = $this->dispatch( [
          'op' => 'getStatus',
     ] );
     return $result[1];
}

I reinstalled Scribunto, just in case I'd messed of some code somewhere, but it hasn't resolved the problem.

I've changed the settings to not show PHP notices for now, but clearly there's some issue that should be resolved.

Thanks for any advice.

Reply to "Undefined Offset in LuaStandaloneInterpreter.php"