- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Feature Request: Strict Compiler / Monticello Mode

by Levente Uzonyi

On Thu, 9 Sep 2010, StÃ©phane Ducasse wrote: > >> Isn't Grease dialect dependent by essence ? >> If Pharo and Squeak diverge, then there will naturally be two versions >> of Grease... >> However, for these two messages, I think Pharo core should integrate >> them and align with Squeak. The question is more whether you need to >> distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ... > > Probably else this means that Pharo and any system is bound to die because > it does not change. The rapid changes and no-backwards-compatibility you prefer and advocate are not essential for a Smalltalk system to "stay alive". Just look at VSE, it didn't change in the last 10 years, and people are still using it. In constrast Pharo 1.0 was considered abandonware four months after it's release, which caused trouble for some users who didn't think that they'll have to patch their code and rebuild their images to "get" updates/fixes. Levente > > This is why configurations are important. > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 9, 2010

Re: [Pharo-project] We'll have a sunny ESUG 2010 :-)

by Hilaire Fernandes

Lucky you :) Hilaire Le 09/09/2010 14:19, Noury Bouraqadi a Ã©crit : > > > Begin forwarded message: > >> From: Jordi Delgado <jdelgado(a)lsi.upc.edu> >> Date: 9 septembre 2010 13:22:27 HAEC >> To: board(a)esug.org >> Subject: weather forecast >> >> Hi, >> >> Good news, it looks like we are going to enjoy >> a sunny ESUG! >> >> http://www.meteocat.com/mediamb_xemec/servmet/english/index.html >> >> At least until next thursday... >> >> Bests, >> >> Jordi > > Noury -- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo

Sept. 9, 2010

Re: [Pharo-project] Changing the world menu

by Hilaire Fernandes

I have proposed a patch ready for integration to easily change the world menu http://code.google.com/p/pharo/issues/detail?id=2930 Hilaire Le 09/09/2010 14:36, Alain Plantec a Ã©crit : > >>> Yes, what is missing is a way to reset the menuBuilder in the >>> WorldState so that >>> it creates a new one. >> Is it what you are looking for ? > argh, no, you need to re-create the menuBuilder with the new pragma > keyword. > and yes it is missing :( > > maybe something like: > > setMenuPragmaKeywordTo: aSymbol > menuBuilder := PragmaMenuBuilder pragmaKeyword: aSymbol model: self > > Alain > > >> >> PasteUpMorph>>resetWorldMenu >> menuBuilder >> ifNotNil: [menuBuilder reset] >> >> >> to be used as follow: >> ---------- >> World resetWorldMenu >> ---------- >> >> Alain >>> Marcus >>> >>> >>> -- >>> Marcus Denker -- http://www.marcusdenker.de >>> INRIA Lille -- Nord Europe. Team RMoD. >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo

Sept. 9, 2010

[Pharo-project] [update 1.2] #12130

by Marcus Denker

12130 ----- Issue 2915: remove tinyDisplay check and code Issue 2916: Clean MorphExtension more Issue 2917: CatchAll entry for small cleanups Issue 2913: Remove empty WebClient class categories -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Sept. 9, 2010

Re: [Pharo-project] Feature Request: Strict Compiler / Monticello Mode

by StÃ©phane Ducasse

> Isn't Grease dialect dependent by essence ? > If Pharo and Squeak diverge, then there will naturally be two versions > of Grease... > However, for these two messages, I think Pharo core should integrate > them and align with Squeak. The question is more whether you need to > distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ... Probably else this means that Pharo and any system is bound to die because it does not change. This is why configurations are important. Stef

Sept. 9, 2010

[Pharo-project] [update 1.2] #12129

by StÃ©phane Ducasse

12129 ----- - Fix suffixOf: - Issue 2107: Using test to encode package dependency structure. Stef

Sept. 9, 2010

Re: [Pharo-project] Feature Request: Strict Compiler / Monticello Mode

by Nicolas Cellier

Isn't Grease dialect dependent by essence ? If Pharo and Squeak diverge, then there will naturally be two versions of Grease... However, for these two messages, I think Pharo core should integrate them and align with Squeak. The question is more whether you need to distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ... Nicolas 2010/9/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > ok let us know how we can help. > There are methods from grease that I would love to have in Pharo to get better libraries. > > Stef > > >> I suggest that we just remove the two methods (Collection>>#sorted and >> Colection>>#sorted:) from Grease. It doesn't look like the system >> itself is calling them on Collection, and most subclasses override >> them anyway. >> >> Lukas >> >> On 9 September 2010 11:10, Philippe Marschall <kustos(a)gmx.net> wrote: >>> Hi >>> >>> It seems like we unintentionally introduced an override for Collection >>>>> #sorted in Grease. That puts in a hard place because we can't simply >>> remove it from Grease. Because if you do that everybody who updates >>> looses the method and potentially breaks his image. Yeah, I see that the >>> real fix you be for Monticello to restore the old method but that hasn't >>> happened in years. >>> >>> Monticello / the compiler already warns about a lot of less important >>> things. Now I know adding an additional preference for that is ugly and >>> I'd welcome and better/nicer solution. >>> >>> Cheers >>> Philippe > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 9, 2010

Re: [Pharo-project] Changing the world menu

by Alain Plantec

>> Yes, what is missing is a way to reset the menuBuilder in the >> WorldState so that >> it creates a new one. > Is it what you are looking for ? argh, no, you need to re-create the menuBuilder with the new pragma keyword. and yes it is missing :( maybe something like: setMenuPragmaKeywordTo: aSymbol menuBuilder := PragmaMenuBuilder pragmaKeyword: aSymbol model: self Alain > > PasteUpMorph>>resetWorldMenu > menuBuilder > ifNotNil: [menuBuilder reset] > > > to be used as follow: > ---------- > World resetWorldMenu > ---------- > > Alain >> Marcus >> >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

Sept. 9, 2010

Re: [Pharo-project] WebClient License Update

by StÃ©phane Ducasse

> > Implicitly yes, but let's discuss this. You're saying you want WebClient "without overrides" but is this really what you mean? The only reason these methods are marked overrides is so that they don't kill your system if the methods themselves get added to the system at some point. For example, Grease currently adds extension methods for Collection>>sorted but these methods are already in Squeak and while nothing harmful happens if you load Grease, unloading it will destroy several methods. As a consequence it is vastly advantageous to mark methods as overrides if they have even the slightest possibility to conflict (but of course if you'd rather have them straightforward extensions, I have no problems with that). may be we should change the semantics of unload with overriding (without *overrides*): restore the hidden method that a new load can be do. Stef

Sept. 9, 2010

Re: [Pharo-project] Changing the world menu

by Alain Plantec

Le 09/09/2010 14:17, Marcus Denker a Ã©crit : > On Sep 9, 2010, at 2:13 PM, Hilaire Fernandes wrote: > > >> Okay I see. >> I will propose a little refactoring of WorldState so one can change the >> world menu programmatically. >> > Yes, what is missing is a way to reset the menuBuilder in the WorldState so that > it creates a new one. > Is it what you are looking for ? PasteUpMorph>>resetWorldMenu menuBuilder ifNotNil: [menuBuilder reset] to be used as follow: ---------- World resetWorldMenu ---------- Alain > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

Sept. 9, 2010