it is possible to build for boards without storage (so no Posix, no Fatafs), but still have scripts in ROMFS.
In this case we will use the backend AP_Filesystem_backend base class when doing file operations. This will alway fail to open directories, so when we try to load scripts from SCRIPTS_DIRECTORY it will always fail.
This leads to a warning being emitted:
Lua: State memory usage: 2796 + 5227
AP: Lua: open directory (./scripts) failed
AP: hello, world
Time has wrapped
Which isn't great.
Detect we are working on this filesystem and don't warn.
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.
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.
Randy Mackay
Andrew Tridgell
Iampete1
Nick Exton
timtuxworth
Peter Barker
Thomas Watson
Clyde McQueen
bugobliterator
Henry Wurzburg
yuri-rage
Tatsuya Yamaguchi
Willian Galvani
Loki077
George Zogopoulos
Hayden Donald