Integrate SimulationStudio

[LinqLover]

This PR switches the existing simulation features of Sandblocks to SimulationStudio. Concretely, this affects the following classes:

• SBStSandboxSimulator: Switched to SimulationStudio's Sandbox.
• SBStReachabilitySimulator: Switched from SBStSimulator to SimulationStudio's SimulationContext. Refined reachability detection to match every single PC.
• SBTypeCollectSimulator:: Switched from InstructionClient to SimulationStudio's SimulationContext.
• The baseline is updated accordingly.

Open todos:

• [ ] Migrate SBStTracingSimulator too? I would be willing to do so, but without any entry point or test, I don't dare. We can also leave this class as-is if this is not important.
• [ ] Delete the old simulator classes? I will not do this without your explicit request. :-)

---

Why SimulationStudio? (may contain traces of self-advertising 👀)

- SimulationStudio reuses and makes extensible the original meta-interpreter of Squeak. As a consequence, no reinvention of the wheel (as it is done in `InstructionClient`) is required, deduplication is avoided, and code will not come out of sync if the execution semantics of Squeak change (i.e., when a new primitive is introduced). All `thisContext` facilities that are required for proper meta-programming tasks such as exception handling are available to the simulated code as usually. - SimulationStudio's sandbox enforces fewer limitations while simulating the code. If any side effect is detected, the simulation does not stop, but the side effect is simulated in a separate object space, visible only to the simulated stack frames. Most VM primitives have been annotated manually to support a maximum number of side-effect-free VM operations. Even interaction with the caller stack is safely possible, for instance: ```smalltalk [Sandbox evaluate: [self inform: #foo]] valueSuppressingAllMessages. ``` At the same time, no outbreak is known yet. If you can find any, please keep them coming! :-) - SimulationStudio offers better tooling; for instance, you can debug the simulated code in a debugger like this: ```smalltalk SBStReachabilitySimulator newFrom: [SBReachabilitySimulatorTest new exampleMethod] asContext) store: SBReachabilityColorPolicy new; debug. ``` For even more advertising, check out my way too long announcement email here: [[ANN] SimulationStudio and sandboxed execution for Squeak](http://forum.world.st/ANN-SimulationStudio-and-sandboxed-execution-for-Squeak-td5127804.html). ;-)

[tom95]

Very nice changes, thank you for the PR! I'll go ahead and merge it as-is and do the open cleanup items you mentioned in a follow-up commit :)

[LinqLover]

Yahoo, glad you like it! :D

[LinqLover]

Oh no, this broke the CI - which was unfortunately not enabled for pull requests :(

https://github.com/tom95/sandblocks/runs/4067603490?check_suite_focus=true#step:4:167

Taking a look at it ...

[LinqLover]

Argh, SimulationStudio is not compatible with Squeak 5.3 at all. I'm going to spike how complex porting it back will be. For Trunk, all tests pass.

[tom95]

If it seems more difficult, we could make the dependency optional and only load it in trunk. Would probably mean that we need to isolate the dependencies in Sandblocks in a separate package.

[LinqLover]

Hmm, this sounds not too elegant, and it would mean that Sandblocks's simulator features would either be unavailable in 5.3 or that we would need to keep the old version of their implementation working for 5.3, wouldn't it?

I'll spend some more time trying to find out how strongly SimulationStudio is actually coupled to Squeak 6.0Alpha, you can track the progress here (but I will keep you up to date in this thread, too, of course). However, this might take me some days, so if a green CI is important to you, you could revert this PR temporarily ...