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

[Pharo-project] Call for contribution to http://pharo-project.org/about/research

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 15, 2010

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

by Mariano Martinez Peck

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

Oct. 15, 2010

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

by Guillermo Polito

BTW, why Stack inherits from LinkedList instead of just using it? Should an Stack have the entire Collection protocol? I don't think so... On Thu, Oct 14, 2010 at 5:31 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr > wrote: > 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 > > > _______________________________________________ > 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] FileChooser (Squeak) = ........ (Pharo)

by Henrik Johansen

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

Oct. 15, 2010

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

by Hannes Hirzel

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 >

Oct. 15, 2010

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

by Hannes Hirzel

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

Oct. 15, 2010

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

by Henrik Johansen

On Oct 15, 2010, at 1:41 06PM, Henrik Johansen wrote: > > On Oct 15, 2010, at 1:01 31PM, StÃ©phane Ducasse wrote: > >> >> 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? >>> >> > http://books.google.no/books?id=kKfY0SB0O-cC&printsec=frontcover&dq=Object+… > > Second hit on google of the title... > > Cheers, > Henry Weird, I could swear I had a tab open where all pages were viewable, but in the currently open one, the preview is limited. Sorry for the noise. Cheers, Henry

Oct. 15, 2010

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

by Henrik Johansen

On Oct 15, 2010, at 1:01 31PM, StÃ©phane Ducasse wrote: > > 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? >> > http://books.google.no/books?id=kKfY0SB0O-cC&printsec=frontcover&dq=Object+… Second hit on google of the title... Cheers, Henry

Oct. 15, 2010

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

by StÃ©phane Ducasse

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

Oct. 15, 2010

Re: [Pharo-project] Xtreams vs become:

by Nicolas Cellier

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 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... I have a bug with File though - it looks like double closing. The symptoms are that no file can't be further opened untill we quit the image... Nicolas 2010/10/15 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Or maybe I have something simple enough : > > 1) let setUp initialize the output but not the input > 2) access input via a message send and lazy initialization > For example, in collection tests, this would be > input > Â Â ^input ifNil:[input := output conclusion reading] > in file tests: > Â Â ^input ifNil:[input := file reading] > > What do you think ? > > Nicolas > > 2010/10/13 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> 2010/10/13 Â <mkobetic(a)gmail.com>: >>> 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 ? >>> >> >> Seems fair to me. >> >> Nicolas >> >>> _______________________________________________ >>> 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