- Pharo-dev - lists.pharo.org

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