[Vm-dev] Hello VM Dev List From StackInterpreterSimulator

[Eliot Miranda]

On Thu, Feb 6, 2014 at 8:36 AM, gettimothy <gettimothy at zoho.com> wrote:

>
> Hi All,
>
> I have some primitive event filtering in place and was able to open a
> Workspace and type a message. See the attached screenshot.
>

Awesome!! Thank you so much!


>
> I figure my work is at the stage where it would benefit from other eyes
> and minds.
>
> For testing, I merged the attached changeset into 4.5 release candidate 3
> after installing the CogDev stuff here:
> http://www.squeakvm.org/svn/squeak/branches/Cog/image/Workspace.text
>
> I copied over the changes and it worked fine. One caveat is that I have
> the bug-fix for WriteStream nextChunkPut: in that change set. you probably
> don't want that.
>
> To launch the thing, see StackInterpreterSimlatorMorph class >
> documentation protocol for examples on launching (currently 1 example (:)
>
>
> Below are some notes.
>
> *Category and source*
>     1.added category VMMaker-InterpreterSimulation-Morphic which contains
> 3 classes
>        StackInterpreterSimulatorImageMorph
>        StackInterpreterSimulatorMorph
>        StackInterpreterSimulatorMorphicModel
>        EventSensorConstants is added as a poolDictionary to the model
>
>   2. Additions where made to HandMorph. Most are in category *VM.oscog
> except for one edit to HandMorph>>processEvents
>
>   3. Some modifications to StackInterpreterSimulator.
>
>   4. I think that's all.
>

Can you e.g. send me your VMMaker package from your local package-cache?
 And can you send me the hand edit to HandMorph>>processEvents?

Looks like Bert is providing useful feedback.  I'm delighted to have this
working!!


> *Event forwarding*
>
>     1. What I call "primitive events" are much easier to use (for me) than
> un-wrapping morphic events.
>
>     2. I modified HandMorph by adding a primitiveEventListener framework
> that mimics the existing HandMorph >>
> addEventListener:/sendListenEvent:to:/handleListenEvent: framwork.
>
>        See HandMorph >>
> addPrimitiveEventListener:/sendListenPrimitiveEvent:to:/handleListenPrimitiveEvent.
>
>         For morphic events, listener notification happens in HandMorph >>
> handleEvent. For the primitiveEvents, I had to use HandMorph >>
> processEvents.
>
>     3. If this is un-acceptable, then the task of 'decoding' the Morphic
> Events that HandMorph creates in HandMorph >> processEvents needs to be
> done.
>         I prefer to not do it as it is ugly.
>
>     4. Primitive events from HandMorph are passed to
> StackInterpreterSimulatorMorphicModel after being registered with HandMorph.
>        1. The StackIterpreterSimulatorMorph >> displayView registers the
> model with the HandMorph for event notification.
>
>     5. StackInterpreterSimulatorMorphicModel >>
> handleListenPrimitiveEvent: evtBuf is where event translation and filtering
> happens.
>        1. This needs a deft hand. Preferrably by somebody who is familiar
> with Morhic bounds translations. I briefly looked at it and its a deep
> subject, so I ran away screaming.
>        2. You can un-comment some code to see the raw events on the
> transcript. I found this handy.
>        3. EventSensorConstants has a list of other events that you may
> want to forward.
>
>     6. Event's are queued in StackInterpreterSimulatorMorphicModel >>
> handleListenPrimitiveEvent: and dequeued in StackInterpreterSimulator >>
> ioGetNextEvent.
>
>
> *Tests*
>     1. I have not written any yet.
>     2. The morph is copied from PreferenceBrowser, so I guess I need to
> look at those tests.
>
>
> *StackInterpreterSimulator notes.*
>
>     1. Rule 1 is to not break the existing openAsMorph functionality Eliot
> has.
>
>     2. StackInterpreterSimulator >> openAsStackInterpreterSimulatorMorph
> launches it. (see StackIntepreterSimulatorMorph class ttyOne for example
> script)
>
>     3. StackInterpreterSimulator is the instance variable 'vm' on the
> morphic model.
>
>     4. There is tight-coupling of the StackInterpreterSimulator's
> displayView variable across all three layers (Morph-Model-VM) I had a good
> reason for this, but I forget what it was.
>
>     5. StackIntepreterSimulator >> incrementByteCount is what triggers the
> display redraw. *This needs attention. *
>            I changed the count to 1000 from 10,000 to trigger the
> forceDisplayUpdate call and got some improvement. Things I am wondering
>        1. Should we change these triggers to options on launch?
>        2. Should we make them variable?
>        3. We can force a fullDisplayUpdate from the GUI, (Which I tried).
>        4. Instead of a byteCount triggering it, what else would make sense?
>

I think getting the BitBltPlugin simulator or the SurfacePlugin, where ever
the code is that in the real VM triggers an update of the real screen, is
the right place to get the simulator to update the image morph.

*Morphic improvments needed*
>     1. Event bound translation  in StackInterpreterSimulatorMorphicModel>>
> handleListenPrimitiveEvent
>         I looked at this briefly and its a deep subject, so I took the
> easy way out and reverted to addition on x/y coordinates. (:
>
>     2. Mouse and Keyboard events are forwarded when mouse is within the
> bounds of the ImageMorph.
>
>
>     3. z-order does not stop events from being forwarded. For example,but
> a Browser over the simulation and events are still forwarded.
>
>     4. Mouse drag moves the entire simulation window--I cannot drag a
> window within the simulation.
>
>     5. Splitters and scroll-bars, splitters and scroll-bars (my first
> morph attempt, sorry)
>
>     6. Buttons and callbacks.
>
>     7. Bert's SqueakJS windows along the bottom--what makes sense to put
> there? How to do it?
>
>     8. See class commments in StackInterpreterSimulatorMorph
>
>     9. Help button contents
>
>     10. Tim R's "WTF goes on in there?" button has not been implemented.
> Its very doable;  events just need to be enqueued for the simulator to suck
> them up.
>
>     11. Eliot's command window menu needs testing. I know the clone vm
> does not work in this simulation. (it does work in the original openAsMorph
> simulation)
>
>
> *Summary*
>        1. It's usable enough now that I think submitting it is a good idea
>
>         2. I expect to improve it as I learn more
>
>        3. I would like to move on towards my goal of porting the
> StackInterpreterSimulator to native 64.
>
>
> cheers.
>
> tty
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140206/d6493fee/attachment-0001.htm