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

[Pharo-project] Example of non-concurrent code :)
by Igor Stasenko Oct. 16, 2010

Oct. 16, 2010

mouseTrailFrom: currentBuf "Current event, a mouse event buffer, is about to be processed. If there are other similar mouse events queued up, then drop them from the queue, and report the positions inbetween." | nextEvent trail | trail := (Array new: 1) writeStream. trail nextPut: currentBuf third @ currentBuf fourth. *a* [(nextEvent := Sensor peekEvent) isNil] whileFalse: [nextEvent first = currentBuf first ifFalse: [^trail contents "different event type"]. nextEvent fifth = currentBuf fifth ifFalse: [^trail contents "buttons changed"]. nextEvent sixth = currentBuf sixth ifFalse: [^trail contents "modifiers changed"]. "nextEvent is similar. Remove it from the queue, and check the next." *b* nextEvent := Sensor nextEvent. trail nextPut: nextEvent third @ nextEvent fourth]. ^trail contents Here, the bug: first it sends #peekEvent and its not nil. Okay, then after some logic voodo, it sends nextEvent, without precaution, that it may also answer nil! So, if some other process get between these two sends (*a*, *b*) and fetch/flush all events, a code will fail, because 'nextEvent third' is DNU , when nextEvent == nil. The fix is simple: nextEvent := Sensor nextEvent. nextEvent ifNotNil: [ trail nextPut: nextEvent third @ nextEvent fourth] Both Pharo & Squeak contain this bug. But this method slightly differs from each other. -- Best regards, Igor Stasenko AKA sig.

2 1

[Pharo-project] OOP best practices
by Fernando olivero Oct. 15, 2010

Oct. 15, 2010

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

4 8

Re: [Pharo-project] Stack should be reimplemented with Array
by StÃ©phane Ducasse Oct. 15, 2010

Oct. 15, 2010

thanks levente! this is always nice to read such kind of post since they educate us and we need that :) I want to be taught a lot :) Stef On Oct 15, 2010, at 6:33 PM, Levente Uzonyi wrote: > On Thu, 14 Oct 2010, jaayer wrote: > >> 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). > > Please write more realistic benchmarks. Adding 10 elements to your Stack implementation won't make it's array grow. Also the benchmark measures a lot of other stuff besides the cost of push and pop. Something like this should do it: > > "The linked Stack implementation" > (1 to: 5) collect: [ :run | > | stack | > Smalltalk garbageCollect. > stack := Stack new. > { > [ 1 to: 1000000 do: [ :each | stack push: each ] ] timeToRun. > [ 1 to: 1000000 do: [ :each | stack pop ] ] timeToRun } ] > #(#(167 88) #(169 91) #(169 88) #(166 87) #(166 88)) > > "OrderedCollection" > (1 to: 5) collect: [ :run | > | stack | > Smalltalk garbageCollect. > stack := OrderedCollection new. > { > [ 1 to: 1000000 do: [ :each | stack addLast: each ] ] timeToRun. > [ 1 to: 1000000 do: [ :each | stack removeLast ] ] timeToRun } ] > #(#(87 98) #(87 100) #(87 98) #(88 97) #(87 99)) > > "The new stack implementation" > (1 to: 5) collect: [ :run | > | stack | > Smalltalk garbageCollect. > stack := Stack new. > { > [ 1 to: 1000000 do: [ :each | stack push: each ] ] timeToRun. > [ 1 to: 1000000 do: [ :each | stack pop ] ] timeToRun } ] > #(#(89 62) #(90 63) #(89 62) #(89 62) #(89 64)) > > All benchmarks were run in the latest Squeak 4.2 alpha using the latest CogVM. > > Conclusion: OrderedCollection >> #removeLast uses #emptyCheck which is slow. Other than that the difference between OrderedCollection and an array-based stack implementation is neglible in Squeak using CogVM. > > Replacing > self emptyCheck > with > lastIndex < firstIndex ifTrue: [ self errorEmptyCollection] > in OrderedCollection >> #removeLast and running the benchmark again gives the following results: > #(#(88 65) #(90 66) #(89 66) #(88 68) #(87 66)) > > > Also please send #postCopy to super if you implement #postCopy. > > > Levente > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Re: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license
by Schwab,Wilhelm K Oct. 15, 2010

Oct. 15, 2010

Didier, I would go along with "clearly" with the code in Smalltalk; I do not have enough experience with Java to pronounce it too slow to do the job. Nor can I claim to understand what is involved in a continental weather forecast. When it comes to transforming 500,000 sample time series, I have a little more sense of it. There the problem is not so much the cost of processing one of them, it's that I have many of them to analyze and summarize. It might be that you do not address the expensive things that I use. For things like non-linear regression with modest numbers of points, the speed penalty of even Smalltalk might indeed not be a deterrent. In terms of my GPL/GSL struggle, the code most likely to be put at risk by GPL is what is needed to do least squares, root finding, and regression; it is also (however indirectly) connected to the more poorly designed parts of GSL. The transforms are relatively clean, and would be almost directly accessible with only modest improvements to Pharo. The few vector operations that I have used from BLAS can be clean-roomed with little effort. This could work out nicely. I'm not sure I agree that communication with external libraries is "unstable." I have done a lot of it for a long time with good results. It is true that our current FFI is not as good as Dolphin's, but it does work as far as it goes. It can be readily modified to provide diagnostic information that is suppressed by default and that helps a lot in getting things to work. NativeBoost and/or Alien will hopefully address callbacks and get closer to Dolphin's handling of structure field types. Bill ________________________________________ From: Didier Besset [didier(a)ieee.org] Sent: Friday, October 15, 2010 11:09 AM To: Schwab,Wilhelm K Subject: Re: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license You just have to see what is good for you. Clearly, you won't compute the weather forecast each day for whole Europe in ST or Java. However, I found that making least-square fits within the time required to refresh a screen perfecttly acceptable compared to the unstability of cross language communication. Cheers, Didier On 14/10/2010 22:36, Schwab,Wilhelm K wrote: > That is wonderful news! > > Didier, There is a natural question that arises: what are the performance implications of Smalltalk or Java? Why not C with a Smalltalk wrapper? I have not tried number crunching with Cog or NativeBoost doing some of the expensive lifting, but absent those advantages, the benefit from coding tight loops in C has been nothing short of eerie. I have never tried Java for it. If there is a speed boost to be had, would a port offend you? I am a pragmatist, so it would begin one function at a time, chosen by the type of work I do and driven by when the machine grunts. > > Thanks, > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Thursday, October 14, 2010 4:02 PM > To: Pharo Development; The general-purpose Squeak developers list; ESUG Mailing list > Cc: Didier H. Besset > Subject: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license > > I want to thanks didier for releasing the code of his book under MIT. > Thanks! > > > Begin forwarded message: > >> From: Didier Besset<didier(a)ieee.org> >> Date: October 14, 2010 8:06:52 PM GMT+02:00 >> To: StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> >> Subject: Disclaimer >> >> I hereby release the code of my book "Object Oriented Implementation of Numerical Methods" under the MIT license. >> >> Didier Besset > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

1 0

[Pharo-project] Stack should be reimplemented with Array
by jaayer Oct. 15, 2010

Oct. 15, 2010

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).

3 6

[Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license
by StÃ©phane Ducasse Oct. 15, 2010

Oct. 15, 2010

I want to thanks didier for releasing the code of his book under MIT. Thanks! Begin forwarded message: > From: Didier Besset <didier(a)ieee.org> > Date: October 14, 2010 8:06:52 PM GMT+02:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Disclaimer > > I hereby release the code of my book "Object Oriented Implementation of Numerical Methods" under the MIT license. > > Didier Besset

4 4

Re: [Pharo-project] Stack should be reimplemented with Array
by StÃ©phane Ducasse Oct. 15, 2010

Oct. 15, 2010

Thanks!!! Stef On Oct 14, 2010, at 8:32 PM, jaayer wrote: > The original contains an error; it send min: where it should max:. This one contains the correction.<Stack.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

3 2

[Pharo-project] FileChooser (Squeak) = ........ (Pharo)
by Hannes Hirzel Oct. 15, 2010

Oct. 15, 2010

Hello I am porting an application from Squeak to Pharo (actually the moose-seaside-glamour image) and I wonder what the equivalent class of FileChooser is? There are five 'Chooser' classes in Pharo 1.1 but no FileChooser. Thank you for the answer in advance Hannes

2 3

[Pharo-project] Call for contribution to http://pharo-project.org/about/research
by Alexandre Bergel Oct. 15, 2010

Oct. 15, 2010

Hi! I set up http://pharo-project.org/about/research Now, it needs content. I need bibitem. Please, send me only the item that you think are relevant to the page. It makes no sense to have hundreds of item directly listed here. Feel free to comment on it. I am open to suggestion. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

[Pharo-project] what happened with Shout colors in Pharo 1.1?
by Mariano Martinez Peck Oct. 15, 2010

Oct. 15, 2010

They've changed a lot from 1.0. For example, self, super, etc, are not in "orange" or that color of 1.0. Instances variables, are blue (instead of black), the same as parameters,etc... is there a way to recover the original colors? do we wanted this change or it is accidental ? cheers mariano

1 0