States and Event blocks bugged

[derwehr]

I tried to rebuild the 'gamble' program below using the states and event blocks

But the program below would not enter the new drawing state a second time. It seems like the block's code is bugged.

I'll also look into changing the way BLAST checks for these conditions.

[derwehr]

related to #307

[derwehr]

When constructing an EFSM for the blocks above, I noticed in the EFSM the lose state had no guard for transitioning back to the new drawing state (see graphic below).

---

Therefore I adapted the EFSM to look like below.

Trying to represent this with the states and event blocks in BLAST I created the program below:

Now BLAST does only provide syntax to evaluate code when entering or exiting states, but not while in a state. But, for the FSM above, I'd have to keep assigning draw a random value while in the lose state. To do this with the current blocks I'd have to introduce an inbetween state similiar to the first EFSM.
Maybe a third while in state option in the event blocks might be beneficial.

[derwehr]

Additionally, we talked about the need to add an operation like addEvent to BLAST node to ease development - related to #314

[derwehr]

[derwehr]

The current state conditions blocks are global, they can't be directly mapped to transitions from one state only.
They describe transitions originating from all states to one with the same guard.
So the direct mapping above (from EFSM transitions to state condition blocks and states to event blocks) only works well with EFSMs limited to 2 states right now

[derwehr]

The program in my first post not running as expected because of how the event blocks check for state transitions in BLAST. To detect when blast enters a state, the state blocks run the following code asynchronously to dispatch events when a state condition is evaluated to true.

1  prevValue := false
2  while (true) {
3    value := (stateCondition == true)
4    if (!prevValue && value) {
5      dispatchEvent('eventName')
6    }
7    prevValue := value
8    sleep(5)
9  }

And the event blocks add event listeners to the corresponding events, to execute blocks placed in the event blocks.

10 addEventListener('eventName', async function() { [block code] });

sleep(5) makes sure the asynchronous function returns to the call stack instead of staying in the event loop. But sleep(5) is also the reason the program I posted above is stuck after setting restart to true a second time.

Take a program like below (which is not running as expected either):

It is stuck, after outputting A B. What happens is:

1. The asynchronous loops of checking the state conditions of A and B are added to the callback queue (they're added to the call stack, whenever the call stack is empty and re-added to the callback queue each time sleep(5) is evaluated) and restart = true is added to the call stack (and as it is on the top of the stack, executed).
2. async check A is added to the call stack, detects a state transition (prevValue = false AND (restart == true) is true), dispatches an event (line 4-5), and sets prevValue to true.
3. The event listener of A is added to the call stack and executed (outputs "A" and sets restart to false)
4. The stack is empty, therefore the next item from the callback queue is added to the call stack. async loop B detects a state transition (prevValue = false AND restart == false is true), dispatches an event, and sets prevValue to false.
5. The event listener of B is added to the call stack and executed (outputs "B" and sets restart to true)
6. The asynchronous loops of A and B run in alternation, but no state conditions are met. (restart is true but prevValue in async check A is true too)

I visualized the Call Stack, Callback Queue, Variables, and Outputs of each of these steps in drawio

---

This can be worked-around by

• adding a sleep() in the handler to defer the handler to back of the callback queue. The program below executes like one would expect:
  
• Or by removing prevValue and changing line 4 of the state-conditions-check above to if (value) {. This would mean getting rid of the enters and exits options for BLAST events.
• Instead of writing the event-checks asynchronously, they could be injected after each line of code. But the checks could include operations waiting for device data, so this would drastically slow down execution.

None of these seem ideal. I'll keep thinking of a better solution

[derwehr]

The equivalent to this in Arduino programming would be the loop() function and (external) interrupts.
An Arduino Sketch consists of a setup() and a loop() function: The setup() function runs once at program startup
and the loop() function runs continuously.

The loop() function executes synchronously and can be interrupted. The Arduino compiler itself doesn't actively check for interrupts during the execution of the loop() function. Instead, the microcontroller on an Arduino board has built-in hardware for interrupt handling that works alongside the compiled code. When an interrupt is triggered the mircocrontroller jumps to the pre-defined interrupt service routing, pausing the loop() function.

To get similar behaviour in BLAST, the state conditions checks probably have to be processed in parallel, not just asynchronously.

[derwehr]

Unfortunately neither Web Workers nor Service Workers support WebBluetooth, see WebBluetoothCG/web-bluetooth#571 and WebBluetoothCG/web-bluetooth#422

[derwehr]

For now, the above bug is fixed by retrieving the current value in the async check again after dispatching the event. i.e. changing the above pseudo code to

 1  prevValue := false
 2  while (true) {
 3    value := (stateCondition == true)
 4    if (!prevValue && value) {
 5      dispatchEvent('eventName')
 6      value := (stateCondition == true)
 7    }
 8    prevValue := value
 9    sleep(5)
10  }

[derwehr]

Game loop

The simplest game loop model consists the 3 tasks depicted below.

Because of the different durations of these tasks, they usually are uncoupled as in the next diagram - the game engine constantly reads inputs and updates the game state, while the game is rendered in parallel.

Typically, game loop models add time measurements to the update task, which is applied in all calculations of the update task to ensure the program performs the same on different machines. Resulting in the model below:

See Valente, L., Conci, A., & Feijó, B. (2005). Real time game loop models for single-player computer games. In Proceedings of the IV Brazilian Symposium on Computer Games and Digital Entertainment (Vol. 89, p. 99).

Appliance to BLAST

When applying the models above to our problem, the tasks read input, and update can be mapped to the state condition checks and the render task the the rest of the BLAST programs, ideally running in parallel.
I don't think the time measurements performed in the update stage are necessary for BLAST programs. Its only benefit for the game loop is that rendered animations look the same on different machines.
Instead, in our case, it is probably best to immediately send an interrupt to the "render" task when an event occurs.
Resulting in the model below:

[derwehr]

An issue arising from parallel execution like in the last picture above would be the isolated contexts:
Typically, each of the uncoupled threads has its own isolated context and they only communicate via messages (there might be programming languages handling this differently). This prevents us from implementing a program with two threads, Thread 1 counting from 0 to 9 and Thread 2 emitting an event each time the counter is event, i.e.:

Thread 1

counter := 0

while (counter < 10)
  increase counter by 1

Thread 2

while (true)
  if (counter is even number)
    dispatch event "even"

[derwehr]

An issue arising from parallel execution like in the last picture above would be the isolated contexts: Typically, each of the uncoupled threads has its own isolated context and they only communicate via messages (there might be programming languages handling this differently). This prevents us from implementing a program with two threads, Thread 1 counting from 0 to 9 and Thread 2 emitting an event each time the counter is event, i.e.:

Thread 1

counter := 0

while (counter < 10)
  increase counter by 1

Thread 2

while (true)
  if (counter is even number)
    dispatch event "even"

Plus, in WebBluetooth GATT read and write operations can not be executed in parallel, they have to be queued (See WebBluetoothCG/web-bluetooth#188)

[derwehr]

• When a BLE GATT characteristic does neither offer the notify nor the indicate service, it has to be polled to detect events ( ⚡ fast polling kinda contradicts the BLE efforts to keep energy consumption low)
• On WebBluetooth polling multiple devices does not work in parallel, they can only be queued
• In NodeJs we can poll BT devices in parallel, but the polling-threads can not access any information from other threads, therefore they'd be polling threads only and the state-updates and event-checks would have to run in another thread receiving the results of all polling threads (pretty much the same as BLE Gateways sending device data streams, processed by (complex?) event detection processors)