- Pharo-dev - lists.pharo.org

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

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

by phil＠highoctane.be

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(a)gmail.com> wrote: > And the removal of the debugging code is here https://gitorious.org/cogvm/blessed/commit/9e2a77928edf0144f0d5c42ada66eb18…;) > > On Tue, Aug 6, 2013 at 5:47 PM, Guillermo Polito < guillermopolito(a)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(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 -- --- 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

Aug. 6, 2013

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

by Jan Vrany

Good, I can wait. It's not a show-stopper for me :-) On 06/08/13 16:37, Esteban Lorenzano wrote: > ah, but in this case... probably the latest vm already fixes that :) > problem is that is still not stable (the vm) so we cannot release it, but well... we'll get there soon :) > > On Aug 6, 2013, at 5:36 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> you know that what is not in the bug tracker does not exists? ;) >> >> I'm sorry, I want to take all problems into consideration, but I cannot make email archeology each time I'm going to tackle something :( >> >> https://pharo.fogbugz.com >> >> under project "Pharo VM" >> >> thanks, and do not hesitate on asking for an account if you need it :) >> >> Esteban >> >> >> On Aug 6, 2013, at 5:17 PM, 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" >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> > > >

Aug. 6, 2013

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

by Jan Vrany

Hi, > On 06/08/13 16:36, Esteban Lorenzano wrote: > you know that what is not in the bug tracker does not exists? ;) > > I'm sorry, I want to take all problems into consideration, but I cannot make email archeology each time I'm going to tackle something :( > I completely understand and I certainly don't ask nor expect you to do so. > https://pharo.fogbugz.com > > under project "Pharo VM" > > thanks, and do not hesitate on asking for an account if you need it :) > I'm sorry but I'm so stupid that I couldn't figure out how to register last time I tried get an account. And, I have dot in my email address, apparently this is an issue too. Anyway, if I find time and courage, I'll certainly try again :-) Best, Jan > Esteban > > > On Aug 6, 2013, at 5:17 PM, 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" >>>> >>>> >>> >>> >>> >> >> > > >

Aug. 6, 2013