Scratch, Inconsistent behavior of how data are sent to remote sensor protocol

Related to the scratch optimizations performed by Tim Rowledge the last weeks,  I have investigated my scratchClient and removed some bottlenecks. In some cases, it used more CPU as scratch itself. Now, the ping-pong-performance test runs in 50ms for one cycle.

When you do things like this, the next question is whether all values are handled correctly. This is the starting point for the following experiments.

You do not need a sophisticated test software to execute the experimennts. A simple “telnet localhost 42001” just displays what is going on, at least the send-to-the-outside part of the story. You need to enable the remote server inside scratch first. Do this by /sensing / rightclick on ‘slider’ sensor value / enable remote sensor connections. In current scratch, you need to disable this first, then enable. In nuScratch or in windows, just enable. I repeated these things on windows, where I used putty in raw mode for the telnet part.

Be careful in typing in characters into the telnet session. Scratch will try to interpret these for the protocol. After some characters, you receive an squeak error popup. There is no recovery, you need to restart scratch then. Think there is no robust error recovery strategy for the receiver part of the protocol, but this is not the topic here.

Make a global variable ‘for all sprites’, named ‘a’. The name does not matter, but ‘a’ is simple and short for now.
Run the following script:

When a was ‘0’ initially, you receive
sensor-update “a” 1 sensor-update “a” 2 sensor-update “a” 3
This is ok.

Next sample:

The result is
sensor-update “a” 2
Which is not very good. The intermediate separate set-values are ignored. When repeating the execution, there are no more sensor-updates sent out.

Now add wait statement to the script.

Now the result is
sensor-update “a” 0 sensor-update “a” 1 sensor-update “a” 2
This is as expected. This also works, when the delay is set to ‘0’.

Some change-by-blocks in a sequence do behave even different. The last value is propagated.
This is done to find out if the ‘change by’ block has special handling.

The result is, when executed multiple times
sensor-update “a” 44 sensor-update “a” 47 sensor-update “a” 50 sensor-update “a” 53
So only every third update is propagated.

Last one, embrace “each set a to something” in a while(1)-loop

This results, as expected, are
sensor-update “a” 66
sensor-update “a” 67
sensor-update “a” 68
sensor-update “a” 69
sensor-update “a” 70
sensor-update “a” 71

Conclusion

Sensor protocol sends out multiple updates in a sequence only when control blocks are in between. Multiple update blocks in a sequence seem to get optimized in a strange way, and not consistent for ‘set value’ and ‘change-value’.
This is same behavior in win-1.4-scratch and RPi-1.4-scratch and RPi-1.4-beta.

My original assumption was, that there is a ‘previous-value’ for each variable, and when a change is detected, then the value is propagated. Current implementations do not work this way.

Current behavior is difficult to explain for kids working with scratch.