Smalltalk › Squeak › Squeak VM

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

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

36 messages Options

tty

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.

Eliot Miranda-2

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

Hi Tty,

On Wed, Jan 22, 2014 at 5:23 AM, gettimothy <[hidden email]> 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@0 corner: 1@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:

StackInterpreterSimulator>>ioProcessEvents

"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

HTH

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.

--
best,

Eliot

tty

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

Eliot,

Thank you for the pointer in the right direction.

I will revisit that. That looks like fun.

My first foray into primitives....hmmmm

cordially,

tty.

---- On Wed, 22 Jan 2014 10:05:46 -0800 Eliot Miranda <[hidden email]> wrote ----

Hi Tty,

On Wed, Jan 22, 2014 at 5:23 AM, gettimothy <[hidden email]> 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@0 corner: 1@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:

StackInterpreterSimulator>>ioProcessEvents
"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

HTH

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.

--
best,
Eliot

Henrik Sperre Johansen

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

In reply to this post by Eliot Miranda-2

On 22 Jan 2014, at 7:05 , Eliot Miranda <[hidden email]> wrote:

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

As for the conversion into the OS array, searching for "Event Types” in sq.h will probably give a better introduction/faster understand as to the structure of said array than delving into the code doing array -> morphic event conversion in an image.

Make sure you get WindowEvent type 6 correct! :)

Cheers,

Henry

signature.asc (859 bytes) Download Attachment

Bob Arning-2

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

I don't think there is any reason to convert to an OS array - HandMorph>>processEvents already knows the OS event array that was used to generate the squeak event. Making that accessible may be all you need from the front end.

Cheers,
Bob

On 1/23/14 4:43 AM, Henrik Johansen wrote:

 
On 22 Jan 2014, at 7:05 , Eliot Miranda <[hidden email]> wrote:

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

As for the conversion into the OS array, searching for "Event Types” in sq.h will probably give a better introduction/faster understand as to the structure of said array than delving into the code doing array -> morphic event conversion in an image.

Make sure you get WindowEvent type 6 correct! :)

Cheers,

Henry

Henrik Sperre Johansen

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

On 23 Jan 2014, at 12:32 , Bob Arning <[hidden email]> wrote:

I don't think there is any reason to convert to an OS array - HandMorph>>processEvents already knows the OS event array that was used to generate the squeak event. Making that accessible may be all you need from the front end.

Cheers,
Bob

There are multiple ways to Rome, each with their own advantages.

What you describe would be simple, but probably require one to overriding the MorphicEvent definition/HandMorph code though. (Plus doing coordinate translation of the event buffer in the SimulatorMorph)

In a Pharo VMMaker-image, you could bypass morph event handling entirely without touching any core system code, by registering a custom InputEventHandler to the InputEventFetcher, which would do a short inside/active test for mouse/keyboard events respectively, and adding the array to the SimulatorMorphs event queue. (with coordinate translation as in the above approach)

Translating back from Morphic events is more work, true, but can be done with standalone code, and would work in both Pharo and Squeak.

Cheers,

Henry

signature.asc (859 bytes) Download Attachment

tty

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

In reply to this post by Bob Arning-2

Henry, Bob and Eliot.

Thanks all.

After I study what Eliot wrote and devise my plan, I will post it back here.
Bear in mind that I am new to this. I am experiencing the same difficulty in thinking 'VM' vs 'Smalltalk' as I did when thinking 'Smalltalk' vs 'Algol';
I am sure the light bulb will come on (40 Watt, sadly) eventually, but expect missteps.

BTW, is there an existing working process that the Simulator currently does that I can use as a model? I was planning on mapping what Eliot wrote to
what I can see in the Simulator's command window menu as a starting point to get a feel for things. Good place to start ?

cordially,

tty

---- On Thu, 23 Jan 2014 03:32:32 -0800 Bob Arning <[hidden email]> wrote ----

I don't think there is any reason to convert to an OS array - HandMorph>>processEvents already knows the OS event array that was used to generate the squeak event. Making that accessible may be all you need from the front end.

Cheers,
Bob

On 1/23/14 4:43 AM, Henrik Johansen wrote:

[hidden email]" type="cite">
 
On 22 Jan 2014, at 7:05 , Eliot Miranda <[hidden email]> wrote:

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

As for the conversion into the OS array, searching for "Event Types” in sq.h will probably give a better introduction/faster understand as to the structure of said array than delving into the code doing array -> morphic event conversion in an image.

Make sure you get WindowEvent type 6 correct! :)

Cheers,

Henry

Eliot Miranda-2

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

Hi Tty,

On Thu, Jan 23, 2014 at 5:11 AM, gettimothy <[hidden email]> wrote:

Henry, Bob and Eliot.

Thanks all.

After I study what Eliot wrote and devise my plan, I will post it back here.
Bear in mind that I am new to this. I am experiencing the same difficulty in thinking 'VM' vs 'Smalltalk' as I did when thinking 'Smalltalk' vs 'Algol';
I am sure the light bulb will come on (40 Watt, sadly) eventually, but expect missteps.

BTW, is there an existing working process that the Simulator currently does that I can use as a model? I was planning on mapping what Eliot wrote to
what I can see in the Simulator's command window menu as a starting point to get a feel for things. Good place to start ?

Sure. But you're going to add event handler code to where that window is created which is StackInterpreterSimulator>>openAsMorph. You're going to need a new inst var in StackInterpreterSimulator to hold the event. As Bob says (wish I'd said it too but I couldn't find it) the Morphic events may hold onto their OS events anyway so you may not even have to convert.

Anyway, dive in, get your hands dirty, and you don't have to commit your mistakes, so we'll never know, only see the shiny finished product ;-)

cordially,

tty

---- On Thu, 23 Jan 2014 03:32:32 -0800 Bob Arning <[hidden email]> wrote ----
I don't think there is any reason to convert to an OS array - HandMorph>>processEvents already knows the OS event array that was used to generate the squeak event. Making that accessible may be all you need from the front end.

Cheers,
Bob

On 1/23/14 4:43 AM, Henrik Johansen wrote:
[hidden email]" type="cite">
 
On 22 Jan 2014, at 7:05 , Eliot Miranda <[hidden email]> wrote:

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

As for the conversion into the OS array, searching for "Event Types” in sq.h will probably give a better introduction/faster understand as to the structure of said array than delving into the code doing array -> morphic event conversion in an image.

Make sure you get WindowEvent type 6 correct! :)

Cheers,

Henry

--
best,

Eliot

tty

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

I think I see the approach now.

Because the Simulated VM is not actually running as its own operating system process, there are no I/O events coming from the operating system to it via the normal VM paths.
However, we can cheat by taking OS events from the host process and "injecting" them into the simulation process in a suitable form such that the simulated UI running
on top of the simulated VM cannot tell the difference.

Does that about sum it up?

thx.

tty

Eliot Miranda-2

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

On Thu, Jan 23, 2014 at 1:50 PM, gettimothy <[hidden email]> wrote:

I think I see the approach now.

Because the Simulated VM is not actually running as its own operating system process, there are no I/O events coming from the operating system to it via the normal VM paths.
However, we can cheat by taking OS events from the host process and "injecting" them into the simulation process in a suitable form such that the simulated UI running
on top of the simulated VM cannot tell the difference.

Does that about sum it up?

Perfectly. Why couldn't I say it that way?

thx.

tty

--
best,

Eliot

tty

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

"Perfectly. Why couldn't I say it that way?"

Because you are smarter than I am and know what you are doing! (:

Thanks for your help.

tty.

Eliot Miranda-2

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

On Thu, Jan 23, 2014 at 2:27 PM, gettimothy <[hidden email]> wrote:

"Perfectly. Why couldn't I say it that way?"

Because you are smarter than I am and know what you are doing! (:

Not so! I've overcomplicated for a long time. Give yourself a pat on the back for seeing clearly and simply. This is a complex beast you're diving into.

Thanks for your help.

tty.

--
best,

Eliot

tty

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

Eliot,

Without your complex description, I could not have written that simple summary.
By you having the know-how of where to look you enabled me to connect the dots.

Don't fear, though, I am sure gum something up!

cheers.

tty

---- On Thu, 23 Jan 2014 14:28:46 -0800 Eliot Miranda<[hidden email]> wrote ----

On Thu, Jan 23, 2014 at 2:27 PM, gettimothy <[hidden email]> wrote:

"Perfectly. Why couldn't I say it that way?"

Because you are smarter than I am and know what you are doing! (:

Not so! I've overcomplicated for a long time. Give yourself a pat on the back for seeing clearly and simply. This is a complex beast you're diving into.

Thanks for your help.

tty.

--
best,
Eliot

tty

One can pass events from EventSensor to the StackInterpreterSimulator

In reply to this post by Henrik Sperre Johansen

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.

SimulationWithMenu.png (229K) Download Attachment

EventBubblingToShare.1.cs (4K) Download Attachment

Bob Arning-2

Re: One can pass events from EventSensor to the StackInterpreterSimulator

Given that it is a simulation popping up the menu, how fast is it
reasonable to expect? What is your normal simulated bytecodes/sec? How
many bytecodes executed in that 5 minutes? Perhaps more importantly, how
many simulated screen redraws in that interval? How expensive are these?

Cheers,
Bob

On 1/30/14 1:50 PM, gettimothy wrote:
> Event processing is dog slow. Be prepared to wait 5 minutes for
> the menu to pop up.
> ...
>
> How do I make this responsive and useful?

Eliot Miranda-2

Re: One can pass events from EventSensor to the StackInterpreterSimulator

In reply to this post by tty

Hi Tty!

On Thu, Jan 30, 2014 at 10:50 AM, gettimothy <[hidden email]> wrote:

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)

congratulations, and *thank you*!

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

see below.

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.

That's just a fact of life. The simulator is dog slow :-).

Tightly coupled.
I don't like the modification to EventSensor.

Agreed. TO proceed, the next step would be to try and eliominate this modification. Isn't there a way of making the change self-contaned by trying to confine the set-up of the plumbing to openAsMorph?

        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.

Right.

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

Which is fab. Again, thanks!

How do I make this responsive and useful?

Three things? 1. figure out how to do it without modifying base packages, confining changes to VMMaker. 2. ask David Lewis for write permission to the VMMaker repository. 3. commit your changed version of VMMaker, from which I can merge :-)

Thank you for your time

Au contraire ;-)

p.s. this is fun.

cheers.

tty.

--
best,

Eliot

Eliot Miranda-2

Re: One can pass events from EventSensor to the StackInterpreterSimulator

In reply to this post by Bob Arning-2

On Thu, Jan 30, 2014 at 11:20 AM, Bob Arning <[hidden email]> wrote:

Given that it is a simulation popping up the menu, how fast is it reasonable to expect? What is your normal simulated bytecodes/sec? How many bytecodes executed in that 5 minutes? Perhaps more importantly, how many simulated screen redraws in that interval? How expensive are these?

Oh, good point! I think the simulator restricts redraws to every few thousand bytecodes. It would be much more responsive if somehow the simulator could update the screen whenever the bitblt primitive affects the screen.

Cheers,
Bob

On 1/30/14 1:50 PM, gettimothy wrote:

Event processing is dog slow. Be prepared to wait 5 minutes for the menu to pop up.
...

How do I make this responsive and useful?

--
best,

Eliot

johnmci

Re: One can pass events from EventSensor to the StackInterpreterSimulator

There is a flush primitive which should be used.

http://isqueak.org/ioForceDisplayUpdate

Normally that is called by morphic. In cases of bad code design the osx and iOS version schedule a flush if needbe every n milliseconds. I think the windows version just respects the flush The x11 flavors just flush on each draw which make it slower

Sent from my iPhone

On Jan 30, 2014, at 2:24 PM, Eliot Miranda <[hidden email]> wrote:

On Thu, Jan 30, 2014 at 11:20 AM, Bob Arning <[hidden email]> wrote:

Given that it is a simulation popping up the menu, how fast is it reasonable to expect? What is your normal simulated bytecodes/sec? How many bytecodes executed in that 5 minutes? Perhaps more importantly, how many simulated screen redraws in that interval? How expensive are these?

Oh, good point! I think the simulator restricts redraws to every few thousand bytecodes. It would be much more responsive if somehow the simulator could update the screen whenever the bitblt primitive affects the screen.

Cheers,
Bob

On 1/30/14 1:50 PM, gettimothy wrote:

Event processing is dog slow. Be prepared to wait 5 minutes for the menu to pop up.
...

How do I make this responsive and useful?

--
best,
Eliot

smime.p7s (6K) Download Attachment

Bert Freudenberg

Re: One can pass events from EventSensor to the StackInterpreterSimulator

In reply to this post by Eliot Miranda-2

On 30.01.2014, at 20:22, Eliot Miranda <[hidden email]> wrote:

Tightly coupled.
I don't like the modification to EventSensor.

Agreed. TO proceed, the next step would be to try and eliominate this modification. Isn't there a way of making the change self-contaned by trying to confine the set-up of the plumbing to openAsMorph?

The right way would be to just use the regular morphic event processing and generate VM events from those. I don't see why you would need to hook into EventSensor.

- Bert -

smime.p7s (5K) Download Attachment

Henrik Sperre Johansen

Re: One can pass events from EventSensor to the StackInterpreterSimulator

In reply to this post by tty

Nice proof of concept!

On 30 Jan 2014, at 7:50 , gettimothy <[hidden email]> wrote:

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.

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.

Was event coordinate translation somehow not needed, or did a click in top left of your screenshot end up opening the menu on mid right side?

       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:[…]

IMHO, If you just keep the EventSensor override code dealing with event delivery to the morph in a separate package, it would be just fine to delay exchange to a less intrusive alternative until later.

As long as the responsibilities are clear, it shouldn’t be too hard (push vs pull expected, who of deliverer/simulator morph does potentially needed coord translation, etc)

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.

There’s already such a Semaphore operating across the VM/image divide, set by primitive 93. You can see an example of how to do an event listener using that in a Pharo images InputEventFetcher ;)

(whose consumer action is… pushing the event to an in-image queue :P)

Related, the morphic polling loop in Pharo images has been decoupled from the raw act of calling getNextEvent:, so for those correct signaling of the semaphore set by primitive 93 is required to get input processing simulated correctly .

Shouldn’t be harder to make it work than signaling said semaphore from ioProcessEvents if the eventQueue is not empty, provided the semaphore setter primitive is actually operational in the Simulator :P

Cheers,

Henry

       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?

I’d say what you’ve achieved is already quite useful!

Maybe filtering out MouseOver events would cut down on the response time?

I would imagine the Simulator could be working up a hefty backlog of byte codes to simulate in order to process those...

Cheers,

Henry

signature.asc (859 bytes) Download Attachment