- Pharo-dev - lists.pharo.org

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

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

Oct. 15, 2010

On Oct 15, 2010, at 8:42 AM, Geert Claes wrote: > > 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? > I do not think so but if we can get the pdf it would be really good for my free Smalltalk books collection :) Stef > > 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

2 2

[Pharo-project] Xtreams vs become:
by mkobetic＠gmail.com Oct. 15, 2010

Oct. 15, 2010

Michael and I talked about this today a bit and here's what we're thinking about doing. We're inheriting the become: behavior from the collection growing APIs in VW and it doesn't make sense to work around that there. Consequently the only (relevant) become: that we do in Xtreams code is the one in CollectionWriteStream>>close. If we're not eliminating the become: from growing then ripping it out of closing creates a strange inconsistency. At the same time nothing is preventing the Squeak port to do away with the become:s altogether. After all the terminals are meant to be dialect specific and so the two ports will just be different in this regard. It's probably worth highlighting in the comments/docs that assuming the "become:" semantics of growing makes one's code non-portable. This way one can both get the the traditional behavior in VW, but at the same time Squeak doesn't have to suffer unnecessarily. To remove the "become" assumption in the test suite, I'll rewrite all the ReadWriteTests splitting them up into writing and reading part, which will allow creating the input after writing into the output is already done. That way we don't care if the collection streams use become or not. Something like: testBlah self write: [ :output | .... ] read: [ :input | ... ] Good enough ?

2 3

[Pharo-project] Problem installing Magritte2
by Casimiro de Almeida Barreto Oct. 15, 2010

Oct. 15, 2010

The following: (Installer squeaksource project: 'MetacelloRepository'; packagesMatching: 'ConfigurationOfMagritte2-*') first install. ConfigurationOfMagritte2 project latestVersion load. Results in: Error: could not resolv Magritte-Model [Magritte-Model-lr.397] Then, the site: source.lukas-renggli.ch returns: Service Temporarily Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. ------------------------------------------------------------------------ Apache/2.2.14 (Ubuntu) Server at source.lukas-renggli.ch Port 80

3 2