Main Page

This is a test wiki for the Scribunto MediaWiki extension, allowing users to embed Lua in wiki pages.

NOTE: This wiki's version of Scribunto is very out of date. You should try test2wiki or mw.org for more up-to-date Scribunto versions.

NOTE: Due to spam, i've been swinging the ban hammer a bit aggressively, so if you find your IP blocked, please go to #mediawiki and ask me(thedj) or TimStarling to lift the ban. TheDJ (talk) 14:12, 2 July 2012 (UTC)

How to organize this site ?

I don't know why, but this site is not a standard wiki, then each one of us try a way to talk about some points. If you agree, we could use this map :

• Main Page could explain the goal and organization of the site, without talk.
• Community portal could be first a talk page about common questions. Later or now we could use some pages to talk about some kinds of subjects : program, administrate, welcome new users, useful changes in scribunto to ask to developers.
• Each module talk could be used to test and talk about each module.
• And each module should have its own Documentation page. Who can do it ?
• Of course, users could use their own pages for the same use, but when created modules become a common work, and objects to talk about.
• Help could be used to build a guide of "how to do" and "good practices" about modules and organization.
• Scribunto:Current events could display the version/date of mediawiki, scribunto and extensions, and describe main changes to answer our main bug questions.
• Is a large part of this page could move in "Community portal" and other common talk pages ?
• What do we want, and how to do it ? --Rical (talk) 09:11, 1 July 2012 (UTC)

Get started

• Coding in Lua
• Setting up an environment on your computer
• Community portal

Modules under development

• Module:MathRoman.lua
• Module:Stats
• Module:StrRight
• Module:Vi2ipa 2
• Module:Hello
• Module:Color
• Module:String
• Module:Trim
• Module:fnielsen
• Module:Curry
• Module:Coordinates - testcases - original testcases
• Module:Huflex
• Module:Unicode
• Module:Whatdowehave
• Module:UserScripts

Experiences

Please add anything that you encounter in your experience and would like to share

• Noticed interesting differences between "" vs " " vs nil (Lua) and undefined vs empty (parser functions) and {{{name| }}} vs. {{{name|}}} vs {{{name|µ}}} (templates). All these nuances are actually already used in current templates, which makes converting it 1-1 output wise can be challenging. We need at least an isEmpty helper function, and perhaps should do some evaluation when mapping from parser function onto frame ("" parser argument should perhaps map to frame.args[1] = false instead of frame.args[1] = "" ? ) TheDJ (talk) 08:40, 3 June 2012 (UTC)
  • Is it easy to quickly indicate how they actually differ? 62.157.47.101 11:44, 3 June 2012 (UTC)
• We should do something with documentation of the authored modules :D

  It'd be great if the wiki could automatically generate a LuaDoc for each module. (LuaDoc comments begin with ---.) – Minh Nguyễn (talk, contribs) 17:56, 3 June 2012 (UTC)

  Yes, that's what I was thinking. And then on Module:yourscript you could actually have auto generated HTML documentation to replace /doc. TheDJ (talk) 22:46, 3 June 2012 (UTC)

• There should definitely be a way to centralize these scripts in an easy way, or we will get the gadgets 1.0 vs gadgets 2.0 problem all over again. TheDJ (talk) 22:32, 3 June 2012 (UTC)
• Some templates have /Print versions which are used for pediapress book and PDF print. There is no replacement for this in Module right now, so that will require some thought TheDJ (talk) 22:32, 3 June 2012 (UTC)
• Hmm, proper and fast trim and round routines are probably a must. We have implicit trim in the way template arguments are implemented right now and we have round in parser functions. Both are however not not part of standard lua libraries unfortunately. I would propose to have these in a core module. TheDJ (talk) 15:05, 5 June 2012 (UTC)
• Yes, I began to build a basical Module_talk:S and ask for a library and some other questions in Community portal. --Rical (talk) 23:21, 5 June 2012 (UTC)
• It'd be nice if the GeSHi extension would highlight [=[ foo ]=] syntax correctly. – Minh Nguyễn (talk, contribs) 06:19, 9 June 2012 (UTC)
  • Done -- Tim Starling (talk) 04:28, 9 July 2012 (UTC)
• Right now every function which is accessible via #invoke must expect a single frame object argument. This means that any function which one wants to be available both from wikitext and from Lua code must exist in two versions: one expecting a frame argument, and one with normal arguments. This is rather awkward. At least for #invoke calls with unnamed arguments, those arguments should be used as extra arguments in the Lua function call so that one can use them for simple functions where the extra power of the frame object is not needed. --Tgr (talk) 21:35, 10 June 2012 (UTC)
• We need date and math libraries that are locale aware. Printing an reading dutch numbers (with , instead of . ) seems an interesting exercise in print and replace atm. TheDJ (talk) 15:39, 1 July 2012 (UTC)
• Is mixedCase or lower_case_with_underscores the preferred style for function names? Is there a lua style guide at all? Σ (talk) 19:12, 12 July 2012 (UTC)

Debugging support

Scribunto clearly has an amazing potential, but it is mega-painful to use now. Module:Huflex took 12 hours or so to write - as a straightforward port of a few dozen lines of existing PHP code, it shouldn't have taken more than an hour, even for an unfamiliar language. The reason was partly Lua's lack of support for common things such as character encodings, regular expressions or arrays, which is already being addressed at mw:Extension:Scribunto/API_specification. The other reason was the lack of debugging support. The automated syntax checks upon saving and the nice stack traces whith the direct links to the editor are nice, but nearly enough. A few things that would be helpful, in decreasing order of importance:

• there is desperate need for a command that prints its argument for debugging. I like the idea that you need to return all output and not just echo it as in PHP, it is good for code readability - but it is horrible for debugging. If you have a problem with a function call five levels down the stack, you need to change the code on all five modules to hand back the debug data. If some of those modules are already widely used, things get even uglier.
  • there is not much support in Lua for pretty-printing data structures, which is another thing needed for convenient debugging (collapsible multi-level-table display, recursion detection, size limits and so on).
  • given that Lua data structures map to JS data structures almost 1-to-1, maybe debugging could be done via the javascript console and console.log? That way, not much effort needs to be put into the UI.
• there should be also a way to break the execution and display an error (for the wrong type of arguments etc.) - a fail or assert command. And speaking of asserts, it would be very nice if one could test the code without all the save/refresh - something like Module:Foo/tests running automatically when Foo is saved, and not allowing to save if the unit tests failed, the same way it is already done for syntax errors.
  • Is it possible to simulate a sort of preprocessor in Lua (or, at least, in Scribunto)? If so, we could enable certain functions during debug (Preview? [see my remark below about ExpandTemplates]) but disallow them in normal (saved) mode? If nothing else, the print statements could be enabled in one mode and not the other. Is this behavior at least theoretically configurable?

76.107.76.96 13:06, 21 June 2012 (UTC)

• constantly saving, opening for editing again, waiting for the editor to load is very annoying when one is debugging and experimenting with small quick changes (e.g. looking for a fatal error by commenting code out row by row). I can think of two things to help with that:
  • offer a way to save without leaving the editing page (possibly with some automatic edit summary)
  • make the edit links in the error messages reuse the already opened page: when I click on a line in the stack trace the first time, the edit page should open in a new window, and when I click on a line for which an edit window already exists, it should bring that window up and reposition the cursor, without reloading. Together with the save-in-the-background feature, that would mirror the behavior of a desktop code editor quite nicely (and it is easy to do - at least in Chrome -, you just need to add target to the links).
  • Something like ExpandTemplates would be awesome. Or, better yet, imagine "preview" view of a page in the Module namespace having a little textarea where you can test calls against the code. If it doesn't work, make a change in the code, hit the preview button, then try your test again.

76.107.76.96 13:06, 21 June 2012 (UTC)

• a client-side interpreter for quick testing would be nice. The Lua Tutorial has one - of course it would be even better if it would understand all the Scributo-specific stuff and simulate querying/parsing commands via AJAX, but even a vanilla Lua interpreter would be helpful.
• pages on which a template invocation resulted in a Lua error should probably be placed in some maintenance category.
• very minor, but annoying: if I write {{#invoke|...}} instead of {{#invoke:...}}, there is no error message, it just silently does not work.
• another minor thing: when one forgets Module: in the require call, the resulting error message is not very helpful.
• also minor, though probably more messy to solve: Lua does not understand "else if", and it results in very misleading error messages which point to distant places in the code. Writing the extra space is an easy error for PHP programmers to make. Scanning the code for "else if"s on the right kind of syntax error and displaying some sort of tip would be nice.

--Tgr (talk) 20:26, 9 June 2012 (UTC)

I wrote a debug console module and deployed it here, let me know what you think of it. -- Tim Starling (talk) 04:50, 14 July 2012 (UTC)

I think it goes in the right direction, and it would do a lot to make module development less painful, but it has two major bugs right now: require does not work (it just returns boolean true), and there is no output from mw.log on error. If these were fixed, developing Lua would be not too different from developing Javascript for the browser: somewhat uncomfortable but manageable.

A few smaller problems/suggestions:

• mw.log does not show the datatype (mw.log(true) and mw.log('true') gives the exact same results), and it cannot handle tables. Some clickable tree structure (similar to Firebug for Javascript or kint for PHP) would be super-nice.
• when I try to print (with the = prefix) a function which ends with return (no arguments), I get Lua error in console input at line X: bad argument #1 to 'tostring' (value expected) which is not very user-friendly.
• it would be super nice if debug console error messages had the same jump to line support as the normal error messages do.
• how do I test functions which expect frame objects?
• use of p as module export name is a bit annoying when copy/pasting code from the module. Might be just me, but I would find it easier to use if I could use the name of the module instead.
• Also subjective, but I don't really like the UX of the debug window, it is very uncomfortable for multiline code (if I have a non-trivial problem with an algorithm, I would normally copy it to the debug console and edit and run until it works). I would prefer something like Firebug's multiline window where you can enter any text, and there is a button (and a key shortcut) to run the whole thing (and maybe another to run just the current line). Of course this could be easily customized individually if the Javascript API used for creating the debug interface is open enough.

--Tgr (talk) 18:00, 26 August 2012 (UTC)

Flying users

Many user accounts in scribunto.wmflabs.org seems used to transmit messages between them. Is this a lack of security ? I am not admin, but I never saw this in any wiki ?

How they create their accounts ? Can this give a way to detect them ?

Some one have an idea to limit or stop this abnormal use ? --Rical (talk) 09:55, 1 July 2012 (UTC)

I now have the right to block the spam users. It was a bit of a mess indeed. TheDJ (talk) 15:09, 2 July 2012 (UTC)

For some days I ask myself about spam here. They seem to be answers in a blog which could have bad settings and loses edits, then they come here. More, many times the edit begin at "== title ==" like in a wiki. Is it a way to look at IP and perhaps alert the webmaster, then keep our and their wiki clean. --Rical (talk) 19:02, 22 July 2012 (UTC)

When I search elsewhere the users who talk/spam here, I find them as users in other wikis.

The question is the same here http://scribunto.wmflabs.org/ and in http://wikisource-dev.wmflabs.org/. --Rical (talk) 19:42, 22 July 2012 (UTC)