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

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

by Pavel Krivanek

It is an extra list that has to be maintained. And what package will own this method? -- Pavel On Fri, Jun 24, 2011 at 2:26 PM, Alexandre Bergel <alexandre.bergel(a)me.com> 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

[Pharo-project] [update 1.4] #14009

by StÃ©phane Ducasse

14009 ----- - Issue 4439: Allow cherry-picking when merging. Thanks Igor Stasenko. http://code.google.com/p/pharo/issues/detail?id=4439 Added more class comments and cleaning method categories Stef and igor

June 24, 2011

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

by Alexandre Bergel

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] Proposal to refactor MethodFinder with pragmas

by Damien Cassou

On Fri, Jun 24, 2011 at 11:34 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > What about only to use a pragma directly in the methods that will > inform that the method has no side effect and doesn't modify the state > of the object? This information may be used not only for the > MethodFinder. I would prefer your solution. But since there is currently no other user for this pragma, the result would be the same cluttering that people complained with previously. What do others 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 StÃ©phane Ducasse

excellent On Jun 24, 2011, at 12:16 PM, Marcus Denker 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

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

by Marcus Denker

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

[Pharo-project] ImageMap

by Pavel Krivanek

Hi, I generated an image map for the latest PharoKernel image http://windmap.cz/playground/imagemap/1.html Let's hunt waste :-) -- Pavel

June 24, 2011

Re: [Pharo-project] [update 1.3] #13273

by Marcus Denker

On Jun 24, 2011, at 11:51 AM, Sven Van Caekenberghe wrote: > Marcus, > > I am a bit confused, before this update my core 1.3 image updated to #13272 and asked to go to 1.4. > I said yes. Now I have: > > Pharo1.4a > Latest update: #13272 > > But I can no longer update. It seems to be looking for 14.... updates. > Normally it should load the updates of 1.4, which are just the same as the ones in 1.3 for now... > I have not yet seen anything about starting 1.4 on the mailing list ? The reason is that nothing yet was done... it's tracking the 1.3 updates. I wanted to announce it / do more but have not come around doing that.... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 24, 2011

Re: [Pharo-project] [update 1.3] #13273

by Sven Van Caekenberghe

Marcus, I am a bit confused, before this update my core 1.3 image updated to #13272 and asked to go to 1.4. I said yes. Now I have: Pharo1.4a Latest update: #13272 But I can no longer update. It seems to be looking for 14.... updates. I have not yet seen anything about starting 1.4 on the mailing list ? Sven On 23 Jun 2011, at 21:00, Marcus Denker wrote: > 13273 > ----- > > Issue 4434: CrLfFileStream>>#lineEndingConvention: > http://code.google.com/p/pharo/issues/detail?id=4434 > > Issue 4129: #assert:equals: is the opposite as expected > http://code.google.com/p/pharo/issues/detail?id=4129 > > Issue 4437: safer FreeTypeSettings>>#monitorType > http://code.google.com/p/pharo/issues/detail?id=4437 > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

June 24, 2011

Re: [Pharo-project] [update 1.3] #13274

by Pavel Krivanek

This one would be handy too: http://code.google.com/p/pharo/issues/detail?id=4446 -- Pavel On Fri, Jun 24, 2011 at 10:47 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Great, > > can you try to integrate this issue too: > http://code.google.com/p/pharo/issues/detail?id=4435 > Then no override of standard Pharo content will be necessary for > generation of kernel, gofer and core image. > > Cheers, > -- Pavel > > On Fri, Jun 24, 2011 at 9:47 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> 13274 >> ----- >> >> Issue 4445: Â Â shrinkToKernel later ChangeSets cleanup >> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=4445 >> >> Issue 4436: Â Â HandMorph mouseTrailFrom: problem >> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=4436 >> >> Issue 4443: Â Â StrikeFontSet isSynthetic >> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=4443 >> >> >> -- >> Marcus Denker Â -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> >

June 24, 2011