Smalltalk › Squeak › Squeak VM

Re: [Pharo-dev] Simulator in Pharo 3

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

33 messages Options

Eliot Miranda-2

Re: [Pharo-dev] Simulator in Pharo 3

Hi Stefan!

On Wed, Feb 12, 2014 at 12:35 PM, Stefan Marr <[hidden email]> wrote:

Hi:

Below you see the result of today, the simulator for the StackInterpreter running in a Pharo 3 image.

Fab! This is great.

Over the last years, people have been tinkering with the simulator from time to time, but I have the feeling everyone gave up before the thing was fully functioning, and not even the trivial things have found their way back into the VM code base.

How can anyone do anything significant with the VM without getting the simulator to work? [ ;-) ] You know about the first attempt at making a 64-bit VM for HP don't you? A nightmare tale :-).

I am aware that Phil was busy with it recently, but I think there was also someone else posting notes here.

Would be great if those people could send me their change sets so that I can try getting everything working again.

As you can see in the screenshot, the simulator loads up properly, and executes the first 10,000,000 bytecodes.

Which is enough to make it notice that a primitive fails, and to pop up the error dialog.
However, it is a Pharo 1.2 image. Later images trigger some bug, I haven’t identified yet. They execute code, but don’t manage to bring up the display.

Thanks to having a unified code repository, everything I got so far (minus a few small changes) is here:
https://github.com/smarr/pharo-vm/tree/fixes/simulator-bit-rot

Hmm. What's the easiest way to map this to a Monticello mcz so I can integrate your changes back into my packages?

More to come soon.
Best regards
Stefan

--
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/

--
best,

Eliot

EstebanLM

Re: [Pharo-dev] Simulator in Pharo 3

On 13 Feb 2014, at 05:46, Eliot Miranda <[hidden email]> wrote:

Hi Stefan!

On Wed, Feb 12, 2014 at 12:35 PM, Stefan Marr <[hidden email]> wrote:

Hi:

Below you see the result of today, the simulator for the StackInterpreter running in a Pharo 3 image.

Fab! This is great.

Over the last years, people have been tinkering with the simulator from time to time, but I have the feeling everyone gave up before the thing was fully functioning, and not even the trivial things have found their way back into the VM code base.

How can anyone do anything significant with the VM without getting the simulator to work? [ ;-) ] You know about the first attempt at making a 64-bit VM for HP don't you? A nightmare tale :-).

I am aware that Phil was busy with it recently, but I think there was also someone else posting notes here.

Would be great if those people could send me their change sets so that I can try getting everything working again.

As you can see in the screenshot, the simulator loads up properly, and executes the first 10,000,000 bytecodes.

Which is enough to make it notice that a primitive fails, and to pop up the error dialog.
However, it is a Pharo 1.2 image. Later images trigger some bug, I haven’t identified yet. They execute code, but don’t manage to bring up the display.

Thanks to having a unified code repository, everything I got so far (minus a few small changes) is here:
https://github.com/smarr/pharo-vm/tree/fixes/simulator-bit-rot

Hmm. What's the easiest way to map this to a Monticello mcz so I can integrate your changes back into my packages?

give me some days… I have in my todo list to create a jenkins job to upload the mcz to source.squeak.org (you asked for it more or less in december, but I didn’t had the time until now, sorry).

Esteban

More to come soon.
Best regards
Stefan

<simulator.jpeg>

--
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/

--
best,
Eliot

Stefan Marr-3

Re: [Pharo-dev] Simulator in Pharo 3

In reply to this post by Eliot Miranda-2

Hi Eliot:

On 13 Feb 2014, at 05:46, Eliot Miranda <[hidden email]> wrote:

> Hmm. What’s the easiest way to map this to a Monticello mcz so I can integrate your changes back into my packages?

I think the bigger question is whether you actually want to adopt those things.
If you skim over the diffs on Github [1], you will probably find that most of the changes are necessary to adopt Pharo-specific API changes.
Not sure what the best way forward would be to avoid having the two Squeak and Pharo flavors diverge even more.

I am open to suggestions, don’t have a good idea how to properly ‘modularize’ these differences myself…

Best regards
Stefan

[1] https://github.com/pharo-project/pharo-vm/pull/18

--
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/

Ron Teitelbaum

RE: [Pharo-dev] [Vm-dev] Simulator in Pharo 3

> Stefan Marr
>
> Hi Eliot:
>
> On 13 Feb 2014, at 05:46, Eliot Miranda <[hidden email]> wrote:
>
> > Hmm. What's the easiest way to map this to a Monticello mcz so I can
> integrate your changes back into my packages?
>
> I think the bigger question is whether you actually want to adopt those

things.

That the vm says in sync should be a core requirement for our communities.
I realize that there is a split. There are some really great advancements
going on in pharo-vm including new build methods and configurations. All of
that has value if pharo can stay in sync with COG developments. It doesn't
make sense to require Pharo developers to redo Eliot's work or to eliminate
Pharo VM advancements from the Squeak / Newspeak community. The VM is the
one place where we can continue to work together for the benefit of all
three communities. We should not, if at all possible, diverge, lest we lose
some excellent contributions from some really terrific people, in one or
another community.

All the best,
Ron Teitelbaum

> If you skim over the diffs on Github [1], you will probably find that most
of the
> changes are necessary to adopt Pharo-specific API changes.
> Not sure what the best way forward would be to avoid having the two Squeak
> and Pharo flavors diverge even more.
>
> I am open to suggestions, don't have a good idea how to properly
'modularize'

> these differences myself.
>
> Best regards
> Stefan
>
> [1] https://github.com/pharo-project/pharo-vm/pull/18
>
> --
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/
>
>
>
>

Stefan Marr-3

Re: [Pharo-dev] [Vm-dev] Simulator in Pharo 3

Hi Ron:

On 13 Feb 2014, at 10:38, Ron Teitelbaum <[hidden email]> wrote:

>> I think the bigger question is whether you actually want to adopt those
> things.
>
> That the vm stays in sync should be a core requirement for our communities.

I am with you on that Ron. But I need a technical solution to manage those things.
Good intensions are one thing, but how do we do that?

Examples: [https://github.com/pharo-project/pharo-vm/pull/18/commits]

primitiveUpdateGZipCrc32
- self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on: GZipWriteStream crcTable].
+ self cCode:’' inSmalltalk:[zipCrcTable := CArrayAccessor on: CRC crc32Table].

primitiveGetAttribute

- attribute := Smalltalk getSystemAttribute: attr.
+ attribute := Smalltalk vm getSystemAttribute: attr.

CogVMSimulator>> initialize
- 'Display has not yet been installed' asDisplayText form.
+ 'Display has not yet been installed' asMorph imageForm.

ioRelinquishProcessorForMicroseconds
- Processor activeProcess == Project uiProcess ifTrue:
+ Processor activeProcess == UIManager default uiProcess ifTrue:

And so far, I only fixed trivial things. Still need to figure out what is going wrong with more recent Pharo images.

Best regards
Stefan

--
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/

Ron Teitelbaum

RE: [Pharo-dev] [Vm-dev] Simulator in Pharo 3

> Stefan Marr
> Hi Ron:
>
> On 13 Feb 2014, at 10:38, Ron Teitelbaum <[hidden email]> wrote:
>
> >> I think the bigger question is whether you actually want to adopt those
> > things.
> >
> > That the vm stays in sync should be a core requirement for our
communities.
>
> I am with you on that Ron. But I need a technical solution to manage those
> things.
> Good intensions are one thing, but how do we do that?
>

I think the answer is one at a time. With some collaboration and
negotiation. Refactoring is fine as long as it provides some value. It
doesn't have to be a change in function, a change in clarity suffices in my
opinion. The benefit needs to be worth the pain of change. Where we can
agree on the benefit the three communities should adopt it. Where we
disagree, each community should take on the pain of supporting their version
and we diverge. I'm confident that Eliot can manage to sync up what makes
sense. Hopefully he can also push back on what doesn't and you can sync up
on his changes or concerns.

With the good intention as a core goal on all sides, proper action follows.
All of this gets easier if we collaborate up front instead of trying to sync
after the fact.

All the best,

Ron Teitelbaum

> Examples: [https://github.com/pharo-project/pharo-vm/pull/18/commits]
>
> primitiveUpdateGZipCrc32
> - self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on:
> GZipWriteStream crcTable].
> + self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on: CRC
> crc32Table].
>
> primitiveGetAttribute
>
> - attribute := Smalltalk getSystemAttribute: attr.
> + attribute := Smalltalk vm getSystemAttribute: attr.
>
> CogVMSimulator>> initialize
> - 'Display has not yet been installed' asDisplayText form.
> + 'Display has not yet been installed' asMorph imageForm.
>
>
> ioRelinquishProcessorForMicroseconds
> - Processor activeProcess == Project uiProcess ifTrue:
> + Processor activeProcess == UIManager default uiProcess ifTrue:
>
>
> And so far, I only fixed trivial things. Still need to figure out what is

going wrong

> with more recent Pharo images.
>
> Best regards
> Stefan
>
> --
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/
>
>
>
>

J. Vuletich (mail lists)

Re: [Pharo-dev] [Vm-dev] Simulator in Pharo 3

In reply to this post by Stefan Marr-3

Hi Folks,

(below)

Quoting Stefan Marr <[hidden email]>:

> Hi Ron:
>
> On 13 Feb 2014, at 10:38, Ron Teitelbaum <[hidden email]> wrote:
>
>>> I think the bigger question is whether you actually want to adopt those
>> things.
>>
>> That the vm stays in sync should be a core requirement for our communities.
>
> I am with you on that Ron. But I need a technical solution to manage
> those things.
> Good intensions are one thing, but how do we do that?
>
> Examples: [https://github.com/pharo-project/pharo-vm/pull/18/commits]
>
> primitiveUpdateGZipCrc32
> - self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on:
> GZipWriteStream crcTable].
> + self cCode:’' inSmalltalk:[zipCrcTable := CArrayAccessor on: CRC
> crc32Table].
>
> primitiveGetAttribute
>
> - attribute := Smalltalk getSystemAttribute: attr.
> + attribute := Smalltalk vm getSystemAttribute: attr.
>
> CogVMSimulator>> initialize
> - 'Display has not yet been installed' asDisplayText form.
> + 'Display has not yet been installed' asMorph imageForm.
>
>
> ioRelinquishProcessorForMicroseconds
> - Processor activeProcess == Project uiProcess ifTrue:
> + Processor activeProcess == UIManager default uiProcess ifTrue:
>
>
> And so far, I only fixed trivial things. Still need to figure out
> what is going wrong with more recent Pharo images.
>
> Best regards
> Stefan
>
> --
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/

All these can be handled without much trouble in a new package
"VMMaker compatibility for Pharo" or such.

Cheers,
Juan Vuletich

Eliot Miranda-2

Re: [Pharo-dev] [Vm-dev] Simulator in Pharo 3

In reply to this post by Stefan Marr-3

On Thu, Feb 13, 2014 at 2:01 AM, Stefan Marr <[hidden email]> wrote:

Hi Ron:

On 13 Feb 2014, at 10:38, Ron Teitelbaum <[hidden email]> wrote:

>> I think the bigger question is whether you actually want to adopt those
> things.
>

> That the vm stays in sync should be a core requirement for our communities.

I am with you on that Ron. But I need a technical solution to manage those things.
Good intensions are one thing, but how do we do that?

I would implement isPharo/isSqueak/isNewspeak in VMClass. These can answer e.g. the value of a class variable. hence, below...

Examples: [https://github.com/pharo-project/pharo-vm/pull/18/commits]

primitiveUpdateGZipCrc32
- self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on: GZipWriteStream crcTable].
+ self cCode:’' inSmalltalk:[zipCrcTable := CArrayAccessor on: CRC crc32Table].

primitiveUpdateGZipCrc32
self cCode:''

inSmalltalk:[zipCrcTable := CArrayAccessor on: (self isPharo ifTrue: [CRC] ifFalse: [GZipWriteStream]) crcTable].

primitiveGetAttribute

- attribute := Smalltalk getSystemAttribute: attr.
+ attribute := Smalltalk vm getSystemAttribute: attr.

This is just my code base being a little out of date. Smalltalk vm getSystemAttribute: works in Squeak. I'll update my code.

CogVMSimulator>> initialize
- 'Display has not yet been installed' asDisplayText form.
+ 'Display has not yet been installed' asMorph imageForm.

This needs to be isPharo.

ioRelinquishProcessorForMicroseconds
- Processor activeProcess == Project uiProcess ifTrue:
+ Processor activeProcess == UIManager default uiProcess ifTrue:

Ditto, until Squeak changes?

And so far, I only fixed trivial things. Still need to figure out what is going wrong with more recent Pharo images.

But fab that the simulator is receiving attention on Pharo (and Tty's work with events is great too).

Now if there could be an automatic job to export whatever git state is the current official Pharo VM to a Monticello VMMaker package I'll be very much happier.

Also for this discussion should we continue to cross-post or is vm-dev an adequate forum? Answers from Pharoites please... I have to admit that I'm a bit troubled by how often subjects that are clearly vm-centric are raised on pharo-dev. To Pharoites perceive vm-dev as a squeak thing? If so, may I suggest pharo-vm-dev? If not, can the Pharo community make an effort to direct vm discussion towards vm-dev in future?

Best regards
Stefan

--
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/

--
best,

Eliot

Eliot Miranda-2

Re: [Pharo-dev] [Vm-dev] Simulator in Pharo 3

In reply to this post by Ron Teitelbaum

On Thu, Feb 13, 2014 at 6:19 AM, <[hidden email]> wrote:

[hidden email] wrote:

Ron,

Sure but at this time, not being able to run the simulator in a full Pharo environment is a severe issue.

The key advantage is that the Smalltalk VM is written in itself.

Now, what do I experience is that it is hard to embark on VM work.

Why? Even if the PharoVMBuilders help in generating and compiling the VM for several platforms (I can build for Windows 8.1, OSX, iOS, Debian 7 etc) this is only one part of the puzzle.

The next step, is to understand how things do work for real, the interpret() C loop isn't gonna help me one bit, I need to be able to simulate this one in a Simulator. And I want to do that on the Pharo platform. Currently on 2.0 - this will (again) be fun to get to work on 3.0.

I am not in the league of the VM maintainers obviously.

But Clement provided me with Eliot's Cog Simulation image, which works for his own work. But only his own. We do not have something like a Configuration to get the same thing. And that's a very acute pain. There are only so many hours in a day, true. So, in order to bring in more people/resources for the VM work, the barrier to entry should be moved a tad down.

We tried to have the StackSimulator working for a while (Stephan I'll definitely get your version, thanks for it). This is also because InterpreterSimulator doesn't work anymore and we have to use the StackInterpreter instead (which is complicated already vs pure interpreter).

All of this rant to say that having a clean interpreter and a basic image (Maybe PharoKernel/Hazelnut/Boostrapping/Spoon will give us a very simple image to simulate - the whole image isn't really needed. Hopefully Oz will also move us forward on that front).

A real Pharo image is overkill for this as a ton of plugins get involved etc.

The core system should be the same for Pharo/Squeak/... :

VMMaker-MemoryManager
VMMaker-Interpreter
VMMaker-InterpreterSimulation
VMMaker-MemoryManagerSimulation

and of course the Slang things (VMMaker-Support and VMMaker-Translation to C).

What I'd love to end up with is an embeddable VM that we could hook into other environments, languages etc (a bit like TCL for example). This requires work on how the VM core runs. And to explore this, simulation is needed.

Sorry for the long post. I wish I was a millionaire to pour in some cash into the project to speed some areas up. Working on it :-) Maybe should we work in that direction for funding. http://www.gv.com/ where are you?

Phil

Getting the simulator working in Pharo could be a GSoC project? or is it too advanced?

If you guys would read and contribute to vm-dev you'd already know that someone with no VM experience (tty) just implemented event processing for the simulator window. The simulator only supported the old polling event architecture. So no it's not too advanced. But more importantly why aren't you all discussing vm stuff on the vm forum?

cheers -ben

--
best,

Eliot

David T. Lewis

Re: [Pharo-dev] [Vm-dev] Simulator in Pharo 3

In reply to this post by J. Vuletich (mail lists)

Sorry for top posting.

Juan is right. The kind of differences we are discussing here are related
to user interface and file system differences in the various images, and
this can be handled with a compatibility package for Pharo.

It also can be done by merging into VMMaker (oscog branch), although this
tends to get messy as Pharo diverges further from Squeak. I would defer to
Eliot as to which approach he would prefer, since it most directly affects
the oscog branch for now. But FWIW, I think that Juan's suggestion is the
most straightforward and easiest to maintain over time.

Dave

> Hi Folks,
>
> (below)
>
> Quoting Stefan Marr <[hidden email]>:
>
>> Hi Ron:
>>
>> On 13 Feb 2014, at 10:38, Ron Teitelbaum <[hidden email]> wrote:
>>
>>>> I think the bigger question is whether you actually want to adopt
>>>> those
>>> things.
>>>
>>> That the vm stays in sync should be a core requirement for our
>>> communities.
>>
>> I am with you on that Ron. But I need a technical solution to manage
>> those things.
>> Good intensions are one thing, but how do we do that?
>>
>> Examples: [https://github.com/pharo-project/pharo-vm/pull/18/commits]
>>
>> primitiveUpdateGZipCrc32
>> - self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on:
>> GZipWriteStream crcTable].
>> + self cCode:â' inSmalltalk:[zipCrcTable := CArrayAccessor on: CRC
>> crc32Table].
>>
>> primitiveGetAttribute
>>
>> - attribute := Smalltalk getSystemAttribute: attr.
>> + attribute := Smalltalk vm getSystemAttribute: attr.
>>
>> CogVMSimulator>> initialize
>> - 'Display has not yet been installed' asDisplayText form.
>> + 'Display has not yet been installed' asMorph imageForm.
>>
>>
>> ioRelinquishProcessorForMicroseconds
>> - Processor activeProcess == Project uiProcess ifTrue:
>> + Processor activeProcess == UIManager default uiProcess ifTrue:
>>
>>
>> And so far, I only fixed trivial things. Still need to figure out
>> what is going wrong with more recent Pharo images.
>>
>> Best regards
>> Stefan
>>
>> --
>> Stefan Marr
>> INRIA Lille - Nord Europe
>> http://stefan-marr.de/research/
>
> All these can be handled without much trouble in a new package
> "VMMaker compatibility for Pharo" or such.
>
> Cheers,
> Juan Vuletich
>
>

Stefan Marr-3

Re: Simulator in Pharo 3

In reply to this post by Eliot Miranda-2

Hi Eliot:

On 13 Feb 2014, at 18:26, Eliot Miranda <[hidden email]> wrote:

> I would implement isPharo/isSqueak/isNewspeak in VMClass. These can answer e.g. the value of a class variable. hence, below…

Hm, this looks really ugly, no? Perhaps with one more indirection of a proper helper method where it makes sense?
Will try to look into it tomorrow.

> Also for this discussion should we continue to cross-post or is vm-dev an adequate forum? Answers from Pharoites please... I have to admit that I'm a bit troubled by how often subjects that are clearly vm-centric are raised on pharo-dev. To Pharoites perceive vm-dev as a squeak thing? If so, may I suggest pharo-vm-dev? If not, can the Pharo community make an effort to direct vm discussion towards vm-dev in future?

Sorry, my fault. I considered it originally a Pharo-only issue, because the simulator seems to work in Squeak.

Best regards
Stefan

--
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/

ccrraaiigg

Re: Simulator in Pharo 3

In reply to this post by Ron Teitelbaum

(followups to vm-dev, please)

Hi Phil--

> ...having a clean interpreter and a basic image (Maybe
> PharoKernel/Hazelnut/Boostrapping/Spoon will give us a very simple
> image to simulate - the whole image isn't really needed).

Yeah, the simulator is crucial to the Spoon[1] work, and I've kept
it working for its development memories at all times. None of those
memories have GUIs in them, but I am simulating things that were never
simulated before, like live network access (so remote messaging between
a simulated memory and a normal one works).

thanks,

-C

[1] http://netjam.org/spoon

--
Craig Latta
www.netjam.org/resume
+31 6 2757 7177 (SMS ok)
+ 1 415 287 3547 (no SMS)

Eliot Miranda-2

Re: Simulator in Pharo 3

In reply to this post by Stefan Marr-3

On Thu, Feb 13, 2014 at 11:56 AM, Stefan Marr <[hidden email]> wrote:

Hi Eliot:

On 13 Feb 2014, at 18:26, Eliot Miranda <[hidden email]> wrote:

> I would implement isPharo/isSqueak/isNewspeak in VMClass. These can answer e.g. the value of a class variable. hence, below…

Hm, this looks really ugly, no? Perhaps with one more indirection of a proper helper method where it makes sense?

Sure, knock yourself out. The simulator isn't pretty, but avoiding adding new warts is fine. Just don't obfuscate.

Will try to look into it tomorrow.

thanks, lovely. i already addressed the getSystemParameter: issue.

> Also for this discussion should we continue to cross-post or is vm-dev an adequate forum? Answers from Pharoites please... I have to admit that I'm a bit troubled by how often subjects that are clearly vm-centric are raised on pharo-dev. To Pharoites perceive vm-dev as a squeak thing? If so, may I suggest pharo-vm-dev? If not, can the Pharo community make an effort to direct vm discussion towards vm-dev in future?

Sorry, my fault. I considered it originally a Pharo-only issue, because the simulator seems to work in Squeak.

But its a VM issue and we should discuss vm issues in the vm forum. Otherwise the community's vm development is in danger (IMO) of being as balkanised as the Pharo/Squeak split and that would break my heart and lower my motivation.

Best regards
Stefan

--
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/

--
best,

Eliot

tty

Simulated mousEvents are now pure morphic...your thoughts on tackling keyboard events requested

Hi All,

I got pure Morphic MouseEvents forwarded just fine (thanks to your help on the bit-fiddling) and the translation is good enough to pop up a menu from the top menu bar.
I had a screenshot, but it bounced the first iteration of this message, so you will have to take my word on that. (:

Next up is KeyboardEvents and at first glance it looks a bit daunting. Here is why.

This method in HandMorph invokes one of ~18 subclasses of KeyboardInputInterpreter

HandMorph>>generateKeyboardEvent: evtBuf
      ....
    type = #keystroke
        ifTrue: [keyValue := (self keyboardInterpreter nextCharFrom: Sensor firstEvt: evtBuf) asInteger]
      ...

That nextCharFrom: firstEvt: send is where it gets interesting as it is keyboard specific.

To see why, compare the implementation in

MacRomanInputInterpreter >>nextCharFrom: sensor firstEvt: evtBuf

    | keyValue |
    keyValue := evtBuf third.
    ^ keyValue asCharacter macToSqueak.

UnicodeInputInterpreter>>nextCharFrom: sensor firstEvt: evtBuf
    "Compose Unicode character sequences"
    | peekEvent keyValue composed |
    "Only try this if the first event is composable and is a character event"
    ((Unicode isComposable: (keyValue := evtBuf sixth))
        and:[evtBuf fourth = EventKeyChar]) ifTrue:[
            "If we have a pending keyDown in the queue, skip that to get to the keystroke"
            peekEvent := sensor peekEvent.
            (peekEvent notNil and: [peekEvent fourth = EventKeyDown]) ifTrue: [
                "skipEvent := "sensor nextEvent.
                peekEvent := sensor peekEvent].
            "If we have another character event in the queue, compose it"
            (peekEvent notNil
                and: [peekEvent first = EventTypeKeyboard
                and:[peekEvent fourth = EventKeyChar]]) ifTrue:[
                    composed := Unicode compose: keyValue with: peekEvent sixth.
                    composed ifNotNil:[
                        sensor nextEvent.
                        ^composed]]].
    "XXXX: Fixme. We should put the skipped event back if we haven't consumed it."
    ^keyValue asCharacter

So, assume I have to stuff some unknown character into a primitive event to feed to the simulator....I don't think "skooch and tack on" is going to work like it did for the mouseEvents.

I will be examining this more closely in a day or two as I have to focus on some work for a client, but wanted to get it out there for your thoughts on the matter in the meantime.

Thanks.

tty.

P.S. David, when you get time, Eliot mentioned getting with you so I could contribute my work. Let me know what I need to do at your convenience.

Bert Freudenberg

Re: Simulated mousEvents are now pure morphic...your thoughts on tackling keyboard events requested

On 14.02.2014, at 00:34, gettimothy <[hidden email]> wrote:

> Hi All,
>
> I got pure Morphic MouseEvents forwarded just fine (thanks to your help on the bit-fiddling) and the translation is good enough to pop up a menu from the top menu bar.

Nice! :)

> Next up is KeyboardEvents and at first glance it looks a bit daunting.

Key stroke events are pretty simple: you just put the ASCII code into one field and the Unicode into another. This is the same on pretty much any platform now.

But for full emulation you also need to emulate key down and key up events. Those are platform-specific, each has their own raw key codes. Unfortunately we never took the time to make all platforms present key codes uniformly. (We could still do it: up/down events are almost completely unused, partly because of this problem).

If you want to emulate up/down events, I think your best bet will be to emulate a Windows VM. Because on Windows, the keycodes are based on ASCII - the 'a' key has key code 65. This must be independent on whether shift is pressed or not, because it refers to the physical key. If you wanted to emulate Mac you'ld have to generate Mac key codes (A=0, S=1, D=2, F=3, etc). Unix/X11 might be easier too, I think it uses X11 keysyms, but IIRC the Unix VM does give different key codes for a and shift-a, which is wrong.

- Bert -

smime.p7s (5K) Download Attachment

tty

Re: Simulated mousEvents are now pure morphic...your thoughts on tackling keyboard events requested

Bert.

Thanks.

You mentioned that ".. we never took the time to make all platforms present key codes uniformly. (We could still do it: up/down events are almost completely unused, partly because of this problem)...."

This sounds like fun. I will poke around and try to understand the sub-system and get back to the list.

Cheers.

tty.

---- On Fri, 14 Feb 2014 02:33:45 -0800 Bert Freudenberg<[hidden email]> wrote ----

On 14.02.2014, at 00:34, gettimothy <[hidden email]> wrote:

> Hi All,
>
> I got pure Morphic MouseEvents forwarded just fine (thanks to your help on the bit-fiddling) and the translation is good enough to pop up a menu from the top menu bar.

Nice! :)

> Next up is KeyboardEvents and at first glance it looks a bit daunting.

Key stroke events are pretty simple: you just put the ASCII code into one field and the Unicode into another. This is the same on pretty much any platform now.

But for full emulation you also need to emulate key down and key up events. Those are platform-specific, each has their own raw key codes. Unfortunately we never took the time to make all platforms present key codes uniformly. (We could still do it: up/down events are almost completely unused, partly because of this problem).

If you want to emulate up/down events, I think your best bet will be to emulate a Windows VM. Because on Windows, the keycodes are based on ASCII - the 'a' key has key code 65. This must be independent on whether shift is pressed or not, because it refers to the physical key. If you wanted to emulate Mac you'ld have to generate Mac key codes (A=0, S=1, D=2, F=3, etc). Unix/X11 might be easier too, I think it uses X11 keysyms, but IIRC the Unix VM does give different key codes for a and shift-a, which is wrong.

- Bert -

Frank Shearar-3

Re: Simulated mousEvents are now pure morphic...your thoughts on tackling keyboard events requested

On 14 February 2014 11:57, gettimothy <[hidden email]> wrote:

>
> Bert.
>
> Thanks.
>
> You mentioned that ".. we never took the time to make all platforms present key codes uniformly. (We could still do it: up/down events are almost completely unused, partly because of this problem)...."
>
> This sounds like fun. I will poke around and try to understand the sub-system and get back to the list.
>
> Cheers.

Could this be enough work for a GSoC project? (I say this knowing I
might tread on your toes here, tty - not wanting to, nor wanting to
take anything away from either your fun or your contributions: just
wondering if we could someone to pay for this kind've work, and thus
maximise VM work.)

frank

> tty.
>
>
>
> ---- On Fri, 14 Feb 2014 02:33:45 -0800 Bert Freudenberg<[hidden email]> wrote ----
>
> On 14.02.2014, at 00:34, gettimothy <[hidden email]> wrote:
>
>> Hi All,
>>
>> I got pure Morphic MouseEvents forwarded just fine (thanks to your help on the bit-fiddling) and the translation is good enough to pop up a menu from the top menu bar.
>
> Nice! :)
>
>> Next up is KeyboardEvents and at first glance it looks a bit daunting.
>
> Key stroke events are pretty simple: you just put the ASCII code into one field and the Unicode into another. This is the same on pretty much any platform now.
>
> But for full emulation you also need to emulate key down and key up events. Those are platform-specific, each has their own raw key codes. Unfortunately we never took the time to make all platforms present key codes uniformly. (We could still do it: up/down events are almost completely unused, partly because of this problem).
>
> If you want to emulate up/down events, I think your best bet will be to emulate a Windows VM. Because on Windows, the keycodes are based on ASCII - the 'a' key has key code 65. This must be independent on whether shift is pressed or not, because it refers to the physical key. If you wanted to emulate Mac you'ld have to generate Mac key codes (A=0, S=1, D=2, F=3, etc). Unix/X11 might be easier too, I think it uses X11 keysyms, but IIRC the Unix VM does give different key codes for a and shift-a, which is wrong.
>
> - Bert -
>
>
>

Stefan Marr-3

Re: Simulator in Pharo 3

In reply to this post by Eliot Miranda-2

Hi Eliot:

On 13 Feb 2014, at 21:04, Eliot Miranda <[hidden email]> wrote:

> thanks, lovely. i already addressed the getSystemParameter: issue.

In the StackInterpreterSimulator, the various #run… methods do unconditionally the initialization of stack pages and initial context.
This looks wrong to me, especially since the comment of #runForNBytes: says that I should be able to use it repeatedly.
I would move the initialization to #initializeInterpreter: in StackInterpreterSimulator and remove it from all the run methods. See [1].

So, with all latest changes the code below gives you a StackInterpreterSimulator that executes the latest Pharo images.
Until it runs into inconsistent values in the BalloonEngineSimulation. But for many cases this should already be more than sufficient.

InterpreterStackPage initialize.
StackInterpreterSimulator initializeWithOptions: Dictionary new.
sim := StackInterpreterSimulator new.
sim openOn: 'Pharo.image'.
sim openAsMorph.
sim initStackPages.
sim loadInitialContext.
1 to: 500 do: [:i |
sim runForNBytes: 100000.
World doOneCycleNow ].

At the moment, there seem to be strange interactions going on between the simulator and the rest of the system.
At least using `[sim run] fork` doesn’t work properly, and I suppose until the event handling is fixed #run will not work completely either.

Please note, all changes I did is merely fixing bit rot, nothing really broken.
I assume that the BalloonEngine issue would take a little more to debug, but I am not sure what it is in the first place. So interested parties could try it comment.

Best regards
Stefan

[1] https://github.com/smarr/pharo-vm/commit/114f5b3db0ff2185ca5eac0d033eb95b99f524cb

--
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/

Stefan Marr-3

Re: Simulated mousEvents are now pure morphic...your thoughts on tackling keyboard events requested

In reply to this post by tty

Hi tty:

I have been loosely following your work on getting the simulator working properly.
Is the code available somewhere? Would like to have a look and try to adapt it if necessary for the simulator on top of Pharo3.

Thanks
Stefan

--
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/

tty

Re: Simulated mousEvents are now pure morphic...your thoughts on tackling keyboard events requested

In reply to this post by Frank Shearar-3

I need some money! Does GSoC apply to free-lancers with dwindling client bases?

---- On Fri, 14 Feb 2014 04:25:39 -0800 Frank Shearar<[hidden email]> wrote ----

On 14 February 2014 11:57, gettimothy <[hidden email]> wrote:

>
> Bert.
>
> Thanks.
>
> You mentioned that ".. we never took the time to make all platforms present key codes uniformly. (We could still do it: up/down events are almost completely unused, partly because of this problem)...."
>
> This sounds like fun. I will poke around and try to understand the sub-system and get back to the list.
>
> Cheers.

Could this be enough work for a GSoC project? (I say this knowing I
might tread on your toes here, tty - not wanting to, nor wanting to
take anything away from either your fun or your contributions: just
wondering if we could someone to pay for this kind've work, and thus
maximise VM work.)

frank

> tty.
>
>
>
> ---- On Fri, 14 Feb 2014 02:33:45 -0800 Bert Freudenberg<[hidden email]> wrote ----
>
> On 14.02.2014, at 00:34, gettimothy <[hidden email]> wrote:
>
>> Hi All,
>>
>> I got pure Morphic MouseEvents forwarded just fine (thanks to your help on the bit-fiddling) and the translation is good enough to pop up a menu from the top menu bar.
>
> Nice! :)
>
>> Next up is KeyboardEvents and at first glance it looks a bit daunting.
>
> Key stroke events are pretty simple: you just put the ASCII code into one field and the Unicode into another. This is the same on pretty much any platform now.
>
> But for full emulation you also need to emulate key down and key up events. Those are platform-specific, each has their own raw key codes. Unfortunately we never took the time to make all platforms present key codes uniformly. (We could still do it: up/down events are almost completely unused, partly because of this problem).
>
> If you want to emulate up/down events, I think your best bet will be to emulate a Windows VM. Because on Windows, the keycodes are based on ASCII - the 'a' key has key code 65. This must be independent on whether shift is pressed or not, because it refers to the physical key. If you wanted to emulate Mac you'ld have to generate Mac key codes (A=0, S=1, D=2, F=3, etc). Unix/X11 might be easier too, I think it uses X11 keysyms, but IIRC the Unix VM does give different key codes for a and shift-a, which is wrong.
>
> - Bert -
>
>
>