January 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [OT] Great job guys

by StÃ©phane Ducasse

cool thanks for the pointer. we hope also to have Pharo by Example in the future and especially Pharo by Example volume 2 :) Stef On Jan 7, 2009, at 10:24 PM, Torsten Bergmann wrote: > see http://mue.tideland.biz/2009/01/great-job-guys.html > -- > Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit > allen: http://www.gmx.net/de/go/multimessenger > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 7, 2009

[Pharo-project] [OT] Great job guys

by Torsten Bergmann

see http://mue.tideland.biz/2009/01/great-job-guys.html -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

Jan. 7, 2009

Re: [Pharo-project] About self halt in removed trait methods

by StÃ©phane Ducasse

yes when I use OB-package browser. Quite annoying. Stef On Jan 7, 2009, at 9:05 PM, Adrian Lienhard wrote: > Very odd. I've never seen this. > Does it happen in a Pharo-core image? > > Adrian > > On Jan 7, 2009, at 19:18 , StÃ©phane Ducasse wrote: > >> When I define a class with a trait and remove it after I get all the >> trait methods >> locally defined with a self halt. >> Does anybody know from where such a behavior could come from? >> >> Stef >> >> _______________________________________________ >> 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 >

Jan. 7, 2009

Re: [Pharo-project] [ANN] 10203

by StÃ©phane Ducasse

hi rob I got not problem with the core image. Stef On Jan 7, 2009, at 8:43 PM, Rob Rothwell wrote: > Has anyone successfully loaded this from the System Update... menu > item? > > Whether starting from my own image, or a fresh dev08.12.3 image, it > eventully goes into debug mode at the bottom of the screen, and if > left on it's own, eventually just shuts down... > > Rob > > On Wed, Jan 7, 2009 at 1:06 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > - Issue 363: fix some traits issues (introduced by changes in > Metaclass and TestCase) > - Traits conflict marker methods stored in wrong cache > - Remove duplicated method in trait and class that uses it (in > collection tests) > - Issue 315: darker colors in diff dialog (thanks to Damien Pollet) > - Issue 342: Removing beginning capital letter of instance variables > (Alexandre Bergel) > - Make MC always display dependencies of a version in its summary text > - Issue: 101: fasterDayOfYear-brp.1 (Mantis 7156) > - Issue 102: better testPrintShowingDecimalPlaces > > Adrian > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > 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

Jan. 7, 2009

Re: [Pharo-project] About self halt in removed trait methods

by Adrian Lienhard

Very odd. I've never seen this. Does it happen in a Pharo-core image? Adrian On Jan 7, 2009, at 19:18 , StÃ©phane Ducasse wrote: > When I define a class with a trait and remove it after I get all the > trait methods > locally defined with a self halt. > Does anybody know from where such a behavior could come from? > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 7, 2009

Re: [Pharo-project] [ANN] 10203

by Rob Rothwell

Has anyone successfully loaded this from the System Update... menu item? Whether starting from my own image, or a fresh dev08.12.3 image, it eventully goes into debug mode at the bottom of the screen, and if left on it's own, eventually just shuts down... Rob On Wed, Jan 7, 2009 at 1:06 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > - Issue 363: fix some traits issues (introduced by changes in > Metaclass and TestCase) > - Traits conflict marker methods stored in wrong cache > - Remove duplicated method in trait and class that uses it (in > collection tests) > - Issue 315: darker colors in diff dialog (thanks to Damien Pollet) > - Issue 342: Removing beginning capital letter of instance variables > (Alexandre Bergel) > - Make MC always display dependencies of a version in its summary text > - Issue: 101: fasterDayOfYear-brp.1 (Mantis 7156) > - Issue 102: better testPrintShowingDecimalPlaces > > Adrian > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 7, 2009

[Pharo-project] About self halt in removed trait methods

by StÃ©phane Ducasse

When I define a class with a trait and remove it after I get all the trait methods locally defined with a self halt. Does anybody know from where such a behavior could come from? Stef

Jan. 7, 2009

Re: [Pharo-project] [ANN] 10203

by StÃ©phane Ducasse

thanks On Jan 7, 2009, at 7:06 PM, Adrian Lienhard wrote: > - Issue 363: fix some traits issues (introduced by changes in > Metaclass and TestCase) > - Traits conflict marker methods stored in wrong cache > - Remove duplicated method in trait and class that uses it (in > collection tests) > - Issue 315: darker colors in diff dialog (thanks to Damien Pollet) > - Issue 342: Removing beginning capital letter of instance variables > (Alexandre Bergel) > - Make MC always display dependencies of a version in its summary text > - Issue: 101: fasterDayOfYear-brp.1 (Mantis 7156) > - Issue 102: better testPrintShowingDecimalPlaces > > Adrian > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 7, 2009

[Pharo-project] [ANN] 10203

by Adrian Lienhard

- Issue 363: fix some traits issues (introduced by changes in Metaclass and TestCase) - Traits conflict marker methods stored in wrong cache - Remove duplicated method in trait and class that uses it (in collection tests) - Issue 315: darker colors in diff dialog (thanks to Damien Pollet) - Issue 342: Removing beginning capital letter of instance variables (Alexandre Bergel) - Make MC always display dependencies of a version in its summary text - Issue: 101: fasterDayOfYear-brp.1 (Mantis 7156) - Issue 102: better testPrintShowingDecimalPlaces Adrian ___________________ http://www.adrian-lienhard.ch/

Jan. 7, 2009

Re: [Pharo-project] Collection extensions

by Brian Brown

On Jan 5, 2009, at 7:56 AM, Lukas Renggli wrote: >> I published to the inbox some cool collection extension methods that >> we use all the time in Moose. >> flatCollect:, collectAsSet:, and groupedBy: > > I think Squeak already has far too many of these methods. I would > rather like to see them all removed, than new ones added. As an author > and maintainer of many Smalltalk framework I experience daily the pain > such methods cause, as they are inherently non-portable not only > between smalltalk dialects but even between users of exactly the same > image. > (This rambles a bit, so bear with me... ) I agree with Lukas as far as what is the core system; I also used many of the unique and helpful methods available in Squeak and not in other Smalltalk implementations *as long as I know I'm not porting it another system*. With the ever improving Installer/Universes/SM system, can we not easily keep the core small and add collection extensions and other extensions as dependencies for a given package? Another option would be to change/rename the categories to denote ansi compliant methods, but since the categories metaphor is flat, methods can't be in more that one at a time. Could the OB smart filters be used in this way? Or would we have to implement some sort of tagging framework to be able to arbitrarily tag methods and classes, so methods can reside in appropriate categories and still be flagged as ANSI (among other things). I also agree with the sentiment (to a point) in the thread that ANSI is old and outdated, and why does Pharo have to be hobbled by that. From a practical matter, regardless of how old the ANSI standard is, it is the only standard we have, and when you are doing a framework like Seaside, or any number of others, compatibility with other Smalltalks where possible is extremely important. My 2 bits... - Brian

Jan. 7, 2009