(Does that block have a name?)
This is good for two reasons:
* it just makes sense to have floor and ceiling together
* It's a minor thing for scratch 2 parity.
* it doesn't clutter anything. 😁
For some reason the function wasnt properly catching errors and was instead rasing native
JS errors. This fixes that bug, so the function will now report nothing when it doesnt know
what to do.
In addition, moving the variable `dateMap` inside the function reduces a global variable, which
shouldnt affect anything other than keeping the code clean. :)
make sure to always evaluate the “report” block’s input, even if used
inside a custom command definition, because hardware extensions (and
other reporters with side-effects) rely on it.
“stop this block” when used inside a custom block definition now always
returns out of the lexically enclosing script (the definition), even if
it is used inside other nested, C-shaped custom blocks in the
definition code. Previously it only stopped the nearest encompassing
“for” block, now it always stops the block whose definition it is in.
I don’t expect this fix to break any existing projects.
REPORT now reports to the nearest lexical element expecting an input
(which may not be the block holding the REPORT statement, this lets you
REPORT out of nested FOR loops).
STOP THIS BLOCK behaves as it used to.
If you’ve been using REPORT instead of STOP THIS BLOCK, you should
migrate.
* Split by whitespace now uses the built-in definition of whitespace \s
This catches all characters definted as whitespace, see below:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp
* Split a line by all unicode compliant line breaks. The biggest impact here is
that OSX and Windows files will now split the same way.
The cr option is still around, but ther's no longer a need for it, IMO.
enables reporting and stopping a bock from within a C-shaped slot in a
custom block, but not (yet) out of nested C-shaped custom blocks (but
that’s coming up, too)