Hi again.
I'm going to teach teachers to code in Scratch and I want to be properly prepared. I have a month on me, so it's ok if there is a lot to read.

I'm wondering how Scratch executes code when there are several unconnected piles/groups of code in the editor. I often see this with children, but also new beginner adults code like that.

I got some links from our Norwegian group of Teach Kids To Code, but I'm currious if there's more.

Thanks in advance.

If you're willing to do some major digging around, the Scratch source code is available here.

As far as I know (though I may be wrong), Scratch will run one block from every script each tick. Let's say I had these scripts:

when green flag clicked
go to x: (0) y: (0)
forever
  move (10) steps
end

when green flag clicked
forever
  turn cw (25) degrees
end

When the green flag was clicked, Scratch would run the first block of the first script (go to 0, 0). Then it would find the next running script (the second one) and run the first block there. I think loops such as forever and repeat count as blocks, so nothing would really happen, except that the loop would start.

Next, Scratch would go back to the first script and look at the next block (forever) and run that (again doing nothing). Then Scratch would move to the next running script and run the next block in line (turn 25 degrees).

Scratch would then jump back to script one and move 10 steps, then go to script 2 and turn 25 degrees. It would continue to alternate between moving and turning for the rest of the project.

Again, I'm not 100% sure that what I'm saying is accurate. (But I think it is.)

The tricky part is that the order in which scripts are run (which is run first, the one with the move block or the turn block?) is difficult to pin down. I've played around with it before, and it appears that whichever script is nearest to the top of the editor (remember, Scratch lets users place scripts wherever they would like) goes first. In other words, scripts are run from top to bottom, with no concern for their x location.

Again, things get more complicated: When there are multiple sprites involved, it's tricky to know which will fire first.

One last note: Custom blocks with “run without screen refresh” checked are treated as just one block in the execution order, which further increases the confusion.

Fortunately, the users who program in this way (rather than using, for example, broadcasts) are generally making projects simple enough that it really doesn't matter the order in which events are fired.

I think I'll go play around with this and see if I can learn anything new…

Here's the folder with all the code for the interpreter -

https://github.com/LLK/scratch-flash/tree/master/src/interpreter

You might want to read the comments at the top of the files for a more detailed description

PullJosh wrote:

If you're willing to do some major digging around, the Scratch source code is available here.

As far as I know (though I may be wrong), Scratch will run one block from every script each tick. Let's say I had these scripts:

when green flag clicked
go to x: (0) y: (0)
forever
  move (10) steps
end

when green flag clicked
forever
  turn cw (25) degrees
end

When the green flag was clicked, Scratch would run the first block of the first script (go to 0, 0). Then it would find the next running script (the second one) and run the first block there. I think loops such as forever and repeat count as blocks, so nothing would really happen, except that the loop would start.

Next, Scratch would go back to the first script and look at the next block (forever) and run that (again doing nothing). Then Scratch would move to the next running script and run the next block in line (turn 25 degrees).

Scratch would then jump back to script one and move 10 steps, then go to script 2 and turn 25 degrees. It would continue to alternate between moving and turning for the rest of the project.

Again, I'm not 100% sure that what I'm saying is accurate. (But I think it is.)

The tricky part is that the order in which scripts are run (which is run first, the one with the move block or the turn block?) is difficult to pin down. I've played around with it before, and it appears that whichever script is nearest to the top of the editor (remember, Scratch lets users place scripts wherever they would like) goes first. In other words, scripts are run from top to bottom, with no concern for their x location.

Again, things get more complicated: When there are multiple sprites involved, it's tricky to know which will fire first.

One last note: Custom blocks with “run without screen refresh” checked are treated as just one block in the execution order, which further increases the confusion.

Fortunately, the users who program in this way (rather than using, for example, broadcasts) are generally making projects simple enough that it really doesn't matter the order in which events are fired.

I think I'll go play around with this and see if I can learn anything new…

Close, but the forever block doesn't count as a block until the end. Then the restarting of the loop is one block

Oops! I've done a little bit of testing, and it appears that the order of execution is not based on y position, but instead on which scripts were moved in the editor most recently.

Strangely, editing the script doesn't affect the order. Only moving it.

The more I play with this, the more I realize just how pointless it is to even try to understand how this all works.
I have these scripts:

when green flag clicked  // This one was moved most recently
set [test v] to [2]

when green flag clicked
set [test v] to [1]
set [test v] to [0]

And the variable test is being set to 2.
No matter what the order is, shouldn't test be set to 0? Apparently not.

PullJosh wrote:

The more I play with this, the more I realize just how pointless it is to even try to understand how this all works.
I have these scripts:

when green flag clicked  // This one was moved most recently
set [test v] to [2]

when green flag clicked
set [test v] to [1]
set [test v] to [0]

And the variable test is being set to 2.
No matter what the order is, shouldn't test be set to 0? Apparently not.

I don't know why it's being set to 2 but I'm pretty sure that some blocks refresh the screen (i.e. yield) and others don't.

liam48D wrote:

I don't know why it's being set to 2 but I'm pretty sure that some blocks refresh the screen (i.e. yield) and others don't.

I actually thought so as well, so I tried this script:

when green flag clicked // Again, this was moved most recently
set [test v] to [2]

when green flag clicked
change x by (10)
set [test v] to [0]

But it didn't make any difference.

I have done some work on porting the Scratch project player to C, so I think I have a decent an understanding of how Scratch works.

As PullJosh said, the source code can be viewed with your browser here. The most important file to understanding how Scratch runs Scratch projects is Interpreter.as.

I'll explain how Scratch handles separate stacks of blocks at once, since that seems to be your main interest.

Scratch keeps a list of running threads. When a hat block is triggered, a new thread for the block stack under that hat block is added to the list of running threads. Then, Scratch goes through each thread in the list of running threads one at a time.

For each thread, first Scratch sets the ‘active thread’ to that thread. Then, it executes each block one by one in the stack for the active thread. It will execute the entire stack all in one go if it can. Certain conditions cause Scratch to stop executing the current thread in the middle of the stack and to move on to the next thread.

Here are the rules that determine whether or not Scratch will switch to executing another thread/stack of blocks:

• At the beginning or end of a loop, like a ‘forever’ or a ‘repeat (n)’, Scratch will switch threads.
  
• In custom block set to ‘run without screen refresh’, Scratch will not switch threads, even if it encounters a looping block, unless the custom block has been running for more than half of a second.
  
• Certain other blocks cause Scratch to switch threads. These are 'stop [all]', ‘wait until <>’ when the condition is false, 'broadcast [] and wait', 'switch backdrop to [] and wait', ‘next backdrop’, 'stop [this script]' when inside a custom block definition, and custom blocks when set to ‘run w/o screen refresh’ and called recursively(inside their own definition).
  
• Some extension blocks cause Scratch to switch threads.
  

Event with these simple rules, Scratch is still usually able to run all threads in a 30th of a second, because a single sequence of blocks that doesn't contain a looping block almost never takes a significant amount of time to execute each block in it.

And, of course, when the end of the stack for a thread is reached, that thread is removed from the list of running threads.

I hope I was clear, and good luck teaching Scratch!

PullJosh wrote:

liam48D wrote:

I don't know why it's being set to 2 but I'm pretty sure that some blocks refresh the screen (i.e. yield) and others don't.

I actually thought so as well, so I tried this script:

when green flag clicked // Again, this was moved most recently
set [test v] to [2]

when green flag clicked
change x by (10)
set [test v] to [0]

But it didn't make any difference.

Defining the order in which scripts are executed is kinda pointless. And confusing.

Znapi wrote:

In custom block set to ‘run without screen refresh’, Scratch will not switch threads, even if it encounters a looping block, unless the custom block has been running for more than a second.

Not particularly important, but I thought it was 1/2 second?

Znapi wrote:

Defining the order in which scripts are executed is kinda pointless. And confusing.

Yes and no. It's a relevant factor which could certainly affect how projects are run. Knowing how it works could come in handy.

Of course, it's probably easier to just write “good” code than it is to figure out the technicalities of how it all works. Still fun to work out though.

PullJosh wrote:

Znapi wrote:

In custom block set to ‘run without screen refresh’, Scratch will not switch threads, even if it encounters a looping block, unless the custom block has been running for more than a second.

Not particularly important, but I thought it was 1/2 second?

Znapi wrote:

Defining the order in which scripts are executed is kinda pointless. And confusing.

Yes and no. It's a relevant factor which could certainly affect how projects are run. Knowing how it works could come in handy.

Of course, it's probably easier to just write “good” code than it is to figure out the technicalities of how it all works. Still fun to work out though.

But there is no reference to which script was moved last in the json!

It must be cached in a flash variable.



Anybody feel like testing, restarting and testing again?

PullJosh wrote:

Znapi wrote:

In custom block set to ‘run without screen refresh’, Scratch will not switch threads, even if it encounters a looping block, unless the custom block has been running for more than a second.

Not particularly important, but I thought it was 1/2 second?

I've observed it to be 1 second. I haven't set up a proper test though.

Znapi wrote:

PullJosh wrote:

Znapi wrote:

In custom block set to ‘run without screen refresh’, Scratch will not switch threads, even if it encounters a looping block, unless the custom block has been running for more than a second.

Not particularly important, but I thought it was 1/2 second?

I've observed it to be 1 second. I haven't set up a proper test though.

Here it is. 500 ms.

PullJosh wrote:

Znapi wrote:

PullJosh wrote:

Znapi wrote:

In custom block set to ‘run without screen refresh’, Scratch will not switch threads, even if it encounters a looping block, unless the custom block has been running for more than a second.

Not particularly important, but I thought it was 1/2 second?

I've observed it to be 1 second. I haven't set up a proper test though.

Here it is. 500 ms.

Ok, I'll fix my post. I'm not sure why it appears to be 1 second in my project.

Have fun finding the order of script execution btw, if you are still doing that.

I just did some research on what other blocks cause a ‘yield’/thread switch and updated my post again.

Dylan5797 wrote:

But there is no reference to which script was moved last in the json!

The order of the scripts in the JSON array are what determine the execution order.

I believe you will find that this highly technical simulator answers all your questions about threads and flow of control.

MathWizz wrote:

Dylan5797 wrote:

But there is no reference to which script was moved last in the json!

The order of the scripts in the JSON array are what determine the execution order.

But why does modifying bring them to the front?

Dylan5797 wrote:

MathWizz wrote:

Dylan5797 wrote:

But there is no reference to which script was moved last in the json!

The order of the scripts in the JSON array are what determine the execution order.

But why does modifying bring them to the front?

Modifying or moving a script likely results in it being removed and replaced at the front of the array.