Jump to content

Lua scripting/Meeting 2012-01-25

From mediawiki.org

Notes from in-person meeting in San Francisco between:

  • Tim Starling
  • Roan Kattouw
  • Asher Feldman
  • Brion Vibber
  • Trevor Parscal
  • Rob Lanphier

Tim reviewed various js engines, mainly about execution time and whether they could limit it. Wrote a Lua implementation which imposed time and memory limits.

Lua advantages:

  • Easy for third parties to use. Lua has sandbox features in language to allow for disabling functions as needed, and can be used via shelling out.
  • Designed to be embedded into applications, and in use by other projects, and the bugs can be sorted out.
  • Language features are very similar to Javascript. Syntax is a little different

Javascript V8 - documentation very sparse

Trevor: Freebase is using Rhino (Mozilla JavaScript engine written in Java). If you look at how we use templates in MediaWiki, we need to have callbacks to templates.

Tim: Gabriel Wicke has vision of Lua inside templates inside Lua inside templates, each with its own context

The preferred method for Wikimedia would be as an extension. Third parties can shell out and have some sort of IPC thing.

  • Lua sandbox can call back to the host environment; over IPC will be slower than direct calls, however. Shell mechanism would need to support all the same calls though.


We will need to not have an "include", because that implicitly introduces globals.

Lua has a pretty efficient interpreter, and also has a jit that we might also be able to use.

We don't think Spidermonkey has good memory limiting in it, but that hasn't been deeply researched.

Lua uses its own virtual stack, so you can limit that like any memory

Trevor: main motivation for Javascript is that it's most widely used, and has a lot of motivation.

Rob: Even if Lua is the "wrong" language, the work of converting from Wikitext to Lua will be valuable in getting the templates converted to other languages.

Tim: OOP model is different than Javascript, but not so different.

Trevor: Separate namespace?

(discussion about pros cons not captured)

Tim: we could use Wikiscripts as a model.

Trevor: worried about allowing scripting inside articles themselves. It makes visual editor very difficult.

Trevor: in Javascript, they have CommonJS http://www.commonjs.org/

... Trevor: give the script writer some control over what they export, and there can be scoping.



Example of fallback, using a new namespace and existing template syntax: 

{{Foo}}
  • -> checks Script:Foo, uses if
    • -> then checks Template:Foo if there is no Script:Foo

whereas {{Template:Foo}} or {{Script:Foo}} would not fall back

  • good: keeps full pages as lua
  • good: lets you replace templates in-place

Alternative: have Template:Foo as a wrapper containing {{#script:Foo}} to invoke Script:Foo

  • good: keeps full pages as lua
  • good: still lets you replace templates, but with an intermediary
  • bad: need to add something to pass through arbitrary parameters? possibly just have first argument be an args object

Freaky in-place alternative:

Wrap the template contents in {{#lua: ...... }} or <lua>...</lua>
  • bad: no full pages of lua, harder to edit

This is probably another reason for the MIME type feature.

We'll probably need to go with the wrappers.

Trevor: How are people going to include other scripts?

Brion: my preference is that we can allow scripts to call out to templates (which may be other scripts) -- that has some limitation potentially on returning wikitext/wikidom data only?


Tim's theory: Good development tools will improve the quality of our templates

Online code editor with syntax highlighting: would be good

Versioning -- even branching? -- good to let you test things

Roan: would be good to have a console where you can say "load my version of the template/script" and have it show you what it would be

  • like classic BASIC "immediate window" or JS debug console
  • this would be useful with *today's* templates as well, can be orthogonal to the language thing

Template performance tools? Would be useful regardless of language, and may be needed for figuring out if we're successful and making a case for convincing people to use this work.

  • both to present to script authors (integrated in debug console?) and to track on the backend (as in mw simpleprofiler)
Interwiki transclusion?

_probably_ should work similarly, no new problems foreseen Trevor: it would be good if interwiki landed first

Brion is interested in the code editor portion of this.

Trevor wants to make sure that we have a sane interface from a scripters perspective (e.g. how objects are invoked)

Maybe get some more community input on testing the UX and workflow


Target a followup in Berlin - May 2012

Retrieved from "https://www.mediawiki.org/w/index.php?title=Lua_scripting/Meeting_2012-01-25&oldid=2437119"