Rather than assuming that the storage instance will be attached to a VM,
just return it. Callers may attach it to a `VM` or (in the case of
`import_sb2.js`) to a `Runtime`.
This new test verifies that clones and their associated threads are
cleaned up properly by the `delete this clone` block. The clones run two
stacks each: one which waits and then deletes the clone, and another
which includes a `forever` loop: this is to verify that the thread
running the `forever` loop is ended when the clone itself is deleted.
The project does this with two batches of clones to ensure there are no
problems with reusing array indices previously occupied by now-removed
threads or clones.
* Add costume dataURI to costumes from storage
Towards #515, LLK/scratch-gui#279
* Fix tests
* Load costumes incrementally
Some of our tests assume that at least some of our costume data is available before the costume data is loaded. So, provide as much costume data as is available.
* Remove unnecessary filter for null costumes
Resolved when we updated to load costumes incrementally.
/ht @cwillisf
- Attach the storage module to the VM for tests which load projects or
other assets.
- Move `import_sb2.js` from `test/unit/ into `test/integration` since it
now depends heavily on `scratch-storage`.
- Skip loading costumes when there is no renderer.
