Extension talk:Scribunto
Contents
| Thread title | Replies | Last modified |
|---|---|---|
| attempt to index field 'text' (a nil value) in luasandbox | 2 | 14:05, 22 May 2013 |
| UniServer (Coral_8_8_1) and Scribunto on Windows 7 | 4 | 02:23, 14 May 2013 |
| Support | 0 | 19:57, 7 May 2013 |
| MediaWiki 1.20 | 3 | 04:40, 3 May 2013 |
| Limits of mw.language:formatDate | 5 | 17:23, 30 April 2013 |
| $wgScribuntoUseCodeEditor = false; | 1 | 13:31, 15 April 2013 |
| Installation of Scribunto | 3 | 19:38, 8 April 2013 |
| Newline encoding | 3 | 21:23, 3 April 2013 |
| Register external library using registerInterface() | 2 | 13:46, 28 March 2013 |
| #invoke without repeating all parameters? | 7 | 10:02, 28 February 2013 |
| require_once | 1 | 07:17, 5 September 2012 |
| Shebang | 2 | 23:52, 17 June 2012 |
I am using Scribunto extension and I see this error in the final pages: attempt to index field 'text' (a nil value)
When I use mw.text. Any idea why I get this error and how to fix it. This happens when I use luansandbox.
Hello: I am trying Scribunto for first time with UniServer on Windows 7 and was not getting Module Talk pages etc. to save correctly (spun wheels and was stuck with a blank page when saving) nor get Lua to work etc. I changed 'defaultContentModel' => MWNamespace::getNamespaceContentModel( $ns ), to 'defaultContentModel' => ' ', In LocalSettings.php -- I did not have require_once("$IP/extensions/Scribunto/Scribunto.php"); and $wqScribuntoDefaultEngine = 'luastandalone'; at the bottom; but rather somewhere with my other listed extensions near the middle... Once I moved that to the bottom of LocalSettings.php -- appears to now be working... (Lesson learned: read the installation note to put Scribunto at the bottom of LocalSettings.php... Thought I would pass this forward... Cheers! wjk
A few observations:
- When editing a Module:Foo I noticed there is no Show Preview button at bottom of page
- MediaWiki 1.20.3 is a bit slower but not a big issue...
- Passing a (list) parameter (ie. Dogs, Cats, Bears) to a Module and converting that list to an array for sorting (ignoring case) and removing duplicates was a fun experience... Lua isn't all that simple to do but understandable and I like it . Reminded me of the Winter extension.
- Can now almost get rid of 4 or 5 extensions (when Scribunto is finalized or out of beta)
- Would like to see tcl as one of the future scripting languages in Scribunto.
- If you add more scripting languages and keep the Module namespace, will there be a way to identify which code/language is being used... or is there to be more namespaces added?
- So far - so good -- keep up the great work -- congrats...
- Issue with Scribunto that may be troublesome or I am missing something?
- An #invoke's parameter that is a string containing an '=' sign and to be handled by Lua Library String functions in the invoked module will fail.
- That string when assigned to string variable in the called module will be nil; thus, a Script error.
- Strings passed without an '=' work fine. This I believe is a parsing issue and probably a vary complex one.
- Any way around this? --- Thank you!
This isn't an issue with Scribunto, it's how MediaWiki's double-brace syntax works. See the first bullet at en:Help:Templates#Usage hints and workarounds.
Great! - I had just been to wikipedia and found that page this morning.. Thanks - I forgot to add Template:= to my test wiki as well.
- I had been defining a variable and passing that variable as a parameter rather than surrounding the ='s sign with curly brackets but will resort to convention.
Again - Thanks!
- Add a link for (installation) support?
I don't even know where to ask the following question: I've installed Scribunto and it shows up fine in Special:Version. Note that I have a Windows PC, but installed it on my hosting (Linux) server.
- It took me a while to figure out I had to change the 'lua' binary to executable.
This should be added to the installation instructions. Probably occurred because I first transferred to my PC and then to the Linux host.
- I'm not sure the 'lua' binary works. Within my own 'Module:Bananas', I keep getting
Script error: Lua error: Internal error: The interpreter exited with status 1.
Indeed, no matter what I place into the debug console, I get
Lua error: Internal error: The interpreter exited with status 1.
Without command shell access to my hosting site, I'm not sure what more to do.
- Can an installation script be run to test the installation?
- Of course, my big worry was that while PHP can be standardized (I had little trouble installing Mediawiki), the installations of binaries may be problematic. As more scripts are converted to Lua and used in other Wikis, the installation of Scribunto must be guaranteed.
I made a small change to engines/LuaCommon/SiteLibraries.php on line 43 and changed
'defaultContentModel' => MWNamespace::getNamespaceContentModel( $ns ),
to
'defaultContentModel' => ' ',
Now it works for 1.20 as well.
Also: If you run it on a German wiki like me, add to Scribunto.namespaces.php these lines:
$namespaceNames['de'] = array(
828 => 'Modul',
829 => 'Modul_Diskussion',
);
Considering that gerrit change Id487097c changed the display of module pages to entirely use ContentHandler, I expect that is will be rendering them wrongly on 1.20 now.
Changing line 43 to what VolkoV suggested works for me as well on 1.20.4
I created a test script in Lua that calculates all available Easter dates. The final output table consists of ~8000 dates. In the next step I tried to format the dates to strip the year and display only day (in arabic notation) and month (in roman notation) but I got error -> "Lua error: Too many calls to mw.language:formatDate()". Why is there any limit? What is the limit? Is any workaround to obey it? Regards.
The limit is currently 6000 characters total for the format srings in all calls to formatDate() (e.g. 6000 calls with 1-character format strings, or 600 with 10-character format strings, 1 with a 6000-character format string).
The limit was copied from ParserFunctions's #time function.
I divided the whole table into smaller chunks (a hundred years per table), hoping that the limit is per {{#invoke:...}}, but this did not help. The limit is per page, and is ehausted in XVI century :-(. Are there any chances to get rid of the limit in the function code? The LUA scripts are already limited in two dimensions: time of script execution and memory consumption.
I created custom date format routine to avoid the limit and got my expected result in this page. However I don't like the solution.
I got a lot of script erros with $wgScribuntoUseCodeEditor = false; Why, what does it do? 90.184.223.136 10:55, 14 April 2013 (UTC)
It tells Scribunto to make use of the CodeEditor extension for editing module pages. What errors, specifically, are you getting?
Is it possible to mention the extra namespaces Scribunto needs in the installation section, with the code to add to localsettings.php?
also,
If Scribunto is downloaded and saved in the extension folder before setting up the wiki, the wiki-installer only adds the "require once" line to localsettings.php, and not the line "$wgScribuntoDefaultEngine = 'luastandalone';" or the namespaces.
Regards Peter
Scribunto doesn't need anything added for extra namespaces in LocalSettings.php. What are you referring to?
As for the installer, it does not appear to have hooks of any sort for extensions to specify additional variables.
In http://en.wikipedia.org/wiki/Wikipedia:Lua and http://en.wikipedia.org/wiki/Wikipedia:Namespace namespace 828 and 829 are mentioned for module and module-talk, so I assumed they are necessary. Are they not?
Peter
Posting it here, since someone may find it useful...
I had big problem with scripts that were returning texts containing a newline character ("\n") while running a test wiki in Windows environment. It was being displayed as "Script error" with "Lua error: Internal error: Unable to decode message." as description.
The problem is that while data passed to lua are being properly encoded, the ones that are returned are passed as raw data through textmode pipe, thus the "\n" was being encoded as "\r\n". In the end the php script didn't read all the transferred data, because there was one extra character in buffer for each newline character, desyncing whole communication in the process.
Managed to bypass the problem with small change in \engines\LuaStandalone\LuaStandaloneEngine.php
Lines 294-295 (the receiveMessage function)
$body .= $buffer;
$lengthRemaining -= strlen( $buffer );
were replaced with
$buf1 = strtr($buffer, array("\r" => ""));
$body .= $buf1;
$lengthRemaining -= strlen( $buf1 );
I can confirm the bug on Windows Vista and also —with a small fix— the solution.
The line
$buf1 = strtr($buffer, array("\r" => ""));
introduces a new bug for strings containing legitimate \r. A better replace is
$buf1 = strtr($buffer, array("\r\n" => "\n"));
Also submitted as bugzilla:46294.
Confirmed bug (and above fix) on Windows XP. Added more notes as per https://bugzilla.wikimedia.org/show_bug.cgi?id=46294#c3
bugzilla:46294 was marked as "RESOLVED FIXED" at 2013-04-02 23:38:24 UTC
Using the following registration method
$this->getEngine()->registerInterface( dirname( __FILE__ ) . '/' . 'smw.library.lua', $lib, array() );
will cause an internal error
Lua file does not exist: C:\xampp\htdocs\mw\extensions\Scribunto\engines\LuaCommon/lualib/C:\xampp\htdocs\mw\extensions\SemanticMediaWiki\includes\lua/smw.library.lua
- Verification
For example, after the smw.library.lua is copied into LuaCommon/lualib directory all methods do work as specified but since Scribunto expects the loading directory to be the Scribunto base directory, registerInterface() for external libraries will fail in case there are not included in LuaCommon/lualib directory (and of course I don't want to copy the file, it should remain in the external library folder).
- Version
MediaWiki 1.21alpha (37875db), Scribunto (a852755)
The problem is the Windows directory paths with drive letter; since c98cc645 Scribunto has supported absolute Unix-style paths in registerInterface(), and 8fd45026 tried to extend this to Windows but failed to consider drive letters.
Would you mind filing a bug so the issue can be properly tracked?
Is there an #invoke call that simply passes all parameters from the template to the module without repeating them? This would make it possible to output an error message if somebody uses a template with a parameter that is not recognized by the template (any more).
You can see an example in Module:Auteur which also translate arguments names and other messages. If you want use it, you can change only the arguments tables in another context. A lua bug in multilevel tables forces me to change the structure of the table Trad. Some options help to document the module. This treatment of arguments is not enough debug but already usable and could become a shared module.
There's something better.
You know that frame.args holds the arguments passed in the {{#invoke:}} tag. Well, frame:getParent() gets you the frame for the template that contains the {{#invoke:}} tag, including the parameters passed to it in frame:getParent().args.
However, it is not allowed to go up more than the one level in that manner, to reduce the risk of making overly complex modules.
Yes for frame.args, but I experimented some bugs in http://test2.wikipedia.org/wiki/Module:Author
- Search "repair", then you can try :
- -- This repair Lua bug where : args = frame.args give later no arguments.
and you can experiment yourself by changing some comments at begin of lines, and test with http://test2.wikipedia.org/wiki/Auteur:Arthur_Rimbaud. I also experiment :
- -- This repair Lua bug where : Argts.any_function or Argts.any_table disappears.
- -- This repair Lua bug where : {{NAMESPACE}} give nothing. Look at "current_space=" (which is OK in http://fr.wikisource.org/wiki/Modèle:Auteur3/documentation)
- -- This repair Lua bug where : Trad[arg_lang]["options"] = value give an error.
- -- This repair Lua bug where : mw.site.namespaces.name is unknown but will be OK in next version.
I see many comments in there about "This repair Lua bug", but there's no indication of what the bug is or how to reproduce it.
The best thing would be to make a module, template, and test page that does nothing except show the bug. The test page should also explain exactly what the expected output is and what you're seeing, in addition to the live test.
About lines with "args_known = Argts.args_known", the table-or-object Argts contains tables and fonctions XYZ. From others functions in the same Argts, I cannot call or refer to XYZ by only their names. I must first "restaure" them like the table-or-object Argts "don't remember" them. Is this normal or no ? Do we must always write Trad.XYZ to access them ?
After this point, do you need that I write a special module for this case ? And for the 2 other ?
If I understand you correctly, you're thinking of this along the lines of a C++ class something like this:
class Argts { public: int foo = 1; int bar = 2; void baz() { // Member variables don't need to be prefixed printf( "%d, %d\n", foo, bar ); } }
and thinking that a Lua table like this should somehow work the same way:
local Argts Argts = { foo = 1, bar = 2, baz = function () -- These aren't "member" variables, so this doesnt work mw.log( string.format( "%d, %d\n", foo, bar ) ) end }
That's just not how Lua works. Functions in Lua, unlike in C++, are first-class objects. The function assigned to Argts.baz has no idea that it happens to be a value in a table, and in fact could be a value in multiple tables as well as being stored in local or global variables. So you always have to specify the Argts table in a situation like this.
Is it desirable to put an optional or mandatory shebang on top of the scripts in the Module namespace? It could be useful if there are other scripting languages in the future. I find it could be a priori a good idea to let the possibility to someone to develop an interface to some other language (Python, Perl, JavaScript…).
I am a new bie here, but I named my lua script Module:mathRoman.lua to discard any doubt and help the management of other kind of modules. In my searches I don't remember anythink about this point.
Extension:Scribunto page is new for april 16th.
Now I see that the Extension:WikiScripts#Functions (for a language mixing JavaScript, PHP and Python) use also the Module: namespace, but do not use a typical end of names of modules.
I thing also to mix various types of scripts is a risk.
