ਵਿਕੀਪੀਡੀਆ:Lua/Requests

ਵਿਕੀਪੀਡੀਆ, ਇੱਕ ਅਜ਼ਾਦ ਗਿਆਨਕੋਸ਼ ਤੋਂ
 WP:Lua
Project
 WT:Lua
Project talk
 Help
 
 To do
 
 Requests
 
 Resources
en: m: mw: external
 

ਵਰਤੋਂਕਾਰ:ClueBot III/Archive Box

Lua scripts on Wikipedia are similar to templates but useful for performing more complex tasks for which templates are too complex or slow. Common examples include numeric computations, string manipulation and parsing, and decision trees. You can use this page to request help from Lua developers in writing a Lua module for a specific task on Wikipedia or another Wikimedia Foundation project. Both debugging help and full implementation are available.

To start a request, just make a new section below and describe what you need. You may wish to first check Special:PrefixIndex/Module: to see if you can find a suitable existing script.

It may help developers to provide examples of where the task is likely to be useful within Wikipedia. If the proposal would replace or improve upon existing templates, please note which ones.

scan for template text in category of articles[ਸੋਧੋ]

Is it possible to scan the contents of articles for specific text strings (actually template) based on a list of articles in a category and its sub-categories? I would like to make these table numbers dynamic. --Traveler100 (talk) 18:03, 4 January 2016 (UTC)

It would help if you were to spell out the operation required for an example, but I suspect the answer is that it is too complex to be achieved with a module. I think you need to list the articles in various categories, then read the wikitext from each page and work out if a certain template is used. I don't think "what links here" is available to a module so using that as a workaround wouldn't work. Some kind of bot would be needed. Johnuniq (talk) 22:16, 4 January 2016 (UTC)
On Wikivoyage the categories are very hierarchical and clean and the articles a standard format so not as risky as with Wikipedia. Task, take a category (say a country), progress through all sub-categories, for each article n categories do a text search for use of specific templates ({{outlinecity}}, {{guideregion}}, .. {{sleep , ..) if found at to count expression. Return count values. --Traveler100 (talk) 06:01, 5 January 2016 (UTC)
Modules don't have access to category members, so this is not possible in Lua at the moment. It is possible to load the wikitext of a given page, but then parsing that wikitext to find a list of templates is hard. You need to take into account things like nowiki tags, HTML comments, template redirects, capitalisation and whitespace allowed for template names/arguments, etc. (This kind of thing is the reason that we have Parsoid, but that data is not available from Lua by design.) The only practical way at the moment to do what you are proposing is to use a bot to update the table. — Mr. Stradivarius ♪ talk ♪ 13:03, 5 January 2016 (UTC)
Just a crazy idea... Could one use JS on the client side to run a mediawiki API to get categories then 'alert data' to call module (via expandtemplates) on server side to do some processing to get category/page names - then get page contents and parse for templates... I can imagine the CPU cycles would be a bit overwhelming and probably die, not to mention the complexity of data parsing. I would expect something like this would have to be limited. -- Definitely would be better if Lua could access category members!Matroc (talk) 01:53, 14 January 2016 (UTC)
in principle yes, though i think you are mixing your metaphors: the API call is "parse" - "expandtemplate" is something to use from lua, not on client side. you can call "parse" with any piece of wikicode, and even tell the backend to parse it "as if" this text was part of a specified page (so, for instance, magic words such as {{PAGENAME}} or {{PAGESIZE}} that the template might use, will receive the desired value.
this whole line of investigation may be wrong, IMO: i do not fully understand the requirements, but to me, it looks awfully close to a functionality cirrus-search already have: we now have meta-search words that can do what i think you want. specifically, "incategory:" and "hastemplate:". this will _not_ cover the "and its subcategories" part of the original request, so if this part is essential, my suggestion falls short. peace - קיפודנחש (aka kipod) (talk) 15:47, 14 January 2016 (UTC)
Thanks - I thought I might have been a bit off base, it was just something I had been thinking about - peace - Matroc (talk) 22:22, 14 January 2016 (UTC)

Code review of Module:Timing[ਸੋਧੋ]

If anyone has some spare time then perhaps do a code review of Module:Timing? And the doc page needs a spell check too! I believe the precision in the produced numbers are about as they get, but there could be other ideas out there. Note that this solution are for those that develop code on their own, without a debugger running in a controlled environment. Note also that the test cases are written for another library, and that it does not work as of this writing. Hopefully it will work later on. Jeblad (talk) 18:03, 18 January 2016 (UTC)

The code is good but since you asked here are some thoughts from a quick look.
  • Line 37–38: Empty for loop with no purpose?
  • Line 44: Nothing wrong with math.pow but it is the same as v^2.
  • Line 46: I don't know if the timing table could ever be empty, but I would test for #timing == 0 even if I thought it couldn't happen.
  • Line 59/63: With a loop like that I would just have time[i] on the lhs.
  • Line 74: Is there a reason p.combine is part of p? Why not just a local function, if module users don't need to access it? Similar for other functions.
  • Line 124: Could be "local function dummy()" as I don't think a global is needed.
It would be pretty rare for a module to need timing, although I happened to do some crude testing of a module I'm working on the other day. Johnuniq (talk) 08:36, 19 January 2016 (UTC)
Thanks for the reviw!
  • p.combine was an access point for testing, could be put inline instead
  • function dummy() is used for baseline timing, and usually you will not test local functions
You will probably never add this to an ordinary module, it is only for crude testing to figure out which kind of code actually works well in this Lua environment. Jeblad (talk) 09:42, 19 January 2016 (UTC)
I think the only effect of putting "local" in front of "function dummy()" would be to change the scope of where dummy can be accessed (along with the fact that a global dummy would be added to the _G globals table). As the code is now, executing dummy = 'hello' would wipe out the dummy function. By "pretty rare" I meant that it would be rare to need to test the timing of a module. I understand that you don't use Module:Timing in another module, but nearly all modules run very fast and don't need to be optimized. I would think any modules that are too slow are just trying to do too much work, and only a very small number of modules would benefit from measuring the time taken by various functions. As mentioned, I had one of those rare exceptions a few days ago where I found a bottleneck that was removed by using a different method. However, I was doing a ridiculously large number of tests just from interest to see how long it would take. Johnuniq (talk) 10:24, 19 January 2016 (UTC)
If you use this module to test load in modules you probably know that executing dummy = 'hello' would have some implications. I haven't checked timing for local lookup, but usually that is much faster in other languages. Often by a factor ten or more. I can put the dummy function in the exported lib, that would be close enough.
The module was written as part of a larger testing framework, which had some timing issues. It was also used for testing FSMs. Jeblad (talk)
I'm sorry to be argumentative and the issue is trivial and can be ignored, but a user would test the timing of a function by executing something like =require 'Module:Timing'(p.hello). In the timing module, timing for the following would then be obtained:
self.runner(dummy, ...)
self.runner(func, ...)
That compares the time to access and execute dummy with the time to access and execute func. The former is a global variable which needs to be looked up in the _G globals table, while the latter is a function parameter which has the same fast access time as a local variable. Therefore using a global for dummy is not adding any accuracy. I'm just mentioning that as something I noticed, but it is unimportant and if there are reasons for having dummy a global for use in another situation, that's good too. Johnuniq (talk) 02:01, 20 January 2016 (UTC)
I was going to point out that Scribunto will report the top functions by time in a page (in the "Parser profiling data" section at the bottom of the preview page) when the page uses more than 1s of time in Lua, but it turns out that was disabled while debugging T70413 and never turned back on. Anomie 03:36, 21 January 2016 (UTC)
Pushing the code above 1s to get a readout would be e bit nasty. The code is more than good enough to figure out simple bottlenecks. Jeblad (talk) 01:33, 22 January 2016 (UTC)