Scratch

nXIII wrote:

When a hat already has a process attached, it is replaced by the new process (at the beginning of the script, regardless of the previous process's position).

I feel like this is not the correct way Scratch should work. Not because it is wrong, but because this is not how people intuitively think it works. Even if re-entrancy works quite well almost for everything (3.000.000 projects can't be wrong...) I think that a sprite should be able to do something even if its hat is called again. And this without having to use "unnatural" variables. Maybe adding a "do not disturb" check button to hats (something reminiscent of BYOB's "atomic" check button) would make sense?

What do you think guys?

Yeah, it seems it should at least run the script at least until the first time it yields, for as many times as the broadcast is sent.

Jens wrote:

yielding doesn't have anything to do with aborting a thread, it's just a way of cooperating nicely 

I was thinking of the way Scratch runs the script until it gets to the bottom, or the bottom of a loop... what do you mean? I want to understand 

The right way to think about this, of course, would be to have first-class threads 

First-class threads? How would that work? O_o

s_federici wrote:

Digimath wrote:

So, then, the trick is to have each cow release control a different number of times before calling the score routine

Wow!!!!!!!!!!!! This is really cool! And, I shouldn't say this but I will say it: I knew there was a non-variable-based way of getting this result! It works incredibly well. I says incredibly as it is not really clear to me why it does work    Any further detail/example?

As Jens put it, the scripts are yielding in a cooperative manner.  The different number of wait blocks per cow should mean that they are each doing a broadcast to the score script in a different dispatch loop instead of all doing it in the same loop.  I’ve never used this this technique before.  This is probably the hard way to control script priority – but an interesting study.

Hardmath123 wrote:

Jens wrote:

Well, ideally if you run a script you don't want it to stop executing unless it decides to do so itself. So force-aborting it when an event happens usually isn't what you would expect at all, regardless of whether that happens at the end of a loop or within a wait block. You want it to execute all the way and not kill it in between.

So why doesn't that happen?

What about running a clone of that script every time it is called? As long as it doesn't conflict with itself, it should work, right?

If the same script could run in multiple "threads", the block flashing for single stepping would become meaningless/intensely confusing. 

s_federici wrote:

Do you have a full list of all yielding blocks?

Here:

Timed blocks (yield every frame including the final one):
<glide () secs to x: () y: ()>
<say () for () secs>
<think () for () secs>
<play sound () until done>
<play drum () for () beats>
<rest for () beats>
<play note () for () beats>
<wait () secs>
<wait until ()>
<broadcast () and wait>
<ask () and wait>

Special forms (yield after each loop iteration but don't yield when done):
<forever>
<repeat ()>
<forever if ()>
<repeat until ()>

Jens wrote:

Hardmath123, a Scratch script is a thread, not a procedure. As such there can always only be a single instance, unless you fork it.

No—a Scratch script is a set of instructions, and it has a one-to-one relationship with a thread wrapping that set of instructions; when this relationship maps to a non-null, running thread, the script is outlined in white. This relationship's cardinality could be changed to one-to-many, but it would be tricky to display feedback for that.

Last edited by nXIII (2013-01-11 17:26:42)