If it is too much for one ticket, break it out and create additional issues by module or directory.

In lib/automata/automata.ex.

So we can use embedded schema without a database, and eventually probably also make automaton_config a struct too

The preferred_cli_env: [espec: :test] in mix.exs isn't working. It should also run the doctests in Automaton.Config.UserConfigParser

Something like this?

Let's add required fields validation, error handling
for user_opts in Automaton.Config.Parser using the Ecto.Schema validation protocol

The NodeTypeError for user_opts[:node_type] is just a string message now, we should make some real error types.

The interface for all nodes in lib/core/control/behavior.ex. See here for an example MockBehavior

Right now with the else clause here commented out, when you run iex -S mix, the tree runs once in the correct order, but when you uncomment the else clause, it runs out of order. I am assuming this is because Process.send_after runs async. But this will not work with BT updates

Should we forget about ticking the entire tree(subtree) and just store the currently running node somewhere as recommended in some BT literature, or should we try to get this working so we have more fine grained control of subtree tick frequencies? One could imagine scenarios in which a control node should update at a high or low frequency relative to others.

1. Move all images from the root dir into an assets dir

2. Search and replace all links to images and replace with new assets/ path

Let's make the Automaton.Types.BT.Config struct an Ecto embedded_schema for ingestion by Automaton.Types.BT.Config.Parser for changeset capabilities as we work towards designing anti-corruption layers and contracts between core components.

It is desirable to be able to run both the dialyzer and docs mix tasks after every change to automata. They should be run before a PR for a change is requested.

To effect this, dialyxer and ex-doc needs to be added as dependencies to mix.ex

See issues #6, #7 and #9

This should probably be done earlier than later in the project's life. It is my understanding that in a couple of weeks (end of Feb?) there might be some significant changes to automata although this should not affect changing automatas dependencies.

Please read the online help for Elixir's dialyzer and docs. tasks.

We need to avoid noise as a stringent focus is required for such an undertaking.

https://github.com/elixir-lang/ex_doc/

Even if it is just setting up simple doctests for functions that describe input / output, and print themeselves would help so we can update them as they change.

This is the doc generator, there is a separate ticket to start on doctests.

Setup a good skeleton with elixir testing best practices would be a big step forward for the project.

See the BTSK (behavior tree starter kit) for examples of whats important to test for the abstract stuff in the API. That would be a great starting point.

Find a way to pass a function to state in user-defined update function so that the update can be run async as a Task so subsequent ticks will return :bh_running until the task completes (which sets the resulting status). This makes the agent reactive. Or is there a better more elixir way to do this? I'm thinking similar to this:

  def handle_cast({:run, fun}, state) do
    Task.async(fun) # sends a message back to the automaton when completed
    {:noreply, state}
  end

  # handle_info/2 receives generic messages from the Task processes
  def handle_info({_task, {:ok, result}}, state) do
    new_state = %{state | status: result}
    {:noreply, new_state}
  end

  def handle_info({_task, {:error, reason}}, state) do
    state = %{state | status: :bh_failure, fail_reason: reason}
    {:noreply, state}
  end

Create simple behavioral test for the MockSeq1. Test that it runs all of it's children, one after the other in time, where no successor runs before a predecessor (since we aim to be fully async).

We can either use espec or the elixir builtin testing library. We can setup the TestMockSeq1 to have more children (simple actions would be best) for now until we get factories or fixtures.

It would be nice to have Factories similar to FactoryBot for ruby/rspec. Is there a good library for elixir? If not, can we setup fixtures?

right now lib/core/control/behavior.ex has the basic API.

TODO:

1. what are the functions that the user will have to define and/or override? Can we get away with just having them define the update function.

2. Once we know this we can decide how the params will be passed, perhaps as a map or keyword list.

Does the NodeSupervisor become the root source of the tick traversal? Or is it in the root user-defined node?

Is it feasible to have a per node tick_freq rather than a tick_freq for the entire user-defined tree? Seems doable but we need to think through all implications and determine if this is the way to go.

1. Determine best way to increase performance by starting subtree nodes as needed or some other such mechanism to avoid starting the whole BT on application start.

2. Determine the best way to prevent ticking the whole tree when started and running. Perhaps a zipper tree can be used to store the tree at the root and only update currently running node as long as it is running otherwise re-update entire tree.

This is a critical abstract controller for user-defined control nodes, and should be carefully thought about how to best design tests.

Using atoms as name option in start_link is bad for scalability. Since these are not garbage collected, using them will eventually cause the BEAM to run out of memory. Lets use unique SHA hashes as names using the via tuple contract provided by Registry.

Use unique content hashes for names of nodes and eventually Distributed Hash Tables for resource discovery (like kademlia). SHA hashes provide versioning and avoid name collisions. For example, reusing an action would be unique from another version even though the user used the same module. Two versions of same module can do different things also. Each version runs in separate process. No namespace collisions. One could have thousands of the same module running as processes. This is a very good thing for programming large systems.

see lib/automata.ex in the start function. Do we load the files and build the nodes_config from the module names? Or is there a better way?

We need to ensure it handles the children properly along with the Automaton.Behavior macro.

This is the abstract controller for injecting actions, decorators, conditions into user-defined nodes and should be tested thoroughly with thoughtful design of tests.

Like rspec shared_context

In order to provide type checking we should go through and add typespecs for the currently defined functions so we get nice compiler errors and extra documentation from them.

We need tests for this as it is one of the trickier logics. Not great for beginners but good first issue for a senior dev.