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

gettimothy gettimothy at zoho.com
Wed Jan 22 20:06:15 UTC 2014


Thank you for the pointer in the right direction.

I will revisit that.  That looks like fun. 

My first foray into primitives....hmmmm



---- On Wed, 22 Jan 2014 10:05:46 -0800 Eliot Miranda <eliot.miranda at gmail.com> wrote ---- 

 Hi Tty,

On Wed, Jan 22, 2014 at 5:23 AM, gettimothy <gettimothy at zoho.com> wrote:
 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 at 0 corner: 1 at 0.8).



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

Let me expand on this, because what you say is not the whole picture ;-)

The Morphic event you cannot (yet) pass to the simulation came from somewhere.  It actually bubbled up from within the real VM you're running.  It started off as an OS event coming in through EventSensor>>primGetNextEvent: which is sent from fetchMoreEvents.  From there EventSensor>>processEvent: created the Morphic event that you're having problems with.

Inside the real VM that OS event was responded to by the VM first calling ioProcessEvents from its event polling routine StackInterpreter>>ioProcessEvents, and then fetching the OS event via InterpreterPrimitives>>primitiveGetNextEvent, which implements EventSensor>>primGetNextEvent:.  Inside primitiveGetNextEvent there's a call to ioGetNextEvent: which will answer the OS event that primitiveGetNextEvent answers as an Array.

Addressing the simulation, what is painting the picture is the VM simulator that sits behind the window.  Within this VM there is a simulation of both ioProcessEvents and ioGetNextEvent:, but they do nothing:


 "do nothing..."

StackInterpreterSimulator>>ioGetNextEvent: evtBuf

 self primitiveFail.

So your challenge is to take the Morphic event, queue it inside StackInterpreterSimulator (e.g. in a new inst var eventQueue), and convert it to an OS event (an Array), so that it can for example implement ioGetNextEvent: as something like

StackInterpreterSimulator>>ioGetNextEvent: evtBuf

 eventQueue isEmpty ifTrue:

   [^self primitiveFail].

 self convertMorphicEvent: eventQueue removeFirst into: evtBuf


 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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140122/a8503f1c/attachment.htm

More information about the Vm-dev mailing list