Talk:Lua scripting

script call template ?
18:57, 2 April 2012 (UTC), Rical wrote:

Sory if my edit is not in a right place. The question is about the transition between template and lua. There are lots of templates and js scripts and they will not disapear. Is it a good idea to permit to call them from lua scripts ?

I well understand this is a very bad way because the time and ram uses. But this permit to re-use a large number of existing template, waiting the time when they will be replaced by lua scripts.

Bots could replace template calls with lua script calls each time a replacement is OK.

-- Rical (talk) 21:11, 2 April 2012 (UTC)


 * I'm not sure at the moment whether invoking templates from Lua should be included in the initial deployment, since it's complex from the perspective of security and resource limiting. A simpler feature to implement would be allowing Lua functions to return some unexpanded wikitext for the parser to later expand. Do you think that would be useful? -- Tim Starling (talk) 00:28, 10 April 2012 (UTC)


 * Yes, this is an other way for same goal.
 * A template call a Lua fonction with parameters
 * Then the Lua fonction generate an unexpanded wikitext, including adapted template call with adapted parameters
 * The unexpanded wikitext can include one or some template calls.
 * Then the parser expand wikitext including the template call(s).
 * I think this is simple to code in parser and in Lua users-scripts and this re-use existing template and would be usefull.
 * But ...
 * If we hope to replace existing template by more efficient Lua script, this way do not permit to easy replace the calls of them. The next step should be :
 * A common extra fonction could be defined in Lua library to do the same as before. Exemple :
 * s = templateCall( s, templateName, param1, param2, ... )
 * Then replace the template call by a future Lua equivalent script become 'easy', even by bot. The replacement give :
 * s = equivalentLua( s, param1, param2, ... )
 * Is this a right way ? Do we want replace many templates ? Will we be able to translate-convert many tempates by equivalent Lua scripts automatically ?
 * Rical (talk) 17:02, 10 April 2012 (UTC)

var in template

 * Some time in template i would like to use var that could replace repeated code. This could reduce the interpreting time, simplify and reduce the code.
 * To do it we could use negative parameters and a syntax similar to switch.
 * To define and  we could code :
 * Rical (talk) 23:34, 3 April 2012 (UTC)
 * Rical (talk) 23:34, 3 April 2012 (UTC)


 * No, there won't be any feature which requires wikitext to be parsed in a certain order, such as top to bottom. This gives us some more flexibility in future parser design. Memorization is probably the best option for efficiency. -- Tim Starling (talk) 00:28, 10 April 2012 (UTC)


 * Yes, '#var:' was not the right word, my idea was to memorize a wikitext value in  as local constant to re-use it in the next wikitext in the same template at the same level. The parser extented function could be #const: or #constant:
 * Rical (talk) 17:02, 10 April 2012 (UTC)
 * Rical (talk) 17:02, 10 April 2012 (UTC)


 * After a few minutes, i think that the value of a «constant» could be replaced by an other value to generate the next wikitext later in the same template. Then the «constant» becomes almost a variable on the same local level. The parser is not more complex. Rical (talk) 21:26, 10 April 2012 (UTC)

Simple users
How will any simple wikiuser without a programmer's background learn to use this? Now it seems to me that only those who learnt programming will be able to use it. Now even the simplest templates can make some editors cringe, how is this going to work in everyday wikilife? I just can't imagine trying to tell new users to learn scripting in Lua to make templates... Or will this have a user friendly interface? Teemeah (talk) 13:20, 2 June 2012 (UTC)
 * I think the simple answer is that nobody expects new users to do this. Templates can already be quite complicated, juggling all the  and   and  . And if people want to use the “old” template syntax, they still can. Also, it's pretty much impossible to make something that is both powerful and “user friendly” so that new users without any programming background could quickly pick it up. Of course, a dedicated newcomer should be able to pick it up, but Lua is probably one of the better languages for this, because it's quite simple. Svick (talk) 13:32, 2 June 2012 (UTC)
 * Moreover most of the time important templates − in term of visibility and/or effective usage − are protected and are in pratical only modified by admins (with template-experts in the editing loop). Regards, Hexasoft (talk) 14:42, 18 January 2013 (UTC)

Breaking the server
Can I try to break the server with this, or is that discouraged? --Carnildo (talk) 23:15, 22 August 2012 (UTC)

Unicode support
Is there any plan to make Lua function properly with unicode characters? At the moment, string length seems to be being measured by how many bytes are in a string, not how many proper characters. Having string manipulation work with non-ASCII characters would be necessary if this is to be deployed on non-English wikis, I think. --Yair rand (talk) 03:13, 23 August 2012 (UTC)
 * Just to add to this, there seems to be no problems with the code handing various Asian unicode characters as parameters. But I noticed a problem with the code editor on test2 with lines with non-ASCII characters in: the cursor position would be out by one. The workaround was to copy and paste those lines into another text editor, or even the edit summary box, to work on them, but this would get tedious if there were a lot of non-ASCII text.--JohnBlackburne (talk) 12:12, 9 October 2012 (UTC)
 * So is this actually a problem with the code-editor failing to handle unicode characters? Maybe that would be a better point of attack. In reference to the original question, we don't seem to have heard anything relating to whether Lua will be made unicode-aware any time soon. —Phil | Talk 12:30, 9 October 2012 (UTC)

Errors


Error handling is terrible. What are we supposed to do when faced with error messages like that? This, that and the other (talk) 11:15, 23 August 2012 (UTC)
 * Oh, I see... it's an HTML comment. Still, that is rather abstruse. This, that and the other (talk) 11:15, 23 August 2012 (UTC)
 * It looks like you can click on the error message and it will show a small window with the error message. But that's still really confusing, I wouldn't expect big red error message to be clickable or that clicking will show the error in that window. Svick (talk) 13:27, 23 August 2012 (UTC)
 * Tim Starling tried to help about this. You can read his answer there :
 * « I wrote a debug console module and deployed it here, let me know what you think of it. » -- Tim Starling (talk) 04:50, 14 July 2012 (UTC)
 * You could try it and return your feeling to him and us. --Rical (talk) 19:51, 23 August 2012 (UTC)

API/syntax
Lua fellow here. The syntax and API described in Lua_scripting/Tutorial could IMO be improved. I hope it is not too late...

Regarding the API, why do you pass the arguements in the frame table? I don't know the purpose of the frame, but I suppose that it contains meta-information. With the current system, reading an argument requires two table lookups, which are far more expensive than fetching an argument (similar to a local lookup). Furthermore, you create the  table, which takes time, space, and time again when the grabage collectore runs. I'd suggest something like this:

function p.foo(frame, named, bar, baz) ... end

would be nil unless there are named arguments. In that case, it is a table with appropriate key/value pairs. It would be up to the Lua scripter to handle both named and unnamed arguments if they occur. Alternatively, named arguments could be part of the frame, but only when they exist.

if frame.named then bar, baz -- already locals since they are arguments = frame.bar or bar , frame.baz or baz end

Actually, I'm not sure if the positional args should be preserved when named arguments are used. It would probably be confusing for editors. Either go all positional or all named (but a given functions could support both).

Regarding the invocation syntax,  (or a variation thereof, I'm not familiar with the meaning of initial sigils in WikiMedia templates) is ligther, more readable and more semantic than. It also allows to have modules that are actually just one function. -- Pierre-Yves 89.90.144.90 15:08, 30 August 2012 (UTC)
 * Hi, Pierre-Yves. Thanks for your note. Tim Starling discussed it starting around 01:12:10 in these IRC logs. Hope this is helpful. Sumana Harihareswara, Engineering Community Manager (talk) 01:40, 6 September 2012 (UTC)
 * Just a point: have both named and unnamed arguments seems fine to me. Named args are fine for pre-defined elements but in somes cases templates also has something that is highly variable in syntax/order, and the only way to handle it with named parameters is to make lot of parameters most of the time never used (i.e. param2, param3, param4… until enough for any purpose). Regards, Hexasoft (talk) 14:48, 18 January 2013 (UTC)

Modules calling Modules
I should just say I've been on WP for years, done a little trivial template work, but complex templates are beyond me. But two days in, learning Lua at the same time, I've ported one of those complex templates to Scribunto:.

One thing I encountered though is the difficulty calling one module from another. I ended up adding all of this

local p = { language = require "Module:Language", fr = { args = {} } } function p.getParent return p.fr end

Then to invoke the module function need to do something like this

p.fr.args[1], p.fr.args[2] = "zh-Hans", s            s = p.language.lang(p)

This works but seems convoluted just to call one function and is probably not especially efficient. It would be better if there were a function that could be called directly, so if the argument parsing code were separate from the logic that processes them, in a function which could be called from other modules. This could be done in Module:Language or a separate Module:Language0 meant to be called by other Modules. Or is there some other preferred way of doing this that I'm not aware of?--JohnBlackburne (talk) 23:59, 9 October 2012 (UTC)

Various notes/questions
Hello, I started playing with modules and now have a basic taxobox (infobox for biology) that works fine. Whatever some points and questions I met during working on it: Whatever, a very nice tool! :)
 * are there any limitations for Module: namespace? I tried to put a "tools" module dedicated to my taxobox. I puted it in Module:Taxobox-fr/tools but I failed to use it from Module:Taxobox-fr. I renamed it into Module:Taxoboxoutils and now it works fine.
 * does the "local config = frame.args" and then to read "config.pagename" is supposed to work? I get an error because it is 'nil' in my code. I use preprocess(" ) rather but it seems not to be the best solution.
 * I did not find how to handle errors (not errors in the code but errors in the template/module usage). I mean it would be nice to be able, in the middle of the module, to detect a bad usage/parameter/whatever and to be able to "leave" the module with a program-generated error page. Sometimes you have to perform complex computations to detect a problem, in the middle of the normal code. Something like calling a function that can perform a "exit 'code to display'" could save writung some complex if/else code. Sorry: I misundertood the "return must be at the end" :) It works fine to return inside code, until it is at the end of a code bloc. Hexasoft (talk) 11:47, 4 December 2012 (UTC)
 * it is not clear for me if "Full deployment of Lua to the production cluster" (in the roadmap) is only about mediawiki or will also applies to wikipedias.

Regards, Hexasoft (talk) 10:48, 4 December 2012 (UTC)
 * Some updates:
 * using modules in subpages (such as Module:Taxobox-fr/tools) works, but it seems that it is not well handled for cache update: changes in a submodule are not visible in articles that use the main module. If a change is applied to the main module changes in submodules become visible. It is so a bug (that may be corrected) or a feature but in this case it would be fine to prevent using submodules in any way to prevent the problems I met.
 * 1.21wmf7 is deployed everywhere (as seen is Special:version). How scribunto extension may/will/is be activated on wikipedias?
 * Regards, Hexasoft (talk) 14:34, 18 January 2013 (UTC)