June 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] Why don't we always register weakly in SystemAnnouncer?

by Mariano Martinez Peck

Hi, with the help of Guille I noticed that normal instances usually register weakly: TestRunner >> initialize ..... SystemAnnouncer current weak on: ClassAdded, CategoryAdded, ClassRemoved, CategoryRemoved, ClassRenamed, CategoryRenamed, ClassRecategorized send: #update to: self. ..... and classes don't: TestCase class >> registerForNotifications ... SystemAnnouncer current on: MethodAdded, MethodModified, MethodRemoved send: #methodChanged: to: self. so..Guille told me this is because usually the cycle-life of instances is short in comparisson with classes. But classes can be removed as well. What happen then? the announcer will hold always a reference to an obsolete class? my question is, should we always use weakly? if not, why ? thanks for the explanation, -- Mariano http://marianopeck.wordpress.com

June 16, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by phil＠highoctane.be

http://en.wikipedia.org/wiki/Java_version_history isn't too bad either with Update x suffix. Pharo SE 4 Update 2 ... there is some good marketing touch to that given the popularity of Java. They switched after 1.4 - As an innovative platform, maybe we can switch now :-) 2.0 would become Pharo SE 5 and things like Seaside would be Pharo WE 6 (Web Edition) and moose Pharo DE 4 (Data visualization Edition) Phil 2012/6/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Sat, Jun 16, 2012 at 3:34 PM, Philippe Marschall <kustos(a)gmx.net> wrote: >> >> On 13.06.2012 11:08, Esteban Lorenzano wrote: >>> >>> Hi, >>> >>> I started thinking on next release of Pharo 1.4 (which will be code named >>> "summer", not an ugly number). >> >> >> It's only summer in the northern hemisphere. Eclipse renamed their winter >> releases because it isn't winter in February in half of the world. >> > > +1 to simply call it 1.4.1 > > -- > Mariano > http://marianopeck.wordpress.com > -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

June 16, 2012

Re: [Pharo-project] Auto create new and initialize methods for new class?

by phil＠highoctane.be

Anyway, we need to learn if we want to create things with something else than new... But I like basicNew initialize the way it is now. 2012/6/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> StÃ©phane, would you mind expanding a bit on what mistake CLOS didn't make? > > create-instance invokes initialize-instance in CLOS for every class. > > In Smalltalk (not squeak or pharo), new does not invoke initialize. Now CLOS arrived 10 years after Smalltalk and we fixed > that problem in our lovely environment. > > Stef > > -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

June 16, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by phil＠highoctane.be

We are closing the gap with Java versions... Pharo 1.6.3_047 nearing... 2012/6/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Sat, Jun 16, 2012 at 3:34 PM, Philippe Marschall <kustos(a)gmx.net> wrote: >> >> On 13.06.2012 11:08, Esteban Lorenzano wrote: >>> >>> Hi, >>> >>> I started thinking on next release of Pharo 1.4 (which will be code named >>> "summer", not an ugly number). >> >> >> It's only summer in the northern hemisphere. Eclipse renamed their winter >> releases because it isn't winter in February in half of the world. >> > > +1 to simply call it 1.4.1 > > -- > Mariano > http://marianopeck.wordpress.com > -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

June 16, 2012

Re: [Pharo-project] #anyChanges still needed?

by Guillermo Polito

Yeah, but logging superfluous changes does not really make a change, does it? On Sat, Jun 16, 2012 at 10:04 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > may be because the source changes was listening to the event. > And the log file needed to log any thing like doits and other. > > On Jun 16, 2012, at 9:14 PM, Mariano Martinez Peck wrote: > > > Hi guys. ChangeSet does at some point: > > > > anEvent itemKind = SystemChangeNotifier classKind ifTrue: [ > > ... > > anEvent isModified > > ifTrue: [anEvent anyChanges ifTrue: [self > changeClass: anEvent item from: anEvent oldItem]]. > > anEven > > > > > > > > So...I don't understand the #anyChanges. We received an event saying > that a class was modified, but it may not have any changes? if true, why > was the event sent? > > Ok...let's say that there could be several reasons that a class was > modified but only some of them make sense to change set. I can imagine > people wanted to avoid writing stuff to .changes that didn't actullay > represente a change? > > > > If this is the case, then #anyChanges looks like a bad name for me. > > > > Now, do we still need this mesage? can there be ClassModified events > without changes? > > thanks > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > >

June 16, 2012

Re: [Pharo-project] Auto create new and initialize methods for new class?

by Frank Shearar

On 16 June 2012 21:07, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> StÃ©phane, would you mind expanding a bit on what mistake CLOS didn't make? > > create-instance invokes initialize-instance in CLOS for every class. > > In Smalltalk (not squeak or pharo), new does not invoke initialize. Now CLOS arrived 10 years after Smalltalk and we fixed > that problem in our lovely environment. OK, that's what I thought you meant. For instance, Objective-C repeats the mistake: [[MyClass alloc] init]. Thanks! frank > Stef > >

June 16, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by Guillermo Polito

On Sat, Jun 16, 2012 at 10:06 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > On Jun 16, 2012, at 8:14 PM, Schwab,Wilhelm K wrote: > > > Stef, > > > > I have had experts on it tell me exactly the opposite. Things like > "always load specific versions" and "never load symbolic versions." They > mean well (and have been helpful in the short term), but it is far from a > generic solution. The "answer" will invariably be different "every time." > > > > Citezen is much appreciated, but your answer to getting it to load was > to load a specific numeric version. > > did you read the configuration? > Because if there is no symbolic version then load a specific one. > Then you have to control what you want to load. > I think that symbolic versions are working quite well. > They are :) > > > > > Ditto Alien/FFI from others. > > > > I am simply repeating what I have been told. > > > > 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: Saturday, June 16, 2012 4:24 AM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] start thinking on summer release of Pharo > 1.4 > > > > On Jun 16, 2012, at 12:57 AM, Schwab,Wilhelm K wrote: > > > >> But if I'm building a new image *today*, I want it to do the right > thing now (automatically for the current version), with the same > incantation as worked months ago or months from now. > > > > Bill when do you take the time to have a look at Metacello. > > Why people like me are spending days on writing 45 pages of > documentation to hear you saying that. > > > > This scenario is supported since months nearly since Barcelona 2010. > > > > > >> If we can't do that, the config browser is pretty much a dream vs. > reality. > > > > > > > > > >> > >> > >> > >> ________________________________________ > >> From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sean P. > DeNigris [sean(a)clipperadams.com] > >> Sent: Friday, June 15, 2012 2:49 PM > >> To: pharo-project(a)lists.gforge.inria.fr > >> Subject: Re: [Pharo-project] start thinking on summer release of Pharo > 1.4 > >> > >> Schwab,Wilhelm K wrote > >>> > >>> My gripe is... that configs... work (very) differently over time > >>> > >> With the current evolution of Metacello, this should not be the case. > Done > >> right, what a config loads can be 100% static and repeatable. If you > load a > >> literal version (e.g. '1.4'), which loads literal versions of dependent > >> projects (which they should unless there is a reason not to, e.g. a > loose > >> dependency like Seaside on OB), which load literal versions all the way > >> down, it will do the same thing today, tomorrow, and ten years from now. > >> > >> The only hill to climb now is getting the word out about Metacello > >> conventions/best practices. > >> > >> > >> Schwab,Wilhelm K wrote > >>> > >>> If pre-loading, how about FFI? > >>> > >> I think "easily loadable" is the correct state, not included by default. > >> > >> -- > >> View this message in context: > http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp46345… > >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >> > >> > > > > > > > > >

June 16, 2012

Re: [Pharo-project] Auto create new and initialize methods for new class?

by StÃ©phane Ducasse

> > StÃ©phane, would you mind expanding a bit on what mistake CLOS didn't make? create-instance invokes initialize-instance in CLOS for every class. In Smalltalk (not squeak or pharo), new does not invoke initialize. Now CLOS arrived 10 years after Smalltalk and we fixed that problem in our lovely environment. Stef

June 16, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by StÃ©phane Ducasse

On Jun 16, 2012, at 8:14 PM, Schwab,Wilhelm K wrote: > Stef, > > I have had experts on it tell me exactly the opposite. Things like "always load specific versions" and "never load symbolic versions." They mean well (and have been helpful in the short term), but it is far from a generic solution. The "answer" will invariably be different "every time." > > Citezen is much appreciated, but your answer to getting it to load was to load a specific numeric version. did you read the configuration? Because if there is no symbolic version then load a specific one. Then you have to control what you want to load. I think that symbolic versions are working quite well. > Ditto Alien/FFI from others. > > I am simply repeating what I have been told. > > 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: Saturday, June 16, 2012 4:24 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 > > On Jun 16, 2012, at 12:57 AM, Schwab,Wilhelm K wrote: > >> But if I'm building a new image *today*, I want it to do the right thing now (automatically for the current version), with the same incantation as worked months ago or months from now. > > Bill when do you take the time to have a look at Metacello. > Why people like me are spending days on writing 45 pages of documentation to hear you saying that. > > This scenario is supported since months nearly since Barcelona 2010. > > >> If we can't do that, the config browser is pretty much a dream vs. reality. > > > > >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean(a)clipperadams.com] >> Sent: Friday, June 15, 2012 2:49 PM >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 >> >> Schwab,Wilhelm K wrote >>> >>> My gripe is... that configs... work (very) differently over time >>> >> With the current evolution of Metacello, this should not be the case. Done >> right, what a config loads can be 100% static and repeatable. If you load a >> literal version (e.g. '1.4'), which loads literal versions of dependent >> projects (which they should unless there is a reason not to, e.g. a loose >> dependency like Seaside on OB), which load literal versions all the way >> down, it will do the same thing today, tomorrow, and ten years from now. >> >> The only hill to climb now is getting the word out about Metacello >> conventions/best practices. >> >> >> Schwab,Wilhelm K wrote >>> >>> If pre-loading, how about FFI? >>> >> I think "easily loadable" is the correct state, not included by default. >> >> -- >> View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp46345… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > >

June 16, 2012

Re: [Pharo-project] #anyChanges still needed?

by StÃ©phane Ducasse

may be because the source changes was listening to the event. And the log file needed to log any thing like doits and other. On Jun 16, 2012, at 9:14 PM, Mariano Martinez Peck wrote: > Hi guys. ChangeSet does at some point: > > anEvent itemKind = SystemChangeNotifier classKind ifTrue: [ > ... > anEvent isModified > ifTrue: [anEvent anyChanges ifTrue: [self changeClass: anEvent item from: anEvent oldItem]]. > anEven > > > > So...I don't understand the #anyChanges. We received an event saying that a class was modified, but it may not have any changes? if true, why was the event sent? > Ok...let's say that there could be several reasons that a class was modified but only some of them make sense to change set. I can imagine people wanted to avoid writing stuff to .changes that didn't actullay represente a change? > > If this is the case, then #anyChanges looks like a bad name for me. > > Now, do we still need this mesage? can there be ClassModified events without changes? > thanks > > -- > Mariano > http://marianopeck.wordpress.com >

June 16, 2012