[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.

Eliot Miranda eliot.miranda at gmail.com
Wed Jan 22 18:05:46 UTC 2014

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/8071a605/attachment-0001.htm

More information about the Vm-dev mailing list