- Pharo-dev - lists.pharo.org

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

by Guillermo Polito

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

Aug. 6, 2013

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

by Guillermo Polito

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

Aug. 6, 2013

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

by Guillermo Polito

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

Aug. 6, 2013

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

by Esteban Lorenzano

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 Esteban Lorenzano

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, 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] Flamel Update

by Gisela Decuzzi

2013/8/6 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > this is the difference between expression and method. Exactly, that's why I said that the current behavior for matching is confusing because nothing points you that I'm assuming that you are writing a pattern for a method. That example was on purpose just to show that... sometimes we give more logic to the semantics and the `name is just a variable name... And we have syntax-correct code but it's the contextual information that we are missing that completly change everything

Aug. 6, 2013

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

by Esteban Lorenzano

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] Flamel Update

by StÃ©phane Ducasse

ok I got it this is the difference between expression and method. Stef > Gisela > > why do you say that > > `anObject size. > > size should match a variable? > > you completely lost me there. > > Because `anObject should match > self > x > tmp > > Stef

Aug. 6, 2013

Re: [Pharo-dev] Flamel Update

by StÃ©phane Ducasse

Gisela why do you say that `anObject size. size should match a variable? you completely lost me there. Because `anObject should match self x tmp Stef

Aug. 6, 2013