[Vm-dev] The R/Squeak VM and plugin Simulator subclasses

Eliot Miranda eliot.miranda at gmail.com
Thu Oct 18 15:28:02 UTC 2018

Hi All,

    it is my understanding that the R/Squeak VM implementation uses plugin
simulator subclasses along with the InterpreterProxy infrastructure
(implementation of the InterpreterProxy interface between plugins and the
VM, which is implemented using normal Smalltalk code for plugin testing) to
implement primitives above the R/Squeak VM.  Meanwhile the simulator
subclasses of plugins, for example the BitBltSimulator subclass of
BitBltSimulation (which would better be called BitBltPlugin) provide
overrides to host plugins within the simulation framework, to add debugging
facilities, etc.  These two uses can conflict.

In debugging a bug whereby BitBlt fetches beyond the last work of a source
bitmap I want to collect the hashes of the destination bitmap after each
copyBits operation in a test that succeeds with the old code (but fetches
beyond the end of the source).  I then want to compare the destination
hashes after each bitable in the version of the code I'm trying to fix
(since I have setup code that makes sense to me but fails for occasional
bits).  The natural way for me to do this is to add a couple of variables
to BitBltSimulator, copyBitsCount and destinationHashes and write

    super copyBits.
    (interpreterProxy failed
     or: [destinationHashes isNil]) ifFalse:
        [(copyBitsCount := copyBitsCount + 1) <= destinationHashes size
                [(destinationHashes at: copyBitsCount) ~= self
destinationHash ifTrue:
                    [self halt: 'destination different']]
                [destinationHashes at: copyBitsCount put: self

then by setting destinationHashes to an empty OrderedCollection I can
collect hashes in one version and by setting destinationHashes to that
sequence I can identify the bait that is different in the other version.

But if I add this code I fear I will break R/Squeak.  If that's the case
then I ant to ask the R/Squeak team to duplicate all the plugin simulator
subclasses, and call them something like BitBltRSqueakImplementation or
RSqueakBitBltImplementation etc.  I don't mind if this lives in the VMMaker
package or a separate package.  I think a separate package is better but I
will keep it loaded anyway to avoid it getting stale.

If on the other hand I won't step on R/Squeak by making modifications such
as the above can someone explain how this works?

In the mean time I'm going to make my mods and possibly damage R/Squeak.
Forgive me, but I have to be able to do things like the above to debug the

best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181018/7db13c36/attachment.html>

More information about the Vm-dev mailing list