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

[Fabio Niephaus]

Hi Eliot,

On Thu, Oct 18, 2018 at 5:28 PM Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
> 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
>
> copyBits
>     super copyBits.
>     (interpreterProxy failed
>      or: [destinationHashes isNil]) ifFalse:
>         [(copyBitsCount := copyBitsCount + 1) <= destinationHashes size
>             ifTrue:
>                 [(destinationHashes at: copyBitsCount) ~= self
> destinationHash ifTrue:
>                     [self halt: 'destination different']]
>             ifFalse:
>                 [destinationHashes at: copyBitsCount put: self
> destinationHash]
>
> 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
> system.
>

Just wanted to mention that GraalSqueak is following a similar approach to
RSqueak/VM. If we notice any problems after pulling new VMMaker changes,
we'll figure something out. :)
And like Tim said, thanks for the heads up!

Fabio


>
> _,,,^..^,,,_
> best, Eliot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181028/cb5eeba5/attachment.html>