CHANGELOG

# Changelog


## Sep 21
- Adding PhysicalActions and also extend the Posix support (using pthread to allow testing with threads scheduling async events.)
- 

## Sep 16-19
- Got back to the project after 3 months vacations.
- Adding most missing features: LogicalAction, Ports, Connections, LEvel assignment, Startup/shutdown, platform abstraction.
- Physical actions is a key missing feature
- Also should look at getting it turn-key with Zephyr.
- ALso Riot is interesting (although Makefile based)
- Lastly, we should start looking at 

## May 21
- Setup code coverage with lcov and Github Actions (omg Github Action is a huuge pain in the ass)

## May 20
- Implemented a priority queue for the event quue and a simple FIFO for the reaction queue
- Integrated with Unity test framework.
- Add triggers, children and reactions to the generic Reactor struct.

## May 19
- Added timer.h and timer.c which is a trivial addition and hello_timer.
- Added support for ports and connections. We will have to elaborate a little on those because we will need inwards
  and outwards connections. And delayed and enclaved and maybe federated. 

## May 11
- Completed the minimal hello world reactor just triggered by a startup event. It is of course not doing it properly and the event queue and reaction queue are just dummys, but it does actually work.
- A minimal example with an action also now works.


## May 6
- I think we need to associate a static, configurable number of events with each trigger which should be derived at compile-time. Practically, it means that a trigger has a FIFO of events associated with it. I would say we should have the value, and the tag there and also on the event queue. The reason is that it will be easy to detect the min_spacing requirements. Either we only have a FIFO, meaning that we only support monotonic scheduling
- Another thing is the whole thing with connections and ports. What about an input connected to a further input. Are each input a trigger? And as such we must copy? How will the runtime perform the copying? Open questions.

## May 5
- Initial stab. Working towards the MVP which is just a startup-reaction.
- I did think mostly about actions, which are the more general case and I think I found a way to make it work when we only allow a single event per action at the moment. In this case an event is simply a tag and a pointer to a Trigger.
- I need to think a little about a standard function API. Should I have all functions return a status code? Might be smart yes.
- Also how will connections and port work? Will we need to copy data between them? 
- What about enclaves? Limiting ourselves to a single outstanding event per action might make it hard to implement enclaves efficiently. Because they are communicating with events scheduled on an action.
- What about delayed connections. If the delay is bigger than the period at which the connection is driven, then we get a "backlog" but it is known at compile-time. Maybe we have to handle this case specifically? Maybe connections need to have the ability to support multiple