aletheiawarellc / wink Goto Github PK

Currently State transition occur immediately when GotoState is called which leads to some footguns.

Instead GotoState should record the next state and only after the current action (OnEntry, OnExit, Receiver) has returned, is the transition made.

There is still an open question around multiple invocation of GotoState within the same action, with two possible answers;

• The first invocation wins, and subsequent ones are ignored.
• The last invocation wins, so subsequent calls can override the next state.

Initial discussion: #43 (comment)

Messages send to self, or to other State Machines on the same host could avoid going through the networking stack and therefore gain a performance improvement.

Split out from #11

It's my understanding main is preferred over master these days.

State Transitions should move through the hierarchy, so that leaving the old state exits all the parent states going up the tree until the common ancestor (if any), and then enter all the parent states going down the tree and into the new state.

Ie. given a State Machine:

         parent
         /    \
        /      \
      leaf1    child1
               /   \
              /     \
            leaf2  leaf3

• Transitioning from leaf2 to leaf3 results in the execution of leaf2.OnExit and leaf3.OnEntry
• Transitioning from leaf1 to leaf3 should result in the execution of leaf1.OnExit, child1.OnEntry, and leaf3.OnEntry
• Transitioning from leaf3 to leaf1 should result in the execution of leaf3.OnExit, child1.OnExit, and leaf1.OnEntry

I forked and cloned the repo and while building the first time got the following message:

wink@3900x 22-12-18T18:27:25.387Z:~/prgs/AletheiaWareLLC/forks/aw-wink (master)
$ cmake -S . -B build
-- The C compiler identification is GNU 12.2.0
-- The CXX compiler identification is GNU 12.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Warning (dev) at /usr/share/cmake/Modules/FetchContent.cmake:1279 (message):
  The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
  not set.  The policy's OLD behavior will be used.  When using a URL
  download, the timestamps of extracted files should preferably be that of
  the time of extraction, otherwise code that depends on the extracted
  contents might not be rebuilt if the URL changes.  The OLD behavior
  preserves the timestamps from the archive instead, but this is usually not
  what you want.  Update your project to the NEW behavior or specify the
  DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
  robustness issue.
Call Stack (most recent call first):
  CMakeLists.txt:21 (FetchContent_Declare)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found Python: /usr/bin/python3.10 (found version "3.10.8") found components: Interpreter 
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE  
-- Configuring done
-- Generating done
-- Build files have been written to: /home/wink/prgs/AletheiaWareLLC/forks/aw-wink/build

The addition of some ASSERT_ macros would help make the tests more readable;

• assert counter (#45):
  • assert onEntry counter
  • assert onExit counter
  • assert receiver(message) counter
• assert state transition
• assert message was sent
• assert child was spawned

In samples/README.md the blinky link is broken because there is no blinky sample.

Adding counters inside State Machines which are incremented for each invocation of the OnEntry & OnExit actions, and message receivers would increase testability by enabling developers to easily assert that code was triggered.

Identifiers are very important and I think there will be a need to link ID's into a hierarchy for versioning, "VersionedId". Also, as I see it, an SM instance will "advertise" a set of Protocols it supports. Where a Protocol is a set of Messages. So each SM, Protocol and Message should have a VersionedId.

As for SMs, I don't see them having a static location nor will a single binary have a single instance so I don't think bin-name+network-address is an adequate ID. Also, networks will likely not be used for SMs communicating within a process which, IMHO, will be the most common case for how SMs communicate.

I'd like to suggest considering something like a UUID or Web3 ID as the basis for identification. I have no firm idea how to create a VersionedId, but I'm sure it's possible, maybe using Web3.