Implements a reasonably comfortable REPL accessible over serial entirely
as a loadable script.
Also accessible over MAVLink using QGroundControl's MAVLink Console and
the new mavport module.
Abstracts the MAVLink SERIAL_CONTROL message to be usable as a Lua port,
in particular the DEV_SHELL device supported by QGroundControl's MAVLink
Console.
remove the metho operator from the class.
This means this will no longer work:
Quaternion q{0,1,2,3};
q(5,6,7,8);
.... that used to set the quaternion componets, but is an odd / atypical syntax to use
remove the metho operator from the class.
This means this will no longer work:
Quaternion q{0,1,2,3};
q(5,6,7,8);
.... that used to set the quaternion componets, but is an odd / atypical syntax to use
Serial bindings were dependant on HAL_GCS_ENABLED but this is not ideal, it should be dependant on AP_SERIALMANAGER_ENABLED so that serial can function without GCS
In Lua, strings are the only type that come with a default metatable.
The metatable must be shared by all string objects, and it is set to be
the `string` library table each time that library is opened. In
Ardupilot's scripting engine, the last script to load then has access to
the string metatable as the library is opened fresh for each script, as
its `string` library will have been set to the metatable.
Therefore, if two scripts are loaded, A first and B second, and script B
executes e.g. `string.byte = "haha"`, then `string.byte()` and
`s:byte()` for script B are broken. Because the metatable is shared,
this also breaks `s:byte()` for script A, which violates the integrity
of the sandbox.
Fix the issue by disabling the metatable setup functionality when the
string libary is opened, then manually opening an additional copy of the
library (which won't be given to any script) and setting it as the
string metatable during intialization.
This will break any script that modifies the string metatable for
constructive purposes, but such a script could have been broken if it
weren't the only script running anyway.
Referencing the original function to run is of questionable value and
the only user uses it to grab the script environent from the upvalues.
Instead, use a reference to the script environment table directly.
Some bits of the code in the require machinery use the `lua_ref` to
access the script environment. However, this can change after the script
is rescheduled and it returns an arbitrary function to run next.
Resolve this by introducing `run_ref` which is specifically a reference
to the function to run next. `lua_ref` is preserved for the script
lifetime.
