Open janwilmans opened 7 years ago
in 1c665634da83ed342ce45bd5f958067d6fde33cf I have modified the runtime to output this instead:
<external>.arm -> .alarm.console.arm [enter] [0, 0]
sensor enabled
<external>.arm <- .alarm.console.arm [leave] [1, 0] (return)
<external>.triggered -> .alarm.sensor.triggered [deferred] [1, 0]
Detected!
siren on!
This looks easier to understand to me, but that will have to be confirmed.
97e17ffc9e297eb14d9f41cdd996a882da4a795d adds human readable state:
<external>.arm -> .alarm.console.arm [enter] [Disarmed, false]
sensor enabled
<external>.arm <- .alarm.console.arm [leave] [Armed, false] (return)
<external>.triggered -> .alarm.sensor.triggered [deferred] [Armed, false]
Detected!
siren on!
17c161c2aeec9db0defce9d29ab90068516adcae adds threadid's
<external>.arm -> .alarm.console.arm [enter] [Disarmed, false] (tid: 11512)
sensor enabled (tid: 11512)
<external>.arm <- .alarm.console.arm [leave] [Armed, false] (return) (tid: 11512)
<external>.triggered -> .alarm.sensor.triggered [deferred] [Armed, false] (tid: 11512)
Detected! (tid: 11512)
siren on! (tid: 11512)
Not very exciting for this single threaded example. But extremely useful to see the context switches in multi threaded applications.
q: is there a way to generated code with a thread-safe-shell from the eclipse environment?
I've added [trace_in] and [trace_out] to the messages here: