One cannot pass Morphic event's along the Morhp chain from the simulation host World to the running simulation on the target World.

I have some questions on how to proceed at the bottom of this post.

In the host simulation environment, one cannot interact with the running simulation using the standard Morphic "event chain".

One cannot do so because from the host environment, there is no World in the simulation; there is only a painted picture of a World.
The key to seeing this  is to grok  what a running simulation actually is.

StackInterpreterSimulator >> run

    "..simulation setup code.."

    [true] whileTrue:
        [self assertValidExecutionPointers.
         atEachStepBlock value. "N.B. may be nil"
         self dispatchOn: currentBytecode in: BytecodeTable.
         self incrementByteCount].

    "..we never get here..."

There is no 'hook' for me to chain the Morphic event's down into, there are only bytecodes being fetched and executed .    (which is totally cool and awesome, btw).

Those bytecodes paint a pretty picture on an ImageMorph placed on a Frame placed within a SystemWindow as seen here in

StackInterpreterSimulater >> openAsMorph
     
      "...."

        window addMorph: (displayView := ImageMorph new image: displayForm)
        frame: (0@0 corner: 1@0.8).


      "...."

That image is not a PasteUpMorph named TheWorld that can respond to events--it is just a pretty picture.


 That ladies and gentleman is the point where us fat and coddled coder Hobbit's have to enter the dragon's cave, leaving the
comfortable environment of the Squeak API for whatever strange and dangerous world lies below; Me? I decided to post here instead
before venturing in (:

So, having learned this the hard way, there are a couple of strategies I could take--RFB, or maybe Nebraska-- to get events over to
the target image but before doing that I have to ask is it really necessary?

My goal is to port the StackInterpeter to native 64 (and after that 64x64). Presumably Eliot managed to do the original work without the
use of direct interaction with morphic on the running world, so shouldn't my task now be to emulate whatever techiques Eliot uses?

If so, that raises the final point. What exactly are those techniques? Specifically, given a running simulation, how does one produce
a new VM? Do we boot up the target image on which we have developed and run VMMaker the standard way?


Finally, direct interaction with the runnig simulation world is desirable, I will be happy to implement it. Just please inform me of what strategy you would prefer and I
will try to get it done.

Thank you for your time.

Hi Eliot, Bob and Henry.

Changeset and pic attached. (If the changeset has problems, let me know, I copied from my live CS to a clean copy to share that omits my fiddling around changes. I might have missed something)

I would appreciate your advice on how to proceed from here.

The approach is modeled after what I saw in HostWindowProxy.
I have other things on my checklist to try, but this seemed the easiest approach, so I ran with it.
My first goal was to just get the darned events into the simulator, see something on the simulated transcript  and a menu to show up.

Modifications were as follows (changeset attached, btw)


EventSensor
       class side
           set class side accessor for instance var forwardVMSimulationEvents
        instance side
           add instance var forwardVMSimultioEvents
           modify processEvent:evt to forward raw events if flag is set.

StackInterpreterSimulator
      class side
         I added infrastructure to make it a Singleton
         Created a class side accesor to invoke the instance side method
       instance side.
          Added an eventQueue (SharedQueue) instance variable
          queueForwardedEvent lazy initialization takes event from EventSensor and dumps it on the eventQueue
          ioGetNextEvent  checks eventQueue and copies data from the forward event to the CArrayAccessor
                          There is commented out code I used to verify that
                          1. the argument evtBuf is a bunch of zeroes coming in
                              2. evtBuf matched the forwarded event after copy


Workspace code to launch the simulation:

            | vm |
            Transcript clear.

            EventSensor forwardVMSimulationEvents: true.
            vm := StackInterpreterSimulator newWithOptions: #(#STACKVM).
            vm openOn: '/home/wm/usr/src/smalltalk/buildCogDevelopmentImageCog.app/Contents/Resources/targets/Squeak4.5.image'.
            vm
                openAsMorph;
                run

            "EventSensor forwardVMSimulationEvents: false."

Observations:

       The events get there and the WorldMenu pops up. woot. (lower case "woot", no exclamation point. not to be confused with WOOT!!!!)
       The tildes "~" in the simulation Transcript (in the attached pic) are generated at StackInterpreterSimulator>> ioGetNextEvent
       Event processing is dog slow. Be prepared to wait 5 minutes for the menu to pop up.
       Tightly coupled.
        I don't like the modification to EventSensor.
        I don't like having to implement a Singleton--but it was saner than Smalltalk at: #StackInterpreterSimulatorLSB allInstances do:[...]
        I am unfamiliar with Smalltalk Semaphores, had I known how to do the Smalltalk equivalent of event listener I would have gone that route.
        Consumer/Producer Semaphore examples from various books I have read are all within the same process, so I cut my losses and went with the current approach.

       EventSensor>>processEvent:evt  does have the events in raw form, no need to translate before forwarding to the StackInterpreter.

       In principle, we know we CAN get the dang events into the StackIntepreter.

       How do I make this responsive and useful?


Thank you for your time

 p.s. this is fun.


cheers.

tty.