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

[Pharo-project] Fwd: [Moose-dev] Re: Re: duplication between default: and version40beta2:?

by StÃ©phane Ducasse

> From: stephane ducasse <stephane.ducasse(a)gmail.com> > Date: December 3, 2009 8:27:27 PM GMT+01:00 > To: metacello(a)googlegroups.com > Cc: Pharo-project(a)lists.gforge.inria.fr, Related to the development of Moose and other related tools <moose-dev(a)iam.unibe.ch> > Subject: Re: [Pharo-project] [Moose-dev] Re: Re: duplication between default: and version40beta2:? > > > apparently we had a differetn definition of map. > my point is that we need map with exact numbers of component to be able to reload and build more. > Now I like the baseline idea. > > On Dec 3, 2009, at 8:14 PM, Dale Henrichs wrote: > >> >> In a Metacello context. >> >> The map of packages and their relationships is called a #baseline version. If one loads a #baseline version the latest version of each package is loaded. The "structure" is stable but loading a #baseline version is a risky proposition for everyone except project developers themselves who are prepared to address load-time conflicts/bugs. >> >> A #development version, imports structure from the #baseline, but a specific package version is supplied for each Monticello package or project. When a development version is loaded, the explicit list of package versions are loaded. IN a #development version, the package versions are not finalized and may change over time. When a #development version is saved, there is an presumption that some level of testing has gone on and that the package versions are expected to work together. One can go to a particular version of the package in which the configuration is saved and expect to load the same packages....However, the list of package versions will change over time. >> >> For all other 'released' versions, (beta, release, alpha, stable, etc.) it is expected that the list of package versions will never change - the code base may still be alpha, but it is a stable known point with respect to package versions. >> >> (BTW, I've added the metacello group to this cross-posted message:) >> >> Dale >> ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: >> >> | Still still still you can always have a map (a map of all the >> | components you loaded that they work or not). >> | This is orthogonal to a release or just publications. This is a >> | sofware artefact. I know that you know it. >> | The fact to have map is orthogonal of the choice latest or one >> | version. >> | I just write that for others following our discussion.... >> | >> | Stef >> | >> | >> | >> | On Dec 3, 2009, at 3:59 PM, Tudor Girba wrote: >> | >> | > Hi, >> | > >> | > Not every loading strategy have the same goal or the same context. >> | > >> | > Sub projects will be developed and published in their own context >> | > without taking into account the overall project. However, when >> | > maintaining the overall project, I want to be able to say "load >> | > latest" so that I can easily load everything and check whether >> | > everything still holds together. >> | > >> | > For overall release management, I do not want to rely on "load >> | > latest". Instead I will release a coherent version when I see that >> | it >> | > works. This will be a fixed set of packages with exact versions that >> | >> | > will work together. >> | > >> | > Cheers, >> | > Doru >> | > >> | > >> | > On 3 Dec 2009, at 14:21, Marcus Denker wrote: >> | > >> | >> >> | >> On Dec 3, 2009, at 1:40 PM, Laval Jannik wrote: >> | >> >> | >>> Yeh, >> | >>> >> | >>> Now, I understand the process... (I am slow :) ) >> | >>> >> | >>> But, in this process we must specify versions and maintain it. >> | >>> Is there a solution (in monticello maybe) to say a version of a >> | >>> package is stable. >> | >>> So in this case, we can say "I want last stable version of my >> | >>> package" and we do not need to maintain ConfigurationOf. >> | >>> >> | >> >> | >> The problem is that it's not one package... your system will be 20 >> | >> | >> packges. You can say " load the latest of all, that works". >> | >> But: now I want to load the version that worked so great last >> | month. >> | >> Which set of packages exactly where that? >> | >> >> | >> Tagging single packages as "release" will not help, as you don't >> | >> have the info which released package works with which other >> | >> released package. >> | >> >> | >> >> | >> Marcus >> | >> _______________________________________________ >> | >> Moose-dev mailing list >> | >> Moose-dev(a)iam.unibe.ch >> | >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> | > >> | > -- >> | > www.tudorgirba.com >> | > >> | > "Obvious things are difficult to teach." >> | > >> | > >> | > >> | > >> | > _______________________________________________ >> | > 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 > > > >

Dec. 3, 2009

Re: [Pharo-project] [ann 1.1] pre-built #11068

by StÃ©phane Ducasse

good I could not see what was the problem with the script because I could not make it run completely. May be a netwrok problem On Dec 3, 2009, at 8:09 PM, Damien Cassou wrote: > 2009/12/2 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> may be we will need two scripts >> one for 1.0 and one for 1.1 because we will have to load different versions of tools ? > > as soon as I see for 2 scripts I will create two. For the moment, one > will be enough because I don't know of any package that use features > specific to Pharo 1.1 and that prevent it from being loaded in Pharo > 1.0. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 3, 2009

Re: [Pharo-project] [Moose-dev] Re: Re: duplication between default: and version40beta2:?

by Dale Henrichs

In a Metacello context. The map of packages and their relationships is called a #baseline version. If one loads a #baseline version the latest version of each package is loaded. The "structure" is stable but loading a #baseline version is a risky proposition for everyone except project developers themselves who are prepared to address load-time conflicts/bugs. A #development version, imports structure from the #baseline, but a specific package version is supplied for each Monticello package or project. When a development version is loaded, the explicit list of package versions are loaded. IN a #development version, the package versions are not finalized and may change over time. When a #development version is saved, there is an presumption that some level of testing has gone on and that the package versions are expected to work together. One can go to a particular version of the package in which the configuration is saved and expect to load the same packages....However, the list of package versions will change over time. For all other 'released' versions, (beta, release, alpha, stable, etc.) it is expected that the list of package versions will never change - the code base may still be alpha, but it is a stable known point with respect to package versions. (BTW, I've added the metacello group to this cross-posted message:) Dale ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | Still still still you can always have a map (a map of all the | components you loaded that they work or not). | This is orthogonal to a release or just publications. This is a | sofware artefact. I know that you know it. | The fact to have map is orthogonal of the choice latest or one | version. | I just write that for others following our discussion.... | | Stef | | | | On Dec 3, 2009, at 3:59 PM, Tudor Girba wrote: | | > Hi, | > | > Not every loading strategy have the same goal or the same context. | > | > Sub projects will be developed and published in their own context | > without taking into account the overall project. However, when | > maintaining the overall project, I want to be able to say "load | > latest" so that I can easily load everything and check whether | > everything still holds together. | > | > For overall release management, I do not want to rely on "load | > latest". Instead I will release a coherent version when I see that | it | > works. This will be a fixed set of packages with exact versions that | | > will work together. | > | > Cheers, | > Doru | > | > | > On 3 Dec 2009, at 14:21, Marcus Denker wrote: | > | >> | >> On Dec 3, 2009, at 1:40 PM, Laval Jannik wrote: | >> | >>> Yeh, | >>> | >>> Now, I understand the process... (I am slow :) ) | >>> | >>> But, in this process we must specify versions and maintain it. | >>> Is there a solution (in monticello maybe) to say a version of a | >>> package is stable. | >>> So in this case, we can say "I want last stable version of my | >>> package" and we do not need to maintain ConfigurationOf. | >>> | >> | >> The problem is that it's not one package... your system will be 20 | | >> packges. You can say " load the latest of all, that works". | >> But: now I want to load the version that worked so great last | month. | >> Which set of packages exactly where that? | >> | >> Tagging single packages as "release" will not help, as you don't | >> have the info which released package works with which other | >> released package. | >> | >> | >> Marcus | >> _______________________________________________ | >> Moose-dev mailing list | >> Moose-dev(a)iam.unibe.ch | >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev | > | > -- | > www.tudorgirba.com | > | > "Obvious things are difficult to teach." | > | > | > | > | > _______________________________________________ | > 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

Dec. 3, 2009

Re: [Pharo-project] [ann 1.1] pre-built #11068

by Damien Cassou

2009/12/2 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > may be we will need two scripts > one for 1.0 and one for 1.1 because we will have to load different versions of tools ? as soon as I see for 2 scripts I will create two. For the moment, one will be enough because I don't know of any package that use features specific to Pharo 1.1 and that prevent it from being loaded in Pharo 1.0. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Dec. 3, 2009

Re: [Pharo-project] ParserTreeSearcher problem (lukas can you check)

by Lukas Renggli

>> I think that I fixed that a long time ago. No? > > Well, if you download current pharo-web image on pharo-project.org and run > code critics, it fails. Slime package loaded is Slime-lr.24. I think that has been reported previously. O2 and the latest RB code don't work well together yet. Use Slime-lr.25, that should solve the problem. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 3, 2009

Re: [Pharo-project] Slime at work

by StÃ©phane Ducasse

yes the rc image contains old code..... we are fixing that. Stef On Dec 3, 2009, at 5:59 PM, laurent laffont wrote: > 2. In the context menu of that item select 'browse package (p)' or > 'refactoring scope > package' which both do the same. > > BrowserEnvironment(Object)>>doesNotUnderstand: #forPackage: > OR2CmdPackageEnvironment>>environment > [] in OR2CmdPackageEnvironment(OR2CmdEnvironment)>>execute > > ... sometimes it's hard to be a newbie ..... but thank you ! > > Laurent > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 3, 2009

Re: [Pharo-project] class comment displayed

by StÃ©phane Ducasse

Since several years I think that we lack a tool to get really fast browsing of class comments. May be that now that we have Momo tree we could have a tree ClassA class comment method method comment ClassB class comment method method comment Alain do you have an example on how to play with Momo .... Stef

Dec. 3, 2009

Re: [Pharo-project] class comment displayed

by StÃ©phane Ducasse

> In fact, the server already worked again yesterday evening. > > I had a leaflet at my door that they replace the internet cables. That > explains the outage. I am happy that I was not here, without internet > I would have gotten nervous ;-) lol >>>> this was to get the comment below the class definition >>>> This is in the preferences at least on my image (rc1.0). >>> >>> That split class-definition/class-comment view is only available in >>> the ST-80 browser. I think that would be difficult to implement in OB. >> >> ok too bad because nicolas made me think that we are doing a poor job >> at pushing people to write comments since nobody can easily read them. > > An easy solution would be to show the class comment somehow like: > > WAPainter subclass: #WAPresenter > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'Seaside-Component'. > > WAPresenter comment: 'WAPresenter holds the functionality that is > common to WAComponent and WADecoration. Subclasses of this class may > have state and can be stored in instance variables of other > Presenters. ... > > It is a bit an ugly solution. Might have some side-effects too :-/ we could give a try.

Dec. 3, 2009

Re: [Pharo-project] Slime at work

by laurent laffont

> > 2. In the context menu of that item select 'browse package (p)' or > 'refactoring scope > package' which both do the same. > BrowserEnvironment(Object)>>doesNotUnderstand: #forPackage: OR2CmdPackageEnvironment>>environment [] in OR2CmdPackageEnvironment(OR2CmdEnvironment)>>execute ... sometimes it's hard to be a newbie ..... but thank you ! Laurent

Dec. 3, 2009

Re: [Pharo-project] class comment displayed

by Lukas Renggli

>>> I hope that the trip was good. >> >> Yep, just arrived home. > > Reboot :) In fact, the server already worked again yesterday evening. I had a leaflet at my door that they replace the internet cables. That explains the outage. I am happy that I was not here, without internet I would have gotten nervous ;-) >>> this was to get the comment below the class definition >>> This is in the preferences at least on my image (rc1.0). >> >> That split class-definition/class-comment view is only available in >> the ST-80 browser. I think that would be difficult to implement in OB. > > ok too bad because nicolas made me think that we are doing a poor job > at pushing people to write comments since nobody can easily read them. An easy solution would be to show the class comment somehow like: WAPainter subclass: #WAPresenter instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Seaside-Component'. WAPresenter comment: 'WAPresenter holds the functionality that is common to WAComponent and WADecoration. Subclasses of this class may have state and can be stored in instance variables of other Presenters. ... It is a bit an ugly solution. Might have some side-effects too :-/ Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 3, 2009