As part of reusing the block utility object, asynchronous say block
functions cannot use the utility in a promise or timeout asynchronous
handle. Store the needed target reference so utility is not needed
later.
blockUtility as an object literal inside execute creates 11 objects,
one for the object, and 10 for the function closures. As a separate
object and allocated once, setting its sequencer and thread members,
block functions can share the same util object. Extract blockUtility to
cut down on allocations.
`handleReport` inside `src/engine/execute.js`'s `execute` method needs
to allocate a closure to be able to refer to the higher scoped
variables. `execute` is called frequently that this has a noticable
impact on memory allocation and later collection. Extract handleReport
and add arguments to prevent the allocation.
Testing with implicitly casted `value` and `value.then` is deoptimizing
isPromise, which deoptimizes execute. In this case deoptimizing means
that the JavaScript VM cannot compile the functions into a form that
can be run faster.
Remove indexOf tests for thread existence in doneThreads. Maintain a
list of null and thread objects mirroring the index position of threads
that are done in runtime.threads. Filter out null values after
filtering out done threads from runtime.threads.
This has a small side effect that threads that normally became DONE and
were added to doneThreads before being removed or restarted will not be
in doneThreads in this version. Restarted threads (_restartThread) do
not appear in this version but new copies will be in Runtime
this.threads supporting glow and monitor updates. Removed threads
(_removeThread) do not appear in this version if they are removed after
they were seen as DONE by the prior version. Threads removed before
they are seen as DONE do not appear in doneThreads in the prior or this
version.
Threads that are removed before normally becoming DONE do not appear in
doneThreads in either case. Threads that are restarted before the loop
checks if the thread is done do not appear in doneThreads in either
case.
- Accumulate extension info while deserializing JSON
- Install extensions (if any) before installing target(s)
- Merged 'install' steps of the "add sprite" and "load project" paths
Since we will only have builtin extensions for a while, the
more-complicated, watchdog-based extension duplication prevention has
been replaced with one that treats the extension URL as equivalent to
the extension ID. This is true only for built-in extensions, so once we
start supporting third-party extensions we will likely need to bring
back the watchdog (commit e4381b4693) and
the more-complex duplication prevention (commit
670e51d335).
The code here should be treated as a last resort: ideally the GUI should
check if a particular extension is loaded (maybe by calling the
Extension Manager's new `isExtensionLoaded` method) and avoid calling
`loadExtensionURL` if it is.
If an extension attempts to register with the same ID as another
extension which has already registered, the new registration is refused.
If the extension is in a worker and no other extension is successfully
registered by that worker, the watchdog system will terminate the
"empty" worker.
If an extension worker does not complete initialization in a reasonable
amount of time (currently 15 seconds) then the worker will be
terminated. A complete initialization includes registering an extension.
* Playground: use UMD to load storage as global
It appears that `expose-loader` is not compatible with WebPack's UMD
exporter, so the VM playground broke when I converted `scratch-storage`
to use UMD. This change causes the playground to load `scratch-storage`
as an independent script and relies on its UMD loader to expose it as a
global. Bonus points: we get better source mapping this way.
* Playground: tell eslint about global ScratchStorage
Due to a typo (I believe) we were overwriting a horizontal hat block's
fields list when collecting hat block inputs. Now we collect inputs into
a temporary object in this case.
Dynamic menus are not yet supported for extension menus, though they are
part of the extension spec. This change provides more thorough feedback
if an extension tries to register an unsupported dynamic menu.
- Remove WeDo 2 extension from the runtime's default block packages list
- The WeDo 2.0 extension now calls its own `connect` method on startup
I also renamed `EXTENSION_NAME` to `EXTENSION_ID` for consistency with
the rest of the extension system.
This prevents generation of invalid XML due to characters like '<' or
'>' in fields' default values. Unfortunately the value comes back in its
escaped form, so there's still more work to be done.
WeDo2 and Pen blocks have been converted to internal extensions, and can
now be loaded by giving `loadExtensionURL` the string 'pen' or 'wedo2'
instead of an actual URL.
The new `_registerInternalExtension` method on the extension manager
will register an extension object (an object with a `getInfo()` method)
with the extension system without sandboxing the object in a Worker.
When asked to load an extension, the Extension Manager starts up a new
Worker. That worker runs the message dispatch system as well as an
instance of the new `ExtensionWorker` class, which will load the desired
extension and register it with the extension system.
Extensions, placed in `./src/extensions/*.js`, are now processed by
Webpack as separate entry points and packed into an `extensions`
subdirectory in the output.
Still to do: query an extension's information, including the blocks it
provides, and register that information with the VM, GUI, etc.
Wrapping of the value is now handled by a new function, _wrapTransparency;
_updatePenColor now handles the transparency value;
DEFAULT_PEN_STATE now includes a transparency value (100).
* Add glide to dropdown block
* Use helper functions instead of copy-paste
* Wrong syntax for array 😒
* Aha
* Fix some Travis issues
* Aha!! This should work
* Wow, Travis is strict about spacing!
* Make requested changes
Rename function getTarget to getTargetXY
Rename parameter TO to targetName
Inferring from the issue, the maximum seems to be 100, not 255 (default for set is 50 and change is 10). Changed that.
A comment line was too long (thanks lint) so it has now been reworded.
Central dispatch and worker dispatch share most of their code now by
inheriting from a new shared dispatch class.
Also, the format of passed messages has been altered to make it easier
to understand in a debugger.
This allows a service to postpone communication with other services
until it can be sure that it's registered with central dispatch. Service
registration on the main thread always happens immediately, but that
version of `setService` still returns a Promise for consistency.
The tests run using TinyWorker, which emulates web workers on Node.
There are quite a few quirks in that situation due to the differences
between Node and Webpack as well as the differences between TinyWorker
and real Web Workers.
The tests also exposed a few bugs in the dispatch system, which have now
been fixed. Most notably, if a method called through the dispatch system
throws an exception that exception will now be passed back to the
caller. Previously the exception would escape the dispatch system and
the caller would never hear any response at all.
This message dispatch system allows a "service" to register itself under
a particular name, and then anyone can call any method on that service
from any context (the main "window" thread or any worker). Return values
are passed back through promise resolution.
If the `dataFormat` field is absent, fall back on the older `assetType`
field. That can at least help us tell if something is a vector or bitmap
image, though it doesn't tell us which kind of bitmap.
The `dispose()` method on `RenderedTarget` now:
- informs the runtime that it should end any threads corresponding the
target being disposed, and
- removes the clone from its sprite.
