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.
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.
On macOS, sometimes ._script.lua is created to store metadata when the
user copies script.lua over to their SD card. Previously, the scripting
engine would barf since the file is not Lua. Now, these files are
ignored.
Also avoids a case where a hidden and valid script might be loaded
without the user's knowledge.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
start of the update
This allows specifying a return value like "return update, 10" to run
at a near perfect 100Hz, where as before it would be run 10 ms after the
script had completed it's loop, which can be highly variable as the
script experiences interupts from the system, as well as needing the
script author to take responsibility for calculating the desired update
rate at the end. This was always intended to be fixed, but I pushed it
back during the initial development, however people are begining to run
scripts that have enough processing, or are rate sensitive enough that
we are now needing to start correcting this, or scripts will have to do
their best to guess the time, which will be inferior to us providing it.
As a note if you exceeded the time expected we will be rescheduling the
script immediately, thus it will have a schedule time in the past and
will be slotted in. This can't indefinetly starve other scripts as they
will still be slotted in, but if you request an update in 1 ms, but took
100ms to run we will simply slide you back into the queue 1ms after when
you started running.
Lowering the sleep time when no scripts are pending, causes starting a
REPL session to respond much faster (this cuts the latency from up to 10
seconds to 1 second before the session is ready to start).
Also lowers the default scripting debug level to hide the statustext
from users, as in the general case this is just a spammy message if it
occurs, and we should be finding better reporting bits to get this to
the user.
This helps SITL where we frequently panic about to long a statustext,
which means a user never sees the intresting part unless they comment
out the sanity check, or run on a real board.
Peter Barker
Thomas Watson
Iampete1
Andrew Tridgell
Tom Pittenger
bugobliterator
murata
Michael du Breuil
Rishabh