Wikipedia talk:Lua/Archive 2

At the moment, the way analogous tasks in different Infobox templates are done seems diverse and arbitrary. Take, for example, listing the non-English name of a (thing) in that (thing)'s Infobox. I've seen non-English names put in the same parameter as the English one, but with a <br> in the middle;^[1] put in a separate, non-language-specific parameter;^[2] and put in separate, language-specific parameters.^[3] All these different ways of performing what is essentially the same function, but in different templates, is (a) difficult to master for the editor, and (b) will surely lead to style inconsistencies somewhere or other. Would it be feasible to assimilate all Infobox templates to be based off a central Module, so that (a) we could have a standard set of parameters/parameter names for doing things for editors, and, consequently, (b) a set format that they would appear in for readers (w.r.t. font size, emboldening, and so on)? Thanks. It Is Me Here ^{t / c} 21:01, 5 April 2014 (UTC)

I'd like to point out that user Hoo man has been working on an extension with a lua module called Capiunto, that makes it easier to build Infoboxes in a more consistent method for sites (not every wiki has an active template community, able to handle all of these problems themselves). Taking this up to the level of content, parameter naming conventions and value validation goes a bit further then what Capiunto was envisioning so far, but it might be something to keep an eye on. —TheDJ (talk • contribs) 12:32, 23 April 2014 (UTC)

I'm having an odd problem with a module/template I'm working on at {{zh/sandbox}} and Module:zh . When it appears on its own in a paragraph, i.e. with blank lines either side, it seems to swallow white space.

Chinese: 香港

Chinese: 中国

Chinese: 北京

Compare that with the current template {{zh}} used identically

Chinese: 香港

Chinese: 中国

Chinese: 北京

This likely isn't much of a problem given how it's used, normally inline with text, e.g. Beijing (Chinese: 北京) is the capital of China (Chinese: 中国), which means an obvious 'fix' of generating blank lines (e.g. para breaks) within the template would only make things worse. I can't see anything though that's causing this. It only seems to happen with white space - I used lists here: Template:Zh/testcases with no problems.--JohnBlackburne^words_deeds 16:58, 26 April 2014 (UTC)

@JohnBlackburne: It's doing that because the lines end with [[Category:Articles containing Chinese-language text]] (which seems like it may be a bug). Jackmcbarn (talk) 17:02, 26 April 2014 (UTC)

Indeed, it's bugzilla:17988. Jackmcbarn (talk)

OK, thanks. Yes, It's different from the current template that embeds them more deeply in output, given the logic they seemed more sensible at the end but i can easily 'fix' it. The use of categories here is perhaps a bit unusual but then again citation templates do something similar, so it's odd if it's not been noticed before. Maybe people have just worked around it.--JohnBlackburne^words_deeds 17:13, 26 April 2014 (UTC)

I'd delegate lang-tagging and categorisation to {{lang}}, personally. In fact, why can't {{zh}} be just a wrapper for lang/lang-x? Anyway, you might be interested in contributing to Module:Language. — lfdder 17:27, 26 April 2014 (UTC)

Effective June 5th, metatables (specifically, the __index metamethod) will work properly on modules' export tables. For example, I've set up Module:Effective protection level to work this way. With this, you will be able to use {{#invoke:Effective protection level|edit}}, even though no "edit" function is exported by the module. You can try this functionality now on the beta cluster. Jackmcbarn (talk) 00:51, 27 May 2014 (UTC)

Nice work - this should make a lot of module code neater and more efficient. Will metamethods other than __index be available? (And will the __call metamethod enable Wnt to finally realise their dream of using #invoke with no function name?) — Mr. Stradivarius ^{♪ talk ♪} 05:07, 27 May 2014 (UTC)

I would think that __index should be enough. But is this live presently? I see this is used in the Effective protection level module above, and that module is linked from all sorts of places like Talk:England, but all I get trying to invoke (Script error for example) is errors. Wnt (talk) 07:30, 27 May 2014 (UTC) Also, trying to add the page on the beta server gets me "Exception from line 832 of /srv/common-local/php-master/includes/jobqueue/JobQueueRedis.php: Redis server error: Could not insert 1 cirrusSearchLinksUpdatePrioritized job(s)." Maybe it's just down for now? Wnt (talk) 07:38, 27 May 2014 (UTC)

@Wnt: It doesn't work here because the functionality hasn't been deployed here yet. I fixed the link I gave to the beta cluster, so it should work there now. Jackmcbarn (talk) 12:55, 27 May 2014 (UTC)

@Mr. Stradivarius: The issue with not using a function name isn't that the __call metamethod wasn't being used, but rather that it wouldn't be able to tell whether you specified a function name or just the first parameter. I do have an idea for that, though, which I'll probably submit something for soon-ish. Jackmcbarn (talk) 12:55, 27 May 2014 (UTC)

I had a pass at it at . So far as I know __call shouldn't be used - the invoke looks up which function to run out of the table rather than calling the table. I had one revision where I actually tried setting the __call method but nothing happened; this is all __index. Wnt (talk) 15:31, 27 May 2014 (UTC)

Right. __call has nothing to do with this. Jackmcbarn (talk) 15:42, 27 May 2014 (UTC)

This syntax may be especially nice with nice simple modules that take one parameter. With those the function name field will still parse correctly even if it contains "=", rather than being split into a parameter name and value unless you do "1=" at the beginning. However, you can't do that if there are other unlabeled parameters (I think) ... at least, strange things happened when I tried recently, with the first unlabeled parameter value (after the function name) seeming to go missing. And of course, the other (real) parameters won't work with "=" in them. Wnt (talk) 20:20, 27 May 2014 (UTC)

Hi,

Scribunto it's a little bit different than Lua. In Wikipedia, we have Scribunto, not Lua. In consequence it's beter to name this page Wikipedia:Module.

Thanks to say me what do you think about that,

Regards,

--Juanes852 (talk) 11:49, 16 May 2014 (UTC)

P.S Excuse-me for my bad english, but I'm a French speaker.

If I understand this topic well: in the future, Scribunto could cover other script languages as well. Next to Lua. So focussing on Lua is OK. IN the future, there could be a Scribunto-handled script "HollywoodScript" sitting next to this Lua.

It is not so that the Lua-in-wiki language is called Scribunto.

PS A HollywoodScript language probably would be useful for vapor, vanity, tinsel and non-existing topics ;-) . -DePiep (talk) 12:14, 16 May 2014 (UTC)

Maybe one day this will change but right now Scribunto is Lua on Wikepedia. Yes, WP:Lua is not the same thing as Lua, but WP:Verifiability is not the same as Verifiability. If you want to learn about Lua go to Lua. If you want to learn about, or participate in, Lua on Wikipedia come to Wikipedia:Lua. Meanwhile redirects help anyone expecting to find this page at another plausible location such as WP:Scribunto.--JohnBlackburne^words_deeds 13:22, 16 May 2014 (UTC)

Instead of "Hollywoodscript", how about brainfuck? Barnstar for the first editor who makes a Mindfuck module that runs faster and takes less space than an existing template. (I remember one template that searched for articles for future years that would have been a good candidate...) Wnt (talk) 02:23, 28 May 2014 (UTC)

It seems to me that the Lua programming scene here is relatively new, so I am wondering if anyone has thought of versioning the scripts? I was looking over the archives and came across some comments about how Lua scripting could get a bit harry depending on the libraries chosen. Wouldn't it be fair to assume that at some point in the future, an update to Lua or its dependencies could break old code, and that code writers should specify which version of Lua is required to run the script? I was even thinking that Lua itself could determine this by a comment field based on a UTC date code. Maybe a simple lookup could be done to determine what version of Lua was active on that date, and run the proper version at that time. I would also suppose that version changes would be relatively few, so the same Lua would be active for 6 to 60 days at a time.

An old saying that I recall about programming and code versions was to "keep the tree green," meaning to ensure that everything in a codebase continues to compile and run whenever the tree is updated with new code.

If such a system is implemented, a system-wide change could be implemented at any time without notifying a thousand code maintainers to watch for any new scripting issues! People maintaining large codebases (Template:Convert always comes to mind) could verify the new version in their next sweeping update of the underlying template or script.

So let me give an example. Let's say that there is a call to Module:Yesno, Module:Sort, and Module:Compare on a particular Lua script called Oldie. The YesNo module changes in 2015 due to some expansion of the codebase unrelated to the script. There's no danger there. But in 2016, the Sort Module gets a major facelift and rewrite from scratch which would break or incredibly slow down Oldie. In 2017, someone asks why every page with Oldie has this strange bug or warning or glitch or slowdown... it takes another couple of years to realize that Oldie was broken years ago and no one was maintaining it. But if Oldie had been time-stamped or versioned, all of those problems would be eliminated because it would have

1. Been using old versions of the Module:Sort all along
2. Been on the "radar" of Lua scripters who were watching for potential problems when Sort changed
3. Been on the "radar" of site administrators when they saw that Oldie was still using code from 2014 and it needed to be tested with the latest version of Lua

By versioning the scripts, there can be a database of script age and version, along with statistics about what scripts use what version of Lua and which ones would be likely candidates to be human-edited. For example, if a very large and very widely deployed script is using ancient code, then it would be a higher priority than small scripts used on 10 or 20 user pages.

I guess a drawback would be whenever there is a need to create both a Module and a script that depended on the module. A person would need to somehow specify that it depended on a particular module unconnected to the version of Lua running. So it would need to call the module explicitly, perhaps specifying the module's version until the module was acquired by the system-wide Lua. I like to saw logs! (talk) 06:46, 29 May 2014 (UTC)

This seems like a strange case of serendipity, but it just so happens that I came across a borken module. I have no idea when it borked, or why, but my guess is that when it was produced in January 2014, whatever the codebase and situation was at the time caused this module to work:

{{#invoke:Module overview|getTable}}

.... but now it no longer does what the writer intended. I found at this page: Wikipedia:Lua/Modules a few minutes ago. I immediately realized that the module code was borked, so I reverted it to a previous version. Is this happening to other Modules? Is this coderot? And would versioning help? Or I am I just a crazy outsider sticking her nose into things? I like to saw logs! (talk) 07:48, 29 May 2014 (UTC)

The module hadn't been changed since January. I think what happened is that {{Special:AllPages|namespace=828}} used to return a list of groups of pages that you could view page by page, but now it just delivers the full alphabetical list starting from the beginning, confusing the module. Wnt (talk) 12:25, 29 May 2014 (UTC)

I don't really see a benefit to this type of versioning, and like Wnt said, it was a change to MediaWiki that broke it in your case, not a Lua upgrade. Jackmcbarn (talk) 14:34, 29 May 2014 (UTC)

I think Uruiamme may be onto something though. It would be nice to have a verification that "this module worked with Mediawiki version N". Right now there is a Category:Pages with script errors. I think it would be a useful routine system maintenance step to save the contents of that category before each Mediawiki upgrade, and compare the list afterward. A bot could check every entry (at least in Module talk: space) and give a notification to the last person to edit it if there is a script error there after the upgrade that wasn't present before. Or maybe there's a way to integrate that directly into the round of page reparsing that I assume must occur after an update? Unfortunately, with the cool mw.message functions taken out, there's no way within Lua to scan all of your module talk pages to see if there are script errors in the cached version without actually parsing them all, which would run afoul of time limits. Wnt (talk) 18:03, 29 May 2014 (UTC)

I don't see how Lua scripts are going to be maintained on such a decentralized system like Wikipedia unless you take this type of criticism at face value. A "normal" codebase is often managed by overseers and team leaders, even those open-source large codebases out there. And even those usually have some method of determining who gets the keys to make major system changes. In a place where "anyone can edit," at what point does someone either maliciously or erroneously throw a monkey wrench into a script or two and cause a meltdown at the front end? A meltdown that could make the evening news broadcast... Wikipedia crashes due to code glitch... Website see garbled mess of errors and frozen screens. I was just thinking you could make it a little more difficult to kill off the hard work of others by forcing coders to EXPLICITLY specify their assumptions. Code writers make assumptions, and one of those is that the set of ingested modules and called functions will not change but be essentially static.

My plan would be to have an automated way of maintaining backward compatibility as the underlying modules and functions get updated over the years. I am trying to put the burden on the frontend (a simple version spec in the code) rather than on the back end (2018, when the script breaks and no one who wrote it is around to fix it). I like to saw logs! (talk) 18:22, 29 May 2014 (UTC)

I think you're trying to do the impossible. Jackmcbarn (talk) 18:37, 29 May 2014 (UTC)

Yes. One 'problem' with being the encylopaedia that anyone can edit is stuff gets changed all the time, by literally thousands of editors making many thousands of edits. No-one sets out to break stuff but stuff breaks all the time. It gets fixed as it's noticed but the old version is still broken. You look at any reasonably old version of a page and it's often a complete mess with missing images and categories, missing or broken templates, dead links. I've seen suggestions that these pages should be maintained so they keep working but that would not only be a massive amount of work but would require major revisions to policies on deletion, moving and renaming (e.g. categories), to no real benefit.

Lua now is mostly compatible as it's all new. But give it a few years and APIs will change, be added and old one deprecated and removed. Coding standards might develop for performance reasons or consistency in formatting. New languages might be added alongside Lua requiring new interfaces and inter-script communication methods. Modules will be updated accordingly and there's no guarantee old versions will still work. As for articles keeping them working would potentially be a massive amount of work, require at least the deletion policy to be revisited, for no real benefit.--JohnBlackburne^words_deeds 19:08, 29 May 2014 (UTC)

Just to clarify, I wasn't talking about someone in 2018 going back to a 2014 revision of an article. I was talking about a regular page with a Lua script in which the script stays unchanged for those 4 years. In that time, the output of the Lua script rots, and in 2018 the output is erroneous. However, in 2018, visitors to the page cannot perhaps easily detect that a change of output occurred, so they see what appears to be a factoid (like a numerical "200") that was originally something else (like a numerical "243"). I don't see that there is a lot of work involved, especially given the possibilities of unintended consequences. A more dire result would be an error that involved something that actually overloaded or crashed something, like using up to the maximum amount of processor time permitted. This borders on a security issue because of the way resources could be over-used. Imagine this happened to one script that was embedded in 100 pages, 1000 pages, or more.

I am looking for the Lua equivalent of a Windows compatibility mode or something, like you see made available when Windows updates their operating system, and due to version declarations, the software must be run with a different set of run-time parameters.... or when you have multiple versions of mysql installed, and you specify the full path to the executable each time. I like to saw logs! (talk) 08:42, 2 June 2014 (UTC)

This is in theory already a problem though. WP's been around far longer than 4 years and things are changing all the time. We cope. Changes to e.g. the WP software go through a process of identifying a need, writing the code, reviewing it, optionally testing it (on e.g. a test wiki or as an opt-in feature) before wide roll out. Problems still occur, as they often are only apparent on a live wiki. But they get fixed. They get spotted and reported to a noticeboard. Or the problem adds the page to a tracking category. Or someone downloads the database dump and runs a program to find problems.

Lua makes this all much much easier. Script error warnings make it much easier to spot and fix code problems. Problems are easier to identify in source as it's so much more readable than parser functions. The better flexibility of the code makes it easier to add things to spot problems, such as tracking categories (see e.g. the work that's been done to fix citation templates since the conversion to Lua). As a standard language Lua's better documented and understood, so problems caused by obscure language behaviours shouldn't happen so much. Lua's better performance means hacky workarounds likely to break are less needed. And so on. It really should make it much easier to find problems and I don't think we need to do anything more.--JohnBlackburne^words_deeds 10:09, 2 June 2014 (UTC)

Lua exposes "_VERSION" which can be used to check what version of Lua is running. However, I think feature detection is a better option. For example to set the environment in a version independent way:

function set_env(env)
  if _G ~= nil and type(_G.setfenv) == "function" then
    setfenv(1, env);
  elseif _G ~= nil and _G == _ENV then
    _ENV = env;
  end
end

A set_env that depends on _VERSION may fail to detect all working or non-working occurrences. --darklama 15:40, 31 May 2014 (UTC)

One of the most common errors I find in templates is the duplication of parameters, like this:

{{Foo
|Year = 1900
|<cut>
|Year =
}}

The second "Year" shadows the first one, so inside the template (and inside a module implementing the template) I read an empty string instead of "1900".

AFAIK there is no way of catching this type of error, so I was wandering if it would be possible to add a new frame sequence table, like frame.duplicatedArgs containg the list of parameters duplicated, just the names. In this way when #frame.duplicatedArgs > 0 I can show an error and/or add the category "Pages with template Foo and duplicated parameters". --Rotpunkt (talk) 08:47, 29 May 2014 (UTC)

I don't think it's likely you'll ever get a duplicatedArgs table, but what you may eventually get is the raw text in its entirety used in the template invocation. Jackmcbarn (talk) 14:31, 29 May 2014 (UTC)

Hi, you say that because the parser doesn't have this information? BTW I also don't understand why the parser allows the duplication of a template parameter... am I missing something? --Rotpunkt (talk) 16:07, 29 May 2014 (UTC)

Right, that information gets thrown away too soon to give it in the format you'd want it in. The parser only "allows" it because one of the design requirements for the parser is that it allows everything. It's not allowed to fail parsing a page. Jackmcbarn (talk) 16:17, 29 May 2014 (UTC)

Thanks for the explanation. Actually I did not think to a parser failure but it could be simply a warning like MediaWiki:Parser-template-loop-warning, MediaWiki:Parser-template-recursion-depth-warning or a category like MediaWiki:Expensive-parserfunction-category. --Rotpunkt (talk) 16:34, 29 May 2014 (UTC)

That's actually a good idea. I'll see if I can implement that. Jackmcbarn (talk) 16:35, 29 May 2014 (UTC)

It would be great, thanks in advance. --Rotpunkt (talk) 16:46, 29 May 2014 (UTC)

This is a good idea overall, but you'll need to be careful not to break legacy templates that might intentionally override parameters for some reason tied to the restrictions of the template "language". So you may need to explicitly mark templates to show warnings for this to happen, at least at first. Wnt (talk) 18:15, 29 May 2014 (UTC)

All my patch does is add pages to tracking categories if they do that. It doesn't change how they parse. Jackmcbarn (talk) 18:17, 29 May 2014 (UTC)

The categorizing breaks a page in this situation: [[History of foo|{{Foo|Year=1900|Someparam=bar|Year=}}]] (the wikilink is not rendered as expected, wikicode shows). -DePiep (talk) 18:01, 31 May 2014 (UTC)

No it doesn't. When the preprocessor adds the category, it doesn't have to emit the text [[Category:Pages with duplicated arguments]], like a template would have to. It just tells the parser to place the page in the category, without affecting the output at all. Jackmcbarn (talk) 18:14, 31 May 2014 (UTC)

Aha. Clear. -DePiep (talk) 18:51, 31 May 2014 (UTC)

I've just finished writing Module:File link, which is used to format links to multimedia files. For instance:

local fileLink = require('Module:File link')
local obj = fileLink.new('Example.png')
return obj:width(220):alt('Some alt text'):caption('The image caption'):render()

This will return the following wikitext:

[[File:Example.png|220px|alt=Some alt text|The image caption]]

I'd appreciate it if people could look over the module syntax to see if the method names etc. make sense, and if anything could be improved. After we have a finalised syntax I plan to write some test cases to make future updates to the code easier. — Mr. Stradivarius ^{♪ talk ♪} 10:53, 1 June 2014 (UTC)

Currently, with frame.args, a call like {{#invoke:Bananas|main|{{bar|5}}}} only shows Module:Bananas the expanded contents of Template:Bar. A new feature, frame.uargs, would cause it to be able to see the string {{bar|5}}. Notably, a call like {{#invoke:Bananas|main|<ref>whatever</ref>}} would allow the code to be able to see the argument without immediately adding the reference to the reflist. This feature is currently undergoing review, and I was asked to find more use cases for it. Can anyone think of use cases for this? The main one I've thought of is implementing the special-casing of Template:Orphan inside Template:Multiple issues. @Mr. Stradivarius: @Wnt: ping. Jackmcbarn (talk) 23:51, 3 June 2014 (UTC)

It would allow us to convert Template:Ubxdisplay/random. Without uargs, a module would have to expand every single userbox to find out how many userboxes there were. — Mr. Stradivarius ^{♪ talk ♪} 00:10, 4 June 2014 (UTC)

I'm not sure how convincing a userbox template would be. I think they'd rather see something that gets used in articles. Jackmcbarn (talk) 00:18, 4 June 2014 (UTC)

Module:Category handler does something very similar, come to think of it. It expands all the namespace arguments to find out if any namespace arguments were used (that's the nsParamsExist function), but it only actually needs two of them in the output - the "all" argument and the argument for the current namespace. Using uargs would save expanding the unneeded namespace parameters - and {{category handler}} is used in 2.5 million pages. — Mr. Stradivarius ^{♪ talk ♪} 02:58, 4 June 2014 (UTC)

@Mr. Stradivarius: The way the preprocessor works, it halfway-parses the arguments before Lua even starts running, then finishes parsing them if you look at them in frame.args. With frame.uargs, the unparsed arguments are already gone before Lua starts, so it has to un-parse the halfway-parsed arguments when it's called. This means that if the arguments are simple, uargs is basically the same speed as args (but if there's arguments that do take a long time to expand, like big templates, then uargs is much faster). Jackmcbarn (talk) 03:35, 4 June 2014 (UTC)

That's more complicated than I imagined. I seem to remember that sometimes {{category handler}} is passed templates as input rather than just category wikitext, but I can't remember off-hand anywhere where this is done. — Mr. Stradivarius ^{♪ talk ♪} 03:47, 4 June 2014 (UTC)

Sounds inefficient to me. I suspect you meant to type that "args" is much faster and not "uargs", unless I misunderstood your comment. I think the mediawiki parser needs a hook or something that passes the unparsed state to extensions early before the parser has discarded it, which would avoid having to recreate the unparsed state, and allow for additional features. --darklama 13:18, 4 June 2014 (UTC)

@Darklama: No, I meant uargs would be faster. Here's an example: Suppose there were a page with Here's some text{{foo|{{bar|3}}|baz|<ref>qux</ref>|paramname=paramvalue}}<ref>here's a reference</ref> as the contents. When MediaWiki first starts parsing it, it goes over the whole thing and turns it into <root>Here's some text<template><title>foo</title><part><name index="1"/><value><template><title>bar</title><part><name index="1"/><value>3</value></part></template></value></part><part><name index="2"/><value>baz</value></part><part><name index="3"/><value><ext><name>ref</name><attr/><inner>qux</inner><close>&lt;/ref&gt;</close></ext></value></part><part><name>paramname</name>=<value>paramvalue</value></part></template><ext><name>ref</name><attr/><inner>here's a reference</inner><close>&lt;/ref&gt;</close></ext></root>. If you request, for example, frame.args[1], it takes the contents of that value tag, <template><title>bar</title><part><name index="1"/><value>3</value></part></template>, and finishes parsing it, actually expanding Template:Bar here. If you were to instead request frame.uargs[1], it takes the same contents, but instead turns them back into the text {{bar|3}}. If Template:Bar is trivial to expand, these take about the same amount of time, but if Template:Bar takes a long time to expand, then args is a lot slower than uargs, since uargs doesn't have to expand it. It can't save the unparsed version, because until it parses into that format, it doesn't know which argument is which. Jackmcbarn (talk) 14:31, 4 June 2014 (UTC)

@Jackmcbarn: I definitely misunderstood. I wasn't thinking about xml output at all. I thought by half-parsed you meant templates were replaced with their wikitext content without parameter, magic word, or other substitutions, and from that half-parsed state un-parsing involved somehow extracting how templates were called. --darklama 15:40, 5 June 2014 (UTC)

Sounds like this could be useful for the tl templates to simplify demonstrating examples.

Unit testing frameworks could benefit by allowing template-like arguments with custom data that exposes more information about the passed template to generate test cases for you. {{#invoke:unit tester|run|{{template|arg1[number,optional]=|arg2[string]=|arg3[default=foobar]=}}}}

Modules could see {{{arg#}}} in the invoke and know to look for arg1, arg2, arg3, etc. from the calling template. --darklama 00:35, 4 June 2014 (UTC)

The tl example is the best I've heard so far, and the others are good too. Thanks. Jackmcbarn (talk) 03:35, 4 June 2014 (UTC)

{{convert}} needs to parse input values which can have weird syntax, mainly for fractions. People sometimes put a reference next to the number, and that gives an error like this: {{convert|12<ref>whatever</ref>|m}} → 12^[1] metres (39 ft) A subtle feature of the error message is that hovering the mouse over it shows the specific problem. That's done by function message in Module:Convert which receives "12" followed by a strip marker. The function has to look for and remove the strip marker because it interferes with the mouseover title. I mention all that in case it's of any interest, but I am satisfied with the workaround the code implements, and I don't think convert would need uargs. Sometimes (rarely) people use a template or {{#expr:...}} to pass a value to convert, and it's good to receive the result of the evaluation.

Hmmm, something in MediaWiki has changed because the mouseover is showing 12... instead of 12<ref>...</ref>. Johnuniq (talk) 00:50, 4 June 2014 (UTC)

I didn't look up the commits, but the feature I'd most want would be a single unprocessed arg containing everything in the call. That way a module can ignore any use of "=" other than in SomeArgIRecognize = something; i.e. you would never have to say 1=, 2= again, or worry that an #invoke would break if edited an "=" into some previously working text. If it did the same for the parent, the same would be true of templates designed to use it. Wnt (talk) 02:01, 4 June 2014 (UTC)

I haven't looked closely yet, but I think enough information gets thrown away early enough that this isn't feasible. Jackmcbarn (talk) 03:35, 4 June 2014 (UTC)

Over the past couple of days I haven't been able to get the code editor to come up, or even expand a script error, despite enabling scripts. Firefox gives me an error on index.php line 36 that GetElementById('wpPreview') is null, and indeed, I don't really see any such element. I'm using NoScript, but I've set it to allow scripts globally, so in theory that shouldn't be the reason. Wnt (talk) 20:10, 8 June 2014 (UTC)

I haven't seen it for at least couple of weeks. It's a week since I did any coding but I look at modules fairly regularly and it's just not appearing. Latest version of Safari with Javascript enabled and no errors in the log.--JohnBlackburne^words_deeds 20:34, 8 June 2014 (UTC)

It's working fine for me. John, have you tried clicking the "/*" button at the top left of the editing window on module pages? That toggles CodeEditor on and off. — Mr. Stradivarius ^{♪ talk ♪} 21:33, 8 June 2014 (UTC)

The button's missing, has been for as long as the CodeEditor. I just have the edit toolbar with a √ in the top left corner.--JohnBlackburne^words_deeds 22:00, 8 June 2014 (UTC)

OK, after a lot of fiddling I fixed the problem, at least for me. (re) enabling the 'enhanced editing toolbar' checkbox at the editing prefs made the CodeEditor re-appear. No idea when or why that was disabled. I've been testing the VisualEditor, and earlier the Typography Refresh; I don't know if either switched it off. I don't ever remember doing so manually and can't think why I would.--JohnBlackburne^words_deeds 22:11, 8 June 2014 (UTC)

This does work - thanks! I feel sure I didn't turn it off in preferences either. In any case the preferences could use a specific mention of "CodeEditor" in the text to help others. Wnt (talk) 17:59, 9 June 2014 (UTC)

Actually, tonight I've been having a lot of inconsistency with the code editor. Roughly 50% of the time it doesn't work, with the same error as before. I can be on the module page and hit "Edit this page" twice and have no code editor to play with, hit it the third time and it works. I can do a preview using the talk page from a working code editor window and it won't expand "script error"; hit the button to preview again and after another run it tells me what the error is. It seems totally random. Wnt (talk) 07:13, 12 June 2014 (UTC)

The CodeEditor requires WikiEditor framework. Before we ignored the "Enhanced toolbar" setting, now we respect it. I want to improve it a bit in the future, to decouple the selection of the editors, but with the amount of time i have available right now, that's gonna take like 2 months. —TheDJ (talk • contribs) 11:57, 12 June 2014 (UTC)

I just managed to hang a module on preview, and the parser profile data said it had taken 141.129 seconds of CPU time, 140.829 seconds of real time (and it seemed like it), 136.755/10 seconds Lua time usage, 18.98/50MB memory usage, other stats look normal. Obviously this is a problem. Wnt (talk) 05:54, 12 June 2014 (UTC)

I should note that (despite thinking I'd jerry-rigged it with a backup to avoid looping) I looped it again anyway, and this time the 10 second limit held. So it's not that reproducible, at least... Wnt (talk) 06:08, 12 June 2014 (UTC)

Do you have a link to the code that caused the loop? — Mr. Stradivarius ^{♪ talk ♪} 06:15, 12 June 2014 (UTC)

I didn't save that precise preview code, but in general it was Module:Module overview with one of the while loops in (now) p._getAll never terminating. The times that the timeout worked properly (and I had four or five later on) were not because of a loop after all, just inefficient code and a lot of data. Wnt (talk) 07:10, 12 June 2014 (UTC)

What would be the code to create a three-column table, and then edit and read a cell? In other languages, I am used to something like array t1[i, j]. (A link to a good example module is welcome too). -DePiep (talk) 11:15, 11 May 2014 (UTC)

What do you mean by "three-column"? If you want to create a 3x3 grid, you can do it by nesting tables:

local grid = {
	{'a1', 'a2', 'a3'},
	{'b1', 'b2', 'b3'},
	{'c1', 'c2', 'c3'}
}

To read the "b3" value, and then write a new value to it, you would do this:

local b3 = grid[2][3]
mw.log(b3) -- gives "b3"
grid[2][3] = 'foo'
b3 = grid[2][3]
mw.log(b3) -- gives "foo"

Was that the kind of thing you had in mind? — Mr. Stradivarius ^{♪ talk ♪} 13:29, 11 May 2014 (UTC)

Yes, exactly this. Thanks. (In initiation the curly brackets are nested, and in approaching the coordinates [2][3] are linear -- that's what I could not figure). -DePiep (talk) 17:44, 11 May 2014 (UTC)

This isn't strictly the same as some of the antediluvian languages in that there's no actual allocation of a 2-dimensional array. Not merely can you say grid[2] = function(foo) return bar*foo end and still have grid[3][3] = "foo"; you can say grid[2] = grid[3], change grid[3][3] and have grid[2][3] change. Wnt (talk) 07:46, 27 May 2014 (UTC)

Thanks Wnt. As you can understand, this expansion is too complicated for my question, but it helps my thinking. I ;-) -DePiep (talk) 21:14, 12 June 2014 (UTC)

Can someone change code (explain by bold edit), so that Module:User:DePiep/element shows the most simple tests OK as in User:DePiep/sandbox? I can't even get the frame to be recognised. (do not explain verbose). -DePiep (talk) 23:43, 12 June 2014 (UTC)

Looking at it, I think you're trying to just get parameters at a very basic level? But missing that frame doesn't contain the parameters - they're in frame.args and frame.getParent().args for the page/template that invoked the module and whatever transcluded that page/template respectively. Worse, AFAIR the stuff coming in from frame is in a goofy mode where pairs() and # and so forth don't work on it to begin with. Wnt (talk) 23:58, 12 June 2014 (UTC)

Yes what you think is what I want (and expect). Please edit my code so that it works, as simple as possible (I'll learn). Again: don't explain verbose. (I do appreciate your contribution) -DePiep (talk) 00:11, 13 June 2014 (UTC)

I did an edit. Is that what was wanted? Johnuniq (talk) 00:32, 13 June 2014 (UTC)

Thx. Now I will learn. -DePiep (talk) 00:36, 13 June 2014 (UTC)

I've added some examples to show how metatables work on the args table too. — Mr. Stradivarius ^{♪ talk ♪} 03:43, 13 June 2014 (UTC)

Is there anyway to get mw.wikibase.entity object of non-current page, like getting it from page title or mw.title object? --Nullzero (talk) 09:03, 14 June 2014 (UTC)

Not now, but it's planned. Jackmcbarn (talk) 14:31, 14 June 2014 (UTC)

It was planned last year and the year before that. If you have a site on the web and you want to scrape Wikidata's APIs, go ahead; otherwise try to forget you heard of it. Wnt (talk) 23:41, 14 June 2014 (UTC)

There is an interesting discussion on Bugzilla now about the mw.html library. The question is, should the mw.html methods like attr, css, cssText and addClass accept nil values as input? At the moment, passing a nil value to those methods generates an error. This is because nil is not a valid css value, attribute or class. It prevents module writers from making mistakes where they may have assumed a variable always has a string or number value, whereas sometimes it is in fact nil. The counter-argument is that not accepting nil values prevents module writers from call-chaining as easily. With accepting nils, a call chain might look like this:

local root = mw.html.create('table')
root
	:tag('tr')
		:tag('td')
			:css('color', args.color)
			:wikitext('some text')
return tostring(root)

Without accepting nils, the same call-chain might look like this:

local root = mw.html.create('table')
local cell = root:tag('tr'):tag('td')
if args.color then
	cell:css('color', args.color)
end
cell:wikitext('some text')
return tostring(root)

You can see more details at bugzilla:62982. What would people prefer to do? Is the error-checking more important than the call-chaining, or is it more important that call-chaining should work without using if statements? Please leave your opinion below if you are interested. — Mr. Stradivarius ^{♪ talk ♪} 13:14, 22 April 2014 (UTC)

Surely I prefer that the library accepts nil values ​​to allow call-chaining. --Rotpunkt (talk) 13:53, 22 April 2014 (UTC)

According to my request. Hlm Z. (talk) 16:18, 22 April 2014 (UTC)

yes, allowing nil makes it much more readable. or, at the very least, have a value which can be passed which causes it to do nothing. I am currently using args.color or '' which creates an empty "color:;", which is suboptimal. Frietjes (talk) 17:02, 22 April 2014 (UTC)

If preserving the principle only is the point ("there is no tag 'nil'"), then default to: accept nil for 'blank'.

If the 'nil' value serves anything, then keep it (for example, in argument processing it could mean something).

But for sure we should not, asap, introduce another blank=/=undefined parsing. -DePiep (talk) 20:11, 30 April 2014 (UTC)

Let me add. The {{#if:{{{1|}}}|a|b}} code issue has cost me thousands of edits & puzzles & hours without being productive. (Then enter the question of {{{1}}} vs. {{{paramname}}} in subtemplates). The reversed "nil=blank & you can code otherwise" solution is better. -DePiep (talk)

Let's not get the code examples get too terrible

local root = mw.html.create('table')
local cellcolor = args.color or 'black' -- or something else, but at least the default is explicit
root
	:tag('tr')
		:tag('td')
			:css('color', cellcolor)
			:wikitext('some text')
return tostring(root)

seems reasonable to me, and fairly sound. Another option is making css(, ) a nop, at the cost of an extra local. Or even

local root = mw.html.create('table')

root
	:tag('tr')
		:tag('td')
			:css('color', args.color or 'inherit')
			:wikitext('some text')
return tostring(root)

Martijn Hoekstra (talk) 20:53, 30 April 2014 (UTC)

Our edits must have crossed.

I state: "nil=blank & you can code otherwise" (contrary to current {{#if:{{{1|}}}|a|b}}. The horror). -DePiep (talk) 21:02, 30 April 2014 (UTC).

Using args.color or 'black' isn't ideal, as you're setting an explicit style in the module that now can't be styled using user stylesheets without using "!important" overrides. Using args.color or 'inherit' is a lot better, and could be very useful - thanks for pointing it out. That doesn't help with addClass or attr, though, which don't have similar non-nil fallback values, as far as I'm aware. Conditional classes and attributes would still have to be added using if/then statements. — Mr. Stradivarius ^{♪ talk ♪} 10:32, 1 May 2014 (UTC)

All options look fairly unappealing to me to be honest. Making a function with invalid arguments a nop is terrible. Appending non-functional (and even somewhat harmful) css because the code looks better is also terrible. Isolating different elements to make if statements happy is also terrible. Other options are even insanely more terrible (patching the metatable to do smart things that are incomprehensible, or doing a conditional over the if up front and passing either the css or identity function down the code, other lovecraftian horrors). I guess it's somewhat user dependent what one considers the most and least terrible. Martijn Hoekstra (talk) 12:58, 1 May 2014 (UTC)

Actually, args.color or 'inherit' is a bad idea as well, because there's a lot of styles that don't get inherited by default. Jackmcbarn (talk) 13:16, 1 May 2014 (UTC)

Hence the 'and even somewhat harmful'. I fully concede that this too is terrible. Martijn Hoekstra (talk) 13:20, 1 May 2014 (UTC)

Another terrible idea might be to introduce methods that make explicit noop is an intentional possibility:

return tostring(mw.html.create('table')
	:tag('tr')
		:tag('td')
			:if_css('color', color)
			:if_wikitext(text)
)

--darklama 19:38, 8 May 2014 (UTC)

I very much support the proposed change. The entire purpose of HtmlBuilder was to reduce and simplify the code needed to generate HTML. Nil values were accepted as a NOP in HtmlBuilder to support the extremely common use case of a module that accepts optional arguments, and reduce the boiler-plate if clauses. The only justification for the input checking is some paternalistic view that programmers should check for valid values before passing them to a function. But the values are only invalid if they violate the contract of the function. If the contract of the function is to accept nil values as a NOP, then everything is fine. It seems to me that changing the contract now would make mw.html easier to use, would not break any currently working code, and would improve compatibility with HtmlBuilder. Toohool (talk) 04:55, 9 May 2014 (UTC)

Well said. Otherwise, why not require a check for input being unicode too? -DePiep (talk) 06:15, 9 May 2014 (UTC)

I don't thing "a check for input being unicode" means anything. Martijn Hoekstra (talk) 14:37, 9 May 2014 (UTC)

I agree values are only invalid if they violate the contract of the functions. The contracts of the mw.html functions are incompatible with the HtmlBuilder functions, which makes switching to mw.html harder then most people probably assume. If mw.html's contract is to return an error-free string then mw.html must depend on the mediawiki parser to validate tag names, attribute names, attribute values, CSS property names, CSS property values, and wikitext passed as arguments. I think nil, false, and "" should be interpreted as wanting to remove a HTML attribute or CSS property, and should silently do nothing if the HTML attribute or CSS property hasn't been set yet. My example above is meant as an alternative to satisfy any view that functions should do as the function names suggest, if that is the reason for not maintaining HtmlBuilder's contract. --darklama 14:15, 9 May 2014 (UTC)

The buzilla discussion, and the intro by mr. Stradivarius here, centers around "This is because nil is not a valid css value, attribute or class". However, that same argument is not applied to input like :tag('sapn'). For this situation, the argument "you must check your input beforehand" is not applied. -DePiep (talk) 11:52, 10 May 2014 (UTC)

Yes, the argument to check input beforehand is not being consistently applied, when applied at all that argument should be consistently applied. Another problem with the check input beforehand argument is the way the argument is being applied means checks are performed twice, once beforehand and again within each function call, which at the most optimized is still O(n*2). If checks beforehand are to be expected, mw.html should instead include validate(input, type) or individual validateType(input) functions to use before passing the input to the other functions, and let the other functions fail horribly and silently when passed invalid input. --darklama 14:46, 10 May 2014 (UTC)

There's no such complexity class as O(n*2). Twice as long as O(n) is still just O(n). There is an O(n^2), but that's definitely not what would happen in that case. Jackmcbarn (talk) 14:51, 10 May 2014 (UTC)

O(n*2) is a correct writing, and it describes the point made. And O(n) is not a complexity class. -DePiep (talk) 16:30, 10 May 2014 (UTC)

Of all terrible ideas, IMO that one is the least terrible. Kudos for finding it :) Martijn Hoekstra (talk) 16:33, 10 May 2014 (UTC)

Even if complexity was the wrong word, you still don't use coefficients in big-O notation. Jackmcbarn (talk) 17:23, 10 May 2014 (UTC)

Almost right: in this case, don't use the big O(), and keep the factor two. But the topic is something else. -DePiep (talk) 11:22, 11 May 2014 (UTC)

I believe I have an interesting solution that would allow error-checking and call-chaining at the same time. The solution is to raise an error when nil is used as a value, but not when false is used as a value. With this solution, we still have error checking (if it is not expected that a value will be nil, an error will be raised, and if it is expected, the module writer will have added or false and mw.html will not raise an error) and Mr. Stradivarius’s example becomes:

local root = mw.html.create('table')
root
	:tag('tr')
		:tag('td')
			:css('color', args.color or false)
			:wikitext('some text')
return tostring(root)

This is not ideal, but I think it is less horrible than all the other suggestions so far. ― Rastus Vernon (talk) 13:48, 18 June 2014 (UTC)

Allowing false is a bad idea, since some attribute values can be "false", and then people would be putting false instead of "false" and wondering why it's not working. Jackmcbarn (talk) 15:46, 18 June 2014 (UTC)

Hi! I imported some templates to the Tigrinya Wikipedia: ti:Template:Side_box and ti:Template:Commons - But they do not work because there is no Lua module in this Wikipedia. What needs to be done? WhisperToMe (talk) 00:47, 3 July 2014 (UTC)

Just import the modules too. Jackmcbarn (talk) 00:52, 3 July 2014 (UTC)

Where may I find the modules? I use the same filename on Tigrinya Wiki, right? WhisperToMe (talk) 00:55, 3 July 2014 (UTC)

Just export and import them the exact same way as the templates. Jackmcbarn (talk) 00:57, 3 July 2014 (UTC)

Ok. What are the filenames of the modules? That way I can locate them. I don't see anything at Module:Lua WhisperToMe (talk) 01:12, 3 July 2014 (UTC)

The thing after the #invoke: is the name. For example, Template:Side box uses Module:Side box. Jackmcbarn (talk) 01:16, 3 July 2014 (UTC)

Click the Edit tab at Template:Side box and then "Templates used in this preview" at the bottom to see which other pages are used. Both templates, modules and other pages can be listed. In this case most of them are only used by the documentation page. Remove {{documentation}} from the edit box and click "Show preview" to see the much shorter list: Module:Side box, Module:Yesno. Import those. I haven't examined it but it's possible other pages are used when Template:Side box is called with certain parameters. It's also possible for a template to depend on some of the code in MediaWiki pages like MediaWiki:Common.js and MediaWiki:Common.css. PrimeHunter (talk) 01:17, 3 July 2014 (UTC)

Actually, the easiest way to see is just to click on the "Script error" message. The popup will tell you the name of the missing module. Jackmcbarn (talk) 01:18, 3 July 2014 (UTC)

I just had a look and they were still giving errors despite the module being there, but purging fixed it, e.g. .--JohnBlackburne^words_deeds 03:22, 3 July 2014 (UTC)

Special:MostLinkedTemplates is now called Special:MostTranscludedPages and has support for listing things other than templates, meaning it now lists the most highly used modules. Jackmcbarn (talk) 23:07, 30 June 2014 (UTC)

1. It's a good step forward, (though a shame another geeky camel case has slipped through).
2. However if it's only run twice a year it is of limited value.
3. There are a bunch of non-module-non-template pages in the list. I have addressed some of them, with a little luck. the rest are listed here, some are legitimate, some indicate issues:
   1. MediaWiki:Toc‏‎ (used on 64,023 pages)
   2. Talk:Devil Survivor 2: The Animation/GA1‏‎ (used on 57,490 pages)
   3. Talk:Dishaster/GA1‏‎ (used on 25,829 pages)
   4. Talk:Drakengard (series)/GA1‏‎ (used on 57,473 pages)
   5. Talk:F-Zero Climax/GA1‏‎ (used on 57,396 pages)
   6. Talk:Fez (video game)/GA1‏‎ (used on 56,802 pages)
   7. Talk:Final Fantasy X/X-2 HD Remaster/GA1‏‎ (used on 38,014 pages)
   8. Talk:Hundreds (video game)/GA1‏‎ (used on 50,758 pages)
   9. Talk:Infamous Second Son/GA1‏‎ (used on 26,724 pages)
   10. Talk:Lost Luggage (video game)/GA1‏‎ (used on 47,755 pages)
   11. Talk:Makoto Yuki (Shin Megami Tensei: Persona)/GA1‏‎ (used on 57,490 pages)
   12. Talk:Music of Final Fantasy XIV/GA1‏‎ (used on 57,492 pages)
   13. Talk:QuackShot/GA1‏‎ (used on 48,412 pages)
   14. Talk:Saints Row 2 (mobile)/GA1‏‎ (used on 56,733 pages)
   15. Talk:Silent Hill: Origins/GA1‏‎ (used on 48,819 pages)
   16. Talk:Sonic Advance 3/GA1‏‎ (used on 25,251 pages)
   17. Talk:Tony Hawk's Underground/GA1‏‎ (used on 54,901 pages)
   18. User:ClueBot NG/Warnings/FPReport‏‎ (used on 1,007,538 pages)
   19. User:ClueBot/Tracker‏‎ (used on 198,711 pages)
   20. User:COIBot/Additionlist bottom‏‎ (used on 54,819 pages)
   21. User:COIBot/Additionlist top‏‎ (used on 54,819 pages)
   22. User:COIBot/EditSummary‏‎ (used on 54,337 pages)
   23. User:COIBot/linksaverdatabases‏‎ (used on 51,164 pages)
   24. User:COIBot/OtherLinks‏‎ (used on 54,171 pages)
   25. User:COIBot/Summary/LinkReports‏‎ (used on 105,569 pages)
   26. User:JL-Bot/Project content‏‎ (used on 248,466 pages)
   27. Wikipedia:Teahouse/Invitation‏‎ (used on 41,529 pages)
   28. Wikipedia:WikiProject Film/Coordinators/Banner‏‎ (used on 137,693 pages)
   29. Wikipedia:WikiProject Food and drink/Open tasks/tasks‏‎ (used on 29,391 pages)
   30. Wikipedia:WikiProject Geography/to do‏‎ (used on 79,784 pages)
   31. Wikipedia:WikiProject Japan/ToDo‏‎ (used on 54,122 pages)
   32. Wikipedia:WikiProject Ohio/tasks/Under review/FAC‏‎ (used on 25,131 pages)
   33. Wikipedia:WikiProject Ohio/tasks/Under review/FLC‏‎ (used on 25,131 pages)
   34. Wikipedia:WikiProject Ohio/tasks/Under review/FSC‏‎ (used on 25,131 pages)
   35. Wikipedia:WikiProject Ohio/tasks/Under review/GAN‏‎ (used on 25,131 pages)
   36. Wikipedia:WikiProject Ohio/to do‏‎ (used on 25,129 pages)
   37. Wikipedia:WikiProject Olympics/to-do‏‎ (used on 94,473 pages)
   38. Wikipedia:WikiProject Tennis/to do‏‎ (used on 24,685 pages)
   39. Wikipedia:WikiProject Texas/tasks/Under review/FAC‏‎ (used on 31,013 pages)
   40. Wikipedia:WikiProject Texas/tasks/Under review/FLC‏‎ (used on 31,013 pages)
   41. Wikipedia:WikiProject Texas/tasks/Under review/FSC‏‎ (used on 31,013 pages)
   42. Wikipedia:WikiProject Texas/tasks/Under review/GAN‏‎ (used on 31,013 pages)
   43. Wikipedia:WikiProject Texas/to do‏‎ (used on 31,011 pages)

All the best: Rich Farmbrough, 19:53, 5 July 2014 (UTC).

How to round numbers in Lua? I'm looking for the equivalent of {{#expr: 1/6 round 5 }}. Could not find hints in the math library . -DePiep (talk) 10:38, 2 July 2014 (UTC)

@DePiep: use Module:Math#round. — Mr. Stradivarius ^{♪ talk ♪} 10:49, 2 July 2014 (UTC)

That obvious. :-) -DePiep (talk) 11:03, 2 July 2014 (UTC)

Because of the potential for pages needing to be reparsed when a basic module is fixed, I'd avoid doing a require for Module:Math unless you want to do something non-trivial. For rounding you can use math.floor(n-1/2) or something. Wnt (talk) 19:04, 7 July 2014 (UTC)

There will probably soon be an mw.math.round function available, which will address Wnt's concern. Jackmcbarn (talk) 19:50, 7 July 2014 (UTC)

Nice! Though I wonder... You have:

function p.round( n, decimals )

local multiplier = decimals ~= nil and 10^decimals or 1

return math.floor( n * multiplier + 0.5 ) / multiplier

end

I'm thinking that every time you do an ordinary humdrum round to integer, you check decimals ~= nil, set multiplier to false, or with 1, set multiplier to 1, take n * 1, take the integer / 1. Because someone might round tens of thousands of times in a module, I think I'd prefer:

function p.round( n, decimals )

if decimals then

local multiplier = 10^decimals -- still need this to avoid expensive exponentiation twice

return math.floor( n * multiplier + 0.5) / multiplier

else

return math.floor( n + 0.5)

end

But I'll admit, I don't know if it matters really, and this does use more lines of code. A chipmunk at the back of my brain is wondering, what if we calculated the decimals by creating an appropriate string with string.rep and doing a tonumber() on it :) Wnt (talk) 20:58, 7 July 2014 (UTC)

I'm guessing that the performance difference probably isn't all that great, and that it's better to write the code for maintainability. But why don't you run some tests on it? You can test it in the debug console with some code like this:

local start = os.clock()
for i = 1, 1000000 do
    -- test code goes here
end
= os.clock() - start

I'd be interested to see your findings. :) — Mr. Stradivarius ^{♪ talk ♪} 23:26, 7 July 2014 (UTC)

I didn't use the debug module - out of 8 runs on page preview, plus a few initial attempts, the Lua script-based editor came up only twice; the rest of the time I could have had javascript disabled for the same effect, due to the usual error. But on preview, your version came up as 0.37, 0.23, 0.23, 0.37, and mine came up as 0.19, 0.19, 0.15, 0.26. Then I tried running both in the same script as an "internal control" but it was still all over the place: the ratio of mine/yours was 0.78 0.91 1.30, 0.84. Saved this as Meanwhile, I don't actually know if the severely restricted Lua for running scripts has anything to do with the Lua used internally by the server. Getting this data may be a bit frustrating. :) Wnt (talk) 00:17, 8 July 2014 (UTC)

The time difference between different runs depends on a few things, chiefly the server that your request gets sent to, and how busy it is. So you need to average things out to get meaningful results. But if the code is running at that speed, there shouldn't be a problem. Your fastest result was running at 6.7 million a second, and the slowest at 2.7 million a second, so the speed difference will only be noticeable for people making millions of calls to the round function. I can't see many modules needing to do that. — Mr. Stradivarius ^{♪ talk ♪} 04:47, 8 July 2014 (UTC)

As my section header states, random question: Why are there not any redirects in the Module namespace, and why can they not be created? Steel1943 (talk) 22:51, 23 June 2014 (UTC)

@Steel1943: Modules aren't wikitext, and #REDIRECT is a wikitext construct. Jackmcbarn (talk) 22:54, 23 June 2014 (UTC)

A counter question: why would they be needed? Modules are not like pages which can be linked by anyone and everyone, or templates that can be transcluded in a multitude of articles. Modules typically are invoked in only a handful, often only one, template. These can be easily updated as a module changes location. Which should happen rarely anyway: as modules don't get invoked in articles there's no need for them to have editor-freiendly names which might need updating from time to time or might need redirects creating for common abbreviations.--JohnBlackburne^words_deeds 00:12, 24 June 2014 (UTC)

You never know when someone may want to rename a module (yay for Module:Rfd, my failed experiment)... Either way, I'm thinking this needs to be added to Wikipedia:Lua for those who don't know ... Steel1943 (talk) 02:52, 24 June 2014 (UTC)

I presume return require('Module:NewModuleName') should do the trick? isaacl (talk) 08:44, 24 June 2014 (UTC)

Is it possible to add a warning in move page for module namespace? At Mediawiki:movepage-summary or Mediawiki:movepagetext-noredirectfixer. A module should not be renamed if there is any require from other modules or invoke from templates. --Vriullop (talk) 09:18, 24 June 2014 (UTC)

Modules are often protected to prevent careless edits which also prevents careless moves. If it's needed I'd suggest just move protecting the lot of them: they don't need to be moved and it will break stuff so make it so it requires an admin and an edit request. But I don't think it's needed; I don't think there's a problem with moves which needs addressing.--JohnBlackburne^words_deeds 11:46, 24 June 2014 (UTC)

I don't think any special protection for moves would make sense. Unlike editing an article, any small change in a module can completely screw it up, so there's nothing intrinsically more serious about a minor edit than a move. Either the editor is being careful, or not. Wnt (talk) 01:18, 27 June 2014 (UTC)

I think we should ask for the faeture. Lots of the module names are in camel case, and should IMHO be moved. Christian75 (talk) 11:47, 27 June 2014 (UTC)

First of all, what's wrong with camel case names? Second, assuming there is consensus to move, just move them and fix the templates that call them. Jackmcbarn (talk) 15:25, 27 June 2014 (UTC)

All the templates has been renamed so they arent camel case any more, so why should module names be named that way? Do you have an easy way to detect which pages (templates/user pages/and so on) who #invoke a given module? Christian75 (talk) 22:44, 28 June 2014 (UTC)

If you don't believe modules should be named with camel case, I'm unclear what the reason would be to leave behind a redirect from the camel case name when moving the module to a new name, since the redirect would allow the camel case name to continue to be used. In any case, the syntax I specified above should do the job, I believe. isaacl (talk) 04:26, 29 June 2014 (UTC)

Which ones and what problems do they cause? All I can think of inherited the name or a name based on the template(s) they implemented. If other names have been chosen I'm sure they too made sense for that module: modules only called by other modules and so that aren't based on templates for example.--JohnBlackburne^words_deeds 22:54, 28 June 2014 (UTC)

Quick how-to for moving modules or functions: 1) copy it to new location, 2) replace each moved function with return require('Module:NewModuleName').newFunction(selfArgs) and, if possible, with a tracking categoy, 3) replace all invoke or require from old name to new one, 4) delete old functions or module. In the long term it is not a rare stuff. I think it makes nonsense a wiki page redirect in modules, but it makes nonsense either to advise fixing double redirects. It would be better to advise moving modules to inadverted users, specially in smaller comunities with less experimented users and modules not always protected. --Vriullop (talk) 09:50, 29 June 2014 (UTC)

re Jackmcbarn. "Move" is a basic WP feature, "Redirect" a basic support solution. But you keep pinpointing to isolated half-answers as "why would they be needed?" (yeah, sure, can someone answer: why would a redirect be needed?). Today I was looking for (preparing) a move, and I did not find primary answers. So instead of making the whole module namespace an exception in a talkpage section, we better make it a normal ns as any other (with its exceptions described, as with any other ns). Check these for ns "Module": WP:MOVE, WP:REDIRECT, WP:DELETE. -DePiep (talk) 21:01, 6 July 2014 (UTC)

Initiated #Guidelines_for_ns:Module_exceptions below. -DePiep (talk) 21:16, 6 July 2014 (UTC)

I've submitted gerrit:146608 which will add redirect support to the Module namespace. Jackmcbarn (talk) 21:21, 15 July 2014 (UTC)