September 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] errata for pharo by example

by Chris Kassopulo

pg 8 BouncingAtomsMorph new openInWorld Unknown variable: BouncingAtomsMorph

Sept. 21, 2009

Re: [Pharo-project] Closure fixes

by Michael Roberts

For anyone actually reviewing this, it breaks after Part 4. Inability to recompile the system. There are MethodProperties around but i'm not sure there should be. need to look closer at the trunk update mechanism. cheers, Mike "A. Load Gofer" ScriptLoader new installGofer. "B. Install packages" | gofer packages | gofer := Gofer new. gofer url: 'http://www.squeaksource.com/PharoTaskForces'. packages := #( "Part 2" 'Kernel-MikeRoberts.405' "Part 3" 'Compiler-MikeRoberts.130' 'CompilerTests-MikeRoberts.21' 'KernelTests-MikeRoberts.150' "Part 4" 'Compiler-MikeRoberts.131'). packages do: [:each | gofer copy add: each; load].

Sept. 21, 2009

Re: [Pharo-project] [squeak-dev] About Collections-ul.137..140

by Ralph Boland

Further comments on fasterSets. My understanding is that the newer version of fasterSets is scheduled to be incorporated into Pharo1.1. It would be unfortunate if one version of fasterSets is incorporated into Squeak and a different version is incorporated into Pharo. Can we get together and decide on one or better still merge the best features of both. I am frustrated by this split so cannot be considered unbiased. Can someone qualified and unbiased be appointed to coordinate creating a version of fasterSets that both the Squeak people and Pharo people are happy with and contains the best features of both. I am willing to work on the problem. P.S. My understanding was that there was no interest in having fasterSets added to Squeak. If/when this changed I would have appreciated being brought into the loop. Regards, Ralph Boland 2009/9/21 Ralph Boland <rpboland(a)gmail.com>: > 2009/9/21 Damien Cassou <damien.cassou(a)gmail.com>: >> ---------- Forwarded message ---------- >> From: Levente Uzonyi <leves(a)elte.hu> >> Date: Sun, Sep 20, 2009 at 4:38 PM >> Subject: [squeak-dev] About Collections-ul.137..140 >> To: squeak-dev(a)lists.squeakfoundation.org >> >> >> Hi! >> >> Just uploaded four packages to inbox: Collections-ul.137, >> Collections-ul.138, Collections-ul.139 and Collections-ul.140. These >> packages reimplement #rehash and #grow in Set and its subclasses >> (except MethodDictionary). The ideas come are from Ralph Boland's >> FasterSets project, but the implementation is different. According to >> my measurements they are even faster. The four packages should be >> loaded in the given order one-by-one otherwise mc might remove old >> methods before adding new ones, etc (couldn't come up with a better mc >> based load mechanism). >> >> While I was rewriting these methods, I found that KeyedSet and >> KeyedIdentitySet are not used (no references, no senders) in the >> trunk. >> Also checked that in a 3.8.1 full image they have no references (just >> senders in DecompilerTests >> #decompilerDiscrepancies). I think they >> might be removed from the base image and moved to a separate package. >> >> Cheers, >> Levente >> >> >> >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Lambdas are relegated to relative obscurity until Java makes them >> popular by not having them." James Iry >> > > > It sounds like you are using an older version of fasterSets. Â The > original version did not make the > modifications for Method dictionary but the new version does. Â I also > made a number of other improvements. > I suggest you test your version to the version currently in fasterSets > to see which one is actually faster. > Note that fasterSets has code for measuring performance at least in > terms of the number of compares. > Perhaps you can make the comparision and post the results. Â I would > like to see them. > I suggest that you study the current version of fasterSets and your > version and combine the best > features of both. > > If you wanted to make improvements I don't know why you didn't start > from the newer version. > I believe it was Damien Cassou who proposed that I make most of them. > I also asked that any modifications be incorporated into fasterSets > but I assume you have not done this. > > > Regards, > > Ralph Boland >

Sept. 21, 2009

Re: [Pharo-project] Fwd: [squeak-dev] About Collections-ul.137..140

by StÃ©phane Ducasse

Hi ralph May be I missed something. > It sounds like you are using an older version of fasterSets. The > original version did not make the > modifications for Method dictionary but the new version does. I also > made a number of other improvements. Are you talking about the pharo version? Because I integrated the version I thought was the best > I suggest you test your version to the version currently in fasterSets > to see which one is actually faster. > Note that fasterSets has code for measuring performance at least in > terms of the number of compares. > Perhaps you can make the comparision and post the results. I would > like to see them. > I suggest that you study the current version of fasterSets and your > version and combine the best > features of both. > > If you wanted to make improvements I don't know why you didn't start > from the newer version. > I believe it was Damien Cassou who proposed that I make most of them. > I also asked that any modifications be incorporated into fasterSets > but I assume you have not done this. to who are you talking to? Pharo integrator (me, marcus...) or do the squeak guy. Stef

Sept. 21, 2009

Re: [Pharo-project] Package loader on Pharo

by StÃ©phane Ducasse

> This is confusing for me. this is simple ScriptLoader should be named ThePrivateClassIntegratorUseToIntegrateAndManageRelease > Maybe the Pharo board should take a decision now in order to the > community to push it. There are: > > ChangeSets ok to keep to manage simple changes > ScriptLoader private don't use don't look at it is crap (I wrote) > Monticello alone ok > Monticello configurations ok > Metacello will manage group of packages and projects based on Monticello > Installer to script different code input > Gofer to script Monticello > They share a lot of overlapped functionality. Some scripts use one of > them, some other. This confuse the developers and the community. Maybe > now is the moment to discuss the tools in order to polish them and use > them, at leas until a new tool arrives that is better than the used by > Pharo. > > You said that ScriptLoader will not be part of the core image but as I > can see, only ScriptLoader and Installer can be installed directly > from > the web in an image that it doesn't have it. > > Can the community discuss this? Or the Pharo board write its opinion? done :)

Sept. 21, 2009

Re: [Pharo-project] Gofer vs Installer

by StÃ©phane Ducasse

> Can you relate the scenarios showing how gofer is intended to use, >> because until now (maybe my narrow perspective) the examples shown >> can >> be done also with ScriptLoader and Installer. > > Maybe the loading part can be performed by these tools (but then again > they mess up with the repositories), but not really the other > operations. ScriptLoader is not for public consumption. It is a private class full of crap that we slowly built to sustain our process. I would like slowly move some of the behavior - loadOneAfterTheOther: - loadSilently - mark ; changedPackages either to Gofer or to use gofer to perform certain actions.

Sept. 21, 2009

Re: [Pharo-project] Gofer vs Installer

by Lukas Renggli

>>> Or will just be for trying to install some group of packages and if some >>> error happens immediatly revert? >> >> No. It uses the normal tools available through Monticello, but >> provides a convenient interface. Furthermore it runs some additional >> code to keep the image in a clean state. For example it ensures that >> every working copy has an repository assigned, that repositories >> pointing to the same physical location are of the same instance, that >> unused repositories get removed again, that categories are properly >> ordered, that unload operations do not leave empty categories and >> protocols, etc. > > I always tough that monticello have complete control over the packages > installed and unloaded from an image. I also assumed that it cleaned its > mess after each operation. It is good to know this. But, a question, > shouldn't this be part of Monticello. Or monticello fixed so to not > leave dirty images behind it. Well that is just a comment. I know that > there are alread a dozen monticello versions. :) This is not only the fault of Monticello. Some of the problems (duplicated or missing repositories, wrongly ordered categories) only arise when you want to load multiple packages. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 21, 2009

Re: [Pharo-project] Gofer vs Installer

by Miguel Enrique CobÃ¡ Martinez

El lun, 21-09-2009 a las 18:04 +0200, Lukas Renggli escribiÃ³: > > This is something that I can't understand. Is this supposed to be a > > package management system per se, a la Metacello, aptitude, yum?? > > Isn't just a installer of MC packages but tries to manage the MC > > database of packages in a way that is clean and *atomic*? > > No, as it says on the first line, it is a tool to perform basic > Monticello operations on multiple packages. It is based on scripts > that we wrote to handle the 70+ Seaside 3.0 packages, as well as code > we wrote for Flair, a system that has similar goals than Metacello, > but is now discontinued in favor of Metacello. Maybe Metacello will > use Gofer as its loader. ok. > > So, there will be a registry of gofer installed operations so that can > > be utilized after the install operation (maybe months later)? > > No. Unless you store them somewhere. The class-side of Gofer has some > examples for common set of packages. > > > Or will just be for trying to install some group of packages and if some > > error happens immediatly revert? > > No. It uses the normal tools available through Monticello, but > provides a convenient interface. Furthermore it runs some additional > code to keep the image in a clean state. For example it ensures that > every working copy has an repository assigned, that repositories > pointing to the same physical location are of the same instance, that > unused repositories get removed again, that categories are properly > ordered, that unload operations do not leave empty categories and > protocols, etc. > I always tough that monticello have complete control over the packages installed and unloaded from an image. I also assumed that it cleaned its mess after each operation. It is good to know this. But, a question, shouldn't this be part of Monticello. Or monticello fixed so to not leave dirty images behind it. Well that is just a comment. I know that there are alread a dozen monticello versions. :) > > Can you relate the scenarios showing how gofer is intended to use, > > because until now (maybe my narrow perspective) the examples shown can > > be done also with ScriptLoader and Installer. > > Maybe the loading part can be performed by these tools (but then again > they mess up with the repositories), but not really the other > operations. > > > Other thing, I tried to convert my image install script but I can't > > finish because I install packages from monticello configurations (magma > > 1.0r42) and from my local directory repository. Neither of those options > > can be handled by gofer (as far as I can see). Of course this can be > > corrected, it is just to integrate the correct MC installer classes. > > Gofer is designed for Monticello only. ok. > > > That reminds me other thing, Installer can handle monticello > > configurations, is the corresponding way of loading the packages using > > gofer to list each package in the mcm file in a gofer script? So mcm > > will not used or it is just that there have no been time to add those > > capability to gofer? > > Yeah, a Gofer specification is very similar to a Monticello > Configuration. In fact when you use specific versions it is basically > the same, but then again it messes up with the repositories and > categories, something that drives me mad for years already :-) > > Cheers, > Lukas > Thanks -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Sept. 21, 2009

Re: [Pharo-project] [squeak-dev] About Collections-ul.137..140

by Ralph Boland

2009/9/21 Damien Cassou <damien.cassou(a)gmail.com>: > ---------- Forwarded message ---------- > From: Levente Uzonyi <leves(a)elte.hu> > Date: Sun, Sep 20, 2009 at 4:38 PM > Subject: [squeak-dev] About Collections-ul.137..140 > To: squeak-dev(a)lists.squeakfoundation.org > > > Hi! > > Just uploaded four packages to inbox: Collections-ul.137, > Collections-ul.138, Collections-ul.139 and Collections-ul.140. These > packages reimplement #rehash and #grow in Set and its subclasses > (except MethodDictionary). The ideas come are from Ralph Boland's > FasterSets project, but the implementation is different. According to > my measurements they are even faster. The four packages should be > loaded in the given order one-by-one otherwise mc might remove old > methods before adding new ones, etc (couldn't come up with a better mc > based load mechanism). > > While I was rewriting these methods, I found that KeyedSet and > KeyedIdentitySet are not used (no references, no senders) in the > trunk. > Also checked that in a 3.8.1 full image they have no references (just > senders in DecompilerTests >> #decompilerDiscrepancies). I think they > might be removed from the base image and moved to a separate package. > > Cheers, > Levente > > > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > It sounds like you are using an older version of fasterSets. The original version did not make the modifications for Method dictionary but the new version does. I also made a number of other improvements. I suggest you test your version to the version currently in fasterSets to see which one is actually faster. Note that fasterSets has code for measuring performance at least in terms of the number of compares. Perhaps you can make the comparision and post the results. I would like to see them. I suggest that you study the current version of fasterSets and your version and combine the best features of both. If you wanted to make improvements I don't know why you didn't start from the newer version. I believe it was Damien Cassou who proposed that I make most of them. I also asked that any modifications be incorporated into fasterSets but I assume you have not done this. Regards, Ralph Boland

Sept. 21, 2009

Re: [Pharo-project] Spring in November, Argentina

by Alexandre Bergel

Both the day before and after the conference are fine with me. Alexandre On 21 Sep 2009, at 12:25, Hernan Wilkinson wrote: > Alex, > if we change the date, is that a problem for you? > > On Mon, Sep 21, 2009 at 12:24 PM, Alexandre Bergel <alexandre(a)bergel.eu > > wrote: > In that case, you should not say that the conference ends after lunch, > but after the Pharo Sprint. It does not make a difference from the > logistic point of view, but it does in people mind. > > Cheers, > Alexandre > > On 21 Sep 2009, at 11:19, Mariano Martinez Peck wrote: > > > > > > > On Mon, Sep 21, 2009 at 2:13 PM, Alexandre Bergel > > <alexandre(a)bergel.eu> wrote: > > > We planned to do it on Wednesday 18... On Sunday the University is > > > not open.... > > > > This is pity, since Sunday has better chance to gather people. > > It will be on Wednesday then. I will buy my flight today or > tomorrow. > > > > > > Yeah. If we do it on Wednesday few people will be able to attend. > > HernÃ¡n is looking for another option. > > > > Another option is to do it on Saturday, after the conference. The > > conference finishes after lunch. So, we have all the afternoon/ > > evening. > > > > Cheers, > > > > Mariano > > > > Cheers, > > Alexandre > > > > > > > > On Sat, Sep 19, 2009 at 3:22 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > > > wrote: > > > for me this is ok too. > > > this can also be the sunday before since I will arrive from chile > > the > > > firday evening. > > > stef > > > > > > On Sep 18, 2009, at 11:32 PM, Mariano Martinez Peck wrote: > > > > > > > Do we know the exact day of the sprint? I suggest during > > weekend as > > > > most of us has to work during the week. It would be nice on > Sunday > > > > 22 but I don't know if the University is open. > > > > > > > > Best, > > > > > > > > Mariano > > > > > > > > > > > > On Thu, Sep 10, 2009 at 8:25 PM, Alexandre Bergel > > > > <alexandre(a)bergel.eu> wrote: > > > > Done. you're on the list. > > > > > > > > Alexandre > > > > > > > > On 10 Sep 2009, at 17:21, csrabak(a)bol.com.br wrote: > > > > > > > > > My first name is Cesar. > > > > > > > > > > > > > > > Em 09/09/2009 13:29, Alexandre Bergel < alexandre(a)bergel.eu > > > > > > > > > escreveu: > > > > > > > > > > > > > > > I can add it. What is your firstname - name ? > > > > > > > > > > Alexandre > > > > > > > > > > > > > > > On 9 Sep 2009, at 10:00, csrabak(a)bol.com.br wrote: > > > > > > > > > > > Would it suffice I add a comment in the wiki or should I > > get > > > > some > > > > > > specific id in order to edit the wiki page itself? > > > > > > > > > > > > BTW, if anything else fails:: I'm attemting to apply :-) > > > > > > > > > > > > > > > > > > Em 08/09/2009 15:10, Alexandre Bergel < > > > alexandre(a)bergel.eu > > > > > > > > > > > > escreveu: > > > > > > > > > > > > > > > > > > Dear List, > > > > > > > > > > > > I added a section in the Sprint wiki page: > > > > > > http://code.google.com/p/pharo/wiki/PharoSprints?ts=1252433348&updated=… > > > > > > > > > > > > People should add their name. I will send a remainder a > few > > > > days > > > > > > before the event. > > > > > > > > > > > > Cheers, > > > > > > Alexandre > > > > > > > > > > > > -- > > > > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > > > > 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 > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > _______________________________________________ > > > > 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 > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > 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 > > > > _______________________________________________ > > 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 > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 21, 2009