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

Re: [Pharo-project] Xtreams vs become:

by mkobetic＠gmail.com

"Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: > I've tested this strategy, and it works well: > > - use accessors self input/self output instead of inst. var. > - lazily initialize the input for Collection and File Sounds good to me, less work too. I just thought the write:read: approach makes it clearer that you need to do all the writing first and then all the reading. But that'll probably become clear quite quickly. So I think I'll go with your approach. The only case I wonder about is the one where we loop with progressively larger buffer sizes, so we'll need to be able to rebuild the input and output several times. I'll see if I can figure something out. > In collection tests, I have used > ^input ifNil:[input := outer terminal reading] > where: outer := output := collection writing. > This is because some Block transforms can't access the terminal collection... Not sure what you mean, but it will probably get clearer when I go do it. BTW, I've updated the package comments and regenerated the docs on the site yesterday. If you want to see the changes highlighted, go through the Sources tab and switch to the wiki repository. The diff view is quite usable there. Martin

Oct. 15, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Ramon Leon

On 10/15/2010 9:40 AM, Simon Denier wrote: > > On 15 oct. 2010, at 17:31, Mariano Martinez Peck wrote: > >> 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 ? > > I think the colors in 1.0 were inherited from the dev images build by Damien Cassou. In 1.1, the colors comes from the settings of Lukas, who maintains Shout? Am I wrong? I preferred the old colors as well and switched them back. The new ones are just too weak, not enough color, not enough bold, can't tell things apart. -- Ramon Leon http://onsmalltalk.com

Oct. 15, 2010

Re: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license

by Schwab,Wilhelm K

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 >

Oct. 15, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Simon Denier

On 15 oct. 2010, at 17:31, Mariano Martinez Peck wrote: > 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 ? I think the colors in 1.0 were inherited from the dev images build by Damien Cassou. In 1.1, the colors comes from the settings of Lukas, who maintains Shout? Am I wrong? I liked the colors in 1.0, but now I am accustomed to the current theme, which is very keen to the eye, except for two things that I change: - distinguish instance vars/class vars from other variables: I use a brownish color for that, as I want to see at once methods accessing the state of the object - distinguish class references: I use bold black as in the previous style, as I want to quickly catch hard dependencies in the code To customize colors, two solutions: 1) hack SHTextStylerST80>>defaultStyleTable 2) load latest Shout and use Settings (then you should be able to save/load your style), since there is now a Settings interface -- Simon

Oct. 15, 2010

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

by Levente Uzonyi

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

Oct. 15, 2010

Re: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license

by Schwab,Wilhelm K

Why should it be free? It might be nice to have an electronic copy, or just permission to scan and release, in escrow. That could be done quietly between Didier and ESUG, and triggered if the book is no longer in print. If it is in print and the code is worth having we should be buying copies. To do otherwise undercuts investment by both the author and the publisher. I bought Numerical Recipes with a much smaller carrot than MIT source. The only reason I did not buy the book long ago is that the mix of topics was not a direct match for me, and because I generally look for C code that I can compile into libraries with clean interfaces. I do more FFT, DWT than anything else; if they are in the book, I missed it. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Geert Claes [geert.wl.claes(a)gmail.com] Sent: Friday, October 15, 2010 2:42 AM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license Maybe a silly question, but it is the "code" of the book "Object Oriented Implementation of Numerical Methods", so the book itself won't be available for free? StÃ©phane Ducasse wrote: > > I want to thanks didier for releasing the code of his book under MIT. > Thanks! > > > Didier Besset wrote: >> >> 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 >> > -- View this message in context: http://forum.world.st/Object-Oriented-Implementation-of-Numerical-Methods-u… Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 15, 2010

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

by Levente Uzonyi

On Thu, 14 Oct 2010, Eliot Miranda wrote: > 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. I've never seen any code using Stack. People are more familiar with OrderedCollection. The O(1) worst case time for push is true in theory, but if we take into account GCs and cache locality, then things are a lot worse. GC pauses caused by the allocation of link objects are longer and happen more often than the pause caused by array growing (though it may also cause GC pauses). An array based implementation has much better cache locality: related object pointers (push/pop) are next to each other and 4x more pointers fit in same amount of cache. There are no speedups that could be applied to OrderedCollection in the code. The code implements a stack which is like an OrderedColelction with a few extra constraints: - firstIndex is always 1 - you can only add to the end - you can only remove from the end The implementation relies on these constraints. That's what makes it faster than an OrderedCollection. Levente > > >> >> 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. 15, 2010

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

by jaayer

---- On Fri, 15 Oct 2010 07:41:24 -0700 Guillermo Polito wrote ---- >BTW, why Stack inherits from LinkedList instead of just using it?Â Should an Stack have the entire Collection protocol? I don't think so... That was the subject of the earlier discussion, and yes, I think it should implement all appropriate messages in Collection, including #add: (as #push:), #size and #do:. The Array-based Stack I wrote does not implement #remove:ifAbsent: and only supports removal at the top of the Stack through #pop.

Oct. 15, 2010

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

by jaayer

On closer inspection, it appears the main reason why Stack is faster than OrderedCollection is that OrderedCollection will reallocate its Array even when #new: is supplied with what should be the correct size. To prevent reallocation, one must actually give it 1.5 times the size needed. This is because OrderedCollection keeps the first one-third of its Array empty so that #addFirst: operations will not require O(n) copying. This means that creating an OrderedCollection with new: 10 will require reallocation when the eighth element is added. If you create an OrderedCollection 50% bigger than what you expect to need, the performance gap closes to about ~7%, which isn't very significant: Smalltalk garbageCollect. r1 :=[100000 timesRepeat: [ s := Stack new: 100. 100 timesRepeat: [s push: #foo]]] timeToRun. Smalltalk garbageCollect. r2 := [100000 timesRepeat: [ oc := OrderedCollection new: 150. 100 timesRepeat: [oc addLast: #foo]]] timeToRun.

Oct. 15, 2010

Re: [Pharo-project] FileChooser (Squeak) = ........ (Pharo)

by Hannes Hirzel

Yes, good idea. Something like this which is in Squeak and Pharo. The snippet as such however does not work... It chooses directories and does not give the full path. --Hannes On 10/15/10, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Oct 15, 2010, at 3:29 01PM, Hannes Hirzel wrote: > >> It seems to be >> FileDialogWindow >> >> So the question is how is the following snippet translated. The >> examples I found in the image did not work for some reason. >> >> "Squeak" >> fc := FileChooser new. >> fc initializeAsDialogBox. >> fc open. >> fc fullName >> >> On 10/15/10, Hannes Hirzel <hannes.hirzel(a)gmail.com> wrote: >>> 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 > > > UIManager default chooseFileMatching: '*' ? > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 15, 2010