August 2013 - Pharo-dev - lists.pharo.org

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linu… 1 regressions found. KernelTests.Numbers.LargePositiveIntegerTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses

Aug. 7, 2013

Re: [Pharo-dev] [Pharo-fuel] Fuel API bug

by StÃ©phane Ducasse

On Aug 6, 2013, at 4:47 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > >> #when:do: is there already ;) > > even better then :) > >> #when:send:to: and #when:do:for: should be added though. what would be when:do:for: ? > > sounds good. > >> >> Cheers, >> Henry >> >> >> > >

Aug. 7, 2013

Re: [Pharo-dev] Keyboard events is broken.

by Esteban Lorenzano

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(a)gmail.com>wrote: > > On Tue, Aug 6, 2013 at 9:33 PM, StÃ©phane Ducasse < > stephane.ducasse(a)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(a)gmail.com> wrote: >> >>> On 6 August 2013 17:47, Guillermo Polito <guillermopolito(a)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(a)gmail.com> >>> > wrote: >>> >> >>> >> >>> >> On Tue, Aug 6, 2013 at 4:53 PM, StÃ©phane Ducasse >>> >> <stephane.ducasse(a)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/2214cee58a5c5266b8ab2322b9847155… >>> >> >>> >> 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(a)gmail.com> >>> >>> wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Aug 6, 2013 at 3:40 PM, Igor Stasenko <siguctua(a)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. >>> >>> >> >> >

Aug. 6, 2013

Re: [Pharo-dev] Keyboard events is broken.

by StÃ©phane Ducasse

On Aug 6, 2013, at 9:51 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > On Tue, Aug 6, 2013 at 9:33 PM, StÃ©phane Ducasse <stephane.ducasse(a)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 â¦. No necessarily in git a branch can be a features that you experiment with. > 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â¦ Exactly > 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 :/. and igor for the Windows one. > 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. yes in the bug tracker. > BTW, tomorrow I go to lille, we can discuss if you have some minutes :). yes The morning I will be present and working on the textEditor stuff. :)

Aug. 6, 2013

Re: [Pharo-dev] Keyboard events is broken.

by Guillermo Polito

On Tue, Aug 6, 2013 at 9:33 PM, StÃ©phane Ducasse <stephane.ducasse(a)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(a)gmail.com> wrote: > >> On 6 August 2013 17:47, Guillermo Polito <guillermopolito(a)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(a)gmail.com> >> > wrote: >> >> >> >> >> >> On Tue, Aug 6, 2013 at 4:53 PM, StÃ©phane Ducasse >> >> <stephane.ducasse(a)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/2214cee58a5c5266b8ab2322b9847155… >> >> >> >> 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(a)gmail.com> >> >>> wrote: >> >>> >> >>> >> >>> >> >>> >> >>> On Tue, Aug 6, 2013 at 3:40 PM, Igor Stasenko <siguctua(a)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. >> >> > >

Aug. 6, 2013

Re: [Pharo-dev] [update 3.0] #30324

by Benjamin

Aug. 6, 2013

Re: [Pharo-dev] Keyboard events is broken.

by StÃ©phane Ducasse

I imagine that having a branch is the way to go. Like that esteban can integrate the fixes of eliot and you do not stress to finish. Once this is ready there is a merge. 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. Stef > > On Tue, Aug 6, 2013 at 8:06 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 6 August 2013 17:47, Guillermo Polito <guillermopolito(a)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(a)gmail.com> > > wrote: > >> > >> > >> On Tue, Aug 6, 2013 at 4:53 PM, StÃ©phane Ducasse > >> <stephane.ducasse(a)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/2214cee58a5c5266b8ab2322b9847155… > >> > >> 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(a)gmail.com> > >>> wrote: > >>> > >>> > >>> > >>> > >>> On Tue, Aug 6, 2013 at 3:40 PM, Igor Stasenko <siguctua(a)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. > >

Aug. 6, 2013

Re: [Pharo-dev] Keyboard events is broken.

by Guillermo Polito

On Tue, Aug 6, 2013 at 8:06 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 6 August 2013 17:47, Guillermo Polito <guillermopolito(a)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(a)gmail.com> > > wrote: > >> > >> > >> On Tue, Aug 6, 2013 at 4:53 PM, StÃ©phane Ducasse > >> <stephane.ducasse(a)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/2214cee58a5c5266b8ab2322b9847155… > >> > >> 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(a)gmail.com> > >>> wrote: > >>> > >>> > >>> > >>> > >>> On Tue, Aug 6, 2013 at 3:40 PM, Igor Stasenko <siguctua(a)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. > >

Aug. 6, 2013

Re: [Pharo-dev] moose build - pharo vm crash

by Igor Stasenko

yeah according to stack dump, this should be already fixed in new vms (once we fix other problems and release it) On 6 August 2013 17:17, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > Hi, > > here: > > -------- Original Message -------- > Subject: Nice VM crash > Date: Fri, 21 Jun 2013 18:37:18 +0100 > From: Jan Vrany <jan.vrany(a)fit.cvut.cz> > To: Pharo Development <pharo-dev(a)lists.pharo.org> > > Hi guys, > > getting bored? Looking for an excuse to play with GDB? Here we go: > > https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchm… > > > Okay, seriously: build 17 from Jun 17 did not crash - the Smalltalk code > was the same. Jenkins executes following script: > > === > export PATH=/usr/bin:$PATH > > IMAGE_BASE=CalipeL-S-$BUILD_NUMBER > IMAGE=$IMAGE_BASE.image > > if [ ! -r Pharo.image ]; then > wget -O- get.pharo.org | bash > fi > > ./pharo Pharo.image save $IMAGE_BASE > ./pharo $IMAGE config http://smalltalkhub.com/mc/JanVrany/CalipeL-S/main > ConfigurationOfCalipeLS --install=0.1 > ./pharo $IMAGE benchmark --json -o results.json BenchmarkMicro > === > > System is running stock 32bit debian stable on VMWare ESX 5.1. > I can provide more details if you like (and ask what exactly :-) > > Best, Jan > > > And here: > > -------- Original Message -------- > Subject: Re: Nice VM crash - UPDATE > Date: Wed, 10 Jul 2013 14:24:58 +0100 > From: Jan Vrany <jan.vrany(a)fit.cvut.cz> > To: Pharo Development <pharo-dev(a)lists.pharo.org>, Eliot Miranda > <eliot.miranda(a)gmail.com> > > Hi, > > a small update to my VM crash. Actually, sometimes it does not crash :-) > (see [1] - the VM is the same all the time). My wild guess is some GC > related problem, depending on timing and actual memory contents/layout, > maybe? > > Cheers, Jan > > [1]: > https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchm… > > > > > > > > > On 06/08/13 16:12, Esteban Lorenzano wrote: >> >> where is the report? >> >> On Aug 6, 2013, at 4:50 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >> >>> Hi Doru, >>> >>> join the club: >>> >>> >>> https://swing.fit.cvut.cz/jenkins/view/CalipeL/job/calipel_s_pharo20_benchm… >>> >>> I reported presumably same issue 21/06/13, update 10/07/13 :-) >>> >>> Best, Jan >>> >>> >>> >>> On 06/08/13 15:43, Tudor Girba wrote: >>>> >>>> Hi, >>>> >>>> It seems that the Moose build crashes the VM since yesterday evening due >>>> to a failing test. The image is based on Pharo 2.0 and is running a >>>> stable VM on Ubuntu. >>>> >>>> See some details here: >>>> https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/804/console >>>> >>>> The script to reproduce the problem (on Ubuntu) is: >>>> >>>> #------------------- >>>> wget --quiet -O - http://get.pharo.org/20+vm | bash >>>> >>>> ./pharo Pharo.image save $JOB_NAME >>>> >>>> REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main >>>> ./pharo $JOB_NAME.image config $REPO ConfigurationOfMoose >>>> --install=development >>>> ./pharo $JOB_NAME.image mooseimagesetup >>>> >>>> ./pharo $JOB_NAME.image moosetest --junit-xml-output >>>> >>>> mv ./pharo-vm/PharoV20.sources ./ >>>> zip $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes PharoV20.sources >>>> #------------------- >>>> >>>> Cheers, >>>> Doru >>>> >>>> -- >>>> www.tudorgirba.com <http://www.tudorgirba.com> >>>> >>>> "Every thing has its own flow" >>> >>> >>> >> >> >> > > -- Best regards, Igor Stasenko.

Aug. 6, 2013

Re: [Pharo-dev] Keyboard events is broken.

by Igor Stasenko

On 6 August 2013 17:47, Guillermo Polito <guillermopolito(a)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]? [1] https://gitorious.org/cogvm/blessed/ > > On Tue, Aug 6, 2013 at 5:46 PM, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: >> >> >> On Tue, Aug 6, 2013 at 4:53 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)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/2214cee58a5c5266b8ab2322b9847155… >> >> 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(a)gmail.com> >>> wrote: >>> >>> >>> >>> >>> On Tue, Aug 6, 2013 at 3:40 PM, Igor Stasenko <siguctua(a)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.

Aug. 6, 2013