I think it quite a reasonable drone design to allow a tier 2 drone to have
1. navigation upgrade (waypoints)
2. chunk loader (for traveling safely)
3. inventory upgrade (to cary and drop items)
closes#2043
thanks to @Pwootage, who explained this change as such:
Previously, checkHandle was not "language safe" (or at least, not JSON-safe):
open() returns a HandleValue (which is a type not exposed by the oc-api jar)
checkHandle() checks for either a integer, or a HandleValue object
When calling through a custom architecture, HandleValue may or may not be preserved, as the underlying language, unless it can attach the original Java object, may not be able to represent the HandleValue class, and so convert it to a table, which checkHandle() did not check for.
move all vt100 code to vt100 library
delay load event rare code
fix shell parse for %d>&%d not followed by whitespace
remove weird tty blink code and use vt100 codes
bump openos patch version
* Parse Lua REPL inputs with an implicit "return "
If an input does not start with a leading "=", this will parse the input
with "return " appended and, if that fails, will parse as a normal
statement.
This allows for normal expressions to be entered into the repl (such as
`2 + 2`) but does mean the parse errors for malformed inputs are
confusing. For instance, `3 + ` will error at '3' rather than '<eof>'.
* Do not insert into history if a duplicate
This mimics the behaviour of shells such as bash or zsh, where
whitespace-only lines are not entered into history, nor are ones equal
to the previous input. This makes history navigation slightly easier.
GPUs have neighbor visibility, and screens have network visibility. But in a robot the gpu and screen are sibling components, with edges to the machine, but without edges to each other. Thus during load they are not connected to each other (regardless of load order). Robots already have a provision for this issue for connecting screens to keyboards and keyboards to screens, but lacked a custom screen->gpu connection. This code change simply adds that search and connects all screens to all gpus.
closes#2302
/bin/less and /bin/more were able to lock up the system if they call string.gsub(string, function) on a very large string (~144k chars long).
The machine layer intercepts expensive strings calls by checking the length of the string, but it does not intercept gsub calls when the replace action is a function
The fix is to intercept all long string actions, not just non-function replacement gsub calls
Note that /bin/more is now more efficient and doesn't call string.gsub, but this is still the right fix to keep the sandbox from being able to lock up the system with string methods
