Part of the motivation for this test is to verify compatibility with
Scratch 2.0 / SB2 behavior, so we shouldn't change the project to an SB3
file without very good reason.
Sometimes load causes the VM to run more slowly, especially with
parallel tests. This change allows the wait block a little extra wiggle
room to account for that. Ending early is still tested with a fairly
strict threshold.
Newer versions of `tap` run more asynchronously, so sometimes using `process.nextTick(process.exit)`
to end a test would prevent the test from completing correctly. Removing all instances of
`process.nextTick(process.exit)` put tests into three categories:
* the test still worked correctly -- no fixup needed.
* the test would hang because the VM's `_steppingInterval` was keeping
Node alive. These tests call a new `quit()` method which ends the
stepping interval.
* the `load-extensions` test needed special attention because the "Video
Sensing" extension starts its own loop using `setTimeout`. I added a
`_stopLoop()` method on the extension and directly call that from the
test. I'm not completely happy with this solution but anything more
general would likely require a change to the extension spec, so I'm
leaving that as a followup task.
As part of simplifying the CI setup I plan to not explicitly specify
`--jobs=4` to `tap` going forward. Upgrading to a newer version of `tap`
means that it will automatically parallelize jobs according to available
CPU count, which should be better anyway. Only one of our tests was
incompatible with newer versions of `tap`, so this commit includes a
compatibility fix there.
Also, by default newer versions of `tap` calculate coverage and consider
the test run to fail if below the configured thresholds. The default is
100% coverage and we're not there, so I adjusted the thresholds to match
where we're at for now. We can ratchet those up over time.
- Add pointer member to thread. This is the current executing block.
- Add stackFrame member to thread. This is the current frame
information like procedure parameters.
This is a step potentially towards stack-less threads. With further
modifications we could have stack and stackFrames be null if a script
does not call a procedure.
