isWhiteSpace works by trimming the entire string. This works, but in the
context we use it, this is a lot of unnecessary work.
At this point we know that `+x === 0` and we want to know if that's
because x is empty or because it actually contains 0, hence we can use
a loop that just checks for a 0 existing in the string. This relies on
the assumption that there is no x such that:
+x === 0 && x.trim().length !== 0 && !x.includes('0')
In a very biased microbenchmark (https://scratch.mit.edu/projects/788352711)
this results in a 10% performance improvement.
This also will allow us to resolve https://github.com/TurboWarp/scratch-vm/issues/115
in a later commit.
If the URL is already loaded, resolve immediately.
Fixes https://github.com/TurboWarp/scratch-gui/issues/637
Caused by TWStateManager repeatedly calling loadExtensionURL on locale
change.
This could be fixed in GUI, but fixing it in VM is easier and loading
multiple instances of the same extension doesn't make sense anyways.
If the compiler's type analysis becomes smarter, being able to show that
its output matches what is expected will become more important. Snapshot
testing is how we will solve that.
This is a breaking change.
Replaces logic that was previously in our scratch-gui fork.
Upstream does the opposite; they disable cloud variables when video
sensing is used. We can't do the same because of custom extensions.
Disabling all custom extensions when video sensing is used would be too
limiting. The concern with custom extensions is not that they will steal
private skins, but that a project could use their blocks to fetch()
color information to a remote server similar to cloud variables.
The end result is not dissimilar: Cloud variables and video sensing
shouldn't be used together.
The parameters didn't work in the way that you would expect. Only the
values provided in the first call to addAddonBlock would do anything,
and this gives a false impression that this will color the blocks in the
editor. Color options may be re-added in the future as part of a more
significant API update.
Promises worked fine, but if the block set status to STATUS_PROMISE_WAIT
without returning a promise (as some addon blocks do), the compatibility
layer would do the wrong thing. This doesn't matter right now, but it
will in a follow-up commit.
GarboMuffin