Stefan Marr

Hi Eliot:

On 13 Feb 2014, at 05:46, Eliot Miranda eliot.miranda@gmail.com 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 Hi Ron:

On 13 Feb 2014, at 10:38, Ron Teitelbaum Ron@USMedRec.com 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/

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 smalltalk@stefan-marr.de:

...

Hi Ron:

On 13 Feb 2014, at 10:38, Ron Teitelbaum Ron@USMedRec.com 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

Hi Eliot:

On 13 Feb 2014, at 18:26, Eliot Miranda eliot.miranda@gmail.com 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

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.

to

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.

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<bert@freudenbergs.de> wrote ----

On 14.02.2014, at 00:34, gettimothy <gettimothy@zoho.com> 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 -

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<frank.shearar@gmail.com> wrote ----

On 14 February 2014 11:57, gettimothy <gettimothy@zoho.com> 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<bert@freudenbergs.de> wrote ---- > > On 14.02.2014, at 00:34, gettimothy <gettimothy@zoho.com> 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 - > > >

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

A image with all the vm simulater stuff loaded would be great! Maybe it could be arranged so it could be available at ftp.squeak.org ? That would be really cool :-)

Cheers, Karl

On Fri, Feb 14, 2014 at 2:08 PM, gettimothy gettimothy@zoho.com wrote:

Hi Stefan,

I contacted David about repository access; I will let you know when it is available.

cordially,

tty

---- On Fri, 14 Feb 2014 04:39:58 -0800 *Stefan Marr<smalltalk@stefan-marr.de smalltalk@stefan-marr.de>* wrote ----

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/

On Fri, Feb 14, 2014 at 02:52:43PM -0800, Eliot Miranda wrote:

On Fri, Feb 14, 2014 at 5:22 AM, karl ramberg karlramberg@gmail.com wrote:

...

A image with all the vm simulater stuff loaded would be great! Maybe it could be arranged so it could be available at ftp.squeak.org ?

Actually there's one in

http://www.squeakvm.org/svn/squeak/branches/Cog/image/%7BCogTrunk43.image,Co...

but I don't update it often enough. Keeping one on ftp.squeak.org is a much better idea. But it needs to be built automatically, and only after a successful VM build. So I think its a fair bit of work to get to, but something I'm trying ot get to in my spare cycles (I got a MacMini for xmas to use to build VMs, but its not yet a priority).

Automated builds ... that reminds me (and sorry I did not mention it before), there seems to be a missing class initialization that affects code generation when oscog VMMaker is loaded into a fresh Squeak image. Symptoms show up on build.squeak.org:

http://build.squeak.org/job/CogVM/492/console

The ProcessorClass class variable in Cogit needs to be initialized to some default (probably BochsIA32Alien class). I think that this is supposed to be done by Cogit class>>initializeMiscConstants, so there is probably just a missing class initializer somewhere.

Dave

Hi David,

---- On Fri, 14 Feb 2014 05:25:42 -0800 David T. Lewis&lt;lewis@mail.msen.com&gt; wrote ----

Hi tty,

Did you send email to me? I'm afraid that I missed it, sorry. Was this related to the simulator support for Pharo 3.0?

Dave

A while ago Eliot asked me to do the following (from my todo list):

+ [ ] Three things (Eliot) + [X ] figure out how to do it without modifying base packages, confining changes to VMMaker. + [ ] ask David Lewis for write permission to the VMMaker repository. + [ ] commit your changed version of VMMaker, from which I can merge :-) &lt;--I will do 2 and 3 when we all agree the approach is sane.repl

It appears the approach is sane and changes are confined to base packages so I figured now was the time to contact you for write permission. I would like to add a caveat that my submissions be peer-reviewed if possible before write as I don't want to create a mess via my inexperience.

thx.

tty

Hi Dave.

&gt;Thanks, sorry I had missed your earlier note. Can you please go to http://source.squeak.org &gt;and register there? Let me know your user id when this is done, and I'll add you to the &gt;VMMaker project.

&gt;Dave

done. username: tty

Hi Eliot:

On 13 Feb 2014, at 21:04, Eliot Miranda eliot.miranda@gmail.com 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/114f5b3db0ff2185ca5eac0d033eb95b99f...

Hi Eliot:

On 14 Feb 2014, at 23:48, Eliot Miranda eliot.miranda@gmail.com wrote:

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].

I agree. This would be really nice. But alas the stack zone must be alloca’ed when first entering the interpreter :-(.

My change is purely in the simulator. I doubt that it has any negative consequences. At least with my superficial understanding.

See https://github.com/smarr/pharo-vm/commit/114f5b3db0ff2185ca5eac0d033eb95b99f...

I see this occasionally and don't understand the code well enough to fix it. But it seems a false error. if you proceed through the inconsistent value errors the system keeps on running. Is there anyone out there who understands the BalloonPlugin well enough to fix it? I’ve tweaked out some of the errors (and not broken anything) but it is not something I understand.

Same here, but I actually didn’t try to skip them.

Hope some people start using the simulator now and will report back.

Best regards Stefan