[Vm-dev] [Foo]InterpreterSimulator not responding to events...
eliot.miranda at gmail.com
Thu Jan 16 18:00:37 UTC 2014
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:
>>> 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
"Handle a mouse down event. The default response is to let my
eventHandler, if any, handle it."
ifTrue: ["First check for option (menu) click"
^ self yellowButtonActivity: evt shiftPressed].
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?
I would like to rule out a missing option in the newWithOptions: #() line
>>> Specifically the "type of VM options in VMBasicConstants:
>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev