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

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

by StÃ©phane Ducasse

On Oct 10, 2010, at 3:17 PM, Igor Stasenko wrote: > On 10 October 2010 16:13, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> personnally I do not like this form >> What does it do? >> >>> process ifNotNil: #terminate. >> > > here the test case for it: > > | process answer | > > process := Object new. > > answer := process ifNotNil: #terminate. > > self assert: answer == #terminate. all that to avoid to have ifNotNil: [#terminate] I would not change the ifNotNil: for that. But make the compiler smarter Stef > > >> >> for me it means passes the symbol #terminate as argument to the method ifNotNil: >> If it has a more magical behavior then I do not know it. >> >> Stef >> >> >>> The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. >>> Thus we cannot write this xtream sentence >>> >>> process ifNotNil: #terminate. >>> >>> When the argument is not a block, Compiler should avoid inlining and >>> just send a normal message. >>> >>> cheers >>> >>> Nicolas >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 10, 2010

Re: [Pharo-project] WeakRegistry>>remove: - when you'll be in trouble

by Igor Stasenko

Moreover, i personally don't understand, why WeakRegistry have to be a subclass of Collection. What registry copy reject, select etc means to weak registry? My gut feeling that this is conceptually wrong. One should not use any kind of copying on weak registry. I think, that more intention revealing , one should send: registry discardFinalization: anObject instead of: registry remove: anObject On 10 October 2010 15:59, Igor Stasenko <siguctua(a)gmail.com> wrote: > A current implementation of this method > > remove: oldObject ifAbsent: exceptionBlock > Â Â Â Â "Remove oldObject as one of the receiver's elements." > > Â Â Â Â oldObject ifNil: [ ^nil ]. > Â Â Â Â ^(self protected: [ valueDictionary removeKey: oldObject ifAbsent: nil ]) > Â Â Â Â Â Â Â Â ifNil: [ exceptionBlock value ] > > simply removes a previously registered object from registry and voila. > > Now lets get back to our discussion about multiple finalizers per > object and using them in weak subscriptions etc. > > Suppose i am added a socket to weak registry, > and suppose i am added a weak subscription to it. > > Now, if i do 'socket close' , it tells weak registry to remove it from list. > And what we'll have: > Â - socket handle is closed > Â - socket is wiped from weak registry > Â - but weak subscription still listed somewhere in a list of subscriptions > > > My suggestion is, that upon #remove:, > a weak registry should notify all executors that object of interest > are no longer takes part in finalization scheme, > so they should not count on receiving #finalize eventually. > > In other words: > > remove: oldObject ifAbsent: exceptionBlock > Â Â Â Â "Remove oldObject as one of the receiver's elements." > > Â Â Â Â oldObject ifNil: [ ^nil ]. > Â Â Â Â ^(self protected: [ | executor | > Â Â Â Â Â Â executor := valueDictionary removeKey: oldObject ifAbsent: nil. > Â Â Â Â Â Â executor discardFinalization. > Â Â Â Â ]) > Â Â Â Â ifNil: [ exceptionBlock value ] > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Oct. 10, 2010

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

by Nicolas Cellier

Yes, this can be surprising at first. But I think this is because you read it with a preformated Smalltalk mind, rather than just english. it's just like: (1 to: 10) select: #even. Nicolas 2010/10/10 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > personnally I do not like this form > What does it do? > >> Â Â process ifNotNil: #terminate. > > > for me it means passes the symbol #terminate as argument to the method ifNotNil: > If it has a more magical behavior then I do not know it. > > Stef > > >> The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. >> Thus we cannot write this xtream sentence >> >> Â Â process ifNotNil: #terminate. >> >> When the argument is not a block, Compiler should avoid inlining and >> just send a normal message. >> >> cheers >> >> Nicolas >> >> _______________________________________________ >> 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. 10, 2010

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

by Igor Stasenko

On 10 October 2010 16:13, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > personnally I do not like this form > What does it do? > >> Â Â process ifNotNil: #terminate. > here the test case for it: | process answer | process := Object new. answer := process ifNotNil: #terminate. self assert: answer == #terminate. > > for me it means passes the symbol #terminate as argument to the method ifNotNil: > If it has a more magical behavior then I do not know it. > > Stef > > >> The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. >> Thus we cannot write this xtream sentence >> >> Â Â process ifNotNil: #terminate. >> >> When the argument is not a block, Compiler should avoid inlining and >> just send a normal message. >> >> cheers >> >> Nicolas >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 10, 2010

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

by StÃ©phane Ducasse

personnally I do not like this form What does it do? > process ifNotNil: #terminate. for me it means passes the symbol #terminate as argument to the method ifNotNil: If it has a more magical behavior then I do not know it. Stef > The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. > Thus we cannot write this xtream sentence > > process ifNotNil: #terminate. > > When the argument is not a block, Compiler should avoid inlining and > just send a normal message. > > cheers > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 10, 2010

[Pharo-project] Symbol>>cull:

by Nicolas Cellier

We recently added #value: to Symbol to be able to use it in place of a one arg block. (1 to: 10) select: #even. It would be logical to add #cull: too, xtreams tests use this for example: output write: #[ 1 2 3 4 5 6 7 8 9 ]. self assert: ((input rejecting: #even) read: 5) = #[ 1 3 5 7 9 ] Any objection to add it in core ? (otherwise i will add it to Xtreams-VWCompatible) Nicolas

Oct. 10, 2010

Re: [Pharo-project] Glamour breaks settings browser on Pharo 1.1.1

by Tudor Girba

Hi, I am glad it works :). If you have further problems or questions about Glamour, it is better to address them on the moose-dev mailing list: https://www.iam.unibe.ch/mailman/listinfo/moose-dev moose-dev(a)iam.unibe.ch Cheers, Doru On 10 Oct 2010, at 14:56, Esteban Lorenzano wrote: > Oh, damn... it was 2.0-beta.4 the problem, I'm sorry, it is working ok with beta 7 > > > On 2010-10-10 09:07:16 -0300, Tudor Girba <tudor.girba(a)gmail.com> said: > >> Hi, >> I cannot reproduce this. I took a PharoDev 1.1.1 and executed: >> Gofer new >> squeaksource: 'Glamour'; >> package: 'ConfigurationOfGlamour'; >> load. >> ((Smalltalk at: #ConfigurationOfGlamour) project version: '2.0-beta.7') load. >> Opening the System Settings browser works just fine. >> Cheers, >> Doru >> On 10 Oct 2010, at 13:28, Esteban Lorenzano wrote: >>> Hi, >>> I'm loading Glamour into a PharoDev 1.1.1 >>> Gofer project repository: 'http://www.squeaksource.com/Glamour'; >>> load: 'Glamour' version: '2.0-beta.7'. >>> and then try to open the settings browser... it raises a DNU >>> Cheers, >>> Esteban >>> _______________________________________________ >>> 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 -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

Oct. 10, 2010

Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument

by Igor Stasenko

On 10 October 2010 15:39, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. > Thus we cannot write this xtream sentence > > Â Â process ifNotNil: #terminate. > > When the argument is not a block, Compiler should avoid inlining and > just send a normal message. > +1 i am also missing: someThing ifTrue: 1 ifFalse: 0 > cheers > > Nicolas > > -- Best regards, Igor Stasenko AKA sig.

Oct. 10, 2010

[Pharo-project] WeakRegistry>>remove: - when you'll be in trouble

by Igor Stasenko

A current implementation of this method remove: oldObject ifAbsent: exceptionBlock "Remove oldObject as one of the receiver's elements." oldObject ifNil: [ ^nil ]. ^(self protected: [ valueDictionary removeKey: oldObject ifAbsent: nil ]) ifNil: [ exceptionBlock value ] simply removes a previously registered object from registry and voila. Now lets get back to our discussion about multiple finalizers per object and using them in weak subscriptions etc. Suppose i am added a socket to weak registry, and suppose i am added a weak subscription to it. Now, if i do 'socket close' , it tells weak registry to remove it from list. And what we'll have: - socket handle is closed - socket is wiped from weak registry - but weak subscription still listed somewhere in a list of subscriptions My suggestion is, that upon #remove:, a weak registry should notify all executors that object of interest are no longer takes part in finalization scheme, so they should not count on receiving #finalize eventually. In other words: remove: oldObject ifAbsent: exceptionBlock "Remove oldObject as one of the receiver's elements." oldObject ifNil: [ ^nil ]. ^(self protected: [ | executor | executor := valueDictionary removeKey: oldObject ifAbsent: nil. executor discardFinalization. ]) ifNil: [ exceptionBlock value ] -- Best regards, Igor Stasenko AKA sig.

Oct. 10, 2010

Re: [Pharo-project] Glamour breaks settings browser on Pharo 1.1.1

by Esteban Lorenzano

Oh, damn... it was 2.0-beta.4 the problem, I'm sorry, it is working ok with beta 7 On 2010-10-10 09:07:16 -0300, Tudor Girba <tudor.girba(a)gmail.com> said: > Hi, > > I cannot reproduce this. I took a PharoDev 1.1.1 and executed: > > Gofer new > squeaksource: 'Glamour'; > package: 'ConfigurationOfGlamour'; > load. > ((Smalltalk at: #ConfigurationOfGlamour) project version: '2.0-beta.7') load. > > Opening the System Settings browser works just fine. > > Cheers, > Doru > > > On 10 Oct 2010, at 13:28, Esteban Lorenzano wrote: > >> Hi, >> I'm loading Glamour into a PharoDev 1.1.1 >> >> Gofer project repository: 'http://www.squeaksource.com/Glamour'; >> load: 'Glamour' version: '2.0-beta.7'. >> >> and then try to open the settings browser... it raises a DNU >> >> Cheers, >> Esteban >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 10, 2010