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

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

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

by StÃ©phane Ducasse

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

Oct. 11, 2010

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

by Igor Stasenko

On 11 October 2010 18:23, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > 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: > Henrik, in previous discussion i shown that multiple finalizers could be effectively replaced with multiple private weak registries. There is one good reason for that: do not let anyone else to do something 'good' with your private stuff. Because 'good' quite often turns out to be 'bad', once you leaking a reference to some critical object outside your model. See http://www.erights.org/index.html#SmartContracts multiple finalizers per object is not a product of a smart contract. Because it means that same object accessible by two different, unrelated frameworks, which then will attempt to race for its ownership as to 'who's gonna finalize it first', or 'who having right to remove it from weak registry etc'. More to that, in context of current discussion, i see that multiple finalizers adding a lot of complexity for implementing correct error handling. > Cheers, > Henry > _______________________________________________ > 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

Henry, Ok, what valid use of multiple executors have I missed? 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

Oct. 11, 2010

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

by Nick Papoylias

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> wrote: > 2010/10/11 Nick Papoylias <npapoylias(a)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 > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 11, 2010

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

by Peter Hugosson-Miller

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. 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. 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. -- 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 >

Oct. 11, 2010

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

by merlyn＠stonehenge.com

>>>>> "Lukas" == Lukas Renggli <renggli(a)gmail.com> writes: Lukas> 1. It is not easily understandable for newbies. Lukas> 2. It quickly leads to very unreadable, hard to understand and hard to Lukas> refactor code. Lukas> 3. It is very limiting in itself and quickly leads to other hacks Lukas> (like to replace sort blocks). Lukas> 4. #value and friends should be only understood by objects that can be Lukas> evaluated (certainly not by Object). A symbol (name) by itself cannot Lukas> be evaluated. +1 Lukas> If people are too lazy to create a block where something Lukas> self-evaluable is needed they should use a programming language Lukas> designed for cryptic code. Creating a block closure in Smalltalk is Lukas> concise and makes clear what happens easily. A symbol does not, you Lukas> need to exactly understand how this dispatches with various Lukas> objects. Agreed. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion

Oct. 11, 2010

Re: [Pharo-project] Pharo by Example has moved to github

by Lukas Renggli

>> Excellent, can I also push the Seaside Book there? > > If you want. Now I do not see the interest of git when we use it as svn. And I would prefer to host the book on an inria server > because I know that this is backup by someboyd else than me. > and for a book I do not want to fork it (or people can fork it but I do not care of what they will do with their fork). The problem is that the sync with Pier does not work with SVN. You can only update and backup by using Git with the SVN backend. Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 11, 2010

Re: [Pharo-project] Migration Manual for Pharo 1.1 ?

by StÃ©phane Ducasse

Welcome and any help is welcome. On Oct 11, 2010, at 4:22 PM, Johannes Rasche wrote: > Thanks Alain, Stef and Mariano for fast answer. > > I assume that will help. > > Possibly I can contribute to improve documentation by carefull reading, trying and so on > > Johannes > > Am 11.10.2010 um 14:51 schrieb Mariano Martinez Peck: > >> >> >> 2010/10/11 Johannes Rasche <johannesrasche(a)mac.com> >> Hi Folks, >> >> I just wanted to install my work on version 1.1 and was surprised >> to discover changes which leave me alone to find out for myself how to change my code : >> >> WorldMenu (I wrote a subclass of PasteUpMorph) >> NaturalLanguageTranslator (what is the "gettext package" mentioned in the class comment? - cannot find a menu to edit translations - hidden sowhere?) >> >> >> http://book.pharo-project.org/book/Localisation/ >> >> possibly more surprises to come .... >> >> some backwardcompatibilty support would have been nice >> and >> some examples >> >> But I like to point out as well, that Pharo is improving from release to release - thanks for that !!!! >> >> Thanks in advance >> >> >> >> >> Johannes Rasche >> Hagelberger Str. 56 >> 10965 Berlin >> >> mail: johannesrasche(a)me.com >> skype: johannesrasche >> www: http://myNeat.de >> fon: +49-30-7469 4425 (skypeIn) >> fax: +49-30-315 66 821 >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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] Pharo by Example has moved to github

by StÃ©phane Ducasse

> Excellent, can I also push the Seaside Book there? If you want. Now I do not see the interest of git when we use it as svn. And I would prefer to host the book on an inria server because I know that this is backup by someboyd else than me. and for a book I do not want to fork it (or people can fork it but I do not care of what they will do with their fork). > > The main data store remains Pier of course, but we already today keep > the backups and other resources in the SCG SVN. > > Lukas > > > > On 11 October 2010 17:06, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: >> Great Oscar ! How to join the SquareBracketAssociates ? >> >> >> On Mon, Oct 11, 2010 at 4:39 PM, Oscar Nierstrasz >> <oscar.nierstrasz(a)gmail.com> wrote: >>> >>> See: http://github.com/SquareBracketAssociates/ >>> >>> Cheers, >>> - on >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> 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 >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > 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

Oct. 11, 2010

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

by Nick Papoylias

On Mon, Oct 11, 2010 at 5:11 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > > > For example there currently exist a setter in the class side for > 'migratting' in a new environment, that just alters the class knowledge > about the new namespace and does not erase it's record from the old > namespace. > where? > Class>>environment: (as far as I understand the class changes it's environment, without erasing itself from the old one and adding itself to the new one) > > > > Is this intented ? What is the underlying design ? Should we add an > environment: setter in the subclass message, so that we integrate namespaces > with the current Browser ? Should Behavior always return Smalltalk globals, > or there should be a setter to be able to migrate a whole hierarchy of > classes elsewhere ? > > Normally a class should be able to return its environment and it can be > different to Smalltalk globals, for example > we want to have to environments so that we can load Opal in one to modify > the other Opal compiler that we will running. > > Up to now marcus was using the old compiler to compile the new but in the > future we only want one compiler and still been able to > change it. > > 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] Another finalization concern: error handling

by Henrik Johansen

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

Oct. 11, 2010

[Pharo-project] MicroSqueak Was: Re: [update 1.2] #12188

by Miguel CobÃ¡

El lun, 11-10-2010 a las 10:56 +0200, StÃ©phane Ducasse escribiÃ³: > 12188 > ----- > > - Issue 3086: MCMethodDefinition>>shutdown hack to avoid lock down. > - Issue 2875: PharoKernel Part 11. Thanks Pavel Krivanek and Nicolas Paes > Now that John Maloney has released MicroSqueak as MIT (http://web.media.mit.edu/~jmaloney/microsqueak/) shouldn't be worth to analize it and see if that can be used as an alternative to build the Pharo Kernel. I know that Pavel (and now also Nicolas) have done a lot of work in getting PharoCore stripped to a minimal kernel. But as I understand, PharoKernel idea is to part from a core image, reorganize packages, _unload_ what isn't needed and then shrink the image to get a kernel image. The approach of John Maloney's MicroSqueak is the inverse, parting from a source code representation and from there to aggregate code until have a full image. Of course the image from John hasn't all the improvements that Squeak and Pharo have made to the core classes and that will mean a lot of effort to reapply in order to get a modern image. But I wonder, and not meaning to discourage any possibility, if isn't worth to discuss the technical effort required and the pros/cons of each approach and if isn't possible a reutilization of knowledge for this very wanted goal of Pharo. Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Oct. 11, 2010

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

by StÃ©phane Ducasse

Arghhhhh >>> > > ObjectFinalizer>>finalize > "Finalize the resource associated with the receiver. This message > should only be sent during the finalization process. There is NO > garantuee that the resource associated with the receiver hasn't been > free'd before so take care that you don't run into trouble - this all > may happen with interrupt priority." > [self value] on: Error do:[:ex| ex return]. > > now, replace this implementation with just > self value > and you'll see what will happen. > > Such behavior is completely unacceptable in terms of finding the bugs > & problems in your code. yes please fix.... arghhhh Stef

Oct. 11, 2010

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

by Serge Stinckwich

2010/10/11 Nick Papoylias <npapoylias(a)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/

Oct. 11, 2010

[Pharo-project] [update 1.2] #12191

by StÃ©phane Ducasse

12191 ----- - Issue 3092: Additional test for weak registry to check for deadlocks. Thanks Igor Stasenko. Issue 3093: Weaklings cleanup & fixes. Thanks Igor Stasenko. Igor the testFinalizationOfMultipleResources breaks, can you have a look? Stef

Oct. 11, 2010

Re: [Pharo-project] Pharo by Example has moved to github

by Lukas Renggli

Excellent, can I also push the Seaside Book there? The main data store remains Pier of course, but we already today keep the backups and other resources in the SCG SVN. Lukas On 11 October 2010 17:06, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > Great Oscar ! How to join the SquareBracketAssociates ? > > > On Mon, Oct 11, 2010 at 4:39 PM, Oscar Nierstrasz > <oscar.nierstrasz(a)gmail.com> wrote: >> >> See: http://github.com/SquareBracketAssociates/ >> >> Cheers, >> - on >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > 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 > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Oct. 11, 2010

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

by StÃ©phane Ducasse

> > For example there currently exist a setter in the class side for 'migratting' in a new environment, that just alters the class knowledge about the new namespace and does not erase it's record from the old namespace. where? > Is this intented ? What is the underlying design ? Should we add an environment: setter in the subclass message, so that we integrate namespaces with the current Browser ? Should Behavior always return Smalltalk globals, or there should be a setter to be able to migrate a whole hierarchy of classes elsewhere ? Normally a class should be able to return its environment and it can be different to Smalltalk globals, for example we want to have to environments so that we can load Opal in one to modify the other Opal compiler that we will running. Up to now marcus was using the old compiler to compile the new but in the future we only want one compiler and still been able to change it. Stef

Oct. 11, 2010

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

by Schwab,Wilhelm K

GPL is a problem. It means that nothing I write on top of GSL gets out the door. However, I see no reason not to give others the same mix of capability and concern in the form of an interface to it. ________________________________________ 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 10:59 AM 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: > Levente, > > Ok, but just because the system saves us at the last instant does not mean that we should be going out of our way to multiply free external resources. Files are well known to the vm; other things (GSL vectors/matrices comes to mind) will not enjoy such protections. This strikes me as a feature that got added when errors arose from attempts to add redundant executors, ultimately due to lack of thread safety. Many things that are being fixed at great cost got started (it sure seems) because someone added a feature or placed something in or too near to Object only to avoid errors vs. finding and fixing the real problem. > > Maybe you have made a strong argument for multiple executors; if so, I've missed it. Right now, it looks like a design flaw instead of a feature. There's code that relies on multiple executors. Every object understands #toFinalizeSend:to:with:. When you use it, you expect that your finalizer will be evaluated when the object is garbage collected. Btw I offered a simple solution for cases like yours. The behavior of WeakRegistry >> #add:executor: can be easily made pluggable when an object has an executor in the registry. Levente P.S.: how will you use GSL knowing that it's license is GPL? Will you keep the code for yourself or release it under the GPL license? > > Bill > > > > ________________________________________ > 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 10:24 AM > 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: > >> Levente, >> >> A similar discussion arose around Dolphin's event (#trigger*) mechanism. My recollection is that it was not fully addressed due to performance concerns. Forking and error handlers both have their costs. I'm not saying we should necessarily follow (we probably should not), though with careful design, an interrupted chain of events might survive to be handled on a subsequent attempt. >> >> 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. > > Smalltalk is not C. Try this: > > | file | > file := StandardFileStream fileNamed: 'foo.txt'. > file close. > file primClose: (file instVarNamed: #fileID). > "Those pesky plugins save us all the time. ;)" > > > Levente > >> >> Bill >> >> >> >> ________________________________________ >> 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 9:51 AM >> To: Pharo Development >> Cc: The general-purpose Squeak developers list >> Subject: Re: [Pharo-project] Another finalization concern: error handling >> >> On Mon, 11 Oct 2010, Igor Stasenko wrote: >> >>> Hello, >>> >>> here a situation, with which we can deal in more safer manner: >>> >>> Suppose you have a weak registry, populated by different objects and >>> their executors. >>> >>> Now, when some of them died, a weak registry performs finalization. >>> >>> The potential danger is , that if there's an error triggered by some >>> executor(s), >>> then rest of executors will have no chance to run and will be >>> forgotten, causing memory leakage. >>> >>> What you think, should we handle this more graciously? >>> >>> (Consider a following meta-code) >>> >>> WeakRegistry>>finalizeValues >>> | executors | >>> executors := self gatherExecutorsToRun. >>> >>> executors do: [:ex | >>> [ ex finalize ] fork. >>> ]. >> >> The "gatherExecutorsToRun" part was implemented in the previous version >> of WeakRegistry (history is not available from the image...). #finalize >> wasn't sent from the protected block. The current version lacks it, so it >> will deadlock if a finalizer will try to access the same WeakRegistry. >> Other kind of deadlocks are also possible. For example when a finalizer >> can access a semaphore which is also used by another process that >> uses the same semaphore and also uses the WeakRegistry, but locks them in >> a different order (JNIPort). >> This only happens if the VM doesn't support the new finalization scheme >> which is the case for most current VMs. >> >> There is another issue with removal, and this affects the new finalization >> scheme too, because the finalizer of valuesDictionary is #finalizeValues. >> This means that finalization can happen in a process other than the >> finalization process. This can lead to random errors. >> >> So I think parts of the old WeakRegistry implementation should be >> restored, like: >> - WeakRegistry should collect executors >> - executors should be evaluated outside the protected block >> >>> >>> in this way, if any executor's #finalize causing error, it won't >>> interfere with other executors, and they will accomplish their task >>> normally. >>> Of course, i'm not saying that we should use #fork for this, because >>> it is costly. Similar could be done w/o forking. >>> I just wanted to show a simplest code with which we could achieve a >>> more gracious error handling. >> >> Wouldn't it be better to use an exception handler? >> >> >> Levente >> >>> >>> P.S. of course, in a first place it would be good to make sure that we >>> writing executors, which can't cause an error during finalization. >>> But bad things happen, and we should make sure that rest of system >>> won't be put on its knees because of some stupid bug in a single >>> #finalize. >>> >>> -- >>> 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 >> >> _______________________________________________ >> 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 > _______________________________________________ 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] Hallo Pharoers.. namespaces in the system level ?

by StÃ©phane Ducasse

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. 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

Oct. 11, 2010

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

by Schwab,Wilhelm K

Sig, I'm not saying to leave the finalizer wide open to the wrath of errors from poorly coded objects. I am saying that we should strive for one finalizer per object (preferably the object itself) and that to get there, we need to make the registry thread safe and have some vm support. Failing the latter, the object can't be its own executor, but there still should be at most one executor per object. Any errors should be raised on the attempt to create the second executor. Arrange for that, and somebody somewhere will ask whether all of this should be thread safe. BTW, Dolphin treats #beFinalizable/#beUnfinalizable by manipulating a mask that controls the vm behavior - haven't looked in a while, but it must be part of the object header. An object can thus be marked as finalizable or not any number of times during its life; no objects are created thanks to the vm support. 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 10:47 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Another finalization concern: error handling On 11 October 2010 17:24, Levente Uzonyi <leves(a)elte.hu> wrote: > On Mon, 11 Oct 2010, Schwab,Wilhelm K wrote: > >> Levente, >> >> A similar discussion arose around Dolphin's event (#trigger*) mechanism. >> My recollection is that it was not fully addressed due to performance >> concerns. Forking and error handlers both have their costs. I'm not saying >> we should necessarily follow (we probably should not), though with careful >> design, an interrupted chain of events might survive to be handled on a >> subsequent attempt. >> >> 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. > > Smalltalk is not C. Try this: > > | file | > file := StandardFileStream fileNamed: 'foo.txt'. > file close. > file primClose: (file instVarNamed: #fileID). > "Those pesky plugins save us all the time. ;)" > > Don't let me starting again on this. You proposing to care about it in multiple various places, where we could fix it in a single one. It is like adding ifNotNil: test at each place you using setter, instead of putting a single ifNotNil: test inside a setter itself. try this: 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. The above works silently only because ObjectFinalizer simply swallows any errors: ObjectFinalizer>>finalize "Finalize the resource associated with the receiver. This message should only be sent during the finalization process. There is NO garantuee that the resource associated with the receiver hasn't been free'd before so take care that you don't run into trouble - this all may happen with interrupt priority." [self value] on: Error do:[:ex| ex return]. now, replace this implementation with just self value and you'll see what will happen. Such behavior is completely unacceptable in terms of finding the bugs & problems in your code. -- 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