farmbot_os/farmbot_celery_script/lib/farmbot_celery_script/sys_calls/stubs.ex

166 lines
4.0 KiB
Elixir
Raw Normal View History

2019-03-05 10:14:01 -07:00
defmodule FarmbotCeleryScript.SysCalls.Stubs do
Implement new CeleryScript Runtime environment. This is obviously a rather large change warranting an essay describing it. A Brief overview Basically the old implementation had quite a few down sides preventing it from really working as intended, especially with the addition of the variables feature. Here is the shortlist of things that needed addressing: * No scoping between sequences. What this essentially means is that a sequence that executes another sequence is unable to add data to the calle. This is important for using Variables. * Error recovery certain nodes have a high likelyhood of failing such as anything that interfaces the firmware. Much focus was spent ensuring that errors would be recoverable when desired. * Complexity of control flow asts versus action asts. Nodes such as `if` will always work in the same way regardless of the state of the rest of the system meaning there is no reason for it to have a special implementation per environment. on the other hand `move_absolute` is bound to a specific part of the system. Seperating these concerns allows for better testing of each piece independently. A More In Depth overview The core of this change resolves around 1 really big change resulting in many more small changes. This change is the CeleryScript `compiler`. The TLDR of this system is that now CeleryScript ASTs are deterministicly compiled to Elixir's AST and executed. Doing this has some big benifits as described below. 1) CeleryScript "runtime" environment is now much simpiler in favor of a somewhat complex "compile time" environment. Basically instead of EVERY single CeleryScript AST having a custom runtime implementation, only a subset of ASTs that require external services such as the Firmware, Database, HTTP, etc require having a runtime implementation. This subset of ASTs are called `SysCalls`. Also the runtime implementations are compiled to a single function call that can be implemented instead of needing to have a contextual environment and making decisions at runtime to evaluate variables and the like. 2) Static analysis is now possible. This means an incorrectly crafted sequence can be validated at compile time rather than getting half way through a sequence before finding the error. 3) Having the "external services" separated leads to better plugability. There is now a behaviour to be implemented for the subset of syscalls that are system specific.
2019-02-20 12:57:45 -07:00
@moduledoc """
SysCall implementation that doesn't do anything. Useful for tests.
"""
@behaviour FarmbotCeleryScript.SysCalls
Implement new CeleryScript Runtime environment. This is obviously a rather large change warranting an essay describing it. A Brief overview Basically the old implementation had quite a few down sides preventing it from really working as intended, especially with the addition of the variables feature. Here is the shortlist of things that needed addressing: * No scoping between sequences. What this essentially means is that a sequence that executes another sequence is unable to add data to the calle. This is important for using Variables. * Error recovery certain nodes have a high likelyhood of failing such as anything that interfaces the firmware. Much focus was spent ensuring that errors would be recoverable when desired. * Complexity of control flow asts versus action asts. Nodes such as `if` will always work in the same way regardless of the state of the rest of the system meaning there is no reason for it to have a special implementation per environment. on the other hand `move_absolute` is bound to a specific part of the system. Seperating these concerns allows for better testing of each piece independently. A More In Depth overview The core of this change resolves around 1 really big change resulting in many more small changes. This change is the CeleryScript `compiler`. The TLDR of this system is that now CeleryScript ASTs are deterministicly compiled to Elixir's AST and executed. Doing this has some big benifits as described below. 1) CeleryScript "runtime" environment is now much simpiler in favor of a somewhat complex "compile time" environment. Basically instead of EVERY single CeleryScript AST having a custom runtime implementation, only a subset of ASTs that require external services such as the Firmware, Database, HTTP, etc require having a runtime implementation. This subset of ASTs are called `SysCalls`. Also the runtime implementations are compiled to a single function call that can be implemented instead of needing to have a contextual environment and making decisions at runtime to evaluate variables and the like. 2) Static analysis is now possible. This means an incorrectly crafted sequence can be validated at compile time rather than getting half way through a sequence before finding the error. 3) Having the "external services" separated leads to better plugability. There is now a behaviour to be implemented for the subset of syscalls that are system specific.
2019-02-20 12:57:45 -07:00
require Logger
2019-07-03 14:04:53 -06:00
@impl true
def log(message, force?), do: error(:log, [message, force?])
2019-07-03 14:04:53 -06:00
@impl true
def sequence_init_log(message), do: error(:log, [message])
@impl true
def sequence_complete_log(message), do: error(:log, [message])
2019-07-03 14:04:53 -06:00
@impl true
def calibrate(axis), do: error(:calibrate, [axis])
Implement new CeleryScript Runtime environment. This is obviously a rather large change warranting an essay describing it. A Brief overview Basically the old implementation had quite a few down sides preventing it from really working as intended, especially with the addition of the variables feature. Here is the shortlist of things that needed addressing: * No scoping between sequences. What this essentially means is that a sequence that executes another sequence is unable to add data to the calle. This is important for using Variables. * Error recovery certain nodes have a high likelyhood of failing such as anything that interfaces the firmware. Much focus was spent ensuring that errors would be recoverable when desired. * Complexity of control flow asts versus action asts. Nodes such as `if` will always work in the same way regardless of the state of the rest of the system meaning there is no reason for it to have a special implementation per environment. on the other hand `move_absolute` is bound to a specific part of the system. Seperating these concerns allows for better testing of each piece independently. A More In Depth overview The core of this change resolves around 1 really big change resulting in many more small changes. This change is the CeleryScript `compiler`. The TLDR of this system is that now CeleryScript ASTs are deterministicly compiled to Elixir's AST and executed. Doing this has some big benifits as described below. 1) CeleryScript "runtime" environment is now much simpiler in favor of a somewhat complex "compile time" environment. Basically instead of EVERY single CeleryScript AST having a custom runtime implementation, only a subset of ASTs that require external services such as the Firmware, Database, HTTP, etc require having a runtime implementation. This subset of ASTs are called `SysCalls`. Also the runtime implementations are compiled to a single function call that can be implemented instead of needing to have a contextual environment and making decisions at runtime to evaluate variables and the like. 2) Static analysis is now possible. This means an incorrectly crafted sequence can be validated at compile time rather than getting half way through a sequence before finding the error. 3) Having the "external services" separated leads to better plugability. There is now a behaviour to be implemented for the subset of syscalls that are system specific.
2019-02-20 12:57:45 -07:00
2019-07-03 14:04:53 -06:00
@impl true
def change_ownership(email, secret, server),
do: error(:change_ownership, [email, secret, server])
2019-07-03 14:04:53 -06:00
@impl true
def check_update(), do: error(:check_update, [])
2019-07-03 14:04:53 -06:00
@impl true
def coordinate(x, y, z), do: error(:coordinate, [x, y, z])
2019-07-03 14:04:53 -06:00
@impl true
def emergency_lock(), do: error(:emergency_lock, [])
2019-07-03 14:04:53 -06:00
@impl true
def emergency_unlock(), do: error(:emergency_unlock, [])
2019-07-03 14:04:53 -06:00
@impl true
def execute_script(package, args), do: error(:execute_script, [package, args])
2019-08-19 10:47:19 -06:00
@impl true
def update_farmware(package), do: error(:update_farmware, [package])
2019-07-03 14:04:53 -06:00
@impl true
def factory_reset(package), do: error(:factory_reset, [package])
2019-07-03 14:04:53 -06:00
@impl true
def find_home(axis), do: error(:find_home, [axis])
2019-07-03 14:04:53 -06:00
@impl true
def firmware_reboot(), do: error(:firmware_reboot, [])
2019-07-03 14:04:53 -06:00
@impl true
def flash_firmware(package), do: error(:flash_firmware, [package])
2019-07-03 14:04:53 -06:00
@impl true
def get_current_x(), do: error(:get_current_x, [])
2019-07-03 14:04:53 -06:00
@impl true
def get_current_y(), do: error(:get_current_y, [])
2019-07-03 14:04:53 -06:00
@impl true
def get_current_z(), do: error(:get_current_z, [])
@impl true
def get_cached_x(), do: error(:get_cached_x, [])
@impl true
def get_cached_y(), do: error(:get_cached_y, [])
@impl true
def get_cached_z(), do: error(:get_cached_z, [])
2019-07-03 14:04:53 -06:00
@impl true
def get_sequence(resource_id), do: error(:get_sequence, [resource_id])
2019-07-03 14:04:53 -06:00
@impl true
2020-01-17 08:58:53 -07:00
def get_toolslot_for_tool(resource_id),
do: error(:get_toolslot_for_tool, [resource_id])
2019-07-03 14:04:53 -06:00
@impl true
def home(axis, speed), do: error(:home, [axis, speed])
2019-07-03 14:04:53 -06:00
@impl true
2020-01-17 08:58:53 -07:00
def install_first_party_farmware(),
do: error(:install_first_party_farmware, [])
2019-07-03 14:04:53 -06:00
@impl true
def move_absolute(x, y, z, speed), do: error(:move_absolute, [x, y, z, speed])
2019-07-03 14:04:53 -06:00
@impl true
2020-01-17 08:58:53 -07:00
def named_pin(named_pin_type, resource_id),
do: error(:named_pin, [named_pin_type, resource_id])
2019-07-03 14:04:53 -06:00
@impl true
def nothing(), do: error(:nothing, [])
2019-07-03 14:04:53 -06:00
@impl true
2020-01-17 08:58:53 -07:00
def point(point_type, resource_id),
do: error(:point, [point_type, resource_id])
@impl true
def find_points_via_group(id), do: error(:find_points_via_group, [id])
2019-07-03 14:04:53 -06:00
@impl true
def power_off(), do: error(:power_off, [])
2019-07-03 14:04:53 -06:00
@impl true
def read_pin(pin_num, pin_mode), do: error(:read_pin, [pin_num, pin_mode])
@impl true
def read_cached_pin(pin_num), do: error(:read_cached_pin, [pin_num])
@impl true
def toggle_pin(pin_num), do: error(:toggle_pin, [pin_num])
2019-07-03 14:04:53 -06:00
@impl true
def read_status(), do: error(:read_status, [])
2019-07-03 14:04:53 -06:00
@impl true
def reboot(), do: error(:reboot, [])
2019-07-03 14:04:53 -06:00
@impl true
2020-01-17 08:58:53 -07:00
def send_message(type, message, channels),
do: error(:send_message, [type, message, channels])
2019-07-03 14:04:53 -06:00
@impl true
def set_servo_angle(pin, value), do: error(:set_servo_angle, [pin, value])
@impl true
def set_pin_io_mode(pin, mode), do: error(:set_pin_io_mode, [pin, mode])
2019-07-03 14:04:53 -06:00
@impl true
2020-01-17 08:58:53 -07:00
def set_user_env(env_name, env_value),
do: error(:set_user_env, [env_name, env_value])
2019-07-03 14:04:53 -06:00
@impl true
def sync(), do: error(:sync, [])
2019-07-03 14:04:53 -06:00
@impl true
def wait(millis), do: error(:wait, [millis])
2019-07-03 14:04:53 -06:00
@impl true
def write_pin(pin_num, pin_mode, pin_value),
do: error(:write_pin, [pin_num, pin_mode, pin_value])
@impl true
def update_resource(kind, id, params),
do: error(:update_resource, [kind, id, params])
2019-07-03 14:04:53 -06:00
@impl true
def zero(axis), do: error(:zero, [axis])
@impl true
2020-01-17 08:58:53 -07:00
def eval_assertion(comment, expression),
do: error(:eval_assertion, [comment, expression])
defp error(fun, _args) do
msg = """
CeleryScript syscall stubbed: #{fun}
"""
Logger.error(msg)
{:error, msg}
Implement new CeleryScript Runtime environment. This is obviously a rather large change warranting an essay describing it. A Brief overview Basically the old implementation had quite a few down sides preventing it from really working as intended, especially with the addition of the variables feature. Here is the shortlist of things that needed addressing: * No scoping between sequences. What this essentially means is that a sequence that executes another sequence is unable to add data to the calle. This is important for using Variables. * Error recovery certain nodes have a high likelyhood of failing such as anything that interfaces the firmware. Much focus was spent ensuring that errors would be recoverable when desired. * Complexity of control flow asts versus action asts. Nodes such as `if` will always work in the same way regardless of the state of the rest of the system meaning there is no reason for it to have a special implementation per environment. on the other hand `move_absolute` is bound to a specific part of the system. Seperating these concerns allows for better testing of each piece independently. A More In Depth overview The core of this change resolves around 1 really big change resulting in many more small changes. This change is the CeleryScript `compiler`. The TLDR of this system is that now CeleryScript ASTs are deterministicly compiled to Elixir's AST and executed. Doing this has some big benifits as described below. 1) CeleryScript "runtime" environment is now much simpiler in favor of a somewhat complex "compile time" environment. Basically instead of EVERY single CeleryScript AST having a custom runtime implementation, only a subset of ASTs that require external services such as the Firmware, Database, HTTP, etc require having a runtime implementation. This subset of ASTs are called `SysCalls`. Also the runtime implementations are compiled to a single function call that can be implemented instead of needing to have a contextual environment and making decisions at runtime to evaluate variables and the like. 2) Static analysis is now possible. This means an incorrectly crafted sequence can be validated at compile time rather than getting half way through a sequence before finding the error. 3) Having the "external services" separated leads to better plugability. There is now a behaviour to be implemented for the subset of syscalls that are system specific.
2019-02-20 12:57:45 -07:00
end
end