adds code comments for a number of method declarations in header,
and in the implementation file, prefixes many method calls with
`this->`. This convention disambiguates whether the call is a method
of the class or a function at global scope. On some projects like
gcc, it is part of the coding standard to do this to avoid subtle
bugs -- I have come to believe that it makes your code more easily
readable, even if it is a little more typing.
@gfgtdf pointed out that preferences contain MP passwords. We can't allow
untrusted code to access them. Since we only need preference access from
plugins for now, the simplest way to avoid security issues is to block Lua
code outside of plugins from accessing preferences at all.
This constitutes drop-in replacements for:
* boost::shared_ptr
* boost::scoped_ptr
* boost::weak_ptr
* boost::enable_shared_from_this
* boost::static_pointer_cast
* boost::dynamic_pointer_cast
This excludes boost::intrusive_ptr, except for stray includes. Refactoring that is more complicated.
This commit converts the following function calls:
* boost::bind -> std::bind
* boost::function and boost::functionN -> std::function
* boost::ref and boost::cref -> std::ref and std::cref
* boost::bad_function_call -> std::bad_function_call
In the process, it was discovered that std::bind has trouble with overloaded
functions. There were two such cases in the code:
* gui2::twindow had an ancient unused overload to draw(). The overload was removed.
* gui2::trepeating_button was binding tdispatcher::fire. This case was converted
to a lambda.
This is used instead of the boost::bind and boost::function method
introduced before. It's a bit simpler than the boost::function code
in lua_cpp_function, and a bit faster / less can go wrong when we
don't use boost::fucntion.
It also fixes a potential future use-case -- if a lua state is
copied, but many of the functions in the environment are made with
boost bind, they become bad pointers since they point to the old
lua state, and there is no easy way to retrieve them. Using lua
extra space instead of bind ties the lua_State more tightly to our
C++ representation of it.
wesnoth.add_dialog_tree_node to add nodes to a tree_value
wesnoth.set_dialog_callback support for tree_views (triggers when the
selected node was changed)
wesnoth.get_dialog_value support for tree_views returns an array of
integers that describe the path to the currebntly selected node.
We use LUAI_EXTRASPACE to add a pointer to the lua_kernel_base in the lua_State
stucture, this makes is very easy to get a reference to the lua_kernel in
functions that take a lua_State* as an argument.
headers from lua/.. contain macros that can break other headers in
wesnoth, boost or other libraries.
In this case it was a macro
#define cast(t, exp) ((t)(exp))
defined in lua/llimits.h that broke a boost header.
The problem was that intf_require would assume use the wrong
lua_State* since it finds it using the kernel's this pointer. This
commit gives a version of "protected_call" which allows to use the
callback's lua_State*.
In the error handling routines for compiling and running a script
at runtime, don't construct a string directly from lua_tostring,
because if it is null that is a runtime error. Instead check for
this scenario.
In intf_require, when getting the "wesnoth" global, luaW_getglobal
is unnecessary and lua_getglobal should be prefered.
This collection of classes provides a framework whereby the engine
may provide scripting capabilities in any "context". A C++
function may declare a plugin context by providing a list of names
function objects, then may call "play_slice()" on this context to
transfer control to lua. A lua script may generate some arguments
and request to call some of these, then yield to the engine. C++
will run them until one of them signals an error, or that the
context is now invalid (using a boolean return value).
The intended semantics is that lua may only make requests
corresponding to the current context. As soon as a new context
is used (play_slice() is called again) the old context is invalid
from lua's point of view -- calling those functions is a lua
error but not undefined behavior. This should be the case even if
the old context has not been destroyed yet in C++, for instance
if a lua request resulted in a new context being created. There is
a system of locks in place to ensure that when old contexts are
invalidated, stale requests are discarded.
We also add the coroutine library to our lua base. This because
threads are run as coroutines, and writing them requires the use
of coroutine yield from the standard library.
This allows some sort of "drop into debug" mode for lua if your
script detects an error.
We could consider to actually add an "option to attach debugger"
as an error handling mechanism, but it might be complicated
because of wesnoth exceptions which must go through lua and be
treated as lua errors, and we cannot handle two exceptions at once
obviously, so the lua interpreter is probably not safe to run that
way in general. Anyways this commit does not do that.
This commit changes the majority of the wesnoth callback functions
for the game lua kernel to be private methods of the game lua
kernel. The game lua kernel is given direct access, via it's ctor,
to references of many of the things provided by resources. The
call back functions are modified to access these private reference
variables instead of resources, and they are added to the
scripting environment using the lua cpp function mechanism.
This greatly improves encapsulation and will eventually lead to
eliminating the resources pointers from the game lua kernel
entirely.
