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

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

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

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 11, 2010

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

by Lukas Renggli

On 11 October 2010 17:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> 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. It is disabled because of the excessive processing power that this requires. And the server is already at the limit. Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 11, 2010

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

by Schwab,Wilhelm K

Nick, I'm certainly no expert on DST, but I will gladly help where I can. You're starting a PhD program? Is Stef your advisor? That would put you in good hands. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nick Papoylias [npapoylias(a)gmail.com] Sent: Monday, October 11, 2010 11:43 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ? I am currently concerned with remote programming (debugger, browser, compiler e.t.c) in Pharo from one image (or environment) to another, so that this infrastructure can be used in the field of autonomous robotics to ease the development cycle. So we should definitely exchange ideas ! Cause there surely is more than one way to go (plain sockets and API, rST, remote SystemDictionary and environment, to name a few..) We should keep in touch ! Nick On Mon, Oct 11, 2010 at 5:16 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com<mailto:serge.stinckwich@gmail.com>> wrote: 2010/10/11 Nick Papoylias <npapoylias(a)gmail.com<mailto:npapoylias@gmail.com>>: > Hallo to all, > > I am starting my Ph.D on 'languages and environments for autonomous > robotics' -- and pharo will be a huge part of it. Hi Nick, Great to see that another guy will work in the domain of embedded systems&autonomous robots with Smalltalk ! I already talked with Noury or Luc about that. This is really important to share code as we are a small community, especially code to interface with existing robotics systems like ROS, OROCOS or Player/Stage. I will start soon to work on how to integrate Smalltalk with ROS: http://www.ros.org/wiki/ Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/ _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010