Currently, the only way for PHP to pass a function to Lua is to pass
back a function that it received from Lua. This means, for example, that
PHP cannot implement a Lua iterator function except by registering a
library holding the function or by using loadString.
This changeset adds Scribunto_LuaInterpreter::wrapPhpFunction (and
implements it for both LuaSandbox and LuaStandalone), which takes a PHP
callable and returns a Lua function wrapping it.
Note that fallback code is included so this does not depend on
I2e552799.
Change-Id: Ic0a98eec7cc17ef4b1acee032c0f42d617b998d2
* Added tests for the engine classes.
* Added some tests that run under Lua.
* In the chunk names, fixed truncation of module names at 60 bytes
by using an "=" prefix instead of @.
* Fixed a bug in mw.clone() which was causing the metatable to be set on
the source table instead of the destination.
* Put restricted setfenv/getfenv in the cloned environment rather than
the base environment, they work better that way.
* In setfenv(), check for getfenv() == nil, since that's what our own
restricted getfenv returns.
* Fixed getfenv() handling of numeric arguments: add one where
appropriate.
Change-Id: I2b356fd65a3fcb348c4e99a3a4267408fb995739
* Introduced a Lua implementation based on shelling out to a standard Lua binary.
* Bundled several Lua binaries for common platforms. I haven't added a 32-bit Linux binary yet, but that will come.
* Refactored the existing Lua class, bringing out functionality common to all Lua implementations into a set of common base classes.
* Moved the bulk of the implementation-specific functionality into a set of "interpreter" classes.
* Renamed LuaSandboxEngine to Scribunto_LuaSandboxEngine
* Don't create an engine object unconditionally when the ParserLimitReport hook is called.
* Implemented isolation of module global variable namespaces. This means that separate {{#invoke}} calls can't pass data to each other -- this was a desired feature in planning since it allows more flexibility in wikitext parser design. Isolation for mw.import() means that modules cannot accidentally create global variables which affect other modules -- exports are solely via the return value.
Change-Id: I3fa35651fe5b1fbfd85adeadc220b1ea31cd6f0b
