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

[pharo-project/pharo-core] d01faa: 40567

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: d01faa9599fe870917dfdc1c15b12c82628de4b8 https://github.com/pharo-project/pharo-core/commit/d01faa9599fe870917dfdc1c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-03-19 (Thu, 19 Mar 2015) Changed paths: M Morphic-Core.package/WorldState.class/class/world menu items/mostUsedToolsOn_.st M NautilusRefactoring.package/NautilusRefactoring.class/instance/display/class_andInstVariable_.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script566.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script567.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40566.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40567.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40567 15115 Spotter should appear in the World menu https://pharo.fogbugz.com/f/cases/15115 15163 #instVarNamed: mixed up https://pharo.fogbugz.com/f/cases/15163 http://files.pharo.org/image/40/40567.zip

March 19, 2015

Re: [Pharo-dev] Number>>#percent

by Tudor Girba

I agree with that. Doru On Thu, Mar 19, 2015 at 2:47 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 19 Mar 2015, at 14:32, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > > > demarey wrote > >> I'm also in favor to have it as default in the core. It is a so basic > >> thing. > > > > By the way, this was integrated into 4.0 :) > > And I am already using it. > > Although I must say that it should have been > > ^ self / 100 > > instead of > > ^ self / 100.0 > > It is up to the caller to decide about conversions. When computing with > money, you typically don't want floating point. > -- www.tudorgirba.com "Every thing has its own flow"

March 19, 2015

Re: [Pharo-dev] subclassResponsibility protocol?

by Sven Van Caekenberghe

No. I wouldn't do that. You could list them in the implementation section of the class comment. > On 19 Mar 2015, at 14:44, Ben Coman <btc(a)openinworld.com> wrote: > > > So now in the image the remnants from the old DelayScheduler have been cleaned up by making it abstract with several methods becoming "subclassResponsibility". > > Would it be a reasonable practice to group these in a protocol "subclass responsibility" to make it easier to determine what is needed for concrete subclasses? Or maybe append "subclass responsibility" to the original protocol of such methods? > > cheers -ben

March 19, 2015

Re: [Pharo-dev] subclassResponsibility protocol?

by Marcus Denker

> On 19 Mar 2015, at 14:44, Ben Coman <btc(a)openInWorld.com> wrote: > > > So now in the image the remnants from the old DelayScheduler have been cleaned up by making it abstract with several methods becoming "subclassResponsibility". > > Would it be a reasonable practice to group these in a protocol "subclass responsibility" to make it easier to determine what is needed for concrete subclasses? Or maybe append "subclass responsibility" to the original protocol of such methods? > no, normally this is not doneâ¦ sometimes I wish we would have tags on methods instead of protocols. Then we could do both. Marcus

March 19, 2015

Re: [Pharo-dev] Number>>#percent

by Sven Van Caekenberghe

> On 19 Mar 2015, at 14:32, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > demarey wrote >> I'm also in favor to have it as default in the core. It is a so basic >> thing. > > By the way, this was integrated into 4.0 :) And I am already using it. Although I must say that it should have been ^ self / 100 instead of ^ self / 100.0 It is up to the caller to decide about conversions. When computing with money, you typically don't want floating point.

March 19, 2015

subclassResponsibility protocol?

by Ben Coman

So now in the image the remnants from the old DelayScheduler have been cleaned up by making it abstract with several methods becoming "subclassResponsibility". Would it be a reasonable practice to group these in a protocol "subclass responsibility" to make it easier to determine what is needed for concrete subclasses? Or maybe append "subclass responsibility" to the original protocol of such methods? cheers -ben

March 19, 2015

Re: [Pharo-dev] Number>>#percent

by Sean P. DeNigris

demarey wrote > I'm also in favor to have it as default in the core. It is a so basic > thing. By the way, this was integrated into 4.0 :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Number-percent-tp4805988p4813187.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 19, 2015

Re: [Pharo-dev] #instVarNamed: mixed up ?

by Guillermo Polito

I could reproduce it! I added the info and a simpler case in https://pharo.fogbugz.com/f/cases/15163/instVarNamed-mixed-up I think it is related with alphabetic sorting of the instance variable names... But I don't know who is doing that. Maybe the refactoring? El jue., 19 de mar. de 2015 a la(s) 1:38 p. m., Sven Van Caekenberghe < sven(a)stfx.eu> escribiÃ³: > Yeah, maybe, in any case, even though I reproduced it this morning in a > clean image, I can no longer do so - too bad, then this just becomes noise. > Sorry. > > > On 19 Mar 2015, at 13:34, Max Leske <maxleske(a)gmail.com> wrote: > > > > Thatâs possibly related to the problem which Sean saw with Fuel. In one > image âself slotsâ and âself instanceVariablesâ answered differently > ordered collections. > > > > > >> On 19 Mar 2015, at 07:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> > >> Ups, a bug. I will investigateâ¦ > >> > >>> On 19 Mar 2015, at 07:51, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>> > >>> I had the strangest problem yesterday in #40528 > >>> > >>> Define a class: > >>> > >>> Object subclass: #AAA > >>> instanceVariableNames: 'five four one three two' > >>> classVariableNames: '' > >>> category: '_UnpackagedPackage' > >>> > >>> With one method: > >>> > >>> initialize > >>> super initialize. > >>> one := 1. > >>> two := 2. > >>> three := 3. > >>> four := 4. > >>> five := 5 > >>> > >>> Open a playground and do it & go an instance: > >>> > >>> AAA new > >>> > >>> In the raw tab execute: > >>> > >>> self class allInstVarNames collect: [ :each | each -> (self > instVarNamed: each) ]. > >>> > >>> Which gives you, as expected: > >>> > >>> {#five->5. #four->4. #one->1. #three->3. #two->2} > >>> > >>> Now auto generate one accessor, say for one. > >>> > >>> Play again, and now the result is: > >>> > >>> {#five->1. #four->2. #one->3. #three->4. #two->5} > >>> > >>> !? > >>> > >>> Reaccepting the class definition fixes the problem. > >>> > >>> Sven > >>> > >>> PS: this code is used by STON, NeoJSON & NeoCSV. > >>> > >>> > >>> > >> > >> > > > > > > >

March 19, 2015

Re: [Pharo-dev] #instVarNamed: mixed up ?

by Sven Van Caekenberghe

Yeah, maybe, in any case, even though I reproduced it this morning in a clean image, I can no longer do so - too bad, then this just becomes noise. Sorry. > On 19 Mar 2015, at 13:34, Max Leske <maxleske(a)gmail.com> wrote: > > Thatâs possibly related to the problem which Sean saw with Fuel. In one image âself slotsâ and âself instanceVariablesâ answered differently ordered collections. > > >> On 19 Mar 2015, at 07:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Ups, a bug. I will investigateâ¦ >> >>> On 19 Mar 2015, at 07:51, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> I had the strangest problem yesterday in #40528 >>> >>> Define a class: >>> >>> Object subclass: #AAA >>> instanceVariableNames: 'five four one three two' >>> classVariableNames: '' >>> category: '_UnpackagedPackage' >>> >>> With one method: >>> >>> initialize >>> super initialize. >>> one := 1. >>> two := 2. >>> three := 3. >>> four := 4. >>> five := 5 >>> >>> Open a playground and do it & go an instance: >>> >>> AAA new >>> >>> In the raw tab execute: >>> >>> self class allInstVarNames collect: [ :each | each -> (self instVarNamed: each) ]. >>> >>> Which gives you, as expected: >>> >>> {#five->5. #four->4. #one->1. #three->3. #two->2} >>> >>> Now auto generate one accessor, say for one. >>> >>> Play again, and now the result is: >>> >>> {#five->1. #four->2. #one->3. #three->4. #two->5} >>> >>> !? >>> >>> Reaccepting the class definition fixes the problem. >>> >>> Sven >>> >>> PS: this code is used by STON, NeoJSON & NeoCSV. >>> >>> >>> >> >> > >

March 19, 2015

Re: [Pharo-dev] #instVarNamed: mixed up ?

by Max Leske

Thatâs possibly related to the problem which Sean saw with Fuel. In one image âself slotsâ and âself instanceVariablesâ answered differently ordered collections. > On 19 Mar 2015, at 07:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Ups, a bug. I will investigateâ¦ > >> On 19 Mar 2015, at 07:51, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> I had the strangest problem yesterday in #40528 >> >> Define a class: >> >> Object subclass: #AAA >> instanceVariableNames: 'five four one three two' >> classVariableNames: '' >> category: '_UnpackagedPackage' >> >> With one method: >> >> initialize >> super initialize. >> one := 1. >> two := 2. >> three := 3. >> four := 4. >> five := 5 >> >> Open a playground and do it & go an instance: >> >> AAA new >> >> In the raw tab execute: >> >> self class allInstVarNames collect: [ :each | each -> (self instVarNamed: each) ]. >> >> Which gives you, as expected: >> >> {#five->5. #four->4. #one->1. #three->3. #two->2} >> >> Now auto generate one accessor, say for one. >> >> Play again, and now the result is: >> >> {#five->1. #four->2. #one->3. #three->4. #two->5} >> >> !? >> >> Reaccepting the class definition fixes the problem. >> >> Sven >> >> PS: this code is used by STON, NeoJSON & NeoCSV. >> >> >> > >

March 19, 2015