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

Re: [Pharo-project] Code review tools?

by Frank Shearar

On 11 March 2013 02:19, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Igor Stasenko wrote >> what would be really cool to have is to integrate some steroids into >> diff viewer where guy B can press "create a review report" >> and write his comments directly under selected change .. then post it >> somewhere on web (or send emal), >> so guy A can see directly which of his changes made guy B unhappy. > > This would be very cool. For me, this is one of github's killer features. > Dale and I were having conversations about particular statements right in > the diff for the commit. What makes it even more crazy is that there is > markup to hyperlink to issues/users/etc It's probably less work to get tools working with github than it is to re-invent an in-image github. frank > Sean

March 11, 2013

Re: [Pharo-project] Code review tools?

by Dennis Schetinin

It is a good idea for GSoC. -- Best regards, Dennis Schetinin 2013/3/11 Igor Stasenko <siguctua(a)gmail.com> > Hello, > > here is some thoughts what i would like to have.. one day. > > imagine guy A did some change(s) to code, and guy B wants to review it. > > Currently we having only one tool which helps a little: MC diff viewer.. > but main tool is still human.. > And it is quite tedious for guy B to go somewhere, copy pieces of code > and/or comment on things.. > > what would be really cool to have is to integrate some steroids into > diff viewer where guy B can press "create a review report" > and write his comments directly under selected change .. then post it > somewhere on web (or send emal), > so guy A can see directly which of his changes made guy B unhappy. > > Going further, and integrating this into pharo development process, as > one guy (stef) said: > automation is good, but no changes should be made into image unless at > least one human took a look at it. > > So, i thinking if we could have more streamlined review process, this > could help a bit (or a lot).. > because personally, for me it is tedious today, because integrator or > reviewer has to do many things manually, > which is not fun and takes too much precious time :) > > I imagining something like opening a window, pressing "get list of > pending reviews from bug tracker" > and then selecting a change, review it and pressing "approve or > disapprove" which then will trigger the rest of automatic > things like integration into image and/or putting entry into bug > tracker with reviewer comments. > > -- > Best regards, > Igor Stasenko. > >

March 11, 2013

Re: [Pharo-project] Code review tools?

by Sean P. DeNigris

Igor Stasenko wrote > what would be really cool to have is to integrate some steroids into > diff viewer where guy B can press "create a review report" > and write his comments directly under selected change .. then post it > somewhere on web (or send emal), > so guy A can see directly which of his changes made guy B unhappy. This would be very cool. For me, this is one of github's killer features. Dale and I were having conversations about particular statements right in the diff for the commit. What makes it even more crazy is that there is markup to hyperlink to issues/users/etc ----- Cheers, Sean -- View this message in context: http://forum.world.st/Code-review-tools-tp4676066p4676068.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 11, 2013

[Pharo-project] Code review tools?

by Igor Stasenko

Hello, here is some thoughts what i would like to have.. one day. imagine guy A did some change(s) to code, and guy B wants to review it. Currently we having only one tool which helps a little: MC diff viewer.. but main tool is still human.. And it is quite tedious for guy B to go somewhere, copy pieces of code and/or comment on things.. what would be really cool to have is to integrate some steroids into diff viewer where guy B can press "create a review report" and write his comments directly under selected change .. then post it somewhere on web (or send emal), so guy A can see directly which of his changes made guy B unhappy. Going further, and integrating this into pharo development process, as one guy (stef) said: automation is good, but no changes should be made into image unless at least one human took a look at it. So, i thinking if we could have more streamlined review process, this could help a bit (or a lot).. because personally, for me it is tedious today, because integrator or reviewer has to do many things manually, which is not fun and takes too much precious time :) I imagining something like opening a window, pressing "get list of pending reviews from bug tracker" and then selecting a change, review it and pressing "approve or disapprove" which then will trigger the rest of automatic things like integration into image and/or putting entry into bug tracker with reviewer comments. -- Best regards, Igor Stasenko.

March 11, 2013

[Pharo-project] generated sources with odd indent

by NISHIHARA Satoshi

latest generator.image ( Balloon-Engine-Pools-JB.2 CMakeVMMaker-EstebanLorenzano.192 Cog-IgorStasenko.57 VMMaker-oscog-EstebanLorenzano.234 ) generate FFTPlugin>>primitiveFFTTransformData with odd indent. regards. /* example begin */ EXPORT(sqInt) primitiveFFTTransformData(void) { // FFTPlugin>>#primitiveFFTTransformData sqInt fftScale; sqInt fftSize2; sqInt fftSize4; sqInt forward; sqInt i; sqInt ii; float imagT; float imagU; sqInt ip; sqInt j; sqInt lev; sqInt lev1; sqInt level; sqInt rcvr; float realT; float realU; sqInt theta; forward = booleanValueOf(stackValue(0)); rcvr = stackObjectValue(1); if (!(loadFFTFrom(rcvr))) { return null; } /* begin transformData: */ permuteData(); if (failed()) { /* ifTrue: */ permuteData(); null; goto l1; } /* begin transformForward: */ fftSize2 = ((sqInt) fftSize >> 1); fftSize4 = ((sqInt) fftSize >> 2); for (level = 1; level <= nu; level += 1) { lev = 1 << level; lev1 = ((sqInt) lev >> 1); fftScale = fftSize / lev; for (j = 1; j <= lev1; j += 1) { /* fftScale */ theta = (j - 1) * fftScale; if (theta < fftSize4) { /* fftSize4 */ /* fftSize4 */ realU = sinTable[(sinTableSize - theta) - 1]; imagU = sinTable[theta]; } else { realU = 0.0 - (sinTable[theta - fftSize4]); imagU = sinTable[fftSize2 - theta]; } if (!forward) { imagU = 0.0 - imagU; } i = j; while (i <= fftSize) { ip = (i + lev1) - 1; ii = i - 1; realT = ((realData[ip]) * realU) - ((imagData[ip]) * imagU); imagT = ((realData[ip]) * imagU) + ((imagData[ip]) * realU); realData[ip] = ((realData[ii]) - realT); imagData[ip] = ((imagData[ii]) - imagT); realData[ii] = ((realData[ii]) + realT); imagData[ii] = ((imagData[ii]) + imagT); i += lev; } } } if (!forward) { scaleData(); } l1: /* end transformData: */; if (!(failed())) { pop(1); } } /* example end */ -- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]

March 10, 2013

Re: [Pharo-project] MorphicEventHandler behavior.

by Guillermo Polito

Yes it does :) On Sun, Mar 10, 2013 at 10:26 PM, stephane ducasse <stephane.ducasse(a)free.fr > wrote: > Guillermo > > can you try if the following method works with you? > I folded the external register inside each note. > > Stef > > > > buildKeyboard > | wtWid bkWid keyRect octavePt nWhite nBlack | > self removeAllMorphs. > wtWid := 8. bkWid := 5. > self extent: 10@10. > 1 to: nOctaves+1 do: > [:i | i <= nOctaves ifTrue: [nWhite := 7. nBlack := 5] > ifFalse: [nWhite := 1. > nBlack := 0 "High C"]. > octavePt := self innerBounds topLeft + ((7*wtWid*(i-1)-1) > @ -1). > 1 to: nWhite do: > [:j | | val | > keyRect := octavePt + (j-1*wtWid@0) extent: > (wtWid+1)@36. > val := i-1*12 + (#(1 3 5 6 8 10 12) at: j). > self addMorph: ((RectangleMorph newBounds: keyRect > color: whiteKeyColor) > > borderWidth: 1; > on: #mouseDown send: > #mouseDownPitch:event:noteMorph: to: self > withValue: > val; > on: #mouseUp > send: > #mouseUpPitch:event:noteMorph: > to: self > withValue: val; > on: #mouseLeaveDragging > send: > #mouseUpPitch:event:noteMorph: > to: self > withValue: val; > on: #mouseMove > send: > #mouseMovePitch:event:noteMorph: > to: self > withValue: val; > on: #mouseEnterDragging send: > #mouseDownPitch:event:noteMorph: to: self > withValue: > val) > ]. > 1 to: nBlack do: > [:j | |val| > keyRect := octavePt + ((#(6 15 29 38 47) at: j)@1) > extent: bkWid@21. > val := i-1*12 + (#(2 4 7 9 11) at: j). > self addMorph: ((Morph newBounds: keyRect color: > blackKeyColor) > on: #mouseDown send: > #mouseDownPitch:event:noteMorph: to: self > withValue: > val; > on: #mouseUp > send: > #mouseUpPitch:event:noteMorph: > to: self > withValue: val ; > on: #mouseLeaveDragging > send: > #mouseUpPitch:event:noteMorph: > to: self > withValue: val; > on: #mouseMove > send: > #mouseMovePitch:event:noteMorph: > to: self > withValue: val; > on: #mouseEnterDragging send: > #mouseDownPitch:event:noteMorph: to: self > withValue: > val > )]]. > "self submorphsDo: > [:m | m on: #mouseMove send: > #mouseMovePitch:event:noteMorph: to: self; > on: #mouseUp send: > #mouseUpPitch:event:noteMorph: to: self; > on: #mouseEnterDragging send: > #mouseDownPitch:event:noteMorph: to: self; > on: #mouseLeaveDragging send: > #mouseUpPitch:event:noteMorph: to: self]." > self extent: (self fullBounds extent + borderWidth - 1) >

March 10, 2013

Re: [Pharo-project] MorphicEventHandler behavior.

by stephane ducasse

Guillermo can you try if the following method works with you? I folded the external register inside each note. Stef buildKeyboard | wtWid bkWid keyRect octavePt nWhite nBlack | self removeAllMorphs. wtWid := 8. bkWid := 5. self extent: 10@10. 1 to: nOctaves+1 do: [:i | i <= nOctaves ifTrue: [nWhite := 7. nBlack := 5] ifFalse: [nWhite := 1. nBlack := 0 "High C"]. octavePt := self innerBounds topLeft + ((7*wtWid*(i-1)-1) @ -1). 1 to: nWhite do: [:j | | val | keyRect := octavePt + (j-1*wtWid@0) extent: (wtWid+1)@36. val := i-1*12 + (#(1 3 5 6 8 10 12) at: j). self addMorph: ((RectangleMorph newBounds: keyRect color: whiteKeyColor) borderWidth: 1; on: #mouseDown send: #mouseDownPitch:event:noteMorph: to: self withValue: val; on: #mouseUp send: #mouseUpPitch:event:noteMorph: to: self withValue: val; on: #mouseLeaveDragging send: #mouseUpPitch:event:noteMorph: to: self withValue: val; on: #mouseMove send: #mouseMovePitch:event:noteMorph: to: self withValue: val; on: #mouseEnterDragging send: #mouseDownPitch:event:noteMorph: to: self withValue: val) ]. 1 to: nBlack do: [:j | |val| keyRect := octavePt + ((#(6 15 29 38 47) at: j)@1) extent: bkWid@21. val := i-1*12 + (#(2 4 7 9 11) at: j). self addMorph: ((Morph newBounds: keyRect color: blackKeyColor) on: #mouseDown send: #mouseDownPitch:event:noteMorph: to: self withValue: val; on: #mouseUp send: #mouseUpPitch:event:noteMorph: to: self withValue: val ; on: #mouseLeaveDragging send: #mouseUpPitch:event:noteMorph: to: self withValue: val; on: #mouseMove send: #mouseMovePitch:event:noteMorph: to: self withValue: val; on: #mouseEnterDragging send: #mouseDownPitch:event:noteMorph: to: self withValue: val )]]. "self submorphsDo: [:m | m on: #mouseMove send: #mouseMovePitch:event:noteMorph: to: self; on: #mouseUp send: #mouseUpPitch:event:noteMorph: to: self; on: #mouseEnterDragging send: #mouseDownPitch:event:noteMorph: to: self; on: #mouseLeaveDragging send: #mouseUpPitch:event:noteMorph: to: self]." self extent: (self fullBounds extent + borderWidth - 1)

March 10, 2013

Re: [Pharo-project] what do we do with SoundService?

by stephane ducasse

> > That's why sound matters in the core of Pharo. And Beeper may be > interesting too. yes! what I mean is that to have Beeper is not a problem to me. But I see what pavel means: no need for SoundSystem and Beeper. > > Phil > > 2013/3/10 stephane ducasse <stephane.ducasse(a)free.fr>: >> Sounds ok for me. We should do that for 3.0alpha :) >> Now I do not care about Beeper removal. >> >> I will split sound in different packages because there are sound and score and these are different domains. >> >> Stef >> >> On Mar 10, 2013, at 11:38 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> >>> Hi, >>> >>> removal of this class is proposed in >>> https://code.google.com/p/pharo/issues/detail?id=6996 >>> >>> -- Pavel >>> >>> >>> On Sun, Mar 10, 2013 at 11:31 AM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> Hi guy >>>> >>>> Sound has an AbstractSoundSystem and a Base and Dummy. Then in addition there is SounService. >>>> >>>> SoundService is not doing much >>>> >>>> soundEnabled >>>> ^ self defaultSoundEnabled >>>> >>>> defaultSoundEnabled >>>> ^DefaultSoundEnabled ifNil: [false] >>>> >>>> toggleSoundEnabling >>>> self soundEnabled: self soundEnabled not >>>> >>>> >>>> >>>> So we could just keep AbstractSoundSystem and deprecate SoundService. >>>> >>>> Stef >>> >> >> >

March 10, 2013

Re: [Pharo-project] FMSound bass1 play

by stephane ducasse

I tried BaseSoundSystem soundEnabled: true. BaseSoundSystem initialize. FMSound marimba play with pharo2.0 and the latest vm but it does not on my mac. I will see esteban soon. Stef On Mar 10, 2013, at 5:44 PM, phil(a)highoctane.be wrote: > SoundService and all that looks like in need of some refactoring at the moment. > > Here is what I do and it appears to work: > > in my app initialize > > BaseSoundSystem soundEnabled: true. > BaseSoundSystem initialize. > > soundbank := Dictionary new. > soundbank add: #rightAnswer -> FMSound flute1. > soundbank add: #wrongAnswer -> FMSound bassoon1. > soundbank add: #clearAnswer -> FMSound marimba. > > and to play: > > (soundbank at: aSoundSymbol) play. > > Works fine. > > Phil > > 2013/3/10 stephane ducasse <stephane.ducasse(a)free.fr>: >> In fact I get really unpredictable behavior. >> >> Sometimes I can produce a sound sometimes not. >> >> SoundService default soundEnabled: true >> >> I'm puzzled >> Stef >> >> On Mar 9, 2013, at 10:21 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> >>> Hi guys >>> >>> I'm migrating the package Sound and MorphicSound to Pharo2.0 and SmalltalkHub. >>> But I cannot make >>> >>> FMSound bass1 play >>> produce a sound. >>> >>> Phil if i remember correctly you worked on that a couple of months ago. >>> Can you summarize your findings? >>> >>> Stef >> >> >

March 10, 2013

Re: [Pharo-project] MorphicEventHandler behavior.

by stephane ducasse

On Mar 10, 2013, at 5:41 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Steph, > > I was looking and in the end of #buildKeyboard you have: > > self submorphsDo: > [:m | m on: #mouseMove send: #mouseMovePitch:event:noteMorph: to: self; > on: #mouseUp send: #mouseUpPitch:event:noteMorph: to: self; > on: #mouseEnterDragging send: #mouseDownPitch:event:noteMorph: to: self; > on: #mouseLeaveDragging send: #mouseUpPitch:event:noteMorph: to: self]. > > Which create subscriptions without any value. And that's why you get the nil and the DNU. Yes! this is exactly that. > It probably was working in 1.4 because the EventHandler code did only manage one subscription at a time and probably didn't notice these last subscriptions. I have the impression that the code logic relied on the fact that the Event got state. > Now int 2.0 all subscriptions to events are handled, and that's the reason of the DNU. > > I tested the code without that statement and get it work.. I did not thought about removing it. Now I tried and the problem is that the pressed key stay red. > > Guille > > On Sun, Mar 10, 2013 at 11:01 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi fernando > > May be you know more than me on MorphicEventHandler. > > Gofer new > squeaksource: 'PharoNonCorePackages'; > package: 'Sound'; > package: 'SoundMorphicUserInterface'; > load. > > > > While trying to make > PianoKeyboardMorph new openInWorld > (which works in 1.4 and does not in 20). > > It breaks here: > > ------------- > mouseUpPitch: pitch event: event noteMorph: noteMorph > > noteMorph color: ((#(0 1 3 5 6 8 10) includes: pitch \\12) > ifTrue: [whiteKeyColor] > ifFalse: [blackKeyColor]). > soundPlaying ifNotNil: [soundPlaying stopGracefully]. > > pitch is nil because notify:from: uses valueParameter which is nil. > ------------- > > mouseUpPitch is invoked by notify: anEvent from: sourceMorph which is invoked by notifyMorphsOfEvent: anEvent ofType: eventType from: sourceMorph > > notify: anEvent from: sourceMorph > | arity | > recipient ifNil: [^ self]. > arity := selector numArgs. > arity = 0 ifTrue: > [^ recipient perform: selector]. > arity = 1 ifTrue: > [^ recipient perform: selector with: anEvent]. > arity = 2 ifTrue: > [^ recipient perform: selector with: anEvent with: sourceMorph]. > arity = 3 ifTrue: > [^ recipient perform: selector with: valueParameter with: anEvent with: sourceMorph]. > ^^^^^^^^^^^^^^^^^^^^^^^ > self error: 'Event handling selectors must be Symbols and take 0-3 arguments' > > notifyMorphsOfEvent: anEvent ofType: eventType from: sourceMorph > | result | > result := false. > ((subscriptions includesKey: eventType) not or: [ (subscriptions at: eventType) isEmpty ]) > ifTrue: [ ^false ]. > (subscriptions at: eventType) do: [ :s | result := result | ((s notify: anEvent from: sourceMorph) == true) ]. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > ^result > > > The idea is that morphs get notified when a certain event occurs so when we look at the morph creation and event registry we get: > > > The buildKeyboard create morph and define event with a given value that will be used > on: #mouseDown send: #mouseDownPitch:event:noteMorph: to: self withValue: i-1*12 + (#(2 4 7 9 11) at: j) > below: > > > buildKeyboard > | wtWid bkWid keyRect octavePt nWhite nBlack | > self removeAllMorphs. > wtWid := 8. bkWid := 5. > self extent: 10@10. > 1 to: nOctaves+1 do: > [:i | i <= nOctaves ifTrue: [nWhite := 7. nBlack := 5] > ifFalse: [nWhite := 1. nBlack := 0 "High C"]. > octavePt := self innerBounds topLeft + ((7*wtWid*(i-1)-1) @ -1). > 1 to: nWhite do: > [:j | keyRect := octavePt + (j-1*wtWid@0) extent: (wtWid+1)@36. > self addMorph: ((RectangleMorph newBounds: keyRect color: whiteKeyColor) > borderWidth: 1; > on: #mouseDown send: #mouseDownPitch:event:noteMorph: to: self > withValue: i-1*12 + (#(1 3 5 6 8 10 12) at: j))]. > 1 to: nBlack do: > [:j | keyRect := octavePt + ((#(6 15 29 38 47) at: j)@1) extent: bkWid@21. > self addMorph: ((Morph newBounds: keyRect color: blackKeyColor) > on: #mouseDown send: #mouseDownPitch:event:noteMorph: to: self > withValue: i-1*12 + (#(2 4 7 9 11) at: j))]]. > self submorphsDo: > [:m | m on: #mouseMove send: #mouseMovePitch:event:noteMorph: to: self; > on: #mouseUp send: #mouseUpPitch:event:noteMorph: to: self; > on: #mouseEnterDragging send: #mouseDownPitch:event:noteMorph: to: self; > on: #mouseLeaveDragging send: #mouseUpPitch:event:noteMorph: to: self]. > self extent: (self fullBounds extent + borderWidth - 1) > > > > Now I can understand that > #mouseDownPitch:event:noteMorph: get notified with a value because this is what is written. > But I do not get why this would be the case with #mouseUpPitch:event:noteMorph: > since we simply get > on: #mouseUp send: #mouseUpPitch:event:noteMorph: to: self; > > > And I do not get why this was working in 1.4 > > > > > > > > >

March 10, 2013