- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Metacello loading semantics

by Dale Henrichs

Stef, The Thanksgiving holiday is coming up tomorrow and through the weekend ... I promised my wife that I would avoid the computer this weekend since I was away in Argentina for 10 days, but I will probably be able to find a couple of hours poke at an image and try to see where things are falling through the cracks:) Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Wednesday, November 21, 2012 2:40:17 PM | Subject: Re: [Pharo-project] Metacello loading semantics | | | On Nov 21, 2012, at 8:51 PM, Dale Henrichs wrote: | | > Doru, | > | > The loadDirectives structure is the structure that does the actual | > package load for metacello, so extracting the information from the | > loadDirectives is the correct technique for producing a list of | > packages in load order. From a cursory read of Stefs code he | > appears to be doing it correctly ... atomic/linear loadType is an | > important distinction that has to be taken into account when | > attempting to reproduce the Metacello load behavior without using | > Metacelloâ¦ | | We thought that too but I got a problem with Roassal since it looks | like some classes are not loaded first. | | > Of course in the end, it's the details like which packages/projects | > specifically are causing trouble that will help me figure out | > exactly where things are breaking down. I assume that when | > Metacello does the load, everything gets loaded correctly? | | Well when we use the configuration of Moose (not the flatten one) it | loads: this is the Moose default configuration. | | > If you want me to help build/debug a package flattener for Moose I | > would be glad to help, but I need more detailed information about | > what you are trying to do and why. Also having the actual code to | > look at and a reproducible test case makes addressing issues a ton | > easier...Perhaps making an image available with a workspace doit | > primed for failure is a good first step:) | | The code in MooseReloader on smalltalkhub. I'm going to bed that and | tomorrow I follow lectures so I will explain it to you. | | | | > | > Dale | > | > ----- Original Message ----- | > | From: "Tudor Girba" <tudor(a)tudorgirba.com> | > | To: Pharo-project(a)lists.gforge.inria.fr | > | Sent: Wednesday, November 21, 2012 10:49:12 AM | > | Subject: Re: [Pharo-project] Metacello loading semantics | > | | > | Hi Dale, | > | | > | The question is how to get all packages that will be loaded for a | > | given configuration version in the correct order. We want to | > | obtain | > | that to provide a flattened configuration version based on what | > | is | > | in the image. | > | | > | Cheers, | > | Doru | > | | > | | > | | > | On 21 Nov 2012, at 19:33, Dale Henrichs <dhenrich(a)vmware.com> | > | wrote: | > | | > | > Stef, | > | > | > | > If you need to leverage the multi-package load, you can do that | > | > in | > | > Metacello by using the #atomic loadType in the project method | > | > of | > | > your configuration: | > | > | > | > project | > | > ^ project | > | > ifNil: [ | > | > "Bootstrap Metacello if it is not already loaded" | > | > self class ensureMetacello. | > | > project := self projectClass new projectAttributes: | > | > self | > | > customProjectAttributes. "Create the Metacello | > | > project" | > | > project versionNumberClass: self versionNumberClass. | > | > project class versionConstructorClass on: self | > | > project: | > | > project. "Construct the project" | > | > project loadType: #'atomic'. "change to #atomic if | > | > desired" | > | > project ] | > | > | > | > With #atomic, all of the packages are loaded in one | > | > multi-package | > | > load. with #linear (the default) each package is loaded | > | > individually. | > | > | > | > If you inspect the loadDirectives that are produced by the | > | > #record | > | > message, the load type is encoded in the class of the | > | > directive, | > | > so you can tell whether #linear or #atomic loadTypes are used | > | > in | > | > the configurations... | > | > | > | > Does this help? | > | > | > | > Dale | > | > | > | > ----- Original Message ----- | > | > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | > | > | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> | > | > | Sent: Saturday, November 17, 2012 11:28:03 AM | > | > | Subject: [Pharo-project] Metacello loading semantics | > | > | | > | > | Hi dale | > | > | | > | > | I implemented a little tool that | > | > | - create a kind of specification (version, package, repo) | > | > | for | > | > | all | > | > | the packages reachable from a configurationOf | > | > | (see below method method | > | > | packagesAndAssociatedRepositoriesFromConfigurationRecord ) | > | > | | > | > | It generates a script looking as follows: | > | > | script3 | > | > | ^ #( | > | > | #('ConfigurationOfFame-TudorGirba.5.mcz' | > | > | 'http://www.squeaksource.com/Fame/' | > | > | 'ConfigurationOfFame' ) | > | > | #('ConfigurationOfMooseAlgos-usmanbhatti.27.mcz' | > | > | 'http://www.squeaksource.com/MooseAlgos/' | > | > | 'ConfigurationOfMooseAlgos' ) | > | > | #('ConfigurationOfGlamour-TudorGirba.98.mcz' | > | > | 'http://www.squeaksource.com/Glamour/' | > | > | 'ConfigurationOfGlamour' | > | > | ) | > | > | #('ConfigurationOfDSM-AlexandreBergel.56.mcz' | > | > | 'http://www.squeaksource.com/dsm/' 'ConfigurationOfDSM' | > | > | ) | > | > | #('ConfigurationOfKumpel-AlexandreBergel.3.mcz' | > | > | 'http://www.squeaksource.com/Kumpel/' | > | > | 'ConfigurationOfKumpel' ) | > | > | #('ConfigurationOfSmallDudâ¦â¦â¦â¦.) | > | > | | > | > | - I keep the order given by Metacello. I extract the | > | > | information | > | > | as | > | > | follows: | > | > | | > | > | packagesAndAssociatedRepositoriesFromConfigurationRecord: | > | > | aConfigurationRecord | > | > | "| record | | > | > | record := ((Smalltalk globals at: #ConfigurationOfMoose) | > | > | project | > | > | version: 'default') ignoreImage: true; record. | > | > | self | > | > | packagesAndAssociatedRepositoriesFromConfigurationRecord: | > | > | record | > | > | " | > | > | | > | > | | pkgs | | > | > | pkgs := OrderedCollection new. | > | > | aConfigurationRecord loadDirective packageDirectivesDo: | > | > | [:directive | | > | > | pkgs add: | > | > | {directive spec name, '*'. | > | > | (self removeCache: directive spec workingCopy | > | > | repositoryGroup repositories) anyOne | > | > | locationWithTrailingSlash} ]. | > | > | ^ pkgs | > | > | | > | > | | > | > | - then I try to load the package as follows: | > | > | | > | > | flatVersion47: spec | > | > | <version: '4.7-flat'> | > | > | | > | > | spec for: #common do: [ | > | > | self populateSpec: spec with: self script3 ] | > | > | | > | > | I load them doing | > | > | (ConfigurationOfMoose project version: '4.7-flat') load | > | > | Now It does not work because after fetching all the packages, | > | > | the | > | > | system complain that some classes that will be loaded later | > | > | are | > | > | not | > | > | present. | > | > | I imagine that you use Gofer and that Gofer does not use the | > | > | merging | > | > | semantics of MC over multiple projects (that you can have | > | > | multiple | > | > | package in any order and that the classes get loaded - as I | > | > | use | > | > | it | > | > | for the scriptLoader and below). | > | > | | > | > | | > | > | - before I was doing it by doing a diff between the pharo | > | > | package | > | > | and the one loaded and I was loading the specification after | > | > | installing the repository | > | > | and the working copies using the MCVersionLoader and it | > | > | worked I | > | > | could reload completely Moose! | > | > | | > | > | | > | > | load: aCollectionOfPackageString | > | > | "self new | > | > | load: #( 'Famix-C-TudorGirba.15' | > | > | 'Famix-Core-NicolasAnquetil.201'))" | > | > | | > | > | | loader | | > | > | loader := MCVersionLoader new. | > | > | (self newerVersionsIn: aCollectionOfPackageString) | > | > | do: [ :fn | loader addVersion: (self | > | > | loadVersionFromFileNamed: | > | > | fn). | > | > | (Delay forSeconds: 2) wait.] | > | > | displayingProgress: 'Adding versions...'. | > | > | loader hasVersions ifTrue: [loader load]. | > | > | | > | > | | > | > | So my question is | > | > | - Does the packageDirectivesDo: provide an order that I can | > | > | use | > | > | to | > | > | load package with the gofer-load on project at a time? | > | > | May be my code does not keep the same order but I payed | > | > | attention to | > | > | this point. I will check that further. | > | > | | > | > | - may be I could extend Gofer to support multiple project | > | > | merge | > | > | loading. | > | > | | > | > | So right now I'm stuck and this is sad because freezing a | > | > | complex | > | > | configuration is really needed. | > | > | | > | > | Stef | > | > | | > | > | | > | > | | > | > | | > | > | | > | > | | > | > | > | | > | -- | > | www.tudorgirba.com | > | | > | "It's not what we do that matters most, it's how we do it." | > | | > | | > | | > |

Nov. 21, 2012

Re: [Pharo-project] when do we go beta?

by Esteban Lorenzano

new class builder is NOT marked for inclusion, I'm sorry (even as a preview) On Nov 21, 2012, at 11:56 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Wed, Nov 21, 2012 at 11:47 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2012-11-21, at 19:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > > > On Nov 21, 2012, at 11:37 PM, Mariano Martinez Peck wrote: > > > >> +1 for including only NB and then just bug fixes. No new stuff. > >> So...slots and new classbuilder will be for next release. Same for Opal I guess. > > > > No Opal should be in previous as well as Athens. > > These projects should come back to light. Else this will never happen. > > I think that the thing we did with filesystem in 1.4 was good > - integrate the detached project > - apply the refactorings during development > > then in the next release > - change tools to use the new infrastructure > - remove old code > > I think we did almost the same with Zinc, no? > > > What about NOT including new class builder nor Opal in 2.0 but as soon as we create the initial repo for 2.1 (or whatever), the first 2 things we do is to integrate them? > > > -- > Mariano > http://marianopeck.wordpress.com >

Nov. 21, 2012

Re: [Pharo-project] when do we go beta?

by Esteban Lorenzano

my proposal so far is: - prepare the vms as "NB ready" (I was planning to work on that next week, using the new infraestructure) - include NB as "ready to use" - include Opal as "preview" No more integrations for 2.0. We will be able to load Athens (since VMs and image will be prepared) with just a simple Metacello configuration. I don't know if including it as "preview" (like opal) Igor, what do you think? I need all next week to prepare that (with Marcus assistance, of course :P)... Are we ok with that? Esteban ps: If we don't go to beta next week will be really difficult to release in February (as is stipulated now) On Nov 21, 2012, at 11:47 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2012-11-21, at 19:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> On Nov 21, 2012, at 11:37 PM, Mariano Martinez Peck wrote: >> >>> +1 for including only NB and then just bug fixes. No new stuff. >>> So...slots and new classbuilder will be for next release. Same for Opal I guess. >> >> No Opal should be in previous as well as Athens. >> These projects should come back to light. Else this will never happen. > > I think that the thing we did with filesystem in 1.4 was good > - integrate the detached project > - apply the refactorings during development > > then in the next release > - change tools to use the new infrastructure > - remove old code > > I think we did almost the same with Zinc, no?

Nov. 21, 2012

Re: [Pharo-project] when do we go beta?

by Mariano Martinez Peck

On Wed, Nov 21, 2012 at 11:47 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > On 2012-11-21, at 19:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > > > On Nov 21, 2012, at 11:37 PM, Mariano Martinez Peck wrote: > > > >> +1 for including only NB and then just bug fixes. No new stuff. > >> So...slots and new classbuilder will be for next release. Same for Opal > I guess. > > > > No Opal should be in previous as well as Athens. > > These projects should come back to light. Else this will never happen. > > I think that the thing we did with filesystem in 1.4 was good > - integrate the detached project > - apply the refactorings during development > > then in the next release > - change tools to use the new infrastructure > - remove old code > > I think we did almost the same with Zinc, no? > What about NOT including new class builder nor Opal in 2.0 but as soon as we create the initial repo for 2.1 (or whatever), the first 2 things we do is to integrate them? -- Mariano http://marianopeck.wordpress.com

Nov. 21, 2012

Re: [Pharo-project] when do we go beta?

by Camillo Bruni

On 2012-11-21, at 19:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Nov 21, 2012, at 11:37 PM, Mariano Martinez Peck wrote: > >> +1 for including only NB and then just bug fixes. No new stuff. >> So...slots and new classbuilder will be for next release. Same for Opal I guess. > > No Opal should be in previous as well as Athens. > These projects should come back to light. Else this will never happen. I think that the thing we did with filesystem in 1.4 was good - integrate the detached project - apply the refactorings during development then in the next release - change tools to use the new infrastructure - remove old code I think we did almost the same with Zinc, no?

Nov. 21, 2012

Re: [Pharo-project] when do we go beta?

by StÃ©phane Ducasse

On Nov 21, 2012, at 11:37 PM, Mariano Martinez Peck wrote: > +1 for including only NB and then just bug fixes. No new stuff. > So...slots and new classbuilder will be for next release. Same for Opal I guess. No Opal should be in previous as well as Athens. These projects should come back to light. Else this will never happen. Stef

Nov. 21, 2012

Re: [Pharo-project] Metacello loading semantics

by StÃ©phane Ducasse

On Nov 21, 2012, at 8:51 PM, Dale Henrichs wrote: > Doru, > > The loadDirectives structure is the structure that does the actual package load for metacello, so extracting the information from the loadDirectives is the correct technique for producing a list of packages in load order. From a cursory read of Stefs code he appears to be doing it correctly ... atomic/linear loadType is an important distinction that has to be taken into account when attempting to reproduce the Metacello load behavior without using Metacelloâ¦ We thought that too but I got a problem with Roassal since it looks like some classes are not loaded first. > Of course in the end, it's the details like which packages/projects specifically are causing trouble that will help me figure out exactly where things are breaking down. I assume that when Metacello does the load, everything gets loaded correctly? Well when we use the configuration of Moose (not the flatten one) it loads: this is the Moose default configuration. > If you want me to help build/debug a package flattener for Moose I would be glad to help, but I need more detailed information about what you are trying to do and why. Also having the actual code to look at and a reproducible test case makes addressing issues a ton easier...Perhaps making an image available with a workspace doit primed for failure is a good first step:) The code in MooseReloader on smalltalkhub. I'm going to bed that and tomorrow I follow lectures so I will explain it to you. > > Dale > > ----- Original Message ----- > | From: "Tudor Girba" <tudor(a)tudorgirba.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Wednesday, November 21, 2012 10:49:12 AM > | Subject: Re: [Pharo-project] Metacello loading semantics > | > | Hi Dale, > | > | The question is how to get all packages that will be loaded for a > | given configuration version in the correct order. We want to obtain > | that to provide a flattened configuration version based on what is > | in the image. > | > | Cheers, > | Doru > | > | > | > | On 21 Nov 2012, at 19:33, Dale Henrichs <dhenrich(a)vmware.com> wrote: > | > | > Stef, > | > > | > If you need to leverage the multi-package load, you can do that in > | > Metacello by using the #atomic loadType in the project method of > | > your configuration: > | > > | > project > | > ^ project > | > ifNil: [ > | > "Bootstrap Metacello if it is not already loaded" > | > self class ensureMetacello. > | > project := self projectClass new projectAttributes: self > | > customProjectAttributes. "Create the Metacello project" > | > project versionNumberClass: self versionNumberClass. > | > project class versionConstructorClass on: self project: > | > project. "Construct the project" > | > project loadType: #'atomic'. "change to #atomic if > | > desired" > | > project ] > | > > | > With #atomic, all of the packages are loaded in one multi-package > | > load. with #linear (the default) each package is loaded > | > individually. > | > > | > If you inspect the loadDirectives that are produced by the #record > | > message, the load type is encoded in the class of the directive, > | > so you can tell whether #linear or #atomic loadTypes are used in > | > the configurations... > | > > | > Does this help? > | > > | > Dale > | > > | > ----- Original Message ----- > | > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | > | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > | > | Sent: Saturday, November 17, 2012 11:28:03 AM > | > | Subject: [Pharo-project] Metacello loading semantics > | > | > | > | Hi dale > | > | > | > | I implemented a little tool that > | > | - create a kind of specification (version, package, repo) for > | > | all > | > | the packages reachable from a configurationOf > | > | (see below method method > | > | packagesAndAssociatedRepositoriesFromConfigurationRecord ) > | > | > | > | It generates a script looking as follows: > | > | script3 > | > | ^ #( > | > | #('ConfigurationOfFame-TudorGirba.5.mcz' > | > | 'http://www.squeaksource.com/Fame/' 'ConfigurationOfFame' ) > | > | #('ConfigurationOfMooseAlgos-usmanbhatti.27.mcz' > | > | 'http://www.squeaksource.com/MooseAlgos/' > | > | 'ConfigurationOfMooseAlgos' ) > | > | #('ConfigurationOfGlamour-TudorGirba.98.mcz' > | > | 'http://www.squeaksource.com/Glamour/' > | > | 'ConfigurationOfGlamour' > | > | ) > | > | #('ConfigurationOfDSM-AlexandreBergel.56.mcz' > | > | 'http://www.squeaksource.com/dsm/' 'ConfigurationOfDSM' ) > | > | #('ConfigurationOfKumpel-AlexandreBergel.3.mcz' > | > | 'http://www.squeaksource.com/Kumpel/' > | > | 'ConfigurationOfKumpel' ) > | > | #('ConfigurationOfSmallDudâ¦â¦â¦â¦.) > | > | > | > | - I keep the order given by Metacello. I extract the information > | > | as > | > | follows: > | > | > | > | packagesAndAssociatedRepositoriesFromConfigurationRecord: > | > | aConfigurationRecord > | > | "| record | > | > | record := ((Smalltalk globals at: #ConfigurationOfMoose) > | > | project > | > | version: 'default') ignoreImage: true; record. > | > | self > | > | packagesAndAssociatedRepositoriesFromConfigurationRecord: > | > | record > | > | " > | > | > | > | | pkgs | > | > | pkgs := OrderedCollection new. > | > | aConfigurationRecord loadDirective packageDirectivesDo: > | > | [:directive | > | > | pkgs add: > | > | {directive spec name, '*'. > | > | (self removeCache: directive spec workingCopy > | > | repositoryGroup repositories) anyOne > | > | locationWithTrailingSlash} ]. > | > | ^ pkgs > | > | > | > | > | > | - then I try to load the package as follows: > | > | > | > | flatVersion47: spec > | > | <version: '4.7-flat'> > | > | > | > | spec for: #common do: [ > | > | self populateSpec: spec with: self script3 ] > | > | > | > | I load them doing > | > | (ConfigurationOfMoose project version: '4.7-flat') load > | > | Now It does not work because after fetching all the packages, the > | > | system complain that some classes that will be loaded later are > | > | not > | > | present. > | > | I imagine that you use Gofer and that Gofer does not use the > | > | merging > | > | semantics of MC over multiple projects (that you can have > | > | multiple > | > | package in any order and that the classes get loaded - as I use > | > | it > | > | for the scriptLoader and below). > | > | > | > | > | > | - before I was doing it by doing a diff between the pharo > | > | package > | > | and the one loaded and I was loading the specification after > | > | installing the repository > | > | and the working copies using the MCVersionLoader and it worked I > | > | could reload completely Moose! > | > | > | > | > | > | load: aCollectionOfPackageString > | > | "self new > | > | load: #( 'Famix-C-TudorGirba.15' > | > | 'Famix-Core-NicolasAnquetil.201'))" > | > | > | > | | loader | > | > | loader := MCVersionLoader new. > | > | (self newerVersionsIn: aCollectionOfPackageString) > | > | do: [ :fn | loader addVersion: (self loadVersionFromFileNamed: > | > | fn). > | > | (Delay forSeconds: 2) wait.] > | > | displayingProgress: 'Adding versions...'. > | > | loader hasVersions ifTrue: [loader load]. > | > | > | > | > | > | So my question is > | > | - Does the packageDirectivesDo: provide an order that I can use > | > | to > | > | load package with the gofer-load on project at a time? > | > | May be my code does not keep the same order but I payed > | > | attention to > | > | this point. I will check that further. > | > | > | > | - may be I could extend Gofer to support multiple project merge > | > | loading. > | > | > | > | So right now I'm stuck and this is sad because freezing a complex > | > | configuration is really needed. > | > | > | > | Stef > | > | > | > | > | > | > | > | > | > | > | > | > | > > | > | -- > | www.tudorgirba.com > | > | "It's not what we do that matters most, it's how we do it." > | > | > | >

Nov. 21, 2012

Re: [Pharo-project] Metacello loading semantics

by StÃ©phane Ducasse

> Stef, > > If you need to leverage the multi-package load, you can do that in Metacello by using the #atomic loadType in the project method of your configuration: > > project > ^ project > ifNil: [ > "Bootstrap Metacello if it is not already loaded" > self class ensureMetacello. > project := self projectClass new projectAttributes: self customProjectAttributes. "Create the Metacello project" > project versionNumberClass: self versionNumberClass. > project class versionConstructorClass on: self project: project. "Construct the project" > project loadType: #'atomic'. "change to #atomic if desired" > project ] > > With #atomic, all of the packages are loaded in one multi-package load. with #linear (the default) each package is loaded individually. Ok I was not aware of that and I will > > If you inspect the loadDirectives that are produced by the #record message, the load type is encoded in the class of the directive, so you can tell whether #linear or #atomic loadTypes are used in the configurations... > > Does this help? Yes I will try. I disabled the cache disabling because loading 800 packages to try is a pain :) > > Dale > > ----- Original Message ----- > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > | Sent: Saturday, November 17, 2012 11:28:03 AM > | Subject: [Pharo-project] Metacello loading semantics > | > | Hi dale > | > | I implemented a little tool that > | - create a kind of specification (version, package, repo) for all > | the packages reachable from a configurationOf > | (see below method method > | packagesAndAssociatedRepositoriesFromConfigurationRecord ) > | > | It generates a script looking as follows: > | script3 > | ^ #( > | #('ConfigurationOfFame-TudorGirba.5.mcz' > | 'http://www.squeaksource.com/Fame/' 'ConfigurationOfFame' ) > | #('ConfigurationOfMooseAlgos-usmanbhatti.27.mcz' > | 'http://www.squeaksource.com/MooseAlgos/' > | 'ConfigurationOfMooseAlgos' ) > | #('ConfigurationOfGlamour-TudorGirba.98.mcz' > | 'http://www.squeaksource.com/Glamour/' 'ConfigurationOfGlamour' > | ) > | #('ConfigurationOfDSM-AlexandreBergel.56.mcz' > | 'http://www.squeaksource.com/dsm/' 'ConfigurationOfDSM' ) > | #('ConfigurationOfKumpel-AlexandreBergel.3.mcz' > | 'http://www.squeaksource.com/Kumpel/' 'ConfigurationOfKumpel' ) > | #('ConfigurationOfSmallDudâ¦â¦â¦â¦.) > | > | - I keep the order given by Metacello. I extract the information as > | follows: > | > | packagesAndAssociatedRepositoriesFromConfigurationRecord: > | aConfigurationRecord > | "| record | > | record := ((Smalltalk globals at: #ConfigurationOfMoose) project > | version: 'default') ignoreImage: true; record. > | self packagesAndAssociatedRepositoriesFromConfigurationRecord: > | record > | " > | > | | pkgs | > | pkgs := OrderedCollection new. > | aConfigurationRecord loadDirective packageDirectivesDo: > | [:directive | > | pkgs add: > | {directive spec name, '*'. > | (self removeCache: directive spec workingCopy > | repositoryGroup repositories) anyOne > | locationWithTrailingSlash} ]. > | ^ pkgs > | > | > | - then I try to load the package as follows: > | > | flatVersion47: spec > | <version: '4.7-flat'> > | > | spec for: #common do: [ > | self populateSpec: spec with: self script3 ] > | > | I load them doing > | (ConfigurationOfMoose project version: '4.7-flat') load > | Now It does not work because after fetching all the packages, the > | system complain that some classes that will be loaded later are not > | present. > | I imagine that you use Gofer and that Gofer does not use the merging > | semantics of MC over multiple projects (that you can have multiple > | package in any order and that the classes get loaded - as I use it > | for the scriptLoader and below). > | > | > | - before I was doing it by doing a diff between the pharo package > | and the one loaded and I was loading the specification after > | installing the repository > | and the working copies using the MCVersionLoader and it worked I > | could reload completely Moose! > | > | > | load: aCollectionOfPackageString > | "self new > | load: #( 'Famix-C-TudorGirba.15' > | 'Famix-Core-NicolasAnquetil.201'))" > | > | | loader | > | loader := MCVersionLoader new. > | (self newerVersionsIn: aCollectionOfPackageString) > | do: [ :fn | loader addVersion: (self loadVersionFromFileNamed: fn). > | (Delay forSeconds: 2) wait.] > | displayingProgress: 'Adding versions...'. > | loader hasVersions ifTrue: [loader load]. > | > | > | So my question is > | - Does the packageDirectivesDo: provide an order that I can use to > | load package with the gofer-load on project at a time? > | May be my code does not keep the same order but I payed attention to > | this point. I will check that further. > | > | - may be I could extend Gofer to support multiple project merge > | loading. > | > | So right now I'm stuck and this is sad because freezing a complex > | configuration is really needed. > | > | Stef > | > | > | > | > | > | >

Nov. 21, 2012

Re: [Pharo-project] when do we go beta?

by Mariano Martinez Peck

+1 for including only NB and then just bug fixes. No new stuff. So...slots and new classbuilder will be for next release. Same for Opal I guess. On Wed, Nov 21, 2012 at 11:30 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Please! > Because I refrain myself to fix and changes so we should focus on bug > fixing and not opening new things. > > > I was thinking on going beta next week, actually :) > > > > > >>> when do we go beta? > >> > >> I have been using 2.0 for months now, it has been very stable (apart > from some hiccups). > >> > >> It is so much better that it would be immoral to keep this from the > world ;-) > >> > >> We just have to declare a stabilization period in which we refrain from > big/dangerous changes and work more on stability and testing. > > Thanks sven. > > > -- Mariano http://marianopeck.wordpress.com

Nov. 21, 2012

Re: [Pharo-project] Metacello Why symbolicversion and not simply tagged version:?

by StÃ©phane Ducasse

On Nov 21, 2012, at 8:16 PM, Dale Henrichs wrote: > Doru, > > I guess because I don't agree that the following statement would be true: > > there will never be a regular version named 'stable' > > I know that in git I can have a branch named 'stable' and a tag named 'stable' and that causes problems ... for me. > > Besides, the set of symbolic versions is not restricted to #stable and #development ... one could choose to define a symbolic version called #default or #'1.0'â¦ I would not. I would like that Metacello constraints the space. Because we should have less option and more structured supported scenarios. > I intend for there to be two namespaces the linear version namespace and the symbolic version namespace to make a clear distinction between the two, because they have different semantics. Ok it was not clear to me that they have a different semantics. > One shouldn't be surprised that when version #stable of project foo is loaded the current version of the project is '1.0' on one day and '1.1' on the next. How this can be possible? Ok you mean because the guy changed the stable definition. > Or when they load #'1.0' that the current version is '1.0-beta.19'. > > This distinction is obviously not important to you and I am okay with that:) > > Dale > > ----- Original Message ----- > | From: "Tudor Girba" <tudor(a)tudorgirba.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Wednesday, November 21, 2012 10:50:37 AM > | Subject: Re: [Pharo-project] Metacello Why symbolicversion and not simply tagged version:? > | > | The question is the same I asked when you introduced them :): > | Why are symbolic versions treated differently from normal ones? > | > | This has two dimensions: > | - why have a different pragma at all? > | - why have the distinction between symbols and versions, given that > | there will never be a regular version named 'stable'? > | > | Cheers, > | Doru > | > | > | On 21 Nov 2012, at 19:27, Dale Henrichs <dhenrich(a)vmware.com> wrote: > | > | > Stef, > | > > | > I'm not sure which context you are talking about ... the symbolic > | > version #stable can be used as an argument anywhere that the > | > linear version '1.1' can be used, so I think that it is true that > | > symbolic versions can be used in a #version: message ... > | > > | > So I guess I need a little more context ... > | > > | > Dale > | > > | > ----- Original Message ----- > | > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | > | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > | > | Sent: Friday, November 16, 2012 2:19:02 PM > | > | Subject: [Pharo-project] Metacello Why symbolicversion and not > | > | simply tagged version:? > | > | > | > | Dale > | > | > | > | in my goal to reduce the complexity of metacello, I'm wondering > | > | why > | > | symbolic versions could not be expressed as version: > | > | > | > | because > | > | > | > | version: #stable > | > | version: #development > | > | > | > | are symbolic versions and there is no clash possible with > | > | > | > | version: '1.1' > | > | > | > | Stef > | > | > | > | > | > > | > | -- > | www.tudorgirba.com > | > | "Things happen when they happen, > | not when you talk about them happening." > | > | > | >

Nov. 21, 2012