- Pharo-dev - lists.pharo.org

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

by Nicolas Cellier

2010/10/11 Levente Uzonyi <leves(a)elte.hu>: > On Mon, 11 Oct 2010, Lukas Renggli wrote: > >>> Object>>value >>> Â Â Â Â ^self >>> >>> What actually shown here is a use of duck typing, because any object, >>> which implemets #value, could be safely passed >>> as argument to #ifTrue:ifFalse: message. >>> It is well consistent with language design. >> >> Magritte implemented Symbol>>#value: for a while before any Smalltalk >> had this is their standard library. I must admit that I liked it in >> the beginning, but in the long run I realized that ... >> >> 1. It is not easily understandable for newbies. > > That's true. > Well, it depends. Very newbies can understand it because they trust the words. My son did. More advanced newbies can wonder how the hell this could work eventually, because they can differentiate a regular message and a literal #symbol. It's true that writing code is another matter. Why and when to use a block a message or a Symbol ? Maybe a newbie could be tempted to write: x > 1 and: #even. which currently does not work. >> 2. It quickly leads to very unreadable, hard to understand and hard to >> refactor code. >> 3. It is very limiting in itself and quickly leads to other hacks >> (like to replace sort blocks). > > That "hack" is really cool IMO. The code is easily understood by anyone: > > #(4 1 3 5 2) sort: #<=. > >> 4. #value and friends should be only understood by objects that can be >> evaluated (certainly not by Object). A symbol (name) by itself cannot >> be evaluated. >> >> I eventually removed Symbol>>#value: for good. Re-occuring questions >> in the mailing list disappeared. > > That's strange, because Symbol >> #value: was added to Squeak in 2006 during > the developement of 3.9. > > > Levente > >> >> Therefor I strongly suggest to remove #value, #value:, and friends >> from all objects that are not self-evaluable. BlockClosure and >> MessageSend are self-evaluable. Only there it makes sense. >> >> If people are too lazy to create a block where something >> self-evaluable is needed they should use a programming language >> designed for cryptic code. Creating a block closure in Smalltalk is >> concise and makes clear what happens easily. A symbol does not, you >> need to exactly understand how this dispatches with various objects. >> >> Lukas >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.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 >

Oct. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Schwab,Wilhelm K

Sig, Understood, but are they all that different? The ones that were served ahead of the error should stay that way (proper recording of same is what needs attention), and those yet to be served, if it's done well, should be ready for the new thread to handle. Just something to consider. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Monday, October 11, 2010 1:02 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Another finalization concern: error handling On 11 October 2010 19:28, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > The Dolphin approach is to restart any of the finalizer, main, timer, idler threads (I *think* there is one more in a baseline image) any time they quit; an #ensure: block forks a new thread of the type that terminated. That way, whether they are taken down by an error doing what they are supposed to do or just by a stray #terminate or mistake with an attached debugger, the system rolls onward intact. > If it would be only about restarting, then its a piece of cake. We should make sure that all finalizations detected prior to error, did not get lost and are able to proceed as if nothing happens, except a single one, which failed with error. > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Monday, October 11, 2010 12:14 PM > To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list > Subject: Re: [Pharo-project] Another finalization concern: error handling > > Meanwhile, i'll try to implement two test cases for WeakRegistryTest. > > One, should cover following: > > coll := OrderedCollection new. > obj := Object new. > wrapper := WeakArray with: obj. > coll add: wrapper. > > obj toFinalizeSend: #remove: to: coll with: wrapper. > obj toFinalizeSend: #remove: to: coll with: wrapper. > obj toFinalizeSend: #remove: to: coll with: wrapper. > obj toFinalizeSend: #remove: to: coll with: wrapper. > > obj := nil. > Smalltalk garbageCollect. > > i.e somehow, user should be notified that there is an error during finalization. > > And second test case is to make sure that if one finalizer unable to > complete due to error, > the other ones (and finalization process itself) should continue > running, skipping over errorneous finalizer. > > -- > 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 > > _______________________________________________ > 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. 11, 2010

Re: [Pharo-project] how to get the diff on commit on the pharo source?

by Lukas Renggli

It is not the mailing list that is the problem, it is the squeaksource.com server that is. It takes several minutes to calculate a simple diff of a single version and that just kills responsiveness at the current rate of commits. Lukas On 11 October 2010 18:01, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > Maybe on a separate mailing list. > > Cheers, > Alexandre > > > On 11 Oct 2010, at 12:49, StÃ©phane Ducasse wrote: > >> I would really like to have the same behavior than the squeak system ie having the source modification >> send to the list. I could not see how to set it up on Â squeaksource. >> May be this is not the same version running. >> >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Oct. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Igor Stasenko

On 11 October 2010 19:28, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > The Dolphin approach is to restart any of the finalizer, main, timer, idler threads (I *think* there is one more in a baseline image) any time they quit; an #ensure: block forks a new thread of the type that terminated. Â That way, whether they are taken down by an error doing what they are supposed to do or just by a stray #terminate or mistake with an attached debugger, the system rolls onward intact. > If it would be only about restarting, then its a piece of cake. We should make sure that all finalizations detected prior to error, did not get lost and are able to proceed as if nothing happens, except a single one, which failed with error. > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Monday, October 11, 2010 12:14 PM > To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list > Subject: Re: [Pharo-project] Another finalization concern: error handling > > Meanwhile, i'll try to implement two test cases for WeakRegistryTest. > > One, should cover following: > > coll := OrderedCollection new. > obj := Object new. > wrapper := WeakArray with: obj. > coll add: wrapper. > > obj toFinalizeSend: #remove: to: coll with: wrapper. > obj toFinalizeSend: #remove: to: coll with: wrapper. > obj toFinalizeSend: #remove: to: coll with: wrapper. > obj toFinalizeSend: #remove: to: coll with: wrapper. > > obj := nil. > Smalltalk garbageCollect. > > i.e somehow, user should be notified that there is an error during finalization. > > And second test case is to make sure that if one finalizer unable to > complete due to error, > the other ones (and finalization process itself) should continue > running, skipping over errorneous finalizer. > > -- > 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 > > _______________________________________________ > 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. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Schwab,Wilhelm K

Ok, I'll dig around for that and have a look. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Monday, October 11, 2010 12:31 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Another finalization concern: error handling On Mon, 11 Oct 2010, Schwab,Wilhelm K wrote: > Henry, > > Ok, what valid use of multiple executors have I missed? I described it earlier how the AXAnnouncements project uses this feature. Levente > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Henrik Johansen [henrik.s.johansen(a)veloxit.no] > Sent: Monday, October 11, 2010 11:23 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Another finalization concern: error handling > > On Oct 11, 2010, at 4:10 13PM, Schwab,Wilhelm K wrote: > >> >> I am far more worried about having multiple executors per object (when did p=malloc();free(p);free(p);free(p) become good style?) than I am about getting the finalizer process itself completely robust at this point. >> >> Bill > > I fail to see how a blatantly obvious misuse of a feature becomes a valid argument against supporting that feature, or something you should worry alot about. > You can do Object become: nil, which is also not good style, but it's certainly not an valid argument for not allowing #become:. > Nor do I lose any sleep thinking of ways people could possibly abuse #become: > > Cheers, > Henry > _______________________________________________ > 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 > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Levente Uzonyi

On Mon, 11 Oct 2010, Schwab,Wilhelm K wrote: > Henry, > > Ok, what valid use of multiple executors have I missed? I described it earlier how the AXAnnouncements project uses this feature. Levente > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Henrik Johansen [henrik.s.johansen(a)veloxit.no] > Sent: Monday, October 11, 2010 11:23 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Another finalization concern: error handling > > On Oct 11, 2010, at 4:10 13PM, Schwab,Wilhelm K wrote: > >> >> I am far more worried about having multiple executors per object (when did p=malloc();free(p);free(p);free(p) become good style?) than I am about getting the finalizer process itself completely robust at this point. >> >> Bill > > I fail to see how a blatantly obvious misuse of a feature becomes a valid argument against supporting that feature, or something you should worry alot about. > You can do Object become: nil, which is also not good style, but it's certainly not an valid argument for not allowing #become:. > Nor do I lose any sleep thinking of ways people could possibly abuse #become: > > Cheers, > Henry > _______________________________________________ > 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. 11, 2010

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

by Igor Stasenko

2010/10/11 Peter Hugosson-Miller <oldmanlink(a)gmail.com>: > I think this discussion has diverged a lot from the original question, which > is to do with the compiler being too pedantic. > > #ifNotNil: and friends are the selectors of methods which just happen to > give the compiler an opportunity for a nice optimization, in the case when > the argument that follows is a literal block. In all other cases they can be > treated as message sends. If the compiler starts to impose limitations on > the language just because some magic selectors can be treated specially, > then IMO it is not behaving as it should. > +100 > Smalltalk is beautiful because it is so simple: everything is an object, and > all processing is done by sending messages to objects. Of course, in the > interests of speed, we can write a compiler that actually does something > different under the covers, like causing a branch in the byte codes instead > of sending a message, and of course the cases when that can be done need to > be clearly defined. But that does not mean that these magic selectors should > be allowed to pose limitations on how they can be used, because then we no > longer have Smalltalk, we have Smalltalk-- instead. > +100. You allowed to cheat, just not get caught! > Now, the above discussion is orthogonal to the questions of what is good > style, what is readable, maintainable, understandable to newbies, etc, etc. > Those questions are IMO just as important, but they should have nothing do > do with what the compiler is supposed to do. If the compiler is being too > pedantic, then it should be fixed. Then we can start discussing good style > without mixing apples and oranges together. > Amen :) > -- > Cheers, > Peter > > On Mon, Oct 11, 2010 at 5:03 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> I think that for typing in a transcript experessions when you want to >> experiment with something >> selectors are fun but not in method body. But I know that this is not a >> really good argument. Just feeling. >> May be we get trapped in our way of thinking. >> >> >> >>>>>> >> > I personally don't like the ifTrue:ifFalse: related changes, though it's >> > a logical change. I probably won't use that feature though. But I like the >> > monadic block <-> keyword selector substitution. Maybe the best is to add a >> > setting/preference to the compiler. >> >> >> _______________________________________________ >> 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. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Schwab,Wilhelm K

Sig, The Dolphin approach is to restart any of the finalizer, main, timer, idler threads (I *think* there is one more in a baseline image) any time they quit; an #ensure: block forks a new thread of the type that terminated. That way, whether they are taken down by an error doing what they are supposed to do or just by a stray #terminate or mistake with an attached debugger, the system rolls onward intact. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Monday, October 11, 2010 12:14 PM To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list Subject: Re: [Pharo-project] Another finalization concern: error handling Meanwhile, i'll try to implement two test cases for WeakRegistryTest. One, should cover following: coll := OrderedCollection new. obj := Object new. wrapper := WeakArray with: obj. coll add: wrapper. obj toFinalizeSend: #remove: to: coll with: wrapper. obj toFinalizeSend: #remove: to: coll with: wrapper. obj toFinalizeSend: #remove: to: coll with: wrapper. obj toFinalizeSend: #remove: to: coll with: wrapper. obj := nil. Smalltalk garbageCollect. i.e somehow, user should be notified that there is an error during finalization. And second test case is to make sure that if one finalizer unable to complete due to error, the other ones (and finalization process itself) should continue running, skipping over errorneous finalizer. -- 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. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Igor Stasenko

Meanwhile, i'll try to implement two test cases for WeakRegistryTest. One, should cover following: coll := OrderedCollection new. obj := Object new. wrapper := WeakArray with: obj. coll add: wrapper. obj toFinalizeSend: #remove: to: coll with: wrapper. obj toFinalizeSend: #remove: to: coll with: wrapper. obj toFinalizeSend: #remove: to: coll with: wrapper. obj toFinalizeSend: #remove: to: coll with: wrapper. obj := nil. Smalltalk garbageCollect. i.e somehow, user should be notified that there is an error during finalization. And second test case is to make sure that if one finalizer unable to complete due to error, the other ones (and finalization process itself) should continue running, skipping over errorneous finalizer. -- Best regards, Igor Stasenko AKA sig.

Oct. 11, 2010

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

by James Foster

On Oct 11, 2010, at 8:07 AM, StÃ©phane Ducasse wrote: > Hi guys > > there is a HUGE HUGE HUGE difference between > (1) namespace at the language level and we do not want that the way german did it. StÃ©phane, Are you suggesting that the approach GermÃ¡n Leiva demonstrated at ESUG last month is "at the language level"? Could you elaborate? James > Give us some times and we will try different solutions and see what come out > (2) systemDictionary at the infrastructure level. > We are working on that since Squeak Kernel Cleaning Project > here we want the tools to be able to use another environment so that we can > - bootstrap the compiler with itself > - load different version of code (for Moose) to build report on Pharo 1.2 from pharo 1.1 > - bootstrap the kernel > - build atomic loading. > We are working on 2 and this is what nick needs. > I will not talk about namespace at the lnaguage level. No time for that. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 11, 2010