October 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Why atomic stuff rules :)

by Igor Stasenko

In the attachment an implementation of SharedQueue3, which using atomic operation. Of course , currently it is based on assumption that some stuff (like two assignments in a row) can't be interrupted. The FIFO implementation using ASWP and CAS: push: - no spins, 1 ASWP pop: - 2 spins, 1 ASWP , 1 CAS Here a simple bench i made, which pushing 100000 elements into queue using 10 different processes, and then looks how many are popped via 3 feeder processes during that time: Squeak VM. SharedQueue : SharedQueue3Test new benchManyPushersAndFeeders: SharedQueue 'Added 100000 items, processed 30000 queue items during 1928 milliseconds' SharedQueue2 : SharedQueue3Test new benchManyPushersAndFeeders: SharedQueue2 'Added 100000 items, processed 30034 queue items during 1074 milliseconds' SharedQueue3 (mine) : SharedQueue3Test new benchManyPushersAndFeeders: SharedQueue3 'Added 100000 items, processed 70229 queue items during 118 milliseconds' Cog: SharedQueue3Test new benchManyPushersAndFeeders: SharedQueue 'Added 100000 items, processed 29999 queue items during 1955 milliseconds' SharedQueue3Test new benchManyPushersAndFeeders: SharedQueue2 'Added 100000 items, processed 29997 queue items during 197 milliseconds' SharedQueue3Test new benchManyPushersAndFeeders: SharedQueue3 'Added 100000 items, processed 100000 queue items during 26 milliseconds' if anyone has better ideas how to bench throughput, send me the code. -- Best regards, Igor Stasenko AKA sig.

Oct. 14, 2010

[Pharo-project] OOP best practices

by Fernando olivero

Hi Hernan, just wanted to get your opinion on the following method, that attempts to adhere to your "complete objects" pattern. ( ESUG 2010 TALK). PerformedExperiment>>experiment: anExperiment start: aTime stop: aStopTime participant: aParticipant tasks: aCollectionOfTasks | experiment | experiment := self new. experiment experiment: anExperiment start: aTime stop: aStopTime participant: aParticipant tasks: aCollectionOfTasks. ^ experiment In your experience, how does the pattern cope with large keyword selectors. Maybe this case is not that evident, although we should try to avoid having more than 4 instance variables anyway, i would like to get your opinion on this problem (?). Thanks, Fernando

Oct. 14, 2010

Re: [Pharo-project] Stack should be reimplemented with Array

by jaayer

The original contains an error; it send min: where it should max:. This one contains the correction.

Oct. 14, 2010

Re: [Pharo-project] Stack should be reimplemented with Array

by Eliot Miranda

2010/10/14 jaayer <jaayer(a)zoho.com> > There was a post on this list back in August complaining about Stack > inheriting from LinkedList. There was some discussion, but apparently no > resolution, as Stack still inherits from LinkedList in the Pharo 1.2 Core > Image I just downloaded. Rather than reimplementing it to forward to a > contained LinkedList, I think it should use an Array internally like > OrderedCollection does. An Array-based implementation of Stack would be > faster than one based on LinkedList due to the basic stack operations (push, > pop and top) being able to rely more on primitives. This assumes that you > know roughly how a big a stack you need; if you don't, reallocating the > array and copying its contents over and over again will cost you, but this > is an exceptional case;-- most stacks are small and when they aren't, the > programmer usually has enough information to select a reasonable stack size. > *No*. Stack and OrderedCollection differ *usefully*. Adding an item to a Stack is always O(1). Adding an item to an OrderedCollection is O(N) because when the array overflows a new one must be allocated and the old objects copied to the new. Why not apply your speedups to OrderedCollection, or is that not possible? If not possible, then come up with a new name and add that. Please /don't/ change Stack. > > Enclosed is a fileout of an Array-based Stack implementation. It trounces > the LinkedList-based implementation easily, but more interestingly, it > performs better than an OrderedCollection when used like a stack: > > Pushing is roughly ~30% faster: > r1 :=[100000 timesRepeat: [ > s := Stack new. > 10 timesRepeat: [s push: #foo]]] timeToRun. > r2 := [100000 timesRepeat: [ > oc := OrderedCollection new. > 10 timesRepeat: [oc addLast: #foo]]] timeToRun. > 100 - ((r1 / r2) asFloat * 100). > > as is pushing + popping: > r3 := [100000 timesRepeat: [ > s := Stack new. > 10 timesRepeat: [s push: #foo]. > 10 timesRepeat: [s pop]]] timeToRun. > r4 := [100000 timesRepeat: [ > oc := OrderedCollection new. > 10 timesRepeat: [oc addLast: #foo]. > 10 timesRepeat: [oc removeLast]]] timeToRun. > 100 - ((r3 / r4) asFloat * 100). > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 14, 2010

Re: [Pharo-project] Bug when changing superclass in latest OB?

by Simon Denier

On 14 oct. 2010, at 19:37, Lukas Renggli wrote: > Hi Simon, > > It works for me too, the change can even be undone and redone. Also > this should be tested as part of the unit tests. > > Maybe try to load the code again and recompile all packages: > > Gofer new > squeaksource: 'rb'; > package: 'AST-Core'; > package: 'Refactoring-Core'; > package: 'Refactoring-Changes'; > package: 'Refactoring-Critics'; > package: 'Refactoring-Environment'; > load; > recompile. > > Gofer new > renggli: 'omnibrowser'; > package: 'OmniBrowser'; > package: 'OB-Standard'; > package: 'OB-Morphic'; > package: 'OB-Refactory'; > load; > recompile Indeed it works as expected when I reload+recompile. Thanks Lukas. > > > On 14 October 2010 19:23, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >> hi Simon, >> >> I cannot reproduce. It works as expected for me. >> >> Alexandre >> >> >> On 14 Oct 2010, at 12:43, Simon Denier wrote: >> >>> Hi >>> >>> Downloading the latest OB today with: >>> >>> Gofer new >>> squeaksource: 'rb'; >>> package: 'AST-Core'; >>> package: 'Refactoring-Core'; >>> package: 'Refactoring-Changes'; >>> package: 'Refactoring-Critics'; >>> package: 'Refactoring-Environment'; >>> load. >>> >>> Gofer new >>> renggli: 'omnibrowser'; >>> package: 'OmniBrowser'; >>> package: 'OB-Standard'; >>> package: 'OB-Morphic'; >>> package: 'OB-Refactory'; >>> load. >>> >>> >>> Then I change the superclass of the template of an existing class, then accept: >>> >>> Object subclass: #FileContentsBrowser >>> instanceVariableNames: 'packages infoString' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'Tools-File Contents Browser' >>> >>> >>> The superclass is not changed, instead OB changes its focus to the superclass. >>> >>> Can anyone confirm this bug? >>> >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon

Oct. 14, 2010

[Pharo-project] Stack should be reimplemented with Array

by jaayer

There was a post on this list back in August complaining about Stack inheriting from LinkedList. There was some discussion, but apparently no resolution, as Stack still inherits from LinkedList in the Pharo 1.2 Core Image I just downloaded. Rather than reimplementing it to forward to a contained LinkedList, I think it should use an Array internally like OrderedCollection does. An Array-based implementation of Stack would be faster than one based on LinkedList due to the basic stack operations (push, pop and top) being able to rely more on primitives. This assumes that you know roughly how a big a stack you need; if you don't, reallocating the array and copying its contents over and over again will cost you, but this is an exceptional case;-- most stacks are small and when they aren't, the programmer usually has enough information to select a reasonable stack size. Enclosed is a fileout of an Array-based Stack implementation. It trounces the LinkedList-based implementation easily, but more interestingly, it performs better than an OrderedCollection when used like a stack: Pushing is roughly ~30% faster: r1 :=[100000 timesRepeat: [ s := Stack new. 10 timesRepeat: [s push: #foo]]] timeToRun. r2 := [100000 timesRepeat: [ oc := OrderedCollection new. 10 timesRepeat: [oc addLast: #foo]]] timeToRun. 100 - ((r1 / r2) asFloat * 100). as is pushing + popping: r3 := [100000 timesRepeat: [ s := Stack new. 10 timesRepeat: [s push: #foo]. 10 timesRepeat: [s pop]]] timeToRun. r4 := [100000 timesRepeat: [ oc := OrderedCollection new. 10 timesRepeat: [oc addLast: #foo]. 10 timesRepeat: [oc removeLast]]] timeToRun. 100 - ((r3 / r4) asFloat * 100).

Oct. 14, 2010

Re: [Pharo-project] Bug when changing superclass in latest OB?

by Lukas Renggli

Hi Simon, It works for me too, the change can even be undone and redone. Also this should be tested as part of the unit tests. Maybe try to load the code again and recompile all packages: Gofer new squeaksource: 'rb'; package: 'AST-Core'; package: 'Refactoring-Core'; package: 'Refactoring-Changes'; package: 'Refactoring-Critics'; package: 'Refactoring-Environment'; load; recompile. Gofer new renggli: 'omnibrowser'; package: 'OmniBrowser'; package: 'OB-Standard'; package: 'OB-Morphic'; package: 'OB-Refactory'; load; recompile On 14 October 2010 19:23, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > hi Simon, > > I cannot reproduce. It works as expected for me. > > Alexandre > > > On 14 Oct 2010, at 12:43, Simon Denier wrote: > >> Hi >> >> Downloading the latest OB today with: >> >> Gofer new >> Â Â Â squeaksource: 'rb'; >> Â Â Â package: 'AST-Core'; >> Â Â Â package: 'Refactoring-Core'; >> Â Â Â package: 'Refactoring-Changes'; >> Â Â Â package: 'Refactoring-Critics'; >> Â Â Â package: 'Refactoring-Environment'; >> Â Â Â load. >> >> Gofer new >> Â Â Â renggli: 'omnibrowser'; >> Â Â Â package: 'OmniBrowser'; >> Â Â Â package: 'OB-Standard'; >> Â Â Â package: 'OB-Morphic'; >> Â Â Â package: 'OB-Refactory'; >> Â Â Â load. >> >> >> Then I change the superclass of the template of an existing class, then accept: >> >> Object subclass: #FileContentsBrowser >> Â Â Â instanceVariableNames: 'packages infoString' >> Â Â Â classVariableNames: '' >> Â Â Â poolDictionaries: '' >> Â Â Â category: 'Tools-File Contents Browser' >> >> >> The superclass is not changed, instead OB changes its focus to the superclass. >> >> Can anyone confirm this bug? >> >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Oct. 14, 2010

Re: [Pharo-project] Bug when changing superclass in latest OB?

by Alexandre Bergel

hi Simon, I cannot reproduce. It works as expected for me. Alexandre On 14 Oct 2010, at 12:43, Simon Denier wrote: > Hi > > Downloading the latest OB today with: > > Gofer new > squeaksource: 'rb'; > package: 'AST-Core'; > package: 'Refactoring-Core'; > package: 'Refactoring-Changes'; > package: 'Refactoring-Critics'; > package: 'Refactoring-Environment'; > load. > > Gofer new > renggli: 'omnibrowser'; > package: 'OmniBrowser'; > package: 'OB-Standard'; > package: 'OB-Morphic'; > package: 'OB-Refactory'; > load. > > > Then I change the superclass of the template of an existing class, then accept: > > Object subclass: #FileContentsBrowser > instanceVariableNames: 'packages infoString' > classVariableNames: '' > poolDictionaries: '' > category: 'Tools-File Contents Browser' > > > The superclass is not changed, instead OB changes its focus to the superclass. > > Can anyone confirm this bug? > > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 14, 2010

[Pharo-project] Bug when changing superclass in latest OB?

by Simon Denier

Hi Downloading the latest OB today with: Gofer new squeaksource: 'rb'; package: 'AST-Core'; package: 'Refactoring-Core'; package: 'Refactoring-Changes'; package: 'Refactoring-Critics'; package: 'Refactoring-Environment'; load. Gofer new renggli: 'omnibrowser'; package: 'OmniBrowser'; package: 'OB-Standard'; package: 'OB-Morphic'; package: 'OB-Refactory'; load. Then I change the superclass of the template of an existing class, then accept: Object subclass: #FileContentsBrowser instanceVariableNames: 'packages infoString' classVariableNames: '' poolDictionaries: '' category: 'Tools-File Contents Browser' The superclass is not changed, instead OB changes its focus to the superclass. Can anyone confirm this bug? -- Simon

Oct. 14, 2010

Re: [Pharo-project] Issue 3101: Wrong Monticello packages initialization order

by Pavel Krivanek

Hi Alexandre, I attached a test to the issue record. Thanks for the poke ;-) Cheers, -- Pavel On Thu, Oct 14, 2010 at 2:00 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > Hi Pavel, > > It would be cool to have a test for this... > > Alexandre > > > On 14 Oct 2010, at 06:04, Pavel Krivanek wrote: > >> see http://code.google.com/p/pharo/issues/detail?id=3101 >> >> Cheers, >> -- Pavel >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 14, 2010