June 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.4] #14010

by StÃ©phane Ducasse

14010 ----- - Issue 4439: Allow cherry-picking when merging. Second part removing MCConflict. http://code.google.com/p/pharo/issues/detail?id=4439 - Issue 4448: Cleaning MC conflicts Stef and Igor

June 24, 2011

Re: [Pharo-project] ConfigurationOfPhexample (was #assert:equals: feels backwards)

by Sean P. DeNigris

Sean P. DeNigris wrote: > > * For some reason, they do not play well with Autotest > Here's a temporary hack to integrate with Autotest: CompiledMethod>>isTestMethod ^ self belongsToTestCase and: [('test*' match: self selector) or: ['should*' match: self selector]]. -- View this message in context: http://forum.world.st/Re-ConfigurationOfPhexample-was-assert-equals-feels-b… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 24, 2011

Re: [Pharo-project] ConfigurationOfPhexample (was #assert:equals: feels backwards)

by Sean P. DeNigris

Sean P. DeNigris wrote: > > * For some reason, they do not play well with Autotest - run > PhexampleTest's tests in OB, and Autotest>>findRunAndShowTestsOf: gets > passed (AnObsoleteClassForTestToBeDeleted1>>#action: "a > CompiledMethod(119537664)") as a parameter, which leads to an error. > Posted a moment too soon. PhexampleTest compiles methods in a test, the other examples work fine. S -- View this message in context: http://forum.world.st/Re-ConfigurationOfPhexample-was-assert-equals-feels-b… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 24, 2011

Re: [Pharo-project] ConfigurationOfPhexample (was #assert:equals: feels backwards)

by Sean P. DeNigris

laurent laffont wrote: > > package: 'ConfigurationOfPhexample'; > Phexample's matchers make me happy (like RSpec's used to before I learned about Smalltalk's live, open image). And they work in regular TestCases too, not just Phexamples. Two initial observations: * the #shouldXxx methods do not fit into OB's SUnit integration (I am fixing right now) * For some reason, they do not play well with Autotest - run PhexampleTest's tests in OB, and Autotest>>findRunAndShowTestsOf: gets passed (AnObsoleteClassForTestToBeDeleted1>>#action: "a CompiledMethod(119537664)") as a parameter, which leads to an error. Sean -- View this message in context: http://forum.world.st/Re-ConfigurationOfPhexample-was-assert-equals-feels-b… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 24, 2011

Re: [Pharo-project] Proposal to refactor MethodFinder with pragmas

by Lukas Renggli

> Arguably using pragma's is cleaner approach to specify orthogonal concerns but without full IDE support (refactorings etc to minimize unmaintained pragma's) I would argue for just using a method and package based on convention. FYI, the refactoring engine supports pragmas and can for example rename them. Lukas -- Lukas Renggli www.lukas-renggli.ch

June 24, 2011

Re: [Pharo-project] Proposal to refactor MethodFinder with pragmas

by Alexandre Bergel

> ... because using method is old school and pragma's are new school ;) (Java annotations anyone) > > Arguably using pragma's is cleaner approach to specify orthogonal concerns but without full IDE support (refactorings etc to minimize unmaintained pragma's) I would argue for just using a method and package based on convention. > At the end of the day both solutions will work but if we are going to aggregate all the MethodFinder acceptable selectors into a class method then we may as well drop the pragma... Have a look at the help browser. It is slow because of global pragma queries. Having a method Behavior>>finderApprovedMethods looks perfectly okay to me. Cheers, Alexandre > > On 24 Jun 2011, at 3:41 PM, StÃ©phane Ducasse wrote: > > Yes > we were wondering with igor why using pragmas and that a simple list would be enough. > > Stef > > On Jun 24, 2011, at 2:26 PM, Alexandre Bergel wrote: > >> Why not something like >> >> Magnitude class>>finderApprovedMethods >> ^ {#max: . #min: . #min:max: . #< . ... } >> >> It is shorter and less magic is involved here. It will also be probably faster to do a query. >> >> Cheers, >> Alexandre >> >> On 24 Jun 2011, at 05:25, Damien Cassou wrote: >> >>> Currently MethodFinder uses a list of acceptable selectors to execute. >>> This list of selectors is not maintained which results in a lot of >>> selectors to exist only in this list as they have been removed in the >>> system. I propose to use pragmas on classes to generate this list >>> automatically. >>> >>> Here is an example >>> >>> Magnitude class>>finderApprovedMethods >>> <finderApproveInstanceMethod: #max:> >>> <finderApproveInstanceMethod: #min:> >>> <finderApproveInstanceMethod: #min:max:> >>> <finderApproveInstanceMethod: #< > >>> <finderApproveInstanceMethod: #<= > >>> <finderApproveInstanceMethod: #< > >>> <finderApproveInstanceMethod: #<= > >>> <finderApproveInstanceMethod: #between:and: > >>> >>> What do you think? >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Lambdas are relegated to relative obscurity until Java makes them >>> popular by not having them." James Iry >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 24, 2011

Re: [Pharo-project] Proposal to refactor MethodFinder with pragmas

by Carlo

... because using method is old school and pragma's are new school ;) (Java annotations anyone) Arguably using pragma's is cleaner approach to specify orthogonal concerns but without full IDE support (refactorings etc to minimize unmaintained pragma's) I would argue for just using a method and package based on convention. At the end of the day both solutions will work but if we are going to aggregate all the MethodFinder acceptable selectors into a class method then we may as well drop the pragma... On 24 Jun 2011, at 3:41 PM, StÃ©phane Ducasse wrote: Yes we were wondering with igor why using pragmas and that a simple list would be enough. Stef On Jun 24, 2011, at 2:26 PM, Alexandre Bergel wrote: > Why not something like > > Magnitude class>>finderApprovedMethods > ^ {#max: . #min: . #min:max: . #< . ... } > > It is shorter and less magic is involved here. It will also be probably faster to do a query. > > Cheers, > Alexandre > > On 24 Jun 2011, at 05:25, Damien Cassou wrote: > >> Currently MethodFinder uses a list of acceptable selectors to execute. >> This list of selectors is not maintained which results in a lot of >> selectors to exist only in this list as they have been removed in the >> system. I propose to use pragmas on classes to generate this list >> automatically. >> >> Here is an example >> >> Magnitude class>>finderApprovedMethods >> <finderApproveInstanceMethod: #max:> >> <finderApproveInstanceMethod: #min:> >> <finderApproveInstanceMethod: #min:max:> >> <finderApproveInstanceMethod: #< > >> <finderApproveInstanceMethod: #<= > >> <finderApproveInstanceMethod: #< > >> <finderApproveInstanceMethod: #<= > >> <finderApproveInstanceMethod: #between:and: > >> >> What do you think? >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Lambdas are relegated to relative obscurity until Java makes them >> popular by not having them." James Iry >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

June 24, 2011

Re: [Pharo-project] ImageMap

by Pavel Krivanek

Hi Craig, of course it is unwelcome content. Sooner the KernelImage had empty Undeclared and very few unimlemented calls. However it must be up-to-date with the current Pharo and till now I prefered little amount of changes with the price of some mess in the image. Easily removeable and fatal Undeclared are already removed. The main task for now is to finish PharoKernel integration to the Pharo development process and then we can focus on the garbage. -- Pavel 24.6.2011 v 15:16, Craig Latta <craig(a)netjam.org>: > > Hi Pavel-- > >> Let's hunt waste :-) > > Does all that stuff in Undeclared need to be there? > > > -C > > -- > Craig Latta > www.netjam.org/resume > +31 6 2757 7177 > + 1 415 287 3547 > > >

June 24, 2011

Re: [Pharo-project] Proposal to refactor MethodFinder with pragmas

by StÃ©phane Ducasse

Yes we were wondering with igor why using pragmas and that a simple list would be enough. Stef On Jun 24, 2011, at 2:26 PM, Alexandre Bergel wrote: > Why not something like > > Magnitude class>>finderApprovedMethods > ^ {#max: . #min: . #min:max: . #< . ... } > > It is shorter and less magic is involved here. It will also be probably faster to do a query. > > Cheers, > Alexandre > > On 24 Jun 2011, at 05:25, Damien Cassou wrote: > >> Currently MethodFinder uses a list of acceptable selectors to execute. >> This list of selectors is not maintained which results in a lot of >> selectors to exist only in this list as they have been removed in the >> system. I propose to use pragmas on classes to generate this list >> automatically. >> >> Here is an example >> >> Magnitude class>>finderApprovedMethods >> <finderApproveInstanceMethod: #max:> >> <finderApproveInstanceMethod: #min:> >> <finderApproveInstanceMethod: #min:max:> >> <finderApproveInstanceMethod: #< > >> <finderApproveInstanceMethod: #<= > >> <finderApproveInstanceMethod: #< > >> <finderApproveInstanceMethod: #<= > >> <finderApproveInstanceMethod: #between:and: > >> >> What do you think? >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Lambdas are relegated to relative obscurity until Java makes them >> popular by not having them." James Iry >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

June 24, 2011

Re: [Pharo-project] ImageMap

by Craig Latta

Hi Pavel-- > Let's hunt waste :-) Does all that stuff in Undeclared need to be there? -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547

June 24, 2011