There is a very elusive bug in Scratch 3 that might have to do with changed initialization compared to Scratch 2. I hope someone has a clue about what this bug could be due to, because I have investigated it for a long time and not found out what causes it.

Project URL(s):
https://scratch.mit.edu/projects/137676871/
Starting FORTH Calculator Screen Keyboard
Last changed: 22 Dec 2016

Error message displayed (if any):
Not error messages from Scratch, but from the program itself. Gives error messages in Scratch3, but not in Scratch2.

Browser version & Operating System this happens in:
My browser / operating system: Linux, Chrome 65.0.3325.181, Flash 32.0 (release 0)
Chromium Version 65.0.3325.181 (Official Build) Built on Raspbian , running on Raspbian 9.6 (32-bit).
It's the most updated Raspbian running on a Raspberry Pi 3 B.

My browser / operating system: ChromeOS 11151.113.0, Chrome 71.0.3578.127, No Flash version detected
It's most updated HP Chromebook 11 G5 EE.

My browser / operating system: Windows NT 10.0, Chrome 73.0.3683.86, No Flash version detected

My browser / operating system: Windows NT 10.0, Firefox 66.0, Flash 27.0 (release 0)

What browser extensions do you have installed (if any)?:
uBlock Origin (Chrome)
Adblock Plus (Firefox)

Description / other details of the behavior you see:
It should start as in this video from Scratch2:
https://youtu.be/FwEgRetggFg
In Scratch 3 it doesn't compile the code, but instead shows its own error messages about undefined words. It's the colon definitions that don't work.

It still works on https://phosphorus.github.io/#137676871 .

If I save to my computer from online Scratch 3 and convert it from sb3 to sb2 it doesn't work in the Scratch 2 Offline Editor (same error as in Scratch 3), but I've found out that if I add another INIT under when GreenFlag clicked it works in the Scratch 2 Offline Editor. Even if I have two or three INITs in Scratch 3, it doesn't work there. Summary: It doesn't work in Scratch 3 even if I modify it and Scratch 3 trashes the project somewhat, but I can fix it using INIT twice so that I can run it in the Scratch 2 Offline Editor after converting it from sb3 to sb2 using a utility.

Can you send over the error message and what programme is kicking it out? Thanks.

Banana

It gives error message “MSG # -13” in Scratch 3, but it works in Scratch 2 on Phosphorus. You have to try the links in the first post and compare to see the difference. This “MSG # -13” is the project's own message about that the word was not found because the definition didn't work. I don't know why this piece of the code (colon-definitions) doesn't work in Scratch 3, but works in Phosphorus and it used to work on scratch.mit.edu before Scratch 3, i.e. during the Scratch 2 era. I just asked here to see if anyone has any ideas.

It would probably need an expert on the Scratch 3 JavaScript code to solve this.

It's caused by a bug in Scratch 3 to do with broadcast-and-wait containing an expression that changes its value while the receiver scripts are still running.

See here for more info: https://github.com/LLK/scratch-vm/issues/2109

The quick way to work around it for now is to create new vars especially for each broadcast-and-wait expression (e.g. replace "broadcast join [rt] (code) and wait“ with ”set newvar to (code)“ / ”broadcast join [rt] (newvar) and wait", and ensure that newvar does not change while the receiver scripts are running – in fact, it looks like that's the only one that causes the problem, since everything ran fine for me once I made that change).

Hope that helps!

TheLogFather wrote:

It's caused by a bug in Scratch 3 to do with broadcast-and-wait containing an expression that changes its value while the receiver scripts are still running.

See here for more info: https://github.com/LLK/scratch-vm/issues/2109

The quick way to work around it for now is to create new vars especially for each broadcast-and-wait expression (e.g. replace "broadcast join [rt] (code) and wait“ with ”set newvar to (code)“ / ”broadcast join [rt] (newvar) and wait", and ensure that newvar does not change while the receiver scripts are running – in fact, it looks like that's the only one that causes the problem, since everything ran fine for me once I made that change).

Hope that helps!

Great! Thank you for your clarification!

Banana

TheLogFather wrote:

It's caused by a bug in Scratch 3 to do with broadcast-and-wait containing an expression that changes its value while the receiver scripts are still running.

See here for more info: https://github.com/LLK/scratch-vm/issues/2109

The quick way to work around it for now is to create new vars especially for each broadcast-and-wait expression (e.g. replace "broadcast join [rt] (code) and wait“ with ”set newvar to (code)“ / ”broadcast join [rt] (newvar) and wait", and ensure that newvar does not change while the receiver scripts are running – in fact, it looks like that's the only one that causes the problem, since everything ran fine for me once I made that change).

Hope that helps!

Thanks for finding the bug and the workaround! How did you find it? It seems to be a difficult bug to discover.

It's strange that join doesn't produce a new string that is unaffected by changing the variable that was joined after it was joined.

I did not change my original project because I think that would break it in Phosphorus. I will make a new project that works in Scratch 3.

The new version of #MOBLuSE_FORTH for Scratch 3 is here:
https://scratch.mit.edu/projects/302444111/

mobluse wrote:

Thanks for finding the bug and the workaround! How did you find it? It seems to be a difficult bug to discover.

Yeah, took a bit of digging – I don't tend to spend as much time on Scratch these days, but when I saw this and ran it, I could tell there was something unusual going on that was specific to Scratch 3, and it'd be a case where I might be able to help.

After cutting down what it was doing (so it went straight to the first problematic command during the init phase), and inserting a few debugging blocks here & there to keep track of things, it didn't take long for me to come to the realisation that it was running two specific scripts simultaneously that were meant to be doing things in serial, and it became clear the broadcast-and-wait was the root cause, due to it finishing early – and, looking at the var used in the expression, the reason that came to mind was that it was because the var was changing in the other script, etc.

Creating a quick-n-simple test project (same as given in the github issue) verified that really was a glitch.


BTW, one other potential issue I came across in your scripting is that the “in_definition” var isn't getting reset to zero on init (or error), and that causes trouble the next time you start running it (or run another command?) –The next definition gives an error (even after restart), because it doesn't get to start a new definition at the beginning of the “make_word” custom block script since “in_definition” is already set to one.

(I suspect this might be the cause of the other problems you mentioned above, which you worked around with the extra init.)

Thanks again for helping me out.

TheLogFather wrote:

BTW, one other potential issue I came across in your scripting is that the “in_definition” var isn't getting reset to zero on init (or error), and that causes trouble the next time you start running it (or run another command?) –The next definition gives an error (even after restart), because it doesn't get to start a new definition at the beginning of the “make_word” custom block script since “in_definition” is already set to one.

(I suspect this might be the cause of the other problems you mentioned above, which you worked around with the extra init.)

Thanks! I added two

set [in_definition v] to [0]

One to the beginning of INIT and another to when MSG # 13 (unknown word) is printed. There was already one at the end of INIT.