Template:WikiProject Lua/header

I've created a new request page for Lua scripts at Wikipedia:Lua requests. If you're a Lua developer, please watchlist it. If you'd like to make a request, please do that too! Dcoetzee 23:09, 23 February 2013 (UTC)[reply]

There's a discussion at the technical pump currently about where to put code that you're experimenting with; as a result Module:Sandbox has been created. — Hex (❝?!❞) 16:39, 24 February 2013 (UTC)[reply]

the following code is arguably better than the current one ;-) [Note: It also highlights more Lua features - assertion, type checking, local scoping, tail call recursion etc.]

function factorial(k)

    assert(type(k)=="number" and k>=0, "factorial: argument must be a number >= 0")

    local function facto_helper(n, p)
        if n == 0 or n == 1 then
            return p
        else
            return facto_helper(n-1, p*n)
        end
    end

    return facto_helper(k, 1)

end

Tail calls are kind of cool, yet... if the point is that you merely return a function, so there is no need to keep track of the original frame after going to the tail call, then it seems like this is just a loop: i.e. you check your variables, do your multiplications, and move on to the start of the function again, just like you were doing a goto. I'm not sure I appreciate the unique power of it. Wnt (talk) 21:50, 24 March 2013 (UTC)[reply]

So templates can call Lua modules, parser functions and pages in MediaWiki namespace. Can templates, MediaWiki pages or parser functions be called from Lua? Can one call lua function that returns sevaral strings and pass them to a template? --Jarekt (talk) 16:24, 14 March 2013 (UTC)[reply]

You can call a template from a Lua module using frame:expandTemplate. Page content can be retrieved with the getContent() method of the title object. Support for calling a parser function is coming soon with frame:callParserFunction, or you could do it today by passing the markup to frame:preprocess. Toohool (talk) 19:25, 14 March 2013 (UTC)[reply]

Are module authors permitted to use other licenses (presumably in addition to the CC-BY-SA license) for modules they develop? -happy5214 14:32, 15 March 2013 (UTC)[reply]

That's a very good question. Creative Commons licenses are explicitly not recommended for software. — Hex (❝?!❞) 15:57, 15 March 2013 (UTC)[reply]

You own the copyright, you can grant whatever licenses you want (in addition, as you say, to the CC-BY-SA license that you've already granted). That would only apply to your contributions though, not to later modifications made by other editors. This is typically done with a copyright template placed on your user page... though you might want to modify one of them to specify that it only applies to Lua modules. Toohool (talk) 18:13, 15 March 2013 (UTC)[reply]

There is talk at the WMF about offering a central Lua repository and probably using more permissive licenses there. Of course that is all well in the future. Dragons flight (talk) 03:46, 16 March 2013 (UTC)[reply]

I just quickly sorted out the present Lua modules to Wikipedia:Lua/Modules/Overview. Looking them all over, I would make some comments about the naming so far...

• We have an even split on people who do personal testing in Sandbox/... and people who do it in User:... At this point, either of us could pull up stakes and migrate to the other pretty easily. We really ought to decide, flip a coin, something so we get this sort of stuff to a predictable spot.

• We have a lot of cases where related modules have the same name with "/" to indicate subpages, and some others where apparently related modules simply extend a name. With those it's not entirely clear if they are meant to go together or not. Normally this wouldn't be an issue, except I was wondering... if you write a Lua module that requires another Lua module or mw.title.new()s a data file, is the target module or file protected when the main module is cascade-protected? I don't know, but with some of these things being transcluded on every page in the wiki, and having elaborate powers to write anything they can slip by the interface, we should be wary of security holes, and the first step is to know quickly and certainly which are a unit, I think.

• The approach of Module:Sandbox - having every user put scripts into a common receptacle - seems unworkable. You couldn't keep track of your old experiments, and my experience is that yes, I do forget how I did things and have to look back at them. I think we might want to give up on that suggestion.

• Almost all of us to be a lot better about putting comments up front in the module and/or documentation saying what the heck our modules are FOR. Wnt (talk) 23:28, 17 March 2013 (UTC)[reply]

If we have to decide, I personally prefer "User:..." as that also allows a space for things that aren't sandbox. For example, if someone needs some custom Lua method for their userpage, or has some code snippets they like to use for debugging or copying and pasting. But why not allow both? Anomie⚔ 11:36, 18 March 2013 (UTC)[reply]

Cascading protection should work fine, since use of modules is recorded in the templatelinks table. And I see that Module:Math is currently in use on Main Page, and is correctly showing the cascading protection notice when I try to edit it. BJorsch (WMF) (talk) 11:41, 18 March 2013 (UTC)[reply]

I noticed that much - my question is, if the person who wrote Module:Math had decided to include some code file=mw.title.new("Module talk:Math/TableOfUnicodeMathCharacters") and used it to parse in certain characters (to make it so that he could fine-tune the font and size of pi, etc. independently of the module), could a random vandal edit that file and insert a picture of a big beautiful bottom? If so then clearly you'd want some finer control, maybe have people make a nominal invoke of all the subtemplates from the main template page or something. Wnt (talk) 14:06, 18 March 2013 (UTC)[reply]

title:getContent() records as a transclusion, so cascade protection will extend to pages fetched in that manner. BJorsch (WMF) (talk) 00:31, 19 March 2013 (UTC)[reply]

Documentation should go on the module's documentation page, since any edit to the module itself, even to update comments, causes everything using the module to be reparsed (just like with templates). This is why we ultimately decided not to try parsing luadoc comments to automatically generate documentation. Comments about the code itself should of course go with the code. BJorsch (WMF) (talk) 11:41, 18 March 2013 (UTC)[reply]

Good point! Wnt (talk) 14:06, 18 March 2013 (UTC)[reply]

I tried to start learning Lua and immediately hit the wall after the "hello, world" part and all I got afterward are "script error". I wonder if there's any actually helpful tutorial for those already familiar with Wikisyntax but without other computer language experience like Lua or C. The tutorials I found usually begin with a simple code to tell you to copy-and-paste (hello, world) then look at the outcome. Immediately afterward it gives you another line of codes which I have absolutely no idea where to insert it to make it functional at all. The tutorial I actually want is how a template with parser functions translate into a Lua module with explanation of what syntax equal what variable/function or whatever. It may sound like asking to be babysat or spoon-fed, but I'm totally stuck. -- Sameboat - 同舟 (talk) 07:07, 18 March 2013 (UTC)[reply]

There will be two office hours this week on IRC where the discussion will focus on Lua. In addition, you can ask questions on the MediaWiki wiki. If all else fails, there are plenty of people here willing to help, myself included. -happy5214 08:12, 18 March 2013 (UTC)[reply]

To give a different reply to the same question: this tutorial on the Lua website is a great source of information. It also helps to look at existing modules, to get an idea of what one would look like. -happy5214 08:12, 18 March 2013 (UTC)[reply]

I don't know if there's any question I can ask because I'm actually having trouble to get to the basic. I think Lua for Wiki lacks a helpful documentation like help:table which with that I can pretty much self-learning without asking any question. To me, mw:Extension:Scribunto/Lua reference manual is just a long list of specification without teaching novice like me anything to start with. mw:Lua scripting/Tutorial is also very lacking. I just stuck at local arg2 = frame.args[2] or "" which I don't know where to add it to make it functional. -- Sameboat - 同舟 (talk) 08:35, 18 March 2013 (UTC)[reply]

That line would go in p.hello (in the tutorial), before the return statement. Then, replace "frame.args[2]" at the end of the return statement with "arg2". Also see Module:BananasArgs for more help with arguments. -happy5214 08:45, 18 March 2013 (UTC)[reply]

Like this {{#invoke:Sandbox/sameboat|function}}? -- Sameboat - 同舟 (talk) 09:03, 18 March 2013 (UTC)[reply]

My bad, I meant the return statement in the p.hello function. -happy5214 09:08, 18 March 2013 (UTC)[reply]

There you go! You can do the same thing with the first argument. -happy5214 09:12, 18 March 2013 (UTC)[reply]

I must say that tutorial has missed one hell of important instruction. (If possible, would you rewrite that part of the tutorial? Because I'm unable to make it sound natural.) But then I'm curious, can the .hello be omitted like in the template? -- Sameboat - 同舟 (talk) 09:18, 18 March 2013 (UTC)[reply]

Which instruction? Where to put the variable declaration? To your second question, no, it can't be omitted. p.hello basically means the function is stored in the "hello" entry of the "p" table, which is returned by the module to MediaWiki. -happy5214 09:22, 18 March 2013 (UTC)[reply]

mw:Lua_scripting/Tutorial, from "results in frame.args[2] being an empty string (which will not, although the resulting text will look odd). One way to work around this is to assign the desired parameters to a local variable, and replacing nils with empty strings at this step; e.g.,". This instruction oversimplifies the full procedure of where to add that code (local arg2 =... ) and what should be replaced. -- Sameboat - 同舟 (talk) 09:30, 18 March 2013 (UTC)[reply]

Again, the official tutorial on the Lua website would probably explain it much better. -happy5214 09:32, 18 March 2013 (UTC)[reply]

Specifically, this section deals with local variables in Lua. -happy5214 09:33, 18 March 2013 (UTC)[reply]

Call me stupid please. I'm stuck at page 1 [1] instantly. How do I invoke the code as simple as print("Hello World") in Wikipedia honestly (Module_talk:Sandbox/sameboat). I think my problem is that I only learn Lua to contribute Wikipedia so I only want to know what I do in Wiki will get what right in wiki. I don't want to fiddle with a separate software like lua executable because I guess the usage is different to how you invoke lus's code in Wiki. -- Sameboat - 同舟 (talk) 01:53, 19 March 2013 (UTC)[reply]

The first and foremost thing to have posted prominently on every page a newbie might hit is that Script error is a link if you enable Javascript. (Which I am loath to do because it enables that awful custom editor, but that's another story...) Wnt (talk) 14:14, 18 March 2013 (UTC)[reply]

I know the "script error" explains something when you click it, but the message is far from useful, to me. -- Sameboat - 同舟 (talk) 14:35, 18 March 2013 (UTC)[reply]

Different people learn differently and I hope we can all work together to accommodate people who learn via videos, people who learn via worked examples and equivalence tables, people who learn by reading reference material, and people who learn via step-by-step instructions. Please check out Brad Jorsch's eleven-slide PDF and perhaps check out the accompanying video. It sounds like the Getting started ("hello world") portion of the Lua reference documentation didn't have what you needed -- maybe you could add some "what's missing from hello world" notes to the talk page to help us fix that omission?

I hear Sameboat's wish for an equivalence table ("you used to do x to get y result, now do z instead") and will try to encourage one -- has someone already started one? Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager (talk) 15:54, 18 March 2013 (UTC)[reply]

I appreciate the comparison of {{convert}}'s before and after, but the template is very inaccessible to most Wikipedians. So yes, I do hope for a much simpler example... -- Sameboat - 同舟 (talk) 01:45, 19 March 2013 (UTC)[reply]

Thank Dragons flight for clearing something for me. But with the banning of the print function and the extra steps to validate the lua code in Wiki, I can't tell if the lua.org tutorial truly helpful to me as I don't know how to convert all those examples to comply with MediaWiki's lua standard. Ultimately MediaWiki should issue another tutorial for Wikipedians (without prior knowledge of C and Lua) due to the differences from standard Lua. (At least script error should be shown when print function is detected.) -- Sameboat - 同舟 (talk) 04:26, 19 March 2013 (UTC)[reply]

I should note Help:Lua for beginners is now being developed. Wnt (talk) 21:46, 24 March 2013 (UTC)[reply]

We now have the /doc system somewhat integrated/forced trough the Scribunto extension. I've taken some steps to bring it partially in line with our Template documentation system.

1. Automatic transclusion of protection templates was added. MediaWiki:Scribunto-doc-page-show and MediaWiki:Scribunto-doc-page-does-not-exist
2. Automatic insertion of the green 'chrome' of our template documentation. MediaWiki:Scribunto-doc-page-show
3. Automatic insertion of the {{documentation subpage}} template. MediaWiki:Scribunto-doc-page-header
4. Editnotice for /doc page. {{Editnotices/Namespace/Module}}
5. Link/Create testcases link for Module pages. {{Editnotices/Namespace/Module}}

There is still lots of work to do of course

• Is it a good idea to deviate from the template standard of calling pages with testcases, tests for the module namespace ? I don't think it was really a active decision.
• The messages for /doc inclusion are currently added as contentlanguage, where really only their parameter should be included as such. Also explains why the uselang=qqq hack doesn't work to show the scribunto messages.
• Create a toolbox for MediaWiki:Scribunto-doc-page-does-not-exist to create doc pages and provide access to tests
• The documentation toolbox does not yet know about Module testcases (though the editnotice 'sort of' does).

But it's a start —TheDJ (talk • contribs) 22:18, 18 March 2013 (UTC)[reply]

So it is in development. For now, there is {{ml}}. -DePiep (talk) 22:43, 18 March 2013 (UTC)[reply]

Should be a bit further today. Some examples of pages and their edit page notices:

• Module:UnitTests () - a module with a documentation page
• Module:Math () - a module with no documentation and no test cases
• Module:HtmlBuilder () - a module with no documentation page, but with test cases
• Module:UnitTests/doc () - a documentation page itself
• Module:HtmlBuilder/testcases () - a page with testcases

For this to work, I currently have a {{documentation/link box}} template which is basically a fork of {{documentation/end box}}. The idea is to merge them again at some point if the module part is a bit more developed/stable. Of course it is also probably easier to generate them using lua, because they have quite a bit of logic. If you have ideas on how to improve.

Ideas for links, and tips that should be in the elements are welcome. —TheDJ (talk • contribs) 22:29, 19 March 2013 (UTC)[reply]

I might sound pricky, but what are you aiming at? We know {{documentation}} in templates, and I have started {{ml}} greatly (thank you). What do you want to add? -DePiep (talk) 23:55, 19 March 2013 (UTC)[reply]

The same as with Templates, a structure that helps make sure we use the same subpages for the same purposes, points at explanatory links for those who don't know the technology, reminds people to update testcases and documentation, has preload templates that help you start documentation/testcase pages from scratch in a consistent manner etc. Some of it is there now, some requires rewording, some requires linking to lua/scribunto best practices in Wikipedia namespace, some smaller things are still missing. —TheDJ (talk • contribs) 09:46, 20 March 2013 (UTC)[reply]

Thank you for explaining. I think I get it now. -DePiep (talk) 12:20, 20 March 2013 (UTC)[reply]

See discussion at Village Pump (policy)#Protection and management of scripts?. Relevant to Lua, userscripts, and user scripting generally. Comments appreciated.

FT2 ^{(Talk | email)} 02:07, 20 March 2013 (UTC)[reply]

I found this guide for learning how to code Lua, may be of help or use www.lua.org/pil/contents.html#P1

It is linked in the page header "Resources". -DePiep (talk) 00:10, 21 March 2013 (UTC)[reply]

As I have stated in the previous thread. If no one tells the beginner how to convert print function (disabled by Scribunto) into return, they might get stuck on page 1 like me. -- Sameboat - 同舟 (talk) 01:18, 21 March 2013 (UTC)[reply]

I've just started Help:Lua for beginners, just rushing through ... I'm sure there's much more to add and possibly a few things to ehm rephrase. Wnt (talk) 20:09, 22 March 2013 (UTC)[reply]

Link added to Wikipedia:Lua/Resources -DePiep (talk) 22:14, 22 March 2013 (UTC)[reply]

I feel like I must have reinvented the wheel here, but I copied Template:Tlx to Template:Mlx with minor modifications, so we can type

{{Mlx|ConvertNumeric|decToHex|99 33}}

and get {{#invoke:ConvertNumeric|decToHex|99 33}}

It would be good if someone could look this over for any flaws before it gets cascade-protected by something. Wnt (talk) 23:14, 21 March 2013 (UTC)[reply]

Actually, I might suggest someone could write a simple Module to replace Tlx, Mlx, and related extended parameter families with something that will happily accept and format arbitrarily many parameters rather than having a giant #if tree. Dragons flight (talk) 23:29, 21 March 2013 (UTC)[reply]

I did that for {{tlx}} at Wikibooks with Module:Template, if anyone wants to try to adapt it for Wikipedia. --darklama 01:36, 26 March 2013 (UTC)[reply]

I've been seeing people talk about the overhead of #invoke, etc. Is it known which is the better way? (Can we try with a module and a template and just compare the data in the HTML source comments, or does that not represent both things?) Wnt (talk) 00:58, 22 March 2013 (UTC)[reply]

The overhead is quite modest, unless you are running the command 100s of times. For something simple like this, I wouldn't worry about it. If you can improve functionality or make the code less of a tangle then it is generally worth doing. To give a concrete example, I estimate that Module:Citation formats a citation in about 10.5 milliseconds. Of that 10.5 ms, about 4.5 ms is Lua overhead which will be present for the typical invoke. Even so, you would have to generate quite a large number of iterations before the impact is noticeable to the user. Out of curiosity, I also tried timing {{Mlx}} and estimated it as running at about 6.5 ms per iteration right now. As long as the module is simple (far simpler than Citation anyway), you'll probably end up with a module version of Mlx that is similar in speed to the current template. Dragons flight (talk) 05:32, 22 March 2013 (UTC)[reply]

Is there somewhere that you have mentioned how to time scripts or templates like Mlx? I know about the NewPP report and Anomie's script, but I have seen a lot of variability in the NewPP Lua time usage and am not confident about the results. There is a tantalizing remark with "I repeated your 10× tests twenty times" here, but I haven't yet tried to work out what exactly that meant.

It does not particularly matter, but I am curious about any methods to get timings. My sandbox has 1689 calls to {{convert/sandboxlua}}, and the current Lua time usage is 2.062s, which is 2062/1689 = 1.2 ms/invoke. Of course 1689 calls is very atypical, and I have more pages with just 10 and 2 calls at test2—they show 4.5 ms/call for 10 calls, and 12 ms/call for 2 calls. Johnuniq (talk) 08:30, 22 March 2013 (UTC)[reply]

First, you have to know what you're looking at. "Lua time used" is just the time inside Lua, and doesn't include things like #invoke overhead. The Lua time usage should be fairly consistent for multiple parses of the exact same input. The "Served by" time is the entire time required for the page, including internal network delays and time lost to multitasking, and may vary significantly depending on various factors. Dragons flight used the latter to measure the #invoke overhead, by comparing the time needed to render an empty page versus a page with many invocations of a module with a single do-nothing function. As far as "I repeated your 10× tests twenty times", it means just that: You have a test that transcludes the template 10 times. I ran (a variation of) that test 20 times, recorded the timing for each run, and averaged. And regarding "4.5 ms/call for 10 calls, and 12 ms/call for 2 calls", that reflects the fact that mw.loadData is much faster for runs after the first, so the more calls there are the more that first call's slowness is amortized. BJorsch (WMF) (talk) 11:39, 22 March 2013 (UTC)[reply]

On a side note, that 4.5 ms overhead per #invoke should go down to about 2–2.5 ms with 1.22wmf1, and I have a change pending review to show timing information at the bottom of the preview page instead of requiring that the source be viewed. BJorsch (WMF) (talk) 11:39, 22 March 2013 (UTC)[reply]

• Lua time usage varies 1%-60% depending on busy servers: Although the Lua portion of total reformat time is more stable than markup parsing, which often varies over 200% slower (rarely over 300% slower), the Lua time clock tends to stay within ±20% of the seconds consumed. However, the Lua time usage can also vary wildly, as sometimes +30%, and on one occasion, I measured the Lua clock as nearly +60% longer than the quickest timing. Hence, if the combined Lua functions typically run over 6.3 seconds, then there is the rare danger of a 10-second Lua timeout on busy servers, as 6.3*160%=10.08 seconds. Fortunately, the Lua interface checks the clock before the next Lua function, and so a tedious Lua function could run 11 seconds but no timeout if the excess occurred during the final Lua function run (with no other Lua functions pending execution). -Wikid77 (talk) 19:29, 22 March 2013 (UTC)[reply]

I have run many timing tests, to compare using shell templates which contain #invoke versus direct use of {#invoke:}, and for tiny templates, such as string-handling functions, the template versions often ran upto 50% slower than direct #invoke of each tiny Lua function. The related, but separate issue, for speed of #invoke, can quicken every use of Lua, if 1.22wmf1 successfully doubles the speed of each #invoke. The #invoke speed in March 2013 has been about 180/second, compared to short templates running 350-600 per second, or parser functions >750/second, or character-insertion templates running 2,400/second. Similar to avoiding use of prior utility templates, when writing other utility templates, I would recommend to use the direct #invoke to access Lua functions from a utility template. Each layer of "shell templates" (to #invoke a Lua function) also increases the expansion depth by about +2 levels of the 41-level limit (shows "41/40"). For infoboxes, which use just a few Lua functions, then running the shell-template versions, rather than direct #invoke in the infobox, would be efficient enough, but still must beware the +2 expansion depth when running a shell-template version instead of direct #invoke in the infobox. -Wikid77 (talk) 19:29, 22 March 2013 (UTC)[reply]

When moving a module there is no redirect left behind and existing invocations should be fixed. The message from MediaWiki:Movepagetext-noredirectfixer should warn about this, perhaps a warning like MediaWiki:Moveuserpage-warning. Currently it is misleading advising to check for double redirects. Also, this page should explain that it is not possible to move a module to another namespace or vice versa, except doc pages (I think). --Vriullop (talk) 11:07, 22 March 2013 (UTC)[reply]

At the moment, we have three patterns in naming a module sandbox page:

1. Module:Citation/CS1/sandbox
2. Module:User:Dcoetzee/Sandbox
3. Module:Sandbox/isaacl/ColourSpace/Tuple

I suggest that is one too much. To maintain similarity with other sandbox pages (in template space and user space), I propose:

• #2 pattern should use lowercase /sandbox.
• Ditch the Module:Sandbox/isaacl ... pattern.

If we agree on this, we can encourage/discourage patterns. -DePiep (talk) 11:51, 22 March 2013 (UTC)[reply]

I think I started the Module:User/Sandbox pattern, before all the Module:X/testcases pages began. But before I switch ... where are we getting the lowercase pattern from? We have pages like WP:Lua/Modules, WP:Reference desk/Science. I remember there is some bug involving upper case and sandboxes, but I think that only affects the Module:Sandbox/Name pattern that you would be avoiding (not sure I have that right though). Still, I agree on the desire for consistency - at some point we want Lua virgins to be able to click on a link to "My Lua Sandbox" and get to a standard location. Wnt (talk) 13:20, 22 March 2013 (UTC)[reply]

The lowercase is used in both template and user space. This is possible because they are subpages always (by common practice). Subpages are fully case-sensitive (X/Sandbox =/= X/sandbox). Differences between spaces are irksome, so I suggested lowercase in Module too.

I don't know if there is a bug associated with Module:Sandbox/.... But surely the first letter of a page title is capitalised (also when creating Module:cherry). This would prevent us from writing the lowercase consistently everywhere. Anyway, if we discourage the third option, this question is gone. -DePiep (talk) 16:46, 22 March 2013 (UTC)[reply]

I started pattern 3. I have to say I'm not fond of pattern 2. The pseudo-namespace "User:" embedded in it is quite unlike the naming pattern of any existing pages and looks like a kludge. The other benefit of Module:Sandbox is that it's searchable with Special:PrefixIndex, allowing the Lua learner (most people at this point) to explore anyone else's experimental code that's put there. Pattern 2 creates silos. — Hex (❝?!❞) 16:09, 22 March 2013 (UTC)[reply]

Good points. The main goal is to have only two patterns, whichever. And this early in the development, that is easier to achieve. I'll drop a note in VPT. -DePiep (talk) 16:55, 22 March 2013 (UTC)[reply]

May I restate. The issue is simply limited to User sandboxes. Otherwise, any Module can use a sandbox. -DePiep (talk) 01:18, 23 March 2013 (UTC)[reply]

When I think about it, I see a subtle difference between the meaning between "Module:User:" and "Module:Sandbox/". I checked WP:About the Sandbox and noted this definition: "The Wikipedia Sandbox is a page designed for testing and experimenting with wiki syntax"; therefore to me, "Module:Sandbox/" are just for temporary testing purpose. And for "Module:User:", I imagine that is the place to reside any modules for long-term personal use, (though I can't come up with a use case for that now). To me, this is like the difference between a User page and the WP:Sandbox; while one can use one's own User page to actively experiment wiki syntax, User page should better contain long-term and useful contents.

And after all, I agree to figure out the naming early. – PeterCX&Talk 01:05, 23 March 2013 (UTC)[reply]

I'm not sure what "silos" are about, but the appeal of keeping a separate module "userspace" is that people will often want to work on a module but then put it aside for a while. To figure out bugs, html code, etc. while keeping it out of the way, so people don't settle on it for a template and have it submerge unexpectedly. Wnt (talk) 03:46, 23 March 2013 (UTC)[reply]

Is requesting on bugzilla a way to have Lua modules in some sort of userspace a good idea? Maybe a "User Module:" namespace? Martijn Hoekstra (talk) 15:27, 14 May 2013 (UTC)[reply]

While running tests to simulate a large #switch function of 3,000 branches, I repeatedly confirmed how passing thousands of parameters is typically exponentially slower beyond the first 500 parameters. Hence, passing 2,000 parameters runs 3 seconds, 4,000 parameters runs 13 seconds, or 6,000 parameters run 27 seconds. It would be much faster to pass a single parameter, as a single string of delimited choices, alternating with resultant values, rather than try to pass 3,000 choices as 6,000 parameters, which has been running about 27 seconds in the parser. Although Lua can still process the 6,000 parameters, to compare choices, within "0.02" Lua seconds, the load time of the #invoke interface is 27 seconds. The NewPP parser hits the huge delays when passing 6,000 parameters whether to Lua, or to a template, or to a #switch parser function of 6,000 "|x=" branches.

Time-delay formula: The initial tests show a time-delay formula as roughly delay=3^(n/2000) seconds, where n is the number of parameters passed, and for n=6,000, the delay has been 3^3 or 27 seconds, or for n=7,000 then the delay has been 3^3.5 or 47 seconds. Formula: Of course, the specific delay depends on server load, but follows the general exponential slowdown formula, where 7,000 parameters is far slower than a linear extension of 7000/6000 or 17% slower, and runs closer to 47 seconds (+70% slower) rather than 27+17%=31.6 seconds.

Affects Lua, templates & parser functions: Again, the time-delay overhead, to pass thousands of parameters, not only affects the Lua #invoke interface, it extends the same exponential time-delay slowdown in passing parameters to templates as well as "|x=" branch-choices in a #switch function (which also runs 27 seconds to process 6,000 branches). Passing just 1,000 parameters run about 1 second, and splitting 6,000 into 6×1,000 groups could process all 6,000 within 6 seconds, rather than 27.

Hence, for Lua, the alternative is to pass fewer parameters, but as strings of choices delimited by separator characters within each string. -Wikid77 (talk) 12:07, 24 March 2013 (UTC)[reply]

Why on Earth would you construct a Lua-based switch that way? If you want it to be fast, the switch options should be stored in Lua and cached with mw.loadData. Trying to import thousands of options via invoke just seems like the wrong way to go about it. Here is an example of a switch alternative that processes 6000 options in about 10 ms using Module:Switch: {{#invoke: Switch | switch | list=Switch/LongTest | case=6000 }}, where the case values are stored in Module:Switch/LongTest. Dragons flight (talk) 15:52, 24 March 2013 (UTC)[reply]

While we're at it - could somebody explain our decision tree for when to use mw.title.new, mw.title.makeTitle, mw.loadData, or to pass the page into the module as a transcluded parameter? Wnt (talk) 21:44, 24 March 2013 (UTC)[reply]

While we're at it you say - I don't get the joke. I made it a new thread. -DePiep (talk) 00:05, 25 March 2013 (UTC)[reply]

mw.title.new() uses the namespace in the string, if any, while mw.title.makeTitle() forces the specified namespace. mw:Extension:Scribunto/Lua reference manual#mw.title.makeTitle has an example illustrating the difference. Whether it's "better" to use mw.title.getCurrentTitle().prefixedText or to pass in {{FULLPAGENAME}} as a parameter, I don't know.

mw.loadData() can be used instead of require() to load a very large submodule that returns only data when the requiring module is likely to be used multiple times per page. It has nothing to do with the mw.title methods. Anomie⚔ 23:48, 24 March 2013 (UTC)[reply]

Well, you can also get data by opening a page with mw.title, or by transclusion. Does loading a module full of data have any advantages? To me it seems like it is more user-friendly to have data files independent of Lua code so that people who don't know it can work on them. Isn't it? Wnt (talk) 03:32, 25 March 2013 (UTC)[reply]

Information loaded via mw.loadData is parsed into a Lua table once per page render. Information passed via mw.title or transclusion will have to be parsed during every #invoke call, which may translate to many occurrences per page render. Hence, if a large table is likely to be needed during many separate invoke calls, then there is an inherent advantage to using mw.loadData. Dragons flight (talk) 04:10, 25 March 2013 (UTC)[reply]

Oh, OK. So Module:Sprite would be a good candidate for this: I was thinking to use it for pages with 170 flags, so 170 calls, and the whole point is to be super efficient if it can be. Wnt (talk) 04:23, 25 March 2013 (UTC)[reply]

Well, I transferred it over to use this... one 'feature' is that the data for loadData needs to be in Module: space. Given the extreme restrictions I would wonder if this restriction can be relaxed, but ... well, anyway, for now I can do it, but I'm sensing a tsunami of extra module: names (one for each file in this case; for other modules one for each page). Wnt (talk) 05:04, 25 March 2013 (UTC)[reply]

I've been trying to get to grips with the concept of frames, and I think I'm almost there. There are still a few things I'm not sure about, though. For example, Module:Navbar contains the code:

    local origArgs
    -- If called via #invoke, use the args passed into the invoking template.
    -- Otherwise, for testing purposes, assume args are being passed directly in.
    if frame == mw.getCurrentFrame() then
        origArgs = frame:getParent().args
    else
        origArgs = frame
    end

In what case would frame not be equal to mw.getCurrentFrame()? Does this apply if you are accessing the module from another Lua module, and not directly from a wiki page? Or is it something else? If anyone could help me to work this out I'd be very grateful. Best — Mr. Stradivarius ^{♪ talk ♪} 10:42, 27 March 2013 (UTC)[reply]

• The if and else statements respectively seem to correspond to line 1 and line 2 of the comments at the top, judging by this. It seems that local args (e.g. for testing), rather than args passed via invoke, are described here; possibly refers to this example. LittleBen (talk) 11:21, 27 March 2013 (UTC)[reply]

You've got it pretty much right. That's a bit of boilerplate code that I've been using in all the modules I write. The first clause supports the case where the module is being invoked from a template as {{#invoke: Navbar | navbar}}. The second clause supports a simple way to invoke the function from another module (such as from Module:Navbox), or from the debug console: Navbar.navbar({arg1 = 'foo', arg2 = 'bar'});. In Module:Sidebar, I extended the boilerplate further to allow a third way, invoking the module from a template and passing args in explicitly (instead of using whatever args were passed to the template), like {{#invoke: Navbar | arg1 = foo | arg2 = bar}}. Toohool (talk) 17:18, 27 March 2013 (UTC)[reply]

Thanks for the replies! This makes a lot more sense now - basically, I need to start using the debug console. :) I'm going to pinch that code from Module:Sidebar as well, as it's just what I need. — Mr. Stradivarius ^{♪ talk ♪} 18:29, 27 March 2013 (UTC)[reply]

I have another related question. I've been trying to use some of the other frame functions, and I can get them working via #invoke, but not through the debug console. For example, Module:User:Mr. Stradivarius/sandbox2 produces the right result when used via invoke from User:Mr. Stradivarius/Sandbox, but when I use the code = p.test() in the debug console I get the error "Lua error at line 4: attempt to index local 'frame' (a nil value)." What am I doing wrong? — Mr. Stradivarius ^{♪ talk ♪} 16:45, 29 March 2013 (UTC)[reply]

You're not passing it a frame, so frame in your function is nil.

You can use mw.getCurrentFrame() to get a frame (i.e. call your function as =p.test( mw.getCurrentFrame() )), and if you need to put arguments into the frame you can use mw.getCurrentFrame():newChild(). Anomie⚔ 01:00, 30 March 2013 (UTC)[reply]

mw:getCurrentFrame():newChild() can also be used as an alternative to adding an exception for when frame is not mw:getCurrentFrame() to functions. --darklama 01:20, 30 March 2013 (UTC)[reply]

Thanks both of you, that really helps. I've started using the code in the debug console for testing:

frame = mw.getCurrentFrame()
frame.args = {"a", "b", c="d"}
=p.test(frame)

That way everything works as it should. I'll have to add all of this to the help pages at some point, as I'm sure others will be having the same problems. Best — Mr. Stradivarius ^{♪ talk ♪} 04:28, 30 March 2013 (UTC)[reply]

p.test(mw:getCurrentFrame():newChild{title='A', args={"a", "b", c="d"}}); is like your example using newChild, with the addition of title which may be needed by some methods of frame. Using newChild twice can also be useful to test the getParent() cases as well, which some functions may assume exist:

 p.test((mw:getCurrentFrame():newChild{
   title = 'B',
   args = { "a", "b", c="d" }
 }):newChild{
   title = 'A',
   args = {}
 })

Also your example may have the unintended side effect of changing an attribute for the current frame anywhere the current frame is used, where as newChild creates a new copy. --darklama 13:19, 30 March 2013 (UTC)[reply]

I decided to implement a Lua replacement for the innards of {{Repeat}} as a learning project for my first Lua module. Please take a look at Module:RepeatString and Template talk:Repeat and see what you think. My initial thought is that having a module named after a single string function may be a bit extravagant, so perhaps it would be better grouped with other similar functions, if those exist somewhere. — Hex (❝?!❞) 16:49, 3 April 2013 (UTC)[reply]

Any reason you aren't using the builtin "string.rep( str, n )"? Dragons flight (talk) 17:01, 3 April 2013 (UTC)[reply]

Because I didn't know about it? Well, that makes that easier, then. Ho hum! I'll fix it up tomorrow when I next have some code time, then. Thanks for the tip! — Hex (❝?!❞) 17:17, 3 April 2013 (UTC)[reply]

Hmmm, you inspired me to write Module:LuaCall, with one small caveat... it doesn't work. Apparently tostring(_G["string.rep"]) is "nil", not "function". If anyone points me to the right tree I'll be grateful. (No, coroutines are not implemented) Wnt (talk) 16:01, 17 April 2013 (UTC)[reply]

That's because if you use "string.rep" Lua tries to find a key called "string.rep" in the table _G, but that key doesn't exist - there's only one called "string". Instead you can use tostring(_G.string.rep) or tostring(_G["string"]["rep"]). — Mr. Stradivarius ^{♪ talk ♪} 16:36, 17 April 2013 (UTC)[reply]

I should have thought of that! Somehow I just assumed the periods would be parsed like the rest of it. Anyway, I now have it working, so

{{#invoke:LuaCall|main|a=test |b=7|string.rep(a,b)}} produces

testtesttesttesttesttesttest

Wnt (talk) 19:49, 17 April 2013 (UTC)[reply]

I've created five categories for different levels of Lua module progress: since each explains the others, Category:Modules in alpha should be sufficient. In brief, the categories I set up were pre-alpha, alpha, beta, release, and protected. Right now I'm putting ratings on the documentation subpages, which I think is what someone suggested before at one point for categories. My own modules populate only the pre-alpha and alpha categories, but there are some here which I know have reached the other levels. I would welcome comments, and if people think the scheme is OK, please consider rating your modules... Wnt (talk) 23:31, 16 April 2013 (UTC)[reply]

Looks like a good idea, and the categories look sensible. How about using a template instead of typing in the whole category every time? I'm thinking of something where you could type, say, {{module rating|alpha}} at the top of the /doc subpage, and it would generate a notice and categorise the module in one go. — Mr. Stradivarius ^{♪ talk ♪} 02:15, 17 April 2013 (UTC)[reply]

In fact, I've gone ahead and created a pre-alpha version of {{module rating}}. Have a play around with it and see what you think. — Mr. Stradivarius ^{♪ talk ♪} 02:49, 17 April 2013 (UTC)[reply]

My lord, but you've just given me the idea for the kind of awful hack I think of that makes Anomie giggle (I hope). We could have an editnotice for the entire Module: namespace which #invokes a module that reads the doc namespace and looks for your template and then returns the Category: tag to be displayed on the Module instead of the doc page... nay, forget I ever said anything. :) Besides, I'm not actually that leet - I still haven't actually figured out how the heck Module:BananasArgs/testcases is placed in a category, and that's a "hello world" program! Wnt (talk) 14:27, 17 April 2013 (UTC)[reply]

That would be {{Module test cases notice}}. I found that out from the "View templates on this page" section on the . I assume that this is done by some magic somewhere in the MediaWiki namespace, but I wasn't leet enough to find where it is. :) The hack I used should have the same effect though - the template just checks that the subpage name isn't "doc" and categorises all other pages - which yes, includes the module pages. I've put it in action on my modules already - see Module:Csdcheck and Module:UrlToWiki for a couple of examples. — Mr. Stradivarius ^{♪ talk ♪} 14:51, 17 April 2013 (UTC)[reply]

Oh, of course! I should have realized that since doc is already transcluded you can just do that. Meanwhile, I found the code at Template:Editnotices/Namespace/Module - but not by a proper method, but by an ad hominem search of the editor TheDJ on the notice you found. Wnt (talk) 15:13, 17 April 2013 (UTC)[reply]

That ad hominem search was a good idea - the MediaWiki pages are MediaWiki:Scribunto-doc-page-show, MediaWiki:Scribunto-doc-page-does-not-exist, and MediaWiki:Scribunto-doc-page-header. We might be able to do some category magic with those if there's a good reason for it. — Mr. Stradivarius ^{♪ talk ♪} 15:43, 17 April 2013 (UTC)[reply]

Thanks. By the way - you've made a great choice of icons so far, and I was wondering if you can suggest one more: we should have a category for pages that will never be rated because they are "Hello world" programs, teaching demonstrations, bug examples, user scripts, sandboxes etc. Wnt (talk) 16:29, 17 April 2013 (UTC)[reply]

I have opened a discussion here: en:Module_talk:String#Replication on other wikis. Cya. --Rotpunkt (talk) 12:35, 1 May 2013 (UTC)[reply]

Would be nice for example if the modules on Commons (http://commons.wikimedia.org/wiki/Commons:Lua/Modules) could be called from all wikis, so that we could put there the most used libraries (like String), in the same way we use Commons for images. --Rotpunkt (talk) 12:46, 1 May 2013 (UTC)[reply]

A central code wiki is planned, but no date is set to start working on it yet. Note this central code wiki is not going to be Commons; they don't want to be it, and I know there are some in the community who wouldn't want it there either. BJorsch (WMF) (talk) 00:15, 2 May 2013 (UTC)[reply]

Thanks for answer. Which are the problems with sharing the modules on Commons among wikis in the same way we already share images from it? I am new to Scribunto, but I tought it was an ideal pattern. Anyway if with "central code wiki" you mean a way of sharing modules like we share images from Commons now, it would be perfect! I think that such a repository (Commons on something else) for sharing code without cut&paste over and over among wikis is essential, already in the first stages of this project for avoiding a useless fragmentation (like 22 versions of String [2]).--Rotpunkt (talk) 10:53, 2 May 2013 (UTC)[reply]

Because code was specially written for images, and the existing code for attempting this doesn't work very well. And for Commons specifically, as I said, Commons doesn't want to be the central wiki for code and some people don't want them to. BJorsch (WMF) (talk) 11:14, 2 May 2013 (UTC)[reply]

Thanks again for the explanation. Anyway, you talked about a "planned central code wiki". Will it work in the same way ("write once and run on each wiki")? can I find some discussion or project documentation about it? thanks in advance. --Rotpunkt (talk) 17:45, 2 May 2013 (UTC)[reply]

Hello, I'm wondering if there is currently a module that counts elements on a page. Perhaps li in a list or tr in a table? Technical 13 (talk) 12:12, 9 May 2013 (UTC)[reply]

Scribunto is intended to insert into a page the wikitext returned from running a Lua script. However, input to the Lua script consists of arguments explicitly passed in the {{#invoke}} that runs the script, and any arguments passed by wikitext to a template, where the template invokes the script. In other words, it is not possible to pass HTML or a selected portion of the wikitext in a page to Lua. There are some "expensive" (that is, slow) procedures that allow a script to read the wikitext of an entire page. I haven't tried that, but I suspect it would not be useful for more than occasional use. Johnuniq (talk) 01:18, 10 May 2013 (UTC)[reply]

Well, there is Module:TextMarkup. It counts the number of {{inc}} templates on a page. I suppose you can modify it to fit your needs. Just use it with care, like Johnuniq mentioned.--Snaevar (talk) 10:41, 10 May 2013 (UTC)[reply]

Thank you both for your answers. This question was not actually a question for me, but more as a follow up question for a {{Help me}} request on Help talk:Template#Counting items in numbered list (and I subsequently found out WT:WikiProject Templates#Counting items in numbered list and Wikipedia:Help desk#Counting items in numbered list too). I've linked back here so that if the original asker would like to try using the Module User:Snaevar has mentioned, they will likely have a lot of questions need some assistance in doing it. Anyways, I feel that my work is done for that request. Have a nice day! Technical 13 (talk) 11:38, 10 May 2013 (UTC)[reply]

What is the equivalent of {{fullurl:page name}} ?

I have used the mw.title library with a call like mw.title.new(page_name):fullUrl({uselang=lang}), but mw.title.new() is marked as an expensive function so I would like to known if there are alternative.--Moroboshi (talk) 07:06, 18 May 2013 (UTC)[reply]

mw.uri.fullUrl(mw.title.getCurrentTitle().text) — Bility (talk) 07:22, 18 May 2013 (UTC)[reply]

Is there a way to use the Mediawiki API inside Lua? Greetings Stephan Kulla (talk) 15:54, 19 May 2013 (UTC)[reply]

No, and the general view is that Lua should not be able to make HTTP calls, so it is unlikely that any access to the API will be added. That said, it is envisioned that Lua will ultimately be extended to allow access to most of the same Mediawiki information that one can get from the API. Dragons flight (talk) 19:54, 19 May 2013 (UTC)[reply]

Thanks for your answer Stephan Kulla (talk) 20:26, 19 May 2013 (UTC)[reply]

(Sorry for writing here. if u can help me)
I imported Module:Citation, Module:Citation/CS1/Configuration, Module:Citation/CS1 in bn.wikipedia. after imported i find error in article with this Category:Pages with script errors. now i wanted to translate Category:Pages with script errors in bn language. how can i do this (on which module, i find this Category for translation). --Aftab1995 (talk) 15:50, 23 May 2013 (UTC)[reply]

You can translate "Pages with script errors" on betawiki:MediaWiki:Scribunto-common-error-category/bn, in translatewiki. If you have not translated before there, then you will need to create an account and ask for translator rights.--Snaevar (talk) 20:40, 23 May 2013 (UTC)[reply]

Thanks--Aftab1995 (talk) 14:32, 25 May 2013 (UTC)[reply]

I'm very happy to announce that Template:FlagiconLua has reached feature parity with Template:Flagicon! It relies on Module:Sandbox/QuimGil/Flagicon, which provides the logics, and Module:Sandbox/QuimGil/FlagTranslations, where the flags data is stored. See the demos and more details at WikiProject Flag Template. I'm a rookie! Your help pointing to ways to improve is welcome. Also, your feedback here about the best way to organize the data is also welcome. Thank you!--QuimGil (talk) 07:52, 21 June 2013 (UTC)[reply]

Does mw.ustring.byteoffset work correctly with negative offsets? Putting the following into the debug window gives the values shown:

for i = -1, -5, -1 do print(i, mw.ustring.byteoffset('abcde', 0, i)) end
-1   3
-2   2
-3   1
-4   nil
-5   nil

I don't need the function—I'm just asking if it has a bug. Johnuniq (talk) 02:22, 25 June 2013 (UTC)[reply]

Yes, that's a bug. Anomie⚔ 14:07, 25 June 2013 (UTC)[reply]

Sorry if this was discussed before, but I did not find relevant links in a couple of minutes.

At Module:DisplayLuaTableContents I see numerous loops as

   for a,b in pairs(j) do
      output = output .. blah-blah-blah
   end

, but I learned that strings are immutable and hence this assignment is rather costly. What should I do to return a large text built from numerous smaller elements? Should I return a sequence of hundreds of strings relying on Scribunto in concatenating it? Incnis Mrsi (talk) 11:59, 2 July 2013 (UTC)[reply]

P.S. mediawikiwiki: Extension:Scribunto/Lua reference manual #table.concat is apparently a solution, but I didn’t test it yet. Incnis Mrsi (talk) 12:11, 2 July 2013 (UTC)[reply]

You might find string.format useful - see this discussion for some examples. I'm not sure how costly concatenation is, but I'd be interested to hear more if anyone knows. — Mr. Stradivarius ^{♪ talk ♪} 12:28, 2 July 2013 (UTC)[reply]

You can insert your words in a table (table.insert(output_table, word)) and concatenate that table at the end with the function that Incnis Mrsi gave (output = table.concatenate(output_table)). That way the string output will not have to be recreated every time a new word is appended to it. Darkdadaah (talk) 15:00, 2 July 2013 (UTC)[reply]

I prefer to not to sweat the small stuff. If something like this is more readable, and the table contains 10 elements, than I don't think anyone will care how performant your solution is. If it's 10.000 elements, that might be a different case. Martijn Hoekstra (talk) 15:47, 2 July 2013 (UTC)[reply]

Hi, your feedback is welcome at Bug 50329 - We need a common repository for Scribunto modules and templates. Please don't take those *personal* suggestions as a criticism to Wikipedia:Lua. I'm a happy user of this space myself with the pet projects I develop in my free time. It's just that a central repository would be so beneficial for everybody (en.wiki devs/editors included) and en.wiki can't really be (in my honest and personal opinion) that place. With a clear upsream in a central place like mediawiki.org then en.wiki and other Wikimedia projects could work better on local support and whatever is specific to their communities. Thank you for your attention!--Qgil (talk) 21:16, 2 July 2013 (UTC)[reply]

I created Module:Testcase table, and it seems to work pretty well (see the current transclusions). I was wondering if there is a way to improve the performance. for example, make this work without copying the args to a new table? I was going to deploy it on Template:Year in other calendars/testcases, but in my preview it runs out of time by the time it gets to the last test. also, if someone already wrote a module that does the same thing, let me know and I will have this one deleted. thank you. Frietjes (talk) 00:03, 4 July 2013 (UTC)[reply]