The R/Squeak VM and plugin Simulator subclasses

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

The R/Squeak VM and plugin Simulator subclasses

Eliot Miranda-2
 
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.

_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: The R/Squeak VM and plugin Simulator subclasses

timfelgentreff
 
Hi Eliot,

I guess that code won't have to live in there forever? If so, we don't mind. If it's there to stay, we can also just add code to R/Squeak VM to resume halts in simulated primitives. Lastly, ideally we will fix the bug eventually and this halt will never trigger. Until that time, we can just avoid pulling in the latest VMMaker into the R/Squeak config.

Thanks for the heads up, I really appreciate it :)
-Tim

From: Vm-dev <[hidden email]> on behalf of Eliot Miranda <[hidden email]>
Sent: Thursday, October 18, 2018 5:28:02 PM
To: Open Smalltalk Virtual Machine Development Discussion
Subject: [Vm-dev] The R/Squeak VM and plugin Simulator subclasses
 
 
Reply | Threaded
Open this post in threaded view
|

Re: The R/Squeak VM and plugin Simulator subclasses

fniephaus
In reply to this post by Eliot Miranda-2
 
Hi Eliot,

On Thu, Oct 18, 2018 at 5:28 PM Eliot Miranda <[hidden email]> 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