[Vm-dev] [Foo]InterpreterSimulator not responding to events...

[Eliot Miranda]

On Thu, Jan 16, 2014 at 10:00 AM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

> Hi All,
>
>     more whitewash...
>
> On Thu, Jan 16, 2014 at 9:41 AM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>
>>
>>
>>
>> On Thu, Jan 16, 2014 at 9:36 AM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>>
>>> Hi Tty,
>>>
>>>
>>> On Thu, Jan 16, 2014 at 8:10 AM, gettimothy <gettimothy at zoho.com> wrote:
>>>
>>>>
>>>>  I am hosting (? correct term)  the StackInterpreterSimulator on
>>>> Squeak4.5-13352.image running Cog.
>>>>
>>>> I instruct the simulator to use a copy of that image that I have
>>>> renamed to Squeak4.5.image.
>>>>
>>>>
>>>> | vm |
>>>> Transcript clear.
>>>> vm := StackInterpreterSimulator newWithOptions: #().
>>>> vm openOn:
>>>> 'home/tty/usr/src/smalltalk/buildCogDevelopmentImageCog.app/Contents/Resources/Squeak4.5.image'.
>>>> vm
>>>>     openAsMorph;
>>>>     toggleTranscript;
>>>>     halt;
>>>>     run
>>>>
>>>>
>>>> The simulation runs, but the simulated World does not respond to mouse
>>>> clicks (the control panel of the Simulator works just fine).
>>>>
>>>
>>> Right.  I've not looked at this.  It never worked for me and I think its
>>> to do with the "new" event mechanism bssed around the interruptPending inst
>>> var.  So for now I use an image that has a read-eval-print-loop in it.
>>>  Much better would be for the input scheme to work.  But I've not had time
>>> or occasion to look at the Interpreter and update StackInterpreterSimulator
>>> appropriately so it responds to input.
>>>
>>
>> Hmmm, looking at Interpreter in the VMMaker.oscog package I see that
>> nothing in the simulator does set interruptPending.  David, does the trunk
>> VMMaker package's InterpreterSimulator respond to input?
>>
>
>
> I see that in the various FooSimulator>>openAsMorph methods the basic
> morph used to display the simulated Smalltalk image is an ImageMorph on the
> Smalltalk image's displayForm.  Looking at the event handling it looks like
> this bottoms out at methods like
>
> Morph>>mouseDown: evt
> "Handle a mouse down event. The default response is to let my
> eventHandler, if any, handle it."
>  evt yellowButtonPressed
> ifTrue: ["First check for option (menu) click"
> ^ self yellowButtonActivity: evt shiftPressed].
>  self eventHandler
> ifNotNil: [self eventHandler mouseDown: evt fromMorph: self]
>
>
> So it could be straight-forward to plum-in a suitably-written event
> handler (e.g. an object that wraps the FooSimulator so that it can be
> reused in each of the simulators, instead of using the simulator as the
> eventHandler itself).  Any volunteers?
>

Ghaahhh, ignore my blathering.  I clearly don't understand how Morph event
handling works.  Looks like it needs a set of on:send:do: messages sent to
the Morph.  So if you do go for this please don't ask me for advice on the
Morph side of things ;-)


>
>
>
>  I would like to rule out a missing option in the newWithOptions: #()
>>>> line
>>>>
>>>> Specifically the "type of VM options in VMBasicConstants:
>>>>
>>>> #COGMTVM
>>>> #COGVM
>>>> #NewspeakVM
>>>> #STACKVM
>>>> #VMBIGENDIAN
>>>>
>>>> 1. To my way of thinking, since I am running a
>>>> StackInterpreterSimulator, passing the option #STACKVM makes no sense.
>>>> 2. Also--if I remember correctly--when first running Cog on a StackVM
>>>> (?) image, it prompts the user that running Cog will make the image
>>>> unusable for the StackInterpreter.
>>>> 3. Therefore telling the StackIntepreterSimulator to expect a COGVM
>>>> image makes no sense either.
>>>> 4. Equally perplexing is the fact that the simulation does run -- it is
>>>> just stuck in idle--which tells me I am incorrect about 2. above.
>>>>
>>>>
>>>> I will be poking around in the guts of things in the mean time.
>>>>
>>>>
>>>> thx
>>>>
>>>> tty
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> best,
>>> Eliot
>>>
>>
>>
>>
>> --
>> best,
>> Eliot
>>
>
>
>
> --
> best,
> Eliot
>



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