thanks guillermo :) Cleaning events at VM level is important. On Aug 6, 2013, at 4:32 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:

On Tue, Aug 6, 2013 at 3:40 PM, Igor Stasenko <siguctua@gmail.com> wrote: I changed this method to see better what happens: HandMorph class>>showDebugEvent: evt

ShowEvents == true ifTrue: [ | ofs| Display fill: (0@0 extent: 500@120) rule: Form over fillColor: Color white. ofs := (owner hands indexOf: self) - 1 * 60. evt printString displayAt: (0@ofs) + (evt isKeyboard ifTrue: [0@30] ifFalse: [0@0]). self keyboardFocus printString displayAt: (0@ofs)+(0@45).

evt isKeyboard ifTrue: [ Transcript show: evt printString;cr ] ].

KeyboardEvent>> printOn: aStream "Print the receiver on a stream"

aStream nextPut: $[. aStream nextPutAll: type; nextPutAll: ' '''. self printKeyStringOn: aStream. aStream nextPut: $'.

aStream space; nextPutAll: 'keyValue: ', self keyValue asString.

aStream nextPut: $]

set HandMorph showEvents:true

Now, pressing single space, gives me this:

[keyDown ' ' keyValue: 49] [keystroke ' ' keyValue: 32] [keyUp ' ' keyValue: 49] [keyUp ' ' keyValue: 49]

Pressing delete key (or fn-backspace , for those who having a lot of spare fingers to use bad keyboards):

[keyDown ' ' keyValue: 117] [keystroke '⌦' keyValue: 188] [keyUp ' ' keyValue: 117] [keyUp ' ' keyValue: 117]

now, can someone tell me , why there is 2 keyUp events for each keyDown?

That I don't know

and of course, main question is why key values are different for keydown and keystroke events?

That I'll dive right now into the vm to see what it is :).

(and why delete key is not 127, but 117 or 188?)

Editor expecting 127:

cmdMap at: (127 + 1) put: #forwardDelete:. "del key"

-- Best regards, Igor Stasenko.

ah, forgot to say. Latest vms from jenkins should be ready in a while, not yet :). On Tue, Aug 6, 2013 at 5:46 PM, Guillermo Polito <guillermopolito@gmail.com>wrote:

On Tue, Aug 6, 2013 at 4:53 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:

...

thanks guillermo :) Cleaning events at VM level is important.

Cleaning is not sooooo easy :).

I've been able to reproduce some of these problems (the delete key and the double keyUp:). I've tried to fix them, bah, actually I did in here, but I'd like someone else tests in their keyboard layouts in their homes :).

Regarding the difference of the keyValues between keyUp and keyDown, I did not address it, and it kinda orthogonal, nothing to do with this particular issue.

To see my changes, people can have a look at the diff in here:

https://gitorious.org/cogvm/blessed/commit/2214cee58a5c5266b8ab2322b98471553...

I'd like to start putting this in some issue tracker. Cog issue tracker or Pharo one? :) Esteban?

...

On Aug 6, 2013, at 4:32 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:

On Tue, Aug 6, 2013 at 3:40 PM, Igor Stasenko <siguctua@gmail.com> wrote:

...

I changed this method to see better what happens: HandMorph class>>showDebugEvent: evt

ShowEvents == true ifTrue: [ | ofs| Display fill: (0@0 extent: 500@120) rule: Form over fillColor: Color white. ofs := (owner hands indexOf: self) - 1 * 60. evt printString displayAt: (0@ofs) + (evt isKeyboard ifTrue: [0@30] ifFalse: [0@0]). self keyboardFocus printString displayAt: (0@ofs)+(0@45 ).

evt isKeyboard ifTrue: [ Transcript show: evt printString;cr ] ].

KeyboardEvent>> printOn: aStream "Print the receiver on a stream"

aStream nextPut: $[. aStream nextPutAll: type; nextPutAll: ' '''. self printKeyStringOn: aStream. aStream nextPut: $'.

aStream space; nextPutAll: 'keyValue: ', self keyValue asString.

aStream nextPut: $]

set HandMorph showEvents:true

Now, pressing single space, gives me this:

[keyDown ' ' keyValue: 49] [keystroke ' ' keyValue: 32] [keyUp ' ' keyValue: 49] [keyUp ' ' keyValue: 49]

Pressing delete key (or fn-backspace , for those who having a lot of spare fingers to use bad keyboards):

[keyDown ' ' keyValue: 117] [keystroke '⌦' keyValue: 188] [keyUp ' ' keyValue: 117] [keyUp ' ' keyValue: 117]

now, can someone tell me , why there is 2 keyUp events for each keyDown?

That I don't know

...

and of course, main question is why key values are different for keydown and keystroke events?

That I'll dive right now into the vm to see what it is :).

...

(and why delete key is not 127, but 117 or 188?)

Editor expecting 127:

cmdMap at: (127 + 1) put: #forwardDelete:. "del key"

-- Best regards, Igor Stasenko.

Not sure you have two keyup. but down, up, and then keypressed should be the right order. Because there is no char pressed until up. Phil On Tuesday, August 6, 2013, Guillermo Polito <guillermopolito@gmail.com> wrote:

And the removal of the debugging code is here https://gitorious.org/cogvm/blessed/commit/9e2a77928edf0144f0d5c42ada66eb189...;)

On Tue, Aug 6, 2013 at 5:47 PM, Guillermo Polito < guillermopolito@gmail.com> wrote:

ah, forgot to say. Latest vms from jenkins should be ready in a while, not yet :).

On Tue, Aug 6, 2013 at 5:46 PM, Guillermo Polito < guillermopolito@gmail.com> wrote:

On Tue, Aug 6, 2013 at 4:53 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:

thanks guillermo :) Cleaning events at VM level is important.

Cleaning is not sooooo easy :). I've been able to reproduce some of these problems (the delete key and the double keyUp:). I've tried to fix them, bah, actually I did in here, but I'd like someone else tests in their keyboard layouts in their homes :). Regarding the difference of the keyValues between keyUp and keyDown, I did not address it, and it kinda orthogonal, nothing to do with this particular issue. To see my changes, people can have a look at the diff in here:

https://gitorious.org/cogvm/blessed/commit/2214cee58a5c5266b8ab2322b98471553...

I'd like to start putting this in some issue tracker. Cog issue tracker

or Pharo one? :) Esteban?

On Aug 6, 2013, at 4:32 PM, Guillermo Polito <guillermopolito@gmail.com>

wrote:

On Tue, Aug 6, 2013 at 3:40 PM, Igor Stasenko <siguctua@gmail.com> wrote:

I changed this method to see better what happens: HandMorph class>>showDebugEvent: evt

ShowEvents == true ifTrue: [ | ofs| Display fill: (0@0 extent: 500@120) rule: Form over fillColor: Color white. ofs := (owner hands indexOf: self) - 1 * 60. evt printString displayAt: (0@ofs) + (evt isKeyboard ifTrue: [0@30] ifFalse: [0@0]). self keyboardFocus printString displayAt: (0@ofs)+(0@45).

evt isKeyboard ifTrue: [ Transcript show: evt

printString;cr ]

].

KeyboardEvent>> printOn: aStream "Print the receiver on a stream"

aStream nextPut: $[. aStream nextPutAll: type; nextPutAll: ' '''. self printKeyStringOn: aStream. aStream nextPut: $'.

aStream space; nextPutAll: 'keyValue: ', self keyValue asString.

aStream nextPut: $]

set HandMorph showEvents:true

Now, pressing single space, gives me this:

[keyDown ' ' keyValue: 49] [keystroke ' ' keyValue: 32] [keyUp ' ' keyValue: 49] [keyUp ' ' keyValue: 49]

Pressing delete key (or fn-backspace , for those who having a lot of spare fingers to use bad keyboards):

[keyDown ' ' keyValue: 117] [keystroke '⌦' keyValue: 188] [keyUp ' ' keyValue: 117] [keyUp ' ' keyValue: 117]

now, can someone tell me , why there is 2 keyUp events

-- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Featured on the Software Process and Measurement Cast http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

On Tue, Aug 6, 2013 at 8:06 PM, Igor Stasenko <siguctua@gmail.com> wrote:

On 6 August 2013 17:47, Guillermo Polito <guillermopolito@gmail.com> wrote:

...

ah, forgot to say. Latest vms from jenkins should be ready in a while, not yet :).

yes, and that's why i want you to answer a following question: why you think the repository was named 'blessed' as in [1]?

I don't know... That some saint has come and blessed it? :) If not, point me to where it is explained, is there a wiki page or something? Igor, I do not know how to read that question. Now, really: - I thought that moving the VM repository to gitorious was meant to open it. If only a couple of people (lets say you, Camilo and Esteban) have the rights to commit, then I feel it defeats the purpose - Maybe I should make a pull-request, but you can see that there are three there, one for at least one year, waiting for integration and probably out of date [1] - to me one benefit of using a CVS is that it gives you the ability to revert and going back in the history, and there are not much commits in cog to traverse... So, if it is really broken we go back and there are no problems. Should I be afraid of committing something? - As Stef says, you only can break if you do... - Now, maybe I should continue not trying to fix some stuff in the vm if people get pissed off when using latest and a bug is found [1] https://gitorious.org/cogvm/blessed/merge_requests

[1] https://gitorious.org/cogvm/blessed/

...

On Tue, Aug 6, 2013 at 5:46 PM, Guillermo Polito <

guillermopolito@gmail.com>

...

wrote:

...

On Tue, Aug 6, 2013 at 4:53 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

thanks guillermo :) Cleaning events at VM level is important.

Cleaning is not sooooo easy :).

I've been able to reproduce some of these problems (the delete key and

the

...

double keyUp:). I've tried to fix them, bah, actually I did in here, but I'd like someone else tests in their keyboard layouts in their homes :).

Regarding the difference of the keyValues between keyUp and keyDown, I did not address it, and it kinda orthogonal, nothing to do with this particular issue.

To see my changes, people can have a look at the diff in here:

https://gitorious.org/cogvm/blessed/commit/2214cee58a5c5266b8ab2322b98471553...

...

I'd like to start putting this in some issue tracker. Cog issue tracker

or

...

Pharo one? :) Esteban?

...

On Aug 6, 2013, at 4:32 PM, Guillermo Polito <

guillermopolito@gmail.com>

...

wrote:

On Tue, Aug 6, 2013 at 3:40 PM, Igor Stasenko <siguctua@gmail.com> wrote:

...

I changed this method to see better what happens: HandMorph class>>showDebugEvent: evt

ShowEvents == true ifTrue: [ | ofs| Display fill: (0@0 extent: 500@120) rule: Form over fillColor: Color white. ofs := (owner hands indexOf: self) - 1 * 60. evt printString displayAt: (0@ofs) + (evt isKeyboard ifTrue: [0@30] ifFalse: [0@0]). self keyboardFocus printString displayAt: (0@ofs)+(0@45).

evt isKeyboard ifTrue: [ Transcript show: evt printString;cr ] ].

KeyboardEvent>> printOn: aStream "Print the receiver on a stream"

aStream nextPut: $[. aStream nextPutAll: type; nextPutAll: ' '''. self printKeyStringOn: aStream. aStream nextPut: $'.

aStream space; nextPutAll: 'keyValue: ', self keyValue asString.

aStream nextPut: $]

set HandMorph showEvents:true

Now, pressing single space, gives me this:

[keyDown ' ' keyValue: 49] [keystroke ' ' keyValue: 32] [keyUp ' ' keyValue: 49] [keyUp ' ' keyValue: 49]

Pressing delete key (or fn-backspace , for those who having a lot of spare fingers to use bad keyboards):

[keyDown ' ' keyValue: 117] [keystroke '⌦' keyValue: 188] [keyUp ' ' keyValue: 117] [keyUp ' ' keyValue: 117]

now, can someone tell me , why there is 2 keyUp events for each

keyDown?

That I don't know

...

and of course, main question is why key values are different for keydown and keystroke events?

That I'll dive right now into the vm to see what it is :).

...

(and why delete key is not 127, but 117 or 188?)

Editor expecting 127:

cmdMap at: (127 + 1) put: #forwardDelete:. "del key"

-- Best regards, Igor Stasenko.

-- Best regards, Igor Stasenko.

On Tue, Aug 6, 2013 at 9:33 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:

I imagine that having a branch is the way to go.

To me, a branch is a fork in the code. That is, you split and they evolve differently. If you want to tag a version as stable, you use a tag :). And git already supports all that. But we don't use it ;). However, branches make sense to me if we have for example - vm for pharo2 - vm for pharo3 - vm .... With that setup, in the pharo2 branch we can backport fixes from the pharo3 branch, but they may evolve differently. And more importantly, we do not need to maintain all the compatibility with the world. Whoever wants a pharo2 vm, they go to the pharo2 branch, which on release is freezed (as well as the image). Now, in Git, I do not think there is a need for having many repositories for that. It's enough with branches and tags...

Like that esteban can integrate the fixes of eliot and you do not stress to finish.

Yes, but esteban has already lots of things to do :). And every time I made a pull request, a had to push it myself into the main branch because if not, nobody did it. And ask Camillo, he was in the same situation... In the image side we have Stef, Marcus and Esteban that integrate fixes. In the vm side it's only Esteban :/. Once this is ready there is a merge.

But that's what happen today, only the naming is bad in the git branch :). - We have a stable VM, which you can download as stable. That VM does not have the latest changes. I do not know if there is a tag, but there should be. - We have a unstable VM, which we call latest. It has the latest sources which we should test and prove before "blessing" it as the stable.

At least this is what I was thinking the process was: one main blessed stream

several others at different level of maturity with the ultimate goal to

avoid bottleneck.

Yes, but with that we lack also a good management of the issue tracking and stuff :). Above in this thread I was asking where do I submit an issue. Maybe we should put everything in the pharo issue tracker and be happy with only one tool. BTW, tomorrow I go to lille, we can discuss if you have some minutes :).

Stef

On Tue, Aug 6, 2013 at 8:06 PM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 6 August 2013 17:47, Guillermo Polito <guillermopolito@gmail.com> wrote:

...

ah, forgot to say. Latest vms from jenkins should be ready in a while, not yet :).

yes, and that's why i want you to answer a following question: why you think the repository was named 'blessed' as in [1]?

I don't know... That some saint has come and blessed it? :) If not, point me to where it is explained, is there a wiki page or something?

Igor, I do not know how to read that question. Now, really:

- I thought that moving the VM repository to gitorious was meant to open it. If only a couple of people (lets say you, Camilo and Esteban) have the rights to commit, then I feel it defeats the purpose

- Maybe I should make a pull-request, but you can see that there are three there, one for at least one year, waiting for integration and probably out of date [1]

- to me one benefit of using a CVS is that it gives you the ability to revert and going back in the history, and there are not much commits in cog to traverse... So, if it is really broken we go back and there are no problems. Should I be afraid of committing something?

- As Stef says, you only can break if you do...

- Now, maybe I should continue not trying to fix some stuff in the vm if people get pissed off when using latest and a bug is found

[1] https://gitorious.org/cogvm/blessed/merge_requests

...

[1] https://gitorious.org/cogvm/blessed/

...

On Tue, Aug 6, 2013 at 5:46 PM, Guillermo Polito <

guillermopolito@gmail.com>

...

wrote:

...

On Tue, Aug 6, 2013 at 4:53 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

thanks guillermo :) Cleaning events at VM level is important.

Cleaning is not sooooo easy :).

I've been able to reproduce some of these problems (the delete key and

the

...

double keyUp:). I've tried to fix them, bah, actually I did in here, but I'd like someone else tests in their keyboard layouts in their homes :).

Regarding the difference of the keyValues between keyUp and keyDown, I did not address it, and it kinda orthogonal, nothing to do with this particular issue.

To see my changes, people can have a look at the diff in here:

https://gitorious.org/cogvm/blessed/commit/2214cee58a5c5266b8ab2322b98471553...

...

I'd like to start putting this in some issue tracker. Cog issue

tracker or

...

Pharo one? :) Esteban?

...

On Aug 6, 2013, at 4:32 PM, Guillermo Polito <

guillermopolito@gmail.com>

...

wrote:

On Tue, Aug 6, 2013 at 3:40 PM, Igor Stasenko <siguctua@gmail.com> wrote:

...

I changed this method to see better what happens: HandMorph class>>showDebugEvent: evt

ShowEvents == true ifTrue: [ | ofs| Display fill: (0@0 extent: 500@120) rule: Form over fillColor: Color white. ofs := (owner hands indexOf: self) - 1 * 60. evt printString displayAt: (0@ofs) + (evt isKeyboard ifTrue: [0@30] ifFalse: [0@0]). self keyboardFocus printString displayAt: (0@ofs)+(0@45).

evt isKeyboard ifTrue: [ Transcript show: evt printString;cr ] ].

KeyboardEvent>> printOn: aStream "Print the receiver on a stream"

aStream nextPut: $[. aStream nextPutAll: type; nextPutAll: ' '''. self printKeyStringOn: aStream. aStream nextPut: $'.

aStream space; nextPutAll: 'keyValue: ', self keyValue asString.

aStream nextPut: $]

set HandMorph showEvents:true

Now, pressing single space, gives me this:

[keyDown ' ' keyValue: 49] [keystroke ' ' keyValue: 32] [keyUp ' ' keyValue: 49] [keyUp ' ' keyValue: 49]

Pressing delete key (or fn-backspace , for those who having a lot of spare fingers to use bad keyboards):

[keyDown ' ' keyValue: 117] [keystroke '⌦' keyValue: 188] [keyUp ' ' keyValue: 117] [keyUp ' ' keyValue: 117]

now, can someone tell me , why there is 2 keyUp events for each

keyDown?

That I don't know

...

and of course, main question is why key values are different for keydown and keystroke events?

That I'll dive right now into the vm to see what it is :).

...

(and why delete key is not 127, but 117 or 188?)

Editor expecting 127:

cmdMap at: (127 + 1) put: #forwardDelete:. "del key"

-- Best regards, Igor Stasenko.

-- Best regards, Igor Stasenko.

ok, jumping in... :) so... there are some problems with the recommended approach. 1) having a branch/trunk whatever that contains just "blessed" versions in the meaning of "stable" is a nonsense. For that, is easier to have a zip somewhere. One thing that is complete wrong is to keep VMMaker version and Platform Sources separated. That's bad for many reasons, but the principal one is that we cannot TAG a version and be sure that everything, platform + vmmaker are in sync. 2) CI is built against "blessed" repository. Since we cannot know if a commit is ok (and therefore, "blessed") until after the build is done and the tests are run (and green), one of both is wrong: - the repository is actually not blessed, or - the CI is taking bad sources (again, this can be solved by tagging, but well...) 3) at beginning of year we decided to take "stable" versions of VMs precisely to avoid this problems and give us time to stabilize. Now I understand people want to get over the SmallInteger bug, but well, we are all humans and our days is still 24hs. So, as a conclusion: - "blessed", for me, does not means "stable"... is more like a "trunk" - working with pull requests would be ideal, but also time consuming, and no-one here has many of that, who put the bell in the cat's neck? - sure we can have branches for experiments, etc... but the key stuff is not that, is a very long time needed work (and for me, since is needed to build real key combinations, is also essential). - we really need to improve the process. First step is to have all sources in one single repository. - I would like to review the use we give to CI process, because IMHO, now we are using it more like a "builder" than a real continuous integration tool. Esteban out On Tue, Aug 6, 2013 at 9:51 PM, Guillermo Polito <guillermopolito@gmail.com>wrote:

On Tue, Aug 6, 2013 at 9:33 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:

...

I imagine that having a branch is the way to go.

To me, a branch is a fork in the code. That is, you split and they evolve differently. If you want to tag a version as stable, you use a tag :). And git already supports all that. But we don't use it ;).

However, branches make sense to me if we have for example

- vm for pharo2 - vm for pharo3 - vm ....

With that setup, in the pharo2 branch we can backport fixes from the pharo3 branch, but they may evolve differently. And more importantly, we do not need to maintain all the compatibility with the world. Whoever wants a pharo2 vm, they go to the pharo2 branch, which on release is freezed (as well as the image).

Now, in Git, I do not think there is a need for having many repositories for that. It's enough with branches and tags...

...

Like that esteban can integrate the fixes of eliot and you do not stress to finish.

Yes, but esteban has already lots of things to do :). And every time I made a pull request, a had to push it myself into the main branch because if not, nobody did it. And ask Camillo, he was in the same situation... In the image side we have Stef, Marcus and Esteban that integrate fixes. In the vm side it's only Esteban :/.

Once this is ready there is a merge.

...

But that's what happen today, only the naming is bad in the git branch :).

- We have a stable VM, which you can download as stable. That VM does not have the latest changes. I do not know if there is a tag, but there should be. - We have a unstable VM, which we call latest. It has the latest sources which we should test and prove before "blessing" it as the stable.

...

At least this is what I was thinking the process was: one main blessed stream

several others at different level of maturity with the ultimate goal to

...

avoid bottleneck.

Yes, but with that we lack also a good management of the issue tracking and stuff :). Above in this thread I was asking where do I submit an issue. Maybe we should put everything in the pharo issue tracker and be happy with only one tool.

BTW, tomorrow I go to lille, we can discuss if you have some minutes :).

...

Stef

On Tue, Aug 6, 2013 at 8:06 PM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 6 August 2013 17:47, Guillermo Polito <guillermopolito@gmail.com> wrote:

...

ah, forgot to say. Latest vms from jenkins should be ready in a while, not yet :).

yes, and that's why i want you to answer a following question: why you think the repository was named 'blessed' as in [1]?

I don't know... That some saint has come and blessed it? :) If not, point me to where it is explained, is there a wiki page or something?

Igor, I do not know how to read that question. Now, really:

- I thought that moving the VM repository to gitorious was meant to open it. If only a couple of people (lets say you, Camilo and Esteban) have the rights to commit, then I feel it defeats the purpose

- Maybe I should make a pull-request, but you can see that there are three there, one for at least one year, waiting for integration and probably out of date [1]

- to me one benefit of using a CVS is that it gives you the ability to revert and going back in the history, and there are not much commits in cog to traverse... So, if it is really broken we go back and there are no problems. Should I be afraid of committing something?

- As Stef says, you only can break if you do...

- Now, maybe I should continue not trying to fix some stuff in the vm if people get pissed off when using latest and a bug is found

[1] https://gitorious.org/cogvm/blessed/merge_requests

...

[1] https://gitorious.org/cogvm/blessed/

...

On Tue, Aug 6, 2013 at 5:46 PM, Guillermo Polito <

guillermopolito@gmail.com>

...

wrote:

...

On Tue, Aug 6, 2013 at 4:53 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

thanks guillermo :) Cleaning events at VM level is important.

Cleaning is not sooooo easy :).

I've been able to reproduce some of these problems (the delete key

and the

...

double keyUp:). I've tried to fix them, bah, actually I did in here, but I'd like someone else tests in their keyboard layouts in their homes :).

Regarding the difference of the keyValues between keyUp and keyDown, I did not address it, and it kinda orthogonal, nothing to do with this particular issue.

To see my changes, people can have a look at the diff in here:

https://gitorious.org/cogvm/blessed/commit/2214cee58a5c5266b8ab2322b98471553...

...

I'd like to start putting this in some issue tracker. Cog issue

tracker or

...

Pharo one? :) Esteban?

...

On Aug 6, 2013, at 4:32 PM, Guillermo Polito <

guillermopolito@gmail.com>

...

wrote:

On Tue, Aug 6, 2013 at 3:40 PM, Igor Stasenko <siguctua@gmail.com> wrote:

...

I changed this method to see better what happens: HandMorph class>>showDebugEvent: evt

ShowEvents == true ifTrue: [ | ofs| Display fill: (0@0 extent: 500@120) rule: Form over fillColor: Color white. ofs := (owner hands indexOf: self) - 1 * 60. evt printString displayAt: (0@ofs) + (evt

isKeyboard

...

ifTrue: [0@30] ifFalse: [0@0]). self keyboardFocus printString displayAt: (0@ofs)+(0@45).

evt isKeyboard ifTrue: [ Transcript show: evt printString;cr ] ].

KeyboardEvent>> printOn: aStream "Print the receiver on a stream"

aStream nextPut: $[. aStream nextPutAll: type; nextPutAll: ' '''. self printKeyStringOn: aStream. aStream nextPut: $'.

aStream space; nextPutAll: 'keyValue: ', self keyValue asString.

aStream nextPut: $]

set HandMorph showEvents:true

Now, pressing single space, gives me this:

[keyDown ' ' keyValue: 49] [keystroke ' ' keyValue: 32] [keyUp ' ' keyValue: 49] [keyUp ' ' keyValue: 49]

Pressing delete key (or fn-backspace , for those who having a lot of spare fingers to use bad keyboards):

[keyDown ' ' keyValue: 117] [keystroke '⌦' keyValue: 188] [keyUp ' ' keyValue: 117] [keyUp ' ' keyValue: 117]

now, can someone tell me , why there is 2 keyUp events for each keyDown?

That I don't know

...

and of course, main question is why key values are different for keydown and keystroke events?

That I'll dive right now into the vm to see what it is :).

...

(and why delete key is not 127, but 117 or 188?)

Editor expecting 127:

cmdMap at: (127 + 1) put: #forwardDelete:. "del key"

-- Best regards, Igor Stasenko.

-- Best regards, Igor Stasenko.

On Wed, Aug 7, 2013 at 2:41 PM, Igor Stasenko <siguctua@gmail.com> wrote:

My understanding how it should be: - you work in own branch (and in git, repository clone is already a branch, just on your computer). If you want to make it public you need to make own branch on gitorious and commit there. - once you finished with changes and tested it , you are free to merge with blessed (no need to have GODs permission to do that, or make pull requests)

We did all that. We tested it with Ben because he needed the change to send ctrl events from the vm to the image, which were not sent. We tested in our computers, and we had no much trouble. - I do not use delete key because I don't have one - circumflex accent (return) was working with my keyboard layout So the vm was to me in a completely usable state.

now i understand we are humans and not immune to mistakes, but i insist that committing to blessed

'blessed' is a crappy name for a repository. And the idea that the code in this repository is always working flawlessly is nonsense. For example, we had for months the problem with the smallinteger in there. And then, the unstable is in another repository then? Where is that repository? Why do we have to make another repository for that and not just a branch (in the same repo, not in my machine)?

should be done after some manual testing and checking it don't breaks things badly, and of course blessed is not for committing the unfinished code , which in the middle of work.

First, we considered it as finished. What you found was a bug, not a pending to do task. Second, I have not the time to change to and learn every keyboard layout to test, nor to plug every external keyboard and see how it behaves. So if you think we should have done that, it will never be finished, and we will die with what we have. Third, we need an unstable official branch for the pharo vm code for people to test. To me, as blessed is the only repository out there, it is the only place where I can put it.

That is my only issue , that you committed code which is not yet finished, and makes VM unusable,

Now again. To me the latest vm was completely usable. How can I *prove*that the change is then finished if I do not test with every existing device and layout? So people has to test it. And let's be realistic: given the few people using nowadays the latest pharo vm, if I put my code in my own personal repository, how many people will download my *experimental* VM to test it from my hidden branch in my hidden and personal repo? I guess almost none. No one tests => never proved => never finished => never merged => dies That does not work. So if *bleesed* is the stable branch, which is the latest unstable branch? Do we need many repositories for that? and we cannot release VM with important fix to smallinteger bug before

you finish, which turns yourself into a bottleneck.

You can always go to the vm log https://gitorious.org/cogvm/blessed/commits/master and check my last commits and try to rollback them in any case. This change was only two lines of code. I'm of course not the code owner. Now, I'm tired to argue. I want to solve this by stating: - how do we get the latest *unstable* and where should the code be - how do we get the latest *stable* and where should the code be Something else is that I have the feeling that we are discussing because of the stupid "blessed" name. So I did this: - create a new pharovm repo inside https://gitorious.org/cogvm, the old blessed repo stays the same - I copied everything from the repo blessed to pharovm, including history - I created a blessed branch, which should in the future have the properties you like <=> latest stable - let master for latest bleedingEdge (not experimental, but maybe buggy) And then if we want other branches we create them. https://gitorious.org/cogvm/pharovm

-- Best regards, Igor Stasenko.

IMO is no point on ask for keeping an "all-time-stable" VM in the development process (it is even a contradiction). Is the same as asking for a 3.0 stable before release (yes, is the same... we are trying to have same process for both). VM development is not stable right now, same way it is not stable 3.0 Want stable stuff? you need to take the stable VM and Pharo 2.0 (even with the bugs we all know). Ok, we (the pharo developers community) cannot do that, we need to work on the bleeding edge and because of that, some times we get uncomfortable situations. But then we all know how hard is to have a functionality working properly and well tested. Our only way to do that is to put it in the development trunk and ask for feedback. So... yes, I'm sorry it annoys some time to time, but latest-VM will have periods in which it doesn't work as expected... is the only way this small community can advance: Developers introduce a functionality, community tests and provide feedback, then loop. Now, what we should have is a better way of mark stuff.. so we can backport stuff et all. For that, what we should have is: - all sources in just one repository, including vmmaker (I'm working on that) - create a tag (that we can branch and backport stuff) each release. no need to stress about :) my 2c Esteban On Aug 7, 2013, at 4:43 PM, Igor Stasenko <siguctua@gmail.com> wrote:

On 7 August 2013 15:55, Guillermo Polito <guillermopolito@gmail.com> wrote:

...

On Wed, Aug 7, 2013 at 2:41 PM, Igor Stasenko <siguctua@gmail.com> wrote:

...

My understanding how it should be: - you work in own branch (and in git, repository clone is already a branch, just on your computer). If you want to make it public you need to make own branch on gitorious and commit there. - once you finished with changes and tested it , you are free to merge with blessed (no need to have GODs permission to do that, or make pull requests)

We did all that. We tested it with Ben because he needed the change to send ctrl events from the vm to the image, which were not sent. We tested in our computers, and we had no much trouble.

- I do not use delete key because I don't have one - circumflex accent (return) was working with my keyboard layout

So the vm was to me in a completely usable state.

...

now i understand we are humans and not immune to mistakes, but i insist that committing to blessed

'blessed' is a crappy name for a repository. And the idea that the code in this repository is always working flawlessly is nonsense. For example, we had for months the problem with the smallinteger in there.

And then, the unstable is in another repository then? Where is that repository? Why do we have to make another repository for that and not just a branch (in the same repo, not in my machine)?

so what you proposing? lets everyone put own unfinished changes into same repository without synchronization and see how it flies? it won't fly, i can tell you even without trying.

...

...

should be done after some manual testing and checking it don't breaks things badly, and of course blessed is not for committing the unfinished code , which in the middle of work.

First, we considered it as finished. What you found was a bug, not a pending to do task.

Ah, in that case it is perfectly ok then. It is your messages in previous mails gave me impression that it is 'not done yet' but 'work in progress' and change is not finished.

...

Second, I have not the time to change to and learn every keyboard layout to test, nor to plug every external keyboard and see how it behaves. So if you think we should have done that, it will never be finished, and we will die with what we have.

Third, we need an unstable official branch for the pharo vm code for people to test. To me, as blessed is the only repository out there, it is the only place where I can put it.

It is blessed in terms that every change you pushing there is blessed by you (as developer), which means "i recommend to use new version by others". And until you can bless your own changes you should not push them into this repository, while obviously you free to push/commit them elsewhere.

...

...

That is my only issue , that you committed code which is not yet finished, and makes VM unusable,

Now again. To me the latest vm was completely usable. How can I prove that the change is then finished if I do not test with every existing device and layout?

So people has to test it. And let's be realistic: given the few people using nowadays the latest pharo vm, if I put my code in my own personal repository, how many people will download my experimental VM to test it from my hidden branch in my hidden and personal repo? I guess almost none.

No one tests => never proved => never finished => never merged => dies

Agreed.

...

That does not work.

So if bleesed is the stable branch, which is the latest unstable branch? Do we need many repositories for that?

it is not stable branch, it is development. stable versions come time to time, we can tag them as stable.

...

...

and we cannot release VM with important fix to smallinteger bug before you finish, which turns yourself into a bottleneck.

You can always go to the vm log

https://gitorious.org/cogvm/blessed/commits/master

and check my last commits and try to rollback them in any case. This change was only two lines of code. I'm of course not the code owner.

Now, I'm tired to argue. I want to solve this by stating: - how do we get the latest unstable and where should the code be - how do we get the latest stable and where should the code be

Something else is that I have the feeling that we are discussing because of the stupid "blessed" name. So I did this: - create a new pharovm repo inside https://gitorious.org/cogvm, the old blessed repo stays the same - I copied everything from the repo blessed to pharovm, including history - I created a blessed branch, which should in the future have the properties you like <=> latest stable - let master for latest bleedingEdge (not experimental, but maybe buggy)

And then if we want other branches we create them.

https://gitorious.org/cogvm/pharovm

just one question: why adding 'blessed' branch if you think it is stupid? name it stable then, since you don't understand/value of blessing or consider it is stupid and unnecessary. but again, we don't need 'stable' as separate branch.. makes little sense, since we can just tag certain versions as stable, like everyone else does.

-- Best regards, Igor Stasenko.

now can we get a working keyboard? On Wednesday, August 7, 2013, Igor Stasenko <siguctua@gmail.com> wrote:

Agree with everything you said. As i said, my impression was that Guille pushed unfininowshed/incomplete pieces. And that is what i against. Because if we go that way, then someone will start pushing changes which even don't compile.

I hope i made my point clear, what blessed means. It is not synonym to 'stable'.

On 7 August 2013 17:11, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

IMO is no point on ask for keeping an "all-time-stable" VM in the development process (it is even a contradiction). Is the same as asking for a 3.0 stable before release (yes, is the same... we are trying to have same process for both).

VM development is not stable right now, same way it is not stable 3.0 Want stable stuff? you need to take the stable VM and Pharo 2.0 (even with the bugs we all know). Ok, we (the pharo developers community) cannot do that, we need to work on the bleeding edge and because of that, some times we get uncomfortable situations. But then we all know how hard is to have a functionality working properly and well tested. Our only way to do that is to put it in the development trunk and ask for feedback.

So... yes, I'm sorry it annoys some time to time, but latest-VM will have periods in which it doesn't work as expected... is the only way this small community can advance: Developers introduce a functionality, community tests and provide feedback, then loop.

Now, what we should have is a better way of mark stuff.. so we can backport stuff et all. For that, what we should have is: - all sources in just one repository, including vmmaker (I'm working on that) - create a tag (that we can branch and backport stuff) each release.

no need to stress about :)

my 2c

Esteban

On Aug 7, 2013, at 4:43 PM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 7 August 2013 15:55, Guillermo Polito <guillermopolito@gmail.com> wrote:

...

On Wed, Aug 7, 2013 at 2:41 PM, Igor Stasenko <siguctua@gmail.com>

wrote:

...

...

My understanding how it should be: - you work in own branch (and in git, repository clone is already a branch, just on your computer). If you want to make it public you need to make own branch on gitorious and commit there. - once you finished with changes and tested it , you are free to merge with blessed (no need to have GODs permission to do that, or make pull requests)

We did all that. We tested it with Ben because he needed the change to send ctrl events from the vm to the image, which were not sent. We tested in our computers, and we had no much trouble.

- I do not use delete key because I don't have one - circumflex accent (return) was working with my keyboard layout

So the vm was to me in a completely usable state.

...

now i understand we are humans and not immune to mistakes, but i insist that committing to blessed

'blessed' is a crappy name for a repository. And the idea that the code in this repository is always working flawlessly is nonsense. For example, we had for months the problem with the smallinteger in there.

And then, the unstable is in another repository then? Where is that repository? Why do we have to make another repository for that and not just a branch (in the same repo, not in my machine)?

so what you proposing? lets everyone put own unfinished changes into same repository without synchronization and see how it flies? it won't fly, i can tell you even without trying.

...

...

should be done after some manual testing and checking it don't breaks things badly, and of course blessed is not for committing the unfinished code , which in the middle of work.

First, we considered it as finished. What you found was a bug, not a pending to do task.

Ah, in that case it is perfectly ok then. It is your messages in previous mails gave me impression that

-- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Featured on the Software Process and Measurement Cast http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

On Aug 7, 2013, at 7:06 PM, Stéphane Ducasse <Stephane.Ducasse@inria.fr> wrote:

On Aug 7, 2013, at 5:59 PM, "phil@highoctane.be" <phil@highoctane.be> wrote:

...

now can we get a working keyboard? Yes here

Hi,

Guille built a new vm with an attept of fixing the key combinations problem. Can you test it?

http://files.pharo.org/vm/pharo/

(and pick the latest for your platform)

Thanks, Esteban

Esteban did this vm get the fix for SmallInteger? Because in the latest moose image (ConfigurationOfMoose project version: #development) record led to problem Stef

I will retry and be careful about which vm I use because I had around 3/4 images open to tests snapshotcello. So I may have open it with the old one. Stef

yes, this latest vm should have the problem solved

On Aug 9, 2013, at 6:02 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

On Aug 7, 2013, at 7:06 PM, Stéphane Ducasse <Stephane.Ducasse@inria.fr> wrote:

...

On Aug 7, 2013, at 5:59 PM, "phil@highoctane.be" <phil@highoctane.be> wrote:

...

now can we get a working keyboard? Yes here

Hi,

Guille built a new vm with an attept of fixing the key combinations problem. Can you test it?

http://files.pharo.org/vm/pharo/

(and pick the latest for your platform)

Thanks, Esteban

Esteban did this vm get the fix for SmallInteger? Because in the latest moose image

(ConfigurationOfMoose project version: #development) record led to problem

Stef