- Pharo-dev - lists.pharo.org

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

by Chris Cunningham

On Fri, Jun 24, 2011 at 9:47 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > - one method per class returning a list of selectors. I guess we could > use the Announcer to be notified when this particular method is loaded > or updated. Of equal/more importance, when a method referenced by this method is removed, it needs to update this referencing method. Even more interesting, when a method is added to the class that is side-effect free and MethodFinder friendly, it should be added to the list (although that would be fun to figure out programmatically). Also, if a method is updated to have side-effects, it should be removed from this list as well, although this doesn't happen very often. -Chris

June 24, 2011

Re: [Pharo-project] [ANN] hard freeze 1.3 and (slow) start of 1.4

by laurent laffont

Thanks a lot Marcus. Laurent. On Fri, Jun 24, 2011 at 12:16 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > So 1.3 seems to get stable... we added some fixes over the week, but most > of them are > related to Pavel's kernel, so they are just refactorings and cleanups, no > real fixes. > > I think we should continue to test 1.3 and end of the month announce it. > > TODO is quite short: > -> harvest the two last Full related issues > -> two more Pavel Kernel fixes for core > -> check one-click on hudson for release. > > We configured the infrastructure last week for 1.4... to get it > > -> update an image before 13267 and say "yes" when asked if you want > to progress to 1.4 > -> or download the image > > https://gforge.inria.fr/frs/download.php/28660/PharoCore-1.4-14000.zip > > -> The 1.4 stream uses a new squeaksource project (pharo14) as the other > one was too large (>4000 mcz files). > -> the updates are just the same as in 1.3 for now, the only difference is > that ToolBuilder was unloaded. > > For continuous integration, 1.4 is using the new Jenkins setup: > > https://ci.lille.inria.fr/pharo/ > > No one-click yet, that will follow... the idea is to move now slowly to the > new jenkins, while letting 1.2 and 1.3 on the old > server (and turn it off at some point in the future). > > Jenkins sends out tweets for every build: http://twitter.com/#!/pharoci > > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

June 24, 2011

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

by laurent laffont

Thanks Sean. I've fixed this in last Autotest. Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfAutotest'; load. (Smalltalk at: #ConfigurationOfAutotest) loadDevelopment. Laurent. On Fri, Jun 24, 2011 at 5:04 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > > 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] Proposal to refactor MethodFinder with pragmas

by Damien Cassou

On Fri, Jun 24, 2011 at 5:52 PM, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > Seems to me, unless individual methods are annotated (or assumed safe/unsafe > if not) that we would still be having to maintain a list that probably > wouldn't be maintained... I agree with all of you. To sum up: - we could add a pragma per method to indicate that the method can be called by the finder or better, that it is side-effect=free (not sure though that side-effect-free = usable-by-methodfinder) other solutions require maintenance, but simpler ones because if you remove the class you also remove the list of methods. These solutions are: - one method per class containing a list of pragmas. Pragmas should be found easily by using a PragmaCollector (I believe that the use of PragmaCollector should make lookup very fast) - one method per class returning a list of selectors. I guess we could use the Announcer to be notified when this particular method is loaded or updated. 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

June 24, 2011

Re: [Pharo-project] [ANN] hard freeze 1.3 and (slow) start of 1.4

by Damien Cassou

Very nice work, thank you very much Marcus. On Fri, Jun 24, 2011 at 12:16 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > So 1.3 seems to get stable... we added some fixes over the week, but most of them are > related to Pavel's kernel, so they are just refactorings and cleanups, no real fixes. > > I think we should continue to test 1.3 and end of the month announce it. > > TODO is quite short: > Â Â Â Â -> harvest the two last Full related issues > Â Â Â Â -> two more Pavel Kernel fixes for core > Â Â Â Â -> check one-click on hudson for release. > > We configured the infrastructure last week for 1.4... to get it > > Â Â Â Â -> update an image before 13267 and say "yes" when asked if you want to progress to 1.4 > Â Â Â Â -> or download the image > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â https://gforge.inria.fr/frs/download.php/28660/PharoCore-1.4-14000.zip > > -> The 1.4 stream uses a new squeaksource project (pharo14) as the other one was too large (>4000 mcz files). > -> the updates are just the same as in 1.3 for now, the only difference is that ToolBuilder was unloaded. > > For continuous integration, 1.4 is using the new Jenkins setup: > > Â Â Â Â https://ci.lille.inria.fr/pharo/ > > No one-click yet, that will follow... the idea is to move now slowly to the new jenkins, while letting 1.2 and 1.3 on the old > server (and turn it off at some point in the future). > > Jenkins sends out tweets for every build: http://twitter.com/#!/pharoci > > > Â Â Â Â Marcus > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 24, 2011

[Pharo-project] [update 1.4] #14012

by StÃ©phane Ducasse

14012 ----- - Issue 4412: CompiledMethod >> #valueWithReceiver:arguments: instead of Object >> #withArgs:executeMethod:. http://code.google.com/p/pharo/issues/detail?id=4412

June 24, 2011

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

by Tudor Girba

Thanks Sean for looking into this. Doru On 24 Jun 2011, at 17:04, Sean P. DeNigris wrote: > > 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. > -- www.tudorgirba.com "Every thing has its own flow."

June 24, 2011

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

by Gary Chambers

Seems to me, unless individual methods are annotated (or assumed safe/unsafe if not) that we would still be having to maintain a list that probably wouldn't be maintained... Just a thought. Regards, Gary ----- Original Message ----- From: "Lukas Renggli" <renggli(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, June 24, 2011 3:03 PM Subject: Re: [Pharo-project] Proposal to refactor MethodFinder with pragmas >> 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

[Pharo-project] [update 1.4] #14011

by StÃ©phane Ducasse

14011 ----- - MC Conflict cleanup: just renaming some methods.

June 24, 2011

[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