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

Re: [Pharo-project] Code review tools?

by stephane ducasse

>>> Camillo needs to hit you around the head with a command line. You >>> haven't used it. You've heard several people who have used both >>> Monticello and git extensively say that git beats the crap out of >>> Monticello. Go and learn git properly. THEN come back and maybe we can >>> have a conversation. >>> >> I always using git from command line. And let me remind you it was me who >> created Cog mirrors on gitorious.. so, you shoot into the sky here. >> But i want more than that.. and why i happy to see that github proposes more >> on top, i do not really see how you can integrate that with usual >> workflow of smalltalk developer >> (means navigating/debugging living code in image). > > OK, fair enough. I had indeed forgotten about your gitorious work, and > in fact if I recall correctly you tried to pushed the VM folk into > moving from subversion to git. My apologies. Oh yes and me too. Because the git model is open and svn not. > >>>> okay, lets throw away MC & stuff, migrate everything on file-based >>>> file-per-method git repository >>>> and then navigate diffs on github, and trying to find senders or >>>> implementors of selector using web browser . >>> >>> I do believe you ought to take a moment and go read the archives. >>> Also, I happen to nearly violently disagree with the file-per-method >>> approach, but that's an entirely different kettle of fish. >>> >>> But you know what, just forget it. It's not your problem, other people >>> are already solving the problem, and one day hopefully you'll forget >>> all about this while quietly your tools happily use git under the >>> hood, where you neither know nor care. >>> >> I actually don't care where files stored , in what format and what >> service it using. >> I want to make my life easier integrating those services with image, >> so i could, without switching >> contexts (like between image/web browser), do my work faster and more efficient. > > Yes, agreed. > > So if I can summarise, > > * git is not an answer for you because you don't care about the format > source is stored in. > * git is an answer for me because it immediately gives you a fantastic > user interface and hooks into just about everything. > * github is not an answer for you because it doesn't provide you with > any tools more advanced than a diff > * github is an answer for me because you can always implement your own > hooks for triggering CI, arbitrary code analysis, etc. Github's commit > API will let you give the green light or red light to any commit so > you can see at a glance how good a pull request is. > > But of course there's nothing stopping one using github OR an-image > tools. (Or tools that produce custom images based on github commits > that run analyses and then persist somewhere so you can (a) see the > analyses immediately and (b) play around with the code. > > Mainly I think it's a mistake to reinvent tech _just because_ you > simply must work in an image. That's the core behind my moaning. (And > yes, I am working on addressing these issues, so I'm not _just_ > moaning.) > > frank >

March 11, 2013

Re: [Pharo-project] Help with MenuMorph

by jannik.laval

Here is what I did (2 classes) Then, you can do: === menu := MenuMorphNG new. menu add: 'test1' value: #testForPharo. menu addLine. menu add: 'test2' value: 2.0. menu localize; invokeModal. menu selectedValue === Jannik On Mar 11, 2013, at 10:09 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > I should probably redefine > > invokeWithEvent: evt > "Perform the action associated with the given menu item." > > | w | > self isEnabled ifFalse: [^ self]. > target class == HandMorph ifTrue: [(self notObsolete) ifFalse: [^ self]]. > owner ifNotNil:[self isStayUpItem ifFalse:[ > self flag: #workAround. "The tile system invokes menus straightforwardly so the menu might not be in the world." > (w := self world) ifNotNil:[ > owner deleteIfPopUp: evt. > "Repair damage before invoking the action for better feedback" > w displayWorldSafely]]]. > selector ifNil:[^self]. > Cursor normal showWhile: [ | selArgCount | "show cursor in case item opens a new MVC window" > (selArgCount := selector numArgs) = 0 > ifTrue: > [target perform: selector] > ifFalse: > [selArgCount = arguments size > ifTrue: [target perform: selector withArguments: arguments] > ifFalse: [target perform: selector withArguments: (arguments copyWith: evt)]]. > self changed]. > > > > On Mar 11, 2013, at 10:06 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> Now I have the problem that I do not know how to get the value from the menu and not the menu item morph >> >> >> setFFTSize >> "Set the size of the FFT used for frequency analysis." >> >> | aMenu sz on | >> aMenu := MenuMorph new title: ('FFT size (currently {1})' translated format:{fft n}). >> ((7 to: 10) collect: [:n | 2 raisedTo: n]) do: [ :r | aMenu add: r printString value: r]. >> sz := aMenu xxxxxxx >> >> sz ifNil: [^ self]. >> on := soundInput isRecording. >> self stop. >> fft := FFT new: sz. >> self resetDisplay. >> on ifTrue: [self start]. >> >> >> do you have an idea? >> >> Stef > >

March 11, 2013

Re: [Pharo-project] Help with MenuMorph

by stephane ducasse

I should probably redefine invokeWithEvent: evt "Perform the action associated with the given menu item." | w | self isEnabled ifFalse: [^ self]. target class == HandMorph ifTrue: [(self notObsolete) ifFalse: [^ self]]. owner ifNotNil:[self isStayUpItem ifFalse:[ self flag: #workAround. "The tile system invokes menus straightforwardly so the menu might not be in the world." (w := self world) ifNotNil:[ owner deleteIfPopUp: evt. "Repair damage before invoking the action for better feedback" w displayWorldSafely]]]. selector ifNil:[^self]. Cursor normal showWhile: [ | selArgCount | "show cursor in case item opens a new MVC window" (selArgCount := selector numArgs) = 0 ifTrue: [target perform: selector] ifFalse: [selArgCount = arguments size ifTrue: [target perform: selector withArguments: arguments] ifFalse: [target perform: selector withArguments: (arguments copyWith: evt)]]. self changed]. On Mar 11, 2013, at 10:06 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Now I have the problem that I do not know how to get the value from the menu and not the menu item morph > > > setFFTSize > "Set the size of the FFT used for frequency analysis." > > | aMenu sz on | > aMenu := MenuMorph new title: ('FFT size (currently {1})' translated format:{fft n}). > ((7 to: 10) collect: [:n | 2 raisedTo: n]) do: [ :r | aMenu add: r printString value: r]. > sz := aMenu xxxxxxx > > sz ifNil: [^ self]. > on := soundInput isRecording. > self stop. > fft := FFT new: sz. > self resetDisplay. > on ifTrue: [self start]. > > > do you have an idea? > > Stef

March 11, 2013

Re: [Pharo-project] Code review tools?

by Frank Shearar

On 11 March 2013 19:00, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 11 March 2013 19:06, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> On 11 March 2013 17:54, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> pff... really people... i am thinking how to streamline our existing >>> development process.. >>> and instead i hear once again about git. >> >> Camillo needs to hit you around the head with a command line. You >> haven't used it. You've heard several people who have used both >> Monticello and git extensively say that git beats the crap out of >> Monticello. Go and learn git properly. THEN come back and maybe we can >> have a conversation. >> > I always using git from command line. And let me remind you it was me who > created Cog mirrors on gitorious.. so, you shoot into the sky here. > But i want more than that.. and why i happy to see that github proposes more > on top, i do not really see how you can integrate that with usual > workflow of smalltalk developer > (means navigating/debugging living code in image). OK, fair enough. I had indeed forgotten about your gitorious work, and in fact if I recall correctly you tried to pushed the VM folk into moving from subversion to git. My apologies. >>> okay, lets throw away MC & stuff, migrate everything on file-based >>> file-per-method git repository >>> and then navigate diffs on github, and trying to find senders or >>> implementors of selector using web browser . >> >> I do believe you ought to take a moment and go read the archives. >> Also, I happen to nearly violently disagree with the file-per-method >> approach, but that's an entirely different kettle of fish. >> >> But you know what, just forget it. It's not your problem, other people >> are already solving the problem, and one day hopefully you'll forget >> all about this while quietly your tools happily use git under the >> hood, where you neither know nor care. >> > I actually don't care where files stored , in what format and what > service it using. > I want to make my life easier integrating those services with image, > so i could, without switching > contexts (like between image/web browser), do my work faster and more efficient. Yes, agreed. So if I can summarise, * git is not an answer for you because you don't care about the format source is stored in. * git is an answer for me because it immediately gives you a fantastic user interface and hooks into just about everything. * github is not an answer for you because it doesn't provide you with any tools more advanced than a diff * github is an answer for me because you can always implement your own hooks for triggering CI, arbitrary code analysis, etc. Github's commit API will let you give the green light or red light to any commit so you can see at a glance how good a pull request is. But of course there's nothing stopping one using github OR an-image tools. (Or tools that produce custom images based on github commits that run analyses and then persist somewhere so you can (a) see the analyses immediately and (b) play around with the code. Mainly I think it's a mistake to reinvent tech _just because_ you simply must work in an image. That's the core behind my moaning. (And yes, I am working on addressing these issues, so I'm not _just_ moaning.) frank

March 11, 2013

Re: [Pharo-project] Help with MenuMorph

by stephane ducasse

Now I have the problem that I do not know how to get the value from the menu and not the menu item morph setFFTSize "Set the size of the FFT used for frequency analysis." | aMenu sz on | aMenu := MenuMorph new title: ('FFT size (currently {1})' translated format:{fft n}). ((7 to: 10) collect: [:n | 2 raisedTo: n]) do: [ :r | aMenu add: r printString value: r]. sz := aMenu xxxxxxx sz ifNil: [^ self]. on := soundInput isRecording. self stop. fft := FFT new: sz. self resetDisplay. on ifTrue: [self start]. do you have an idea? Stef

March 11, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by stephane ducasse

thanks doru! > Hi, > > Where should I report Pharo VM crashes with Pharo 2.0? here first :) > > In particular, I wanted to report the problem related to running Moose tests from the command line: > > --- > You can reproduce it on Mac, quite consistently: just run the attached script (you need to have wget installed), or do it manually: > > 1. download and unzip the latest Moose 4.8: > https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/lastSuccessfulBuild/arti… > 2. download and unzip the latest Pharo VM: > http://pharo.gforge.inria.fr/ci/vm/pharo/mac/pharo-mac-latest.zip > 3. execute: > ./Pharo.app/Contents/MacOS/Pharo ./Moose-latest-dev-4.8.image moosetest > > The VM crashes, but there is no trace of the error. > --- > > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "It's not what we do that matters most, it's how we do it." > > <crasher.sh>

March 11, 2013

[Pharo-project] Menu :)

by StÃ©phane Ducasse

I'm sure that we can do better... popUpAt: aPoint forHand: hand in: aWorld allowKeyboard: aBoolean "Present this menu at the given point under control of the given hand." | evt | aWorld submorphs select: [ :each | (each isKindOf: MenuMorph) and: [each stayUp not]] thenCollect: [ :menu | menu delete]. self items isEmpty ifTrue: [^ self]. (self submorphs select: [:m | m isKindOf: UpdatingMenuItemMorph]) do: [:m | m updateContents]. self layoutItems. "precompute width" self positionAt: aPoint relativeTo: (selectedItem ifNil: [self items first]) inWorld: aWorld. aWorld addMorphFront: self. "Acquire focus for valid pop up behavior" hand newMouseFocus: self. aBoolean ifTrue: [hand newKeyboardFocus: self]. evt := hand lastEvent. (evt isKeyboard or: [evt isMouse and: [evt anyButtonPressed not]]) ifTrue: ["Select first item if button not down" self moveSelectionDown: 1 event: evt]. self updateColor. self changed

March 11, 2013

Re: [Pharo-project] Help with MenuMorph

by jannik.laval

Ok, I did it too :)) I created a ValuedMenuItemMorph as you propose. Jannik On Mar 11, 2013, at 9:53 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Jannik > > It works :) > I will produce a cs because this is a nice extension :) > > Stef >

March 11, 2013

[Pharo-project] where to report vm crashes? (while running Moose tests)

by Tudor Girba

Hi, Where should I report Pharo VM crashes with Pharo 2.0? In particular, I wanted to report the problem related to running Moose tests from the command line: --- You can reproduce it on Mac, quite consistently: just run the attached script (you need to have wget installed), or do it manually: 1. download and unzip the latest Moose 4.8: https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/lastSuccessfulBuild/arti… 2. download and unzip the latest Pharo VM: http://pharo.gforge.inria.fr/ci/vm/pharo/mac/pharo-mac-latest.zip 3. execute: ./Pharo.app/Contents/MacOS/Pharo ./Moose-latest-dev-4.8.image moosetest The VM crashes, but there is no trace of the error. --- Cheers, Doru -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it."

March 11, 2013

Re: [Pharo-project] Help with MenuMorph

by stephane ducasse

Jannik It works :) I will produce a cs because this is a nice extension :) Stef

March 11, 2013