collecting all packages of a configuration
Locked
123
123
Re: collecting all packages of a configuration
 
|
Hi Dale. I find myself again, trying to collect the packages loaded (and their order). There is something that does not work and I cannot figure out what is happening. At least, it is reproducible ;)
I took the last Pharo 2.0 available from Jenkins, and I install seaside and pier as following:
Gofer it squeaksource: 'MetacelloRepository';
package: 'ConfigurationOfSeaside30'; load. ((Smalltalk at: #ConfigurationOfSeaside30) project version: #stable) load: #('Base' 'Zinc-Seaside' 'Base Tests' 'RSS-Core' 'Javascript-Core' 'Prototype-Core' 'Scriptaculous-Core' 'JQuery-Core' 'JQuery-UI' 'Seaside-Email' 'Seaside-HTML5' 'Seaside-InternetExplorer' 'Seaside-Examples' 'RSS-Examples' 'Seaside-Tools-Web' 'Scriptaculous-Components' 'Seaside-Welcome' 'Seaside-FileSystem' 'RSS-Tests-Core' 'Javascript-Tests-Core' 'Seaside-Tests-Email' 'Seaside-Tests-Functional' 'Prototype-Tests-Core' 'Scriptaculous-Tests-Core' 'Scriptaculous-Tests-Components' 'JQuery-Tests-Core' 'JQuery-Tests-UI' 'Seaside-Tests-HTML5' 'Seaside-Tests-InternetExplorer' 'Seaside-Tests-Examples' 'Seaside-Tests-Tools-Web' 'Seaside-Tests-UTF8' 'Seaside-Tests-FileSystem' 'Seaside-Tests-Welcome').
Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPier2';
load. ((Smalltalk at: #ConfigurationOfPier2) project version: #stable) load. Gofer it squeaksource: 'MetacelloRepository';
package: 'ConfigurationOfPierAddOns2'; load. ((Smalltalk at: #ConfigurationOfPierAddOns2) project version: #stable) load: #('default' 'Pier-Shout' 'Pier-Design' ).
Now...while loading that, I have an popup saying I am about to load a new version of XML-Parser (see attachment). Ok, I say "load" and everything loads fine after. The problem is that if now I ask Metacello the loaded packages: >> packagesFromConf: confName version: versionString loading: packageOrGroups
| loader pkgs | loader := ((Smalltalk at: confName asSymbol) project version: versionString)
ignoreImage: true; record: packageOrGroups. pkgs := OrderedCollection new.
loader loadDirective packageDirectivesDo: [:directive | pkgs add: directive spec name ]. ^ pkgs
>> seasidePackages | packages loader | packages := OrderedCollection new.
packages addAll: (self packagesFromConf: #ConfigurationOfSeaside30 version: #stable loading: #('Base' 'Zinc-Seaside' 'Base Tests' 'RSS-Core' 'Javascript-Core' 'Prototype-Core' 'Scriptaculous-Core' 'JQuery-Core' 'JQuery-UI' 'Seaside-Email' 'Seaside-HTML5' 'Seaside-InternetExplorer' 'Seaside-Examples' 'RSS-Examples' 'Seaside-Tools-Web' 'Scriptaculous-Components' 'Seaside-Welcome' 'Seaside-FileSystem' 'RSS-Tests-Core' 'Javascript-Tests-Core' 'Seaside-Tests-Email' 'Seaside-Tests-Functional' 'Prototype-Tests-Core' 'Scriptaculous-Tests-Core' 'Scriptaculous-Tests-Components' 'JQuery-Tests-Core' 'JQuery-Tests-UI' 'Seaside-Tests-HTML5' 'Seaside-Tests-InternetExplorer' 'Seaside-Tests-Examples' 'Seaside-Tests-Tools-Web' 'Seaside-Tests-UTF8' 'Seaside-Tests-FileSystem' 'Seaside-Tests-Welcome'
)). packages addAll: (self packagesFromConf: #ConfigurationOfPier2 version: #stable loading: #('default')). packages addAll: (self packagesFromConf: #ConfigurationOfPierAddOns2 version: #stable loading: #('default' 'Pier-Shout' 'Pier-Design' )).
packages addAll: #('Pier-FuelPersistence-Core' 'Pier-FuelPersistence-Test'). packages := packages removeDuplicates. ^ packages
There are some packages that do not appear, like 'Collections-BitmapCharacterSet' or 'Collections-OrderPreservingDictionary', which are needed by ConfigurationOfXMLSupport . And....this is related to the error I got popup (saying I was loading a new version)
So...all in all, do you have something in mind that could be happening? Sorry for not being able to dig deeper. Thanks!!!
On Sun, May 13, 2012 at 5:05 PM, Dale Henrichs <[hidden email]> wrote: Mariano, Mariano http://marianopeck.wordpress.com |
Screen shot 2012-08-02 at 6.14.01 PM.png (46K)
Re: collecting all packages of a configuration
|
|
Mariano,
To be frank, when it comes to Pharo-2.0 at this point in time, I assume that the issue is a problem in Pharo-2.0. I haven't been able to load Metacello into Pharo-2.0 for about a month, so I haven't been able to use Pharo-2.0 myself ... I'm somewhat surprised that folks are able to get work done ... I just assume they don't use Metacello that much:) In my experience trying to use pharo-2.0, the system is hosed when that "unsaved changes dialog" pops up. If the system were functioning correctly you wouldn't get a message about dirty packages. The package is being freshly loaded (in my cases) so there should be no dirty package warning ... once you can't trust the uderlying system... If you can reproduce the problem in Pharo1.4 or Pharo1.3 or squeak4.3 or gemstone, I will be glad to try to fix the problem. I don't like having to say this, but I've "wasted" time several times in the past month giving Pharo-2.0 a go and attempting to debug the problems (assuming that I needed to make changes to work in Pharo-2.0) and each time it was some nasty little bug in the base. From my perspective I don't really know if Metacello is working on Pharo-2.0 or not and I'm waiting for Pharo-2.0 to stabilize before trying again. Dale ----- Original Message ----- | From: "Mariano Martinez Peck" <[hidden email]> | To: [hidden email] | Sent: Thursday, August 2, 2012 9:56:40 AM | Subject: Re: [Metacello] collecting all packages of a configuration | | Hi Dale. I find myself again, trying to collect the packages loaded | (and their order). There is something that does not work and I | cannot figure out what is happening. At least, it is reproducible ;) | | | I took the last Pharo 2.0 available from Jenkins, and I install | seaside and pier as following: | | | | Gofer it | squeaksource: 'MetacelloRepository'; | package: 'ConfigurationOfSeaside30'; | load. | | | ((Smalltalk at: #ConfigurationOfSeaside30) project version: #stable) | load: #('Base' 'Zinc-Seaside' 'Base Tests' 'RSS-Core' | 'Javascript-Core' 'Prototype-Core' 'Scriptaculous-Core' | 'JQuery-Core' 'JQuery-UI' 'Seaside-Email' 'Seaside-HTML5' | 'Seaside-InternetExplorer' 'Seaside-Examples' 'RSS-Examples' | 'Seaside-Tools-Web' 'Scriptaculous-Components' 'Seaside-Welcome' | 'Seaside-FileSystem' 'RSS-Tests-Core' 'Javascript-Tests-Core' | 'Seaside-Tests-Email' 'Seaside-Tests-Functional' | 'Prototype-Tests-Core' 'Scriptaculous-Tests-Core' | 'Scriptaculous-Tests-Components' 'JQuery-Tests-Core' | 'JQuery-Tests-UI' 'Seaside-Tests-HTML5' | 'Seaside-Tests-InternetExplorer' 'Seaside-Tests-Examples' | 'Seaside-Tests-Tools-Web' 'Seaside-Tests-UTF8' | 'Seaside-Tests-FileSystem' 'Seaside-Tests-Welcome'). | | Gofer it | squeaksource: 'MetacelloRepository'; | package: 'ConfigurationOfPier2'; | load. | | | ((Smalltalk at: #ConfigurationOfPier2) project version: #stable) | load. | | | | | Gofer it | squeaksource: 'MetacelloRepository'; | package: 'ConfigurationOfPierAddOns2'; | load. | | | | | | ((Smalltalk at: #ConfigurationOfPierAddOns2) project version: | #stable) load: #('default' 'Pier-Shout' 'Pier-Design' ). | | | | | Now...while loading that, I have an popup saying I am about to load a | new version of XML-Parser (see attachment). Ok, I say "load" and | everything loads fine after. | | | The problem is that if now I ask Metacello the loaded packages: | | | | | | | >> packagesFromConf: confName version: versionString loading: | >> packageOrGroups | | loader pkgs | | | loader := ((Smalltalk at: confName asSymbol) project version: | versionString) | ignoreImage: true; | record: packageOrGroups. | pkgs := OrderedCollection new. | loader loadDirective packageDirectivesDo: [:directive | pkgs add: | directive spec name ]. | ^ pkgs | | | | | >> seasidePackages | | packages loader | | packages := OrderedCollection new. | packages addAll: (self packagesFromConf: #ConfigurationOfSeaside30 | version: #stable loading: #('Base' 'Zinc-Seaside' 'Base Tests' | 'RSS-Core' 'Javascript-Core' 'Prototype-Core' 'Scriptaculous-Core' | 'JQuery-Core' 'JQuery-UI' 'Seaside-Email' 'Seaside-HTML5' | 'Seaside-InternetExplorer' 'Seaside-Examples' 'RSS-Examples' | 'Seaside-Tools-Web' 'Scriptaculous-Components' 'Seaside-Welcome' | 'Seaside-FileSystem' 'RSS-Tests-Core' 'Javascript-Tests-Core' | 'Seaside-Tests-Email' 'Seaside-Tests-Functional' | 'Prototype-Tests-Core' 'Scriptaculous-Tests-Core' | 'Scriptaculous-Tests-Components' 'JQuery-Tests-Core' | 'JQuery-Tests-UI' 'Seaside-Tests-HTML5' | 'Seaside-Tests-InternetExplorer' 'Seaside-Tests-Examples' | 'Seaside-Tests-Tools-Web' 'Seaside-Tests-UTF8' | 'Seaside-Tests-FileSystem' 'Seaside-Tests-Welcome' | )). | | | packages addAll: (self packagesFromConf: #ConfigurationOfPier2 | version: #stable loading: #('default')). | packages addAll: (self packagesFromConf: #ConfigurationOfPierAddOns2 | version: #stable loading: #('default' 'Pier-Shout' 'Pier-Design' )). | packages addAll: #('Pier-FuelPersistence-Core' | 'Pier-FuelPersistence-Test'). | | packages := packages removeDuplicates. | | ^ packages | | | | | | | | There are some packages that do not appear, like | 'Collections-BitmapCharacterSet' or | 'Collections-OrderPreservingDictionary', which are needed by | ConfigurationOfXMLSupport . And....this is related to the error I | got popup (saying I was loading a new version) | | | So...all in all, do you have something in mind that could be | happening? Sorry for not being able to dig deeper. | | | Thanks!!! | | | | | | | On Sun, May 13, 2012 at 5:05 PM, Dale Henrichs < [hidden email] | > wrote: | | | Mariano, | | The loadDirectives are actually used for the Metacello load, so you | are getting the load order from the horse's mouth... | | Seaside-Core is one of the first packages that needs to be loaded so | Seaside-Tools-Core should be loaded _after_ Seaside-Core ... | | WARegistry class is in Seaside-Core, but the method WARegistry | class>>#clearAllHandlers is actually in the Seaside-Tools-Core | package (*seaside-tools-core) so everything is consistent... | | | Dale | | ----- Original Message ----- | | From: "Mariano Martinez Peck" < [hidden email] > | | To: [hidden email] | | | | Sent: Sunday, May 13, 2012 6:50:18 AM | | Subject: Re: [Metacello] collecting all packages of a configuration | | | | Hi Dale. For a different purpose, I need again something related to | | this. | | What I actually need is to ask Metacello the list of packages I | | need | | when I do load: xxx SORTED by the load order. I mean, I want they | | to | | be sorted in the way that those that need to be loaded first go | | first. | | | | Take this example. I have download seaside this way: | | | | | | ((Smalltalk at: #ConfigurationOfSeaside30) project version: | | #stable) | | load: #('Base' 'Zinc-Seaside' 'Base Tests' 'RSS-Core' | | 'Javascript-Core' 'Prototype-Core' 'Scriptaculous-Core' | | 'JQuery-Core' 'JQuery-UI' 'Seaside-Email' 'Seaside-HTML5' | | 'Seaside-InternetExplorer' 'Seaside-Examples' 'RSS-Examples' | | 'Seaside-Tools-Web' 'Scriptaculous-Components' 'Seaside-Welcome' | | 'Seaside-FileSystem' 'RSS-Tests-Core' 'Javascript-Tests-Core' | | 'Seaside-Tests-Email' 'Seaside-Tests-Functional' | | 'Prototype-Tests-Core' 'Scriptaculous-Tests-Core' | | 'Scriptaculous-Tests-Components' 'JQuery-Tests-Core' | | 'JQuery-Tests-UI' 'Seaside-Tests-HTML5' | | 'Seaside-Tests-InternetExplorer' 'Seaside-Tests-Examples' | | 'Seaside-Tests-Tools-Web' 'Seaside-Tests-UTF8' | | 'Seaside-Tests-FileSystem' 'Seaside-Tests-Welcome' | | ). | | | | But those pacakages/groups have another dependencies etc etc. So I | | am | | using this to query: | | | | | pkgs loader | | | loader := ((Smalltalk at: #ConfigurationOfSeaside30) project | | version: | | '3.0.6.3') | | ignoreImage: true; | | record: #('Base' 'Zinc-Seaside' 'Base Tests' 'RSS-Core' | | 'Javascript-Core' 'Prototype-Core' 'Scriptaculous-Core' | | 'JQuery-Core' 'JQuery-UI' 'Seaside-Email' 'Seaside-HTML5' | | 'Seaside-InternetExplorer' 'Seaside-Examples' 'RSS-Examples' | | 'Seaside-Tools-Web' 'Scriptaculous-Components' 'Seaside-Welcome' | | 'Seaside-FileSystem' 'RSS-Tests-Core' 'Javascript-Tests-Core' | | 'Seaside-Tests-Email' 'Seaside-Tests-Functional' | | 'Prototype-Tests-Core' 'Scriptaculous-Tests-Core' | | 'Scriptaculous-Tests-Components' 'JQuery-Tests-Core' | | 'JQuery-Tests-UI' 'Seaside-Tests-HTML5' | | 'Seaside-Tests-InternetExplorer' 'Seaside-Tests-Examples' | | 'Seaside-Tests-Tools-Web' 'Seaside-Tests-UTF8' | | 'Seaside-Tests-FileSystem' 'Seaside-Tests-Welcome' | | ). | | pkgs := OrderedCollection new. | | loader loadDirective packageDirectivesDo: [:directive | pkgs add: | | directive spec name ]. | | ^ pkgs | | | | | | It loooks like if that would answer the list of packages in load | | order, but this is not true. If you inspect that, you obtain this: | | | | an OrderedCollection('ConfigurationOfGrease' | | 'ConfigurationOfGrease' | | 'ConfigurationOfSPort2' 'ConfigurationOfZincHTTPComponents' | | 'Grease-Core' 'Grease-Pharo-Core' 'Grease-Core' 'Grease-Pharo-Core' | | 'Grease-Tests-Core' 'Grease-Tests-Pharo-Core' 'Zinc-HTTP' | | 'Seaside-Core' 'Seaside-Pharo-Core' 'Seaside-Component' | | 'Seaside-Canvas' 'Seaside-Pharo-Canvas' 'RSS-Core' | | 'Javascript-Core' | | 'Javascript-Pharo-Core' 'Prototype-Core' 'Scriptaculous-Core' | | 'JQuery-Core' 'JQuery-UI' 'Seaside-Email' 'Seaside-Pharo-Email' | | 'Seaside-HTML5' 'Seaside-InternetExplorer' 'Seaside-Session' | | 'Seaside-RenderLoop' 'Seaside-Tools-Core' 'Seaside-Flow' | | 'Seaside-Examples' 'RSS-Examples' 'Seaside-Widgets' | | 'Seaside-Tools-Web' 'Seaside-Pharo-Tools-Web' 'Seaside-Environment' | | 'Seaside-Pharo-Environment' 'Seaside-Development' | | 'Scriptaculous-Components' 'Zinc-Seaside' 'Seaside-Tests-Core' | | 'Seaside-Tests-Pharo-Core' 'Seaside-Tests-Session' | | 'Seaside-Tests-RenderLoop' 'Seaside-Tests-Component' | | 'Seaside-Tests-Canvas' 'Seaside-Tests-Environment' 'RSS-Tests-Core' | | 'Javascript-Tests-Core' 'Javascript-Tests-Pharo-Core' | | 'Seaside-Tests-Email' 'Seaside-Tests-Functional' | | 'Seaside-Tests-Pharo-Functional' 'Seaside-Tests-Flow' | | 'Seaside-Welcome' 'Seaside-Pharo-Welcome' 'Prototype-Tests-Core' | | 'Scriptaculous-Tests-Core' 'Scriptaculous-Tests-Components' | | 'JQuery-Tests-Core' 'JQuery-Tests-UI' 'Seaside-Tests-HTML5' | | 'Seaside-Tests-InternetExplorer' 'Seaside-Tests-Examples' | | 'Seaside-Tests-Tools-Web' 'Seaside-Tests-UTF8' | | 'Seaside-Tests-Welcome' 'Sport' 'Seaside-FileSystem' | | 'Seaside-Tests-FileSystem' 'Seaside-Pharo-Continuation' | | 'Seaside-Tests-Pharo-Continuation' 'Seaside-Pharo-Flow' | | 'Seaside-Pharo-Development') | | | | As you can see, for example, 'Seaside-Tools-Core' is AFTER | | 'Seaside-Core'. Right? However, for example, WARegistry >> | | #clearAllHandlers (package 'Seaside-Core') has references to | | WAAdmin | | (present in 'Seaside-Tools-Core''). So? is 'Seaside-Tools-Core' | | actually loaded before 'Seaside-Core'? if true, how can I query | | that | | to Metacello. If false, why don't you get the ugly Monticello popup | | saying you that you have dependencies on ... | | | | Thanks! | | | | | | | | | | | | On Mon, Dec 5, 2011 at 6:53 PM, Dale Henrichs < [hidden email] | | > | | wrote: | | | | | | Mariano, | | | | Regarding your complaint about having the OmniBrowser packages show | | up when you are using the #loadDirective based variant. The 'Core' | | group for Seaside includes Seaside-Tools-OmniBrowser, so when you | | load the 'Core' group OmniBrowser is a required package. You are | | sitting in a Pharo image that already has OmniBrowser loaded, so | | when you load Seaside30 you don't see the OB packages getting | | loaded. However, in the #loadDirective variant, you are using | | #ignoreImage: and when Metacello ignores the image, it ignores the | | fact that OB is already loaded as well ... If you want to know what | | would be loaded into the current image, then don't set #ignoreImage | | to true ... the OmniBrowser packages and any other packages that | | are | | already loaded won't show up ... | | | | If there is a set of configs that you would like to | | include/exclude, | | then a more complex load directive algorithm can be used... | | | | Regarding the duplication of packages, I would say that since you | | are | | only interested in the list of packages that would be loaded, you | | can safely ignore the duplicates. | | | | Regarding the inclusion of the ConfigurationOfXXX files, | | technically, | | those files are needed for a load. No version information is | | associated with the configuration file, because config files always | | have their latest available version loaded ... If you want to | | filter | | those files out, then there is a more complex loadDirective | | traversal algorithm you could use, or you can filter out the | | configs | | with #beginsWith:... | | | | | | Dale | | | | ----- Original Message ----- | | | | | From: "Mariano Martinez Peck" < [hidden email] > | | | To: [hidden email] | | | Sent: Saturday, December 3, 2011 4:27:13 PM | | | | | | | Subject: Re: [Metacello] collecting all packages of a | | | configuration | | | | | | | | | | | | | | | On Thu, Nov 17, 2011 at 6:57 PM, Dale Henrichs < | | | [hidden email] | | | > wrote: | | | | | | | | | Jannik, | | | | | | There are two routes you can take to answer your question. | | | Firstly, | | | you can directly query the version itself: | | | | | | ((ConfigurationOfMetacello project currentVersion) | | | allPackagesForSpecNamed: 'ALL') | | | collect: [:spec | spec file ]. | | | | | | Or you can use #record: and then collect the information you | | | want: | | | | | | | pkgs loader | | | | loader := (ConfigurationOfMetacello project currentVersion) | | | ignoreImage: true; | | | record: 'ALL'. | | | pkgs := OrderedCollection new. | | | loader loadDirective packageDirectivesDo: [:directive |pkgs add: | | | directive spec file ]. | | | pkgs. | | | | | | | | | | | | Hi Dale. I have notice that both ways are different. For example, | | | the | | | first one does not take into account those ConfigurationOfXXX | | | packages, whereas the second one does. Moreoever, in the second | | | one, | | | I see that there are repetitions. For example: | | | | | | | pkgs loader | | | | loader := ((Smalltalk at: #ConfigurationOfSeaside30) project | | | version: | | | ' 3.0.6.3 ') | | | ignoreImage: true; | | | record: #('Core' 'Tests' 'Zinc-Seaside' ). | | | pkgs := OrderedCollection new. | | | loader loadDirective packageDirectivesDo: [:directive |pkgs add: | | | directive spec file ]. | | | pkgs. | | | | | | size gives me 127, but asSet size, 106. It seems some packages | | | appear | | | more than once like ConfigurationOfGrease. | | | | | | ConfigurationOfXXX do not have version number in their name, but | | | the | | | rest do have. | | | | | | Now, the main problem is that none of them is what I need: I need | | | ALL | | | the required packages that are needed to load such project with | | | metacello. I want to capture the exact list of packages needed | | | when | | | I do, for example: | | | ((Smalltalk at: #ConfigurationOfSeaside30) project version: | | | ' 3.0.6.3 ') | | | load: #('Core' 'Tests' 'Zinc-Seaside' ). | | | | | | The first one doesn't even take into account ConfigurationOfXX, | | | so | | | it | | | doesn't help me. The second one, not only has repetitions, but | | | also | | | it lists packages that I really don't need. For example, | | | OB-Morphic-lr.164 and Seaside-Tools-OmniBrowser-lr.25. I don't | | | understand how those packages arrived to the list. If I take a | | | clean | | | image, and install Seaside with the way I showed you, those | | | packages | | | are not even downloaded. So why do they appear here? | | | | | | So...all in all, what I need is a list of the exact packages I | | | need | | | to reproduce something I have loaded with Metacello. In other | | | words, | | | if I start an image with an empty package-cache, and execute the | | | load of seaside, how can I know the list of packages that were | | | downloaded? of course, not inspecting the package-cache ;) | | | | | | Thanks in advance Dale!!! | | | | | | | | | | | | | | | Dale | | | | | | | | | | | | ----- Original Message ----- | | | | From: "jannik.laval" < [hidden email] > | | | | To: [hidden email] | | | | Sent: Thursday, November 17, 2011 5:11:09 AM | | | | Subject: [Metacello] collecting all packages of a configuration | | | | | | | | | | | | | | | | | | | | | | | | Hi guys, | | | | | | | | | | | | With mariano, we had a discussion about a problem I have: | | | | How can I collect all packages from a configuration with | | | | resolving | | | | all sub projects ? | | | | | | | | | | | | Thank you for your help. | | | | Cheers, | | | | Jannik | | | | | | | | | | | | | | | | Begin forwarded message: | | | | | | | | | | | | | | | | From: Mariano Martinez Peck < [hidden email] > | | | | | | | | Subject: Re: Metacello question | | | | | | | | Date: November 16, 2011 4:09:38 PM GMT+01:00 | | | | | | | | To: "jannik.laval" < [hidden email] > | | | | | | | | | | | | | | | | | | | | On Wed, Nov 16, 2011 at 11:57 AM, jannik.laval < | | | | [hidden email] > wrote: | | | | | | | | | | | | | | | | | | | | Hi Mariano, | | | | | | | | | | | | I understand your code and It seems to be the same as mine. | | | | version40 make the same as "project version: '4.0'". | | | | | | | | | | | | The problem is the resolution of internal projects. | | | | We should collect the methods recursively... and possibly with | | | | circular dependencies. | | | | So, Metacello can resolve them, but I do not know Metacello :( | | | | | | | | | | | | | | | | | | | | I have no idea :( | | | | Ask in metacello mailing list: [hidden email] , | | | | | | | | good luck | | | | | | | | | | | | | | | | | | | | | | | | Jannik | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Nov 16, 2011, at 15:36 , Mariano Martinez Peck wrote: | | | | | | | | | | | | | | | | | | | | | | | | On Wed, Nov 16, 2011 at 6:59 AM, jannik.laval < | | | | [hidden email] > wrote: | | | | | | | | | | | | Hi Mariano, | | | | How are you ? | | | | Here, at Bordeaux, I am fine, and all the family too :) | | | | | | | | | | | | | | | | Excellent, nice to hear that :) | | | | I am in Argentina in holidays (after Smalltalks) and all | | | | familiy | | | | good | | | | as well hahahahah | | | | | | | | | | | | | | | | I have a question about Metacello, and you know well Metacello | | | | :) | | | | I would like to collect all the files to load of a | | | | Configuration | | | | with | | | | all dependencies already resolved. | | | | | | | | For now, I have this code in a transcript: | | | | === | | | | ConfigurationOfMoose version40 spec packages map select:[:e | e | | | | isKindOf: MetacelloPackageSpec ] | | | | thenCollect: [:e | e repositories list isEmpty | | | | ifTrue: [e file] | | | | ifFalse: [e repositories list first name, '/' , e file]]. | | | | === | | | | It allows me to have all files in ConfigurationOfMoose, but I | | | | have | | | | two problems: | | | | | | | | - if I change version40 by version42, I have no more the name | | | | of | | | | packages. | | | | Here is an example: | | | | with version40, the first value of my collection is: ' | | | | http://www.squeaksource.com/Arki/Arki-Reporter-tg.3 ' | | | | with version42, it is: ' | | | | http://www.squeaksource.com/Arki/Arki-Reporter-Browser ' | | | | ==> I have no more the versions to load. | | | | | | | | | | | | | | | | (ConfigurationOfMoose project version: '4.0') packages collect: | | | | [ | | | | :each | each name ] as: Set. | | | | | | | | or .. | | | | | | | | (ConfigurationOfMoose project version: '4.2') packages collect: | | | | [ | | | | :each | each name ] as: Set. | | | | | | | | does that help ? | | | | | | | | | | | | | | | | - the second problem is about depending project. Moose load | | | | other | | | | projects, and there are some cyclic dependencies between the | | | | loads: | | | | for example DSM needs Moose, and Moose loads DSM..... | | | | I know that Metacello resolves this kind of problems. | | | | | | | | So, my question is: is it possible to obtain a list of all | | | | packages | | | | of a configuration ? | | | | | | | | Thank you | | | | --- | | | | Jannik Laval | | | | | | | | | | | | | | | | | | | | -- | | | | Mariano | | | | http://marianopeck.wordpress.com | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --- | | | | Jannik Laval | | | | | | | | | | | | | | | | -- | | | | Mariano | | | | http://marianopeck.wordpress.com | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --- | | | | Jannik Laval | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --- | | | | Jannik Laval | | | | | | | | | | | | | | | | -- | | | Mariano | | | http://marianopeck.wordpress.com | | | | | | | | | | | | | | -- | | Mariano | | http://marianopeck.wordpress.com | | | | | | | | | -- | Mariano | http://marianopeck.wordpress.com | | |
Re: collecting all packages of a configuration
|
Administrator
|
+1. This sounds to me like http://code.google.com/p/pharo/issues/detail?id=6461 Try loading in #20232 to confirm... Sean
Cheers,
Sean |
Re: collecting all packages of a configuration
|
|
In reply to this post by Dale Henrichs
On Thu, Aug 2, 2012 at 8:46 PM, Dale Henrichs <[hidden email]> wrote: Mariano, mmmm I have been using Metacello in Pharo 2.0 from the very beginning and it always worked (there was one small problem about MCCacheRepository uniqueInstance but that's all I have seen)
In my experience trying to use pharo-2.0, the system is hosed when that "unsaved changes dialog" pops up. If the system were functioning correctly you wouldn't get a message about dirty packages. The package is being freshly loaded (in my cases) so there should be no dirty package warning ... once you can't trust the uderlying system... I have just reproduced the problem in latest Pharo 1.4. Following exactly the same steps mentioned there. 'Collections-BitmapCharacterSet' or 'Collections-OrderPreservingDictionary' are not listed but indeed are LOADED.
Thanks Dale. I don't like having to say this, but I've "wasted" time several times in the past month giving Pharo-2.0 a go and attempting to debug the problems (assuming that I needed to make changes to work in Pharo-2.0) and each time it was some nasty little bug in the base. Mariano http://marianopeck.wordpress.com |
Re: collecting all packages of a configuration
|
|
In reply to this post by Sean P. DeNigris
Issue 6295[2] was the first bug that shut me down and then when I went to try loading Metacello again (with a new vm) I hit Issue 6336[1] so I have yet to validate whether Issue 6295 is fixed or not (the resolution comment is not confidence inspiring)....
Sean hit Issue 6461[3] a week ago and it is still open... Mariano, you hit 6336 a couple of days ago (I just reopened it). And now you've hit another issue that smells an awful lot like the other two issues ... that are still unresolved So, right now it seems that there are some serious Pharo-2.0 issues with package loading independent of Metacello. As I said, I'll patiently wait until the base system stabilizes a bit more before taking a chance that the load might work and that I might get a chance to run my unit tests ... BTW, does anyone know if the Metacello unit tests are run by the Jenkins server against 2.0? Dale [1] http://code.google.com/p/pharo/issues/detail?id=6336 [2] http://code.google.com/p/pharo/issues/detail?id=6295 [3] http://code.google.com/p/pharo/issues/detail?id=6461 ----- Original Message ----- | From: "Sean P. DeNigris" <[hidden email]> | To: [hidden email] | Sent: Thursday, August 2, 2012 1:35:08 PM | Subject: [Metacello] Re: collecting all packages of a configuration | | | Dale Henrichs wrote | > | > I assume that the issue is a problem in Pharo-2.0. | | +1. This sounds to me like | http://code.google.com/p/pharo/issues/detail?id=6461 | | Try loading in #20232 to confirm... | | Sean | | | | -- | View this message in context: | http://forum.world.st/collecting-all-packages-of-a-configuration-tp4079913p4642748.html | Sent from the Metacello mailing list archive at Nabble.com. | |
Re: collecting all packages of a configuration
|
|
On Thu, Aug 2, 2012 at 11:00 PM, Dale Henrichs <[hidden email]> wrote: Issue 6295[2] was the first bug that shut me down and then when I went to try loading Metacello again (with a new vm) I hit Issue 6336[1] so I have yet to validate whether Issue 6295 is fixed or not (the resolution comment is not confidence inspiring).... Ok, those 2 were fixed. Sean hit Issue 6461[3] a week ago and it is still open... I have just reproduce it. Ok, maybe I don't use too much the MC browser...that's why metacello was "always working" for me hahha. Mariano, you hit 6336 a couple of days ago (I just reopened it). I just close it because I cannot reproduce it anymore y latest images. And now you've hit another issue that smells an awful lot like the other two issues ... that are still unresolved Well, my previous answer was later than your response....the problem I have reported here also happens in 1.4. So, right now it seems that there are some serious Pharo-2.0 issues with package loading independent of Metacello. indeed. The only pending one is http://code.google.com/p/pharo/issues/detail?id=6461 As I said, I'll patiently wait until the base system stabilizes a bit more before taking a chance that the load might work and that I might get a chance to run my unit tests ... no, because it is not included by default. However, we can create a job for Metacello in 5 minutes. I think it is worth. Do you want us to do it? Thanks!
Dale Mariano http://marianopeck.wordpress.com |
Re: collecting all packages of a configuration
|
|
In reply to this post by Dale Henrichs
On Thu, Aug 2, 2012 at 11:00 PM, Dale Henrichs <[hidden email]> wrote: Issue 6295[2] was the first bug that shut me down and then when I went to try loading Metacello again (with a new vm) I hit Issue 6336[1] so I have yet to validate whether Issue 6295 is fixed or not (the resolution comment is not confidence inspiring).... This week, SystemChangeNotifier was removed. If you just change its references to SystemAnnouncer in Metacello, I got the following (using last Metacello version) 678 run, 667 passes, 0 expected failures, 0 failures, 11 errors, 0 unexpected passes Failures: Errors: MetacelloDevelopmentCycleTutorialTests>>#testCreateNewBaseline
MetacelloDevelopmentCycleTutorialTests>>#testCreateNewBaseline MetacelloDevelopmentCycleTutorialTests>>#testCreateNewDevelopment MetacelloDevelopmentCycleTutorialTests>>#testCreateNewDevelopment
MetacelloDevelopmentCycleTutorialTests>>#testReleaseDevelopment MetacelloDevelopmentCycleTutorialTests>>#testReleaseDevelopment MetacelloDevelopmentCycleTutorialTests>>#testValidateAndSave
MetacelloDevelopmentCycleTutorialTests>>#testValidateAndSave MetacelloInsideToolBoxTutorialTests>>#testExamples MetacelloIssue136TestCase>>#testCachedIssue136 MetacelloIssue136TestCase>>#testIssue136
BTW, does anyone know if the Metacello unit tests are run by the Jenkins server against 2.0? Mariano http://marianopeck.wordpress.com |
Re: collecting all packages of a configuration
|
|
In reply to this post by Mariano Martinez Peck
Mariano,
I appreciate the fact that pharo-2.0 needs to do what it is doing to build the great thing that is building, but I have not been able to load my Metacello development environment into Pharo-2.0 every time I tried this month. When something hurts every time you do it, you become gun shy. This morning I get to hear the FileTree is completely broken on Pharo-2.0 because FileDirectory has been deleted from the system ... guess what, I use FileTree on a daily basis and FileTree is used as the repository of record for Metacello, so as of this morning I cannot begin to even load my development environment into Pharo-2.0...and will not be able to that until FileTree is "rewritten to run without FileDirectory"... I am very glad that the old version of Metacello is working for you. But for me I cannot base my development on Pharo2.0 because I will spend all of my time dealing with the changes as the system is moved out from under me ... Don't get me wrong, Pharo-2.0 is a project that is worth doing and the pain and agony is necessary, but I prefer to take my pain and agony in one lump sum and not on a daily basis, so I choose to wait until the rate of change in Pharo-2.0 settles down to a low roar before getting my Metacello development environment running on Pharo-2.0 ... Do you now understand why I might be skeptical of bugs reported against Pharo-2.0? I see in a later email that you were able to reproduce the issue in Pharo-1.4 so I won't have to port FileTree to Pharo-2.0 before looking into your problem... Dale ----- Original Message ----- | From: "Mariano Martinez Peck" <[hidden email]> | To: [hidden email] | Sent: Thursday, August 2, 2012 1:57:31 PM | Subject: Re: [Metacello] collecting all packages of a configuration | | | | | On Thu, Aug 2, 2012 at 8:46 PM, Dale Henrichs < [hidden email] > | wrote: | | | Mariano, | | To be frank, when it comes to Pharo-2.0 at this point in time, I | assume that the issue is a problem in Pharo-2.0. | | I haven't been able to load Metacello into Pharo-2.0 for about a | month, so I haven't been able to use Pharo-2.0 myself ... I'm | somewhat surprised that folks are able to get work done ... I just | assume they don't use Metacello that much:) | | | | | mmmm I have been using Metacello in Pharo 2.0 from the very beginning | and it always worked (there was one small problem about | MCCacheRepository uniqueInstance but that's all I have seen) | | | | | In my experience trying to use pharo-2.0, the system is hosed when | that "unsaved changes dialog" pops up. If the system were | functioning correctly you wouldn't get a message about dirty | packages. The package is being freshly loaded (in my cases) so there | should be no dirty package warning ... once you can't trust the | uderlying system... | | If you can reproduce the problem in Pharo1.4 or Pharo1.3 or squeak4.3 | or gemstone, I will be glad to try to fix the problem. | | | | | I have just reproduced the problem in latest Pharo 1.4. Following | exactly the same steps mentioned there. | 'Collections-BitmapCharacterSet' or | 'Collections-OrderPreservingDictionary' are not listed but indeed | are LOADED. | | | Thanks Dale. | | | | | I don't like having to say this, but I've "wasted" time several times | in the past month giving Pharo-2.0 a go and attempting to debug the | problems (assuming that I needed to make changes to work in | Pharo-2.0) and each time it was some nasty little bug in the base. | | From my perspective I don't really know if Metacello is working on | Pharo-2.0 or not and I'm waiting for Pharo-2.0 to stabilize before | trying again. | | | Dale | | | ----- Original Message ----- | | From: "Mariano Martinez Peck" < [hidden email] > | | To: [hidden email] | | | | Sent: Thursday, August 2, 2012 9:56:40 AM | | Subject: Re: [Metacello] collecting all packages of a configuration | | | | Hi Dale. I find myself again, trying to collect the packages loaded | | (and their order). There is something that does not work and I | | cannot figure out what is happening. At least, it is reproducible | | ;) | | | | | | I took the last Pharo 2.0 available from Jenkins, and I install | | seaside and pier as following: | | | | | | | | Gofer it | | squeaksource: 'MetacelloRepository'; | | package: 'ConfigurationOfSeaside30'; | | load. | | | | | | ((Smalltalk at: #ConfigurationOfSeaside30) project version: | | #stable) | | load: #('Base' 'Zinc-Seaside' 'Base Tests' 'RSS-Core' | | 'Javascript-Core' 'Prototype-Core' 'Scriptaculous-Core' | | 'JQuery-Core' 'JQuery-UI' 'Seaside-Email' 'Seaside-HTML5' | | 'Seaside-InternetExplorer' 'Seaside-Examples' 'RSS-Examples' | | 'Seaside-Tools-Web' 'Scriptaculous-Components' 'Seaside-Welcome' | | 'Seaside-FileSystem' 'RSS-Tests-Core' 'Javascript-Tests-Core' | | 'Seaside-Tests-Email' 'Seaside-Tests-Functional' | | 'Prototype-Tests-Core' 'Scriptaculous-Tests-Core' | | 'Scriptaculous-Tests-Components' 'JQuery-Tests-Core' | | 'JQuery-Tests-UI' 'Seaside-Tests-HTML5' | | 'Seaside-Tests-InternetExplorer' 'Seaside-Tests-Examples' | | 'Seaside-Tests-Tools-Web' 'Seaside-Tests-UTF8' | | 'Seaside-Tests-FileSystem' 'Seaside-Tests-Welcome'). | | | | Gofer it | | squeaksource: 'MetacelloRepository'; | | package: 'ConfigurationOfPier2'; | | load. | | | | | | ((Smalltalk at: #ConfigurationOfPier2) project version: #stable) | | load. | | | | | | | | | | Gofer it | | squeaksource: 'MetacelloRepository'; | | package: 'ConfigurationOfPierAddOns2'; | | load. | | | | | | | | | | | | ((Smalltalk at: #ConfigurationOfPierAddOns2) project version: | | #stable) load: #('default' 'Pier-Shout' 'Pier-Design' ). | | | | | | | | | | Now...while loading that, I have an popup saying I am about to load | | a | | new version of XML-Parser (see attachment). Ok, I say "load" and | | everything loads fine after. | | | | | | The problem is that if now I ask Metacello the loaded packages: | | | | | | | | | | | | | | >> packagesFromConf: confName version: versionString loading: | | >> packageOrGroups | | | loader pkgs | | | | | loader := ((Smalltalk at: confName asSymbol) project version: | | versionString) | | ignoreImage: true; | | record: packageOrGroups. | | pkgs := OrderedCollection new. | | loader loadDirective packageDirectivesDo: [:directive | pkgs add: | | directive spec name ]. | | ^ pkgs | | | | | | | | | | >> seasidePackages | | | packages loader | | | packages := OrderedCollection new. | | packages addAll: (self packagesFromConf: #ConfigurationOfSeaside30 | | version: #stable loading: #('Base' 'Zinc-Seaside' 'Base Tests' | | 'RSS-Core' 'Javascript-Core' 'Prototype-Core' 'Scriptaculous-Core' | | 'JQuery-Core' 'JQuery-UI' 'Seaside-Email' 'Seaside-HTML5' | | 'Seaside-InternetExplorer' 'Seaside-Examples' 'RSS-Examples' | | 'Seaside-Tools-Web' 'Scriptaculous-Components' 'Seaside-Welcome' | | 'Seaside-FileSystem' 'RSS-Tests-Core' 'Javascript-Tests-Core' | | 'Seaside-Tests-Email' 'Seaside-Tests-Functional' | | 'Prototype-Tests-Core' 'Scriptaculous-Tests-Core' | | 'Scriptaculous-Tests-Components' 'JQuery-Tests-Core' | | 'JQuery-Tests-UI' 'Seaside-Tests-HTML5' | | 'Seaside-Tests-InternetExplorer' 'Seaside-Tests-Examples' | | 'Seaside-Tests-Tools-Web' 'Seaside-Tests-UTF8' | | 'Seaside-Tests-FileSystem' 'Seaside-Tests-Welcome' | | )). | | | | | | packages addAll: (self packagesFromConf: #ConfigurationOfPier2 | | version: #stable loading: #('default')). | | packages addAll: (self packagesFromConf: | | #ConfigurationOfPierAddOns2 | | version: #stable loading: #('default' 'Pier-Shout' 'Pier-Design' | | )). | | packages addAll: #('Pier-FuelPersistence-Core' | | 'Pier-FuelPersistence-Test'). | | | | packages := packages removeDuplicates. | | | | ^ packages | | | | | | | | | | | | | | | | There are some packages that do not appear, like | | 'Collections-BitmapCharacterSet' or | | 'Collections-OrderPreservingDictionary', which are needed by | | ConfigurationOfXMLSupport . And....this is related to the error I | | got popup (saying I was loading a new version) | | | | | | So...all in all, do you have something in mind that could be | | happening? Sorry for not being able to dig deeper. | | | | | | Thanks!!! | | | | | | | | | | | | | | On Sun, May 13, 2012 at 5:05 PM, Dale Henrichs < | | [hidden email] | | > wrote: | | | | | | Mariano, | | | | The loadDirectives are actually used for the Metacello load, so you | | are getting the load order from the horse's mouth... | | | | Seaside-Core is one of the first packages that needs to be loaded | | so | | Seaside-Tools-Core should be loaded _after_ Seaside-Core ... | | | | WARegistry class is in Seaside-Core, but the method WARegistry | | class>>#clearAllHandlers is actually in the Seaside-Tools-Core | | package (*seaside-tools-core) so everything is consistent... | | | | | | Dale | | | | ----- Original Message ----- | | | From: "Mariano Martinez Peck" < [hidden email] > | | | To: [hidden email] | | | | | | | Sent: Sunday, May 13, 2012 6:50:18 AM | | | Subject: Re: [Metacello] collecting all packages of a | | | configuration | | | | | | Hi Dale. For a different purpose, I need again something related | | | to | | | this. | | | What I actually need is to ask Metacello the list of packages I | | | need | | | when I do load: xxx SORTED by the load order. I mean, I want they | | | to | | | be sorted in the way that those that need to be loaded first go | | | first. | | | | | | Take this example. I have download seaside this way: | | | | | | | | | ((Smalltalk at: #ConfigurationOfSeaside30) project version: | | | #stable) | | | load: #('Base' 'Zinc-Seaside' 'Base Tests' 'RSS-Core' | | | 'Javascript-Core' 'Prototype-Core' 'Scriptaculous-Core' | | | 'JQuery-Core' 'JQuery-UI' 'Seaside-Email' 'Seaside-HTML5' | | | 'Seaside-InternetExplorer' 'Seaside-Examples' 'RSS-Examples' | | | 'Seaside-Tools-Web' 'Scriptaculous-Components' 'Seaside-Welcome' | | | 'Seaside-FileSystem' 'RSS-Tests-Core' 'Javascript-Tests-Core' | | | 'Seaside-Tests-Email' 'Seaside-Tests-Functional' | | | 'Prototype-Tests-Core' 'Scriptaculous-Tests-Core' | | | 'Scriptaculous-Tests-Components' 'JQuery-Tests-Core' | | | 'JQuery-Tests-UI' 'Seaside-Tests-HTML5' | | | 'Seaside-Tests-InternetExplorer' 'Seaside-Tests-Examples' | | | 'Seaside-Tests-Tools-Web' 'Seaside-Tests-UTF8' | | | 'Seaside-Tests-FileSystem' 'Seaside-Tests-Welcome' | | | ). | | | | | | But those pacakages/groups have another dependencies etc etc. So | | | I | | | am | | | using this to query: | | | | | | | pkgs loader | | | | loader := ((Smalltalk at: #ConfigurationOfSeaside30) project | | | version: | | | '3.0.6.3') | | | ignoreImage: true; | | | record: #('Base' 'Zinc-Seaside' 'Base Tests' 'RSS-Core' | | | 'Javascript-Core' 'Prototype-Core' 'Scriptaculous-Core' | | | 'JQuery-Core' 'JQuery-UI' 'Seaside-Email' 'Seaside-HTML5' | | | 'Seaside-InternetExplorer' 'Seaside-Examples' 'RSS-Examples' | | | 'Seaside-Tools-Web' 'Scriptaculous-Components' 'Seaside-Welcome' | | | 'Seaside-FileSystem' 'RSS-Tests-Core' 'Javascript-Tests-Core' | | | 'Seaside-Tests-Email' 'Seaside-Tests-Functional' | | | 'Prototype-Tests-Core' 'Scriptaculous-Tests-Core' | | | 'Scriptaculous-Tests-Components' 'JQuery-Tests-Core' | | | 'JQuery-Tests-UI' 'Seaside-Tests-HTML5' | | | 'Seaside-Tests-InternetExplorer' 'Seaside-Tests-Examples' | | | 'Seaside-Tests-Tools-Web' 'Seaside-Tests-UTF8' | | | 'Seaside-Tests-FileSystem' 'Seaside-Tests-Welcome' | | | ). | | | pkgs := OrderedCollection new. | | | loader loadDirective packageDirectivesDo: [:directive | pkgs add: | | | directive spec name ]. | | | ^ pkgs | | | | | | | | | It loooks like if that would answer the list of packages in load | | | order, but this is not true. If you inspect that, you obtain | | | this: | | | | | | an OrderedCollection('ConfigurationOfGrease' | | | 'ConfigurationOfGrease' | | | 'ConfigurationOfSPort2' 'ConfigurationOfZincHTTPComponents' | | | 'Grease-Core' 'Grease-Pharo-Core' 'Grease-Core' | | | 'Grease-Pharo-Core' | | | 'Grease-Tests-Core' 'Grease-Tests-Pharo-Core' 'Zinc-HTTP' | | | 'Seaside-Core' 'Seaside-Pharo-Core' 'Seaside-Component' | | | 'Seaside-Canvas' 'Seaside-Pharo-Canvas' 'RSS-Core' | | | 'Javascript-Core' | | | 'Javascript-Pharo-Core' 'Prototype-Core' 'Scriptaculous-Core' | | | 'JQuery-Core' 'JQuery-UI' 'Seaside-Email' 'Seaside-Pharo-Email' | | | 'Seaside-HTML5' 'Seaside-InternetExplorer' 'Seaside-Session' | | | 'Seaside-RenderLoop' 'Seaside-Tools-Core' 'Seaside-Flow' | | | 'Seaside-Examples' 'RSS-Examples' 'Seaside-Widgets' | | | 'Seaside-Tools-Web' 'Seaside-Pharo-Tools-Web' | | | 'Seaside-Environment' | | | 'Seaside-Pharo-Environment' 'Seaside-Development' | | | 'Scriptaculous-Components' 'Zinc-Seaside' 'Seaside-Tests-Core' | | | 'Seaside-Tests-Pharo-Core' 'Seaside-Tests-Session' | | | 'Seaside-Tests-RenderLoop' 'Seaside-Tests-Component' | | | 'Seaside-Tests-Canvas' 'Seaside-Tests-Environment' | | | 'RSS-Tests-Core' | | | 'Javascript-Tests-Core' 'Javascript-Tests-Pharo-Core' | | | 'Seaside-Tests-Email' 'Seaside-Tests-Functional' | | | 'Seaside-Tests-Pharo-Functional' 'Seaside-Tests-Flow' | | | 'Seaside-Welcome' 'Seaside-Pharo-Welcome' 'Prototype-Tests-Core' | | | 'Scriptaculous-Tests-Core' 'Scriptaculous-Tests-Components' | | | 'JQuery-Tests-Core' 'JQuery-Tests-UI' 'Seaside-Tests-HTML5' | | | 'Seaside-Tests-InternetExplorer' 'Seaside-Tests-Examples' | | | 'Seaside-Tests-Tools-Web' 'Seaside-Tests-UTF8' | | | 'Seaside-Tests-Welcome' 'Sport' 'Seaside-FileSystem' | | | 'Seaside-Tests-FileSystem' 'Seaside-Pharo-Continuation' | | | 'Seaside-Tests-Pharo-Continuation' 'Seaside-Pharo-Flow' | | | 'Seaside-Pharo-Development') | | | | | | As you can see, for example, 'Seaside-Tools-Core' is AFTER | | | 'Seaside-Core'. Right? However, for example, WARegistry >> | | | #clearAllHandlers (package 'Seaside-Core') has references to | | | WAAdmin | | | (present in 'Seaside-Tools-Core''). So? is 'Seaside-Tools-Core' | | | actually loaded before 'Seaside-Core'? if true, how can I query | | | that | | | to Metacello. If false, why don't you get the ugly Monticello | | | popup | | | saying you that you have dependencies on ... | | | | | | Thanks! | | | | | | | | | | | | | | | | | | On Mon, Dec 5, 2011 at 6:53 PM, Dale Henrichs < | | | [hidden email] | | | > | | | wrote: | | | | | | | | | Mariano, | | | | | | Regarding your complaint about having the OmniBrowser packages | | | show | | | up when you are using the #loadDirective based variant. The | | | 'Core' | | | group for Seaside includes Seaside-Tools-OmniBrowser, so when you | | | load the 'Core' group OmniBrowser is a required package. You are | | | sitting in a Pharo image that already has OmniBrowser loaded, so | | | when you load Seaside30 you don't see the OB packages getting | | | loaded. However, in the #loadDirective variant, you are using | | | #ignoreImage: and when Metacello ignores the image, it ignores | | | the | | | fact that OB is already loaded as well ... If you want to know | | | what | | | would be loaded into the current image, then don't set | | | #ignoreImage | | | to true ... the OmniBrowser packages and any other packages that | | | are | | | already loaded won't show up ... | | | | | | If there is a set of configs that you would like to | | | include/exclude, | | | then a more complex load directive algorithm can be used... | | | | | | Regarding the duplication of packages, I would say that since you | | | are | | | only interested in the list of packages that would be loaded, you | | | can safely ignore the duplicates. | | | | | | Regarding the inclusion of the ConfigurationOfXXX files, | | | technically, | | | those files are needed for a load. No version information is | | | associated with the configuration file, because config files | | | always | | | have their latest available version loaded ... If you want to | | | filter | | | those files out, then there is a more complex loadDirective | | | traversal algorithm you could use, or you can filter out the | | | configs | | | with #beginsWith:... | | | | | | | | | Dale | | | | | | ----- Original Message ----- | | | | | | | From: "Mariano Martinez Peck" < [hidden email] > | | | | To: [hidden email] | | | | Sent: Saturday, December 3, 2011 4:27:13 PM | | | | | | | | | | Subject: Re: [Metacello] collecting all packages of a | | | | configuration | | | | | | | | | | | | | | | | | | | | On Thu, Nov 17, 2011 at 6:57 PM, Dale Henrichs < | | | | [hidden email] | | | | > wrote: | | | | | | | | | | | | Jannik, | | | | | | | | There are two routes you can take to answer your question. | | | | Firstly, | | | | you can directly query the version itself: | | | | | | | | ((ConfigurationOfMetacello project currentVersion) | | | | allPackagesForSpecNamed: 'ALL') | | | | collect: [:spec | spec file ]. | | | | | | | | Or you can use #record: and then collect the information you | | | | want: | | | | | | | | | pkgs loader | | | | | loader := (ConfigurationOfMetacello project currentVersion) | | | | ignoreImage: true; | | | | record: 'ALL'. | | | | pkgs := OrderedCollection new. | | | | loader loadDirective packageDirectivesDo: [:directive |pkgs | | | | add: | | | | directive spec file ]. | | | | pkgs. | | | | | | | | | | | | | | | | Hi Dale. I have notice that both ways are different. For | | | | example, | | | | the | | | | first one does not take into account those ConfigurationOfXXX | | | | packages, whereas the second one does. Moreoever, in the second | | | | one, | | | | I see that there are repetitions. For example: | | | | | | | | | pkgs loader | | | | | loader := ((Smalltalk at: #ConfigurationOfSeaside30) project | | | | version: | | | | ' 3.0.6.3 ') | | | | ignoreImage: true; | | | | record: #('Core' 'Tests' 'Zinc-Seaside' ). | | | | pkgs := OrderedCollection new. | | | | loader loadDirective packageDirectivesDo: [:directive |pkgs | | | | add: | | | | directive spec file ]. | | | | pkgs. | | | | | | | | size gives me 127, but asSet size, 106. It seems some packages | | | | appear | | | | more than once like ConfigurationOfGrease. | | | | | | | | ConfigurationOfXXX do not have version number in their name, | | | | but | | | | the | | | | rest do have. | | | | | | | | Now, the main problem is that none of them is what I need: I | | | | need | | | | ALL | | | | the required packages that are needed to load such project with | | | | metacello. I want to capture the exact list of packages needed | | | | when | | | | I do, for example: | | | | ((Smalltalk at: #ConfigurationOfSeaside30) project version: | | | | ' 3.0.6.3 ') | | | | load: #('Core' 'Tests' 'Zinc-Seaside' ). | | | | | | | | The first one doesn't even take into account ConfigurationOfXX, | | | | so | | | | it | | | | doesn't help me. The second one, not only has repetitions, but | | | | also | | | | it lists packages that I really don't need. For example, | | | | OB-Morphic-lr.164 and Seaside-Tools-OmniBrowser-lr.25. I don't | | | | understand how those packages arrived to the list. If I take a | | | | clean | | | | image, and install Seaside with the way I showed you, those | | | | packages | | | | are not even downloaded. So why do they appear here? | | | | | | | | So...all in all, what I need is a list of the exact packages I | | | | need | | | | to reproduce something I have loaded with Metacello. In other | | | | words, | | | | if I start an image with an empty package-cache, and execute | | | | the | | | | load of seaside, how can I know the list of packages that were | | | | downloaded? of course, not inspecting the package-cache ;) | | | | | | | | Thanks in advance Dale!!! | | | | | | | | | | | | | | | | | | | | Dale | | | | | | | | | | | | | | | | ----- Original Message ----- | | | | | From: "jannik.laval" < [hidden email] > | | | | | To: [hidden email] | | | | | Sent: Thursday, November 17, 2011 5:11:09 AM | | | | | Subject: [Metacello] collecting all packages of a | | | | | configuration | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hi guys, | | | | | | | | | | | | | | | With mariano, we had a discussion about a problem I have: | | | | | How can I collect all packages from a configuration with | | | | | resolving | | | | | all sub projects ? | | | | | | | | | | | | | | | Thank you for your help. | | | | | Cheers, | | | | | Jannik | | | | | | | | | | | | | | | | | | | | Begin forwarded message: | | | | | | | | | | | | | | | | | | | | From: Mariano Martinez Peck < [hidden email] > | | | | | | | | | | Subject: Re: Metacello question | | | | | | | | | | Date: November 16, 2011 4:09:38 PM GMT+01:00 | | | | | | | | | | To: "jannik.laval" < [hidden email] > | | | | | | | | | | | | | | | | | | | | | | | | | On Wed, Nov 16, 2011 at 11:57 AM, jannik.laval < | | | | | [hidden email] > wrote: | | | | | | | | | | | | | | | | | | | | | | | | | Hi Mariano, | | | | | | | | | | | | | | | I understand your code and It seems to be the same as mine. | | | | | version40 make the same as "project version: '4.0'". | | | | | | | | | | | | | | | The problem is the resolution of internal projects. | | | | | We should collect the methods recursively... and possibly | | | | | with | | | | | circular dependencies. | | | | | So, Metacello can resolve them, but I do not know Metacello | | | | | :( | | | | | | | | | | | | | | | | | | | | | | | | | I have no idea :( | | | | | Ask in metacello mailing list: [hidden email] , | | | | | | | | | | good luck | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Jannik | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Nov 16, 2011, at 15:36 , Mariano Martinez Peck wrote: | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Wed, Nov 16, 2011 at 6:59 AM, jannik.laval < | | | | | [hidden email] > wrote: | | | | | | | | | | | | | | | Hi Mariano, | | | | | How are you ? | | | | | Here, at Bordeaux, I am fine, and all the family too :) | | | | | | | | | | | | | | | | | | | | Excellent, nice to hear that :) | | | | | I am in Argentina in holidays (after Smalltalks) and all | | | | | familiy | | | | | good | | | | | as well hahahahah | | | | | | | | | | | | | | | | | | | | I have a question about Metacello, and you know well | | | | | Metacello | | | | | :) | | | | | I would like to collect all the files to load of a | | | | | Configuration | | | | | with | | | | | all dependencies already resolved. | | | | | | | | | | For now, I have this code in a transcript: | | | | | === | | | | | ConfigurationOfMoose version40 spec packages map select:[:e | | | | | | e | | | | | isKindOf: MetacelloPackageSpec ] | | | | | thenCollect: [:e | e repositories list isEmpty | | | | | ifTrue: [e file] | | | | | ifFalse: [e repositories list first name, '/' , e file]]. | | | | | === | | | | | It allows me to have all files in ConfigurationOfMoose, but I | | | | | have | | | | | two problems: | | | | | | | | | | - if I change version40 by version42, I have no more the name | | | | | of | | | | | packages. | | | | | Here is an example: | | | | | with version40, the first value of my collection is: ' | | | | | http://www.squeaksource.com/Arki/Arki-Reporter-tg.3 ' | | | | | with version42, it is: ' | | | | | http://www.squeaksource.com/Arki/Arki-Reporter-Browser ' | | | | | ==> I have no more the versions to load. | | | | | | | | | | | | | | | | | | | | (ConfigurationOfMoose project version: '4.0') packages | | | | | collect: | | | | | [ | | | | | :each | each name ] as: Set. | | | | | | | | | | or .. | | | | | | | | | | (ConfigurationOfMoose project version: '4.2') packages | | | | | collect: | | | | | [ | | | | | :each | each name ] as: Set. | | | | | | | | | | does that help ? | | | | | | | | | | | | | | | | | | | | - the second problem is about depending project. Moose load | | | | | other | | | | | projects, and there are some cyclic dependencies between the | | | | | loads: | | | | | for example DSM needs Moose, and Moose loads DSM..... | | | | | I know that Metacello resolves this kind of problems. | | | | | | | | | | So, my question is: is it possible to obtain a list of all | | | | | packages | | | | | of a configuration ? | | | | | | | | | | Thank you | | | | | --- | | | | | Jannik Laval | | | | | | | | | | | | | | | | | | | | | | | | | -- | | | | | Mariano | | | | | http://marianopeck.wordpress.com | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --- | | | | | Jannik Laval | | | | | | | | | | | | | | | | | | | | -- | | | | | Mariano | | | | | http://marianopeck.wordpress.com | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --- | | | | | Jannik Laval | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --- | | | | | Jannik Laval | | | | | | | | | | | | | | | | | | | | | -- | | | | Mariano | | | | http://marianopeck.wordpress.com | | | | | | | | | | | | | | | | | | | | -- | | | Mariano | | | http://marianopeck.wordpress.com | | | | | | | | | | | | | | | | -- | | Mariano | | http://marianopeck.wordpress.com | | | | | | | | | -- | Mariano | http://marianopeck.wordpress.com | | |
Re: collecting all packages of a configuration
|
|
In reply to this post by Mariano Martinez Peck
Mariano,
So the bug that you reported 2 days[1] ago was fixed? ... I saw no information in the bug report to that effect. In fact it looked like you reported the bug against a closed bug (you claimed in the comment that the problem still existed) so noone else even looked at the bug ... I see now that you and Esteban have had a conversation and that you weren't able to reproduce the bug on a newer version. Do you acknowledge the fact that I might be a little gun shy? Just this morning a change was made to the system that makes it impossible for me to use Pharo-2.0 for development until a bunch of work that I was not planning on having to do right now, gets done...Cami made a first cut at a port[2] of FileTree to Pharo-2.0 this morning and I greatly appreciate the effort, but I cannot afford to maintain two versions of FileTree so it's back to the drawing board... It looks to me that 2 days ago was the first time I could have loaded my development environment into Pharo2.0 and this morning my development environment would have been broken again... Do you not acknowledge that there are still major changes being done to Pharo-2.0 and anyone using Pharo-2.0 for development is doing so at their own risk? Dale [1] http://code.google.com/p/pharo/issues/detail?id=6336 [2] https://github.com/dalehenrich/filetree/pull/54#issuecomment-7462968 ----- Original Message ----- | From: "Mariano Martinez Peck" <[hidden email]> | To: [hidden email] | Sent: Thursday, August 2, 2012 2:08:45 PM | Subject: Re: [Metacello] Re: collecting all packages of a configuration | | | | | On Thu, Aug 2, 2012 at 11:00 PM, Dale Henrichs < [hidden email] | > wrote: | | | Issue 6295[2] was the first bug that shut me down and then when I | went to try loading Metacello again (with a new vm) I hit Issue | 6336[1] so I have yet to validate whether Issue 6295 is fixed or not | (the resolution comment is not confidence inspiring).... | | | | | Ok, those 2 were fixed. | | | Sean hit Issue 6461[3] a week ago and it is still open... | | | | | I have just reproduce it. Ok, maybe I don't use too much the MC | browser...that's why metacello was "always working" for me hahha. | | | Mariano, you hit 6336 a couple of days ago (I just reopened it). | | | | | I just close it because I cannot reproduce it anymore y latest | images. | | | And now you've hit another issue that smells an awful lot like the | other two issues ... that are still unresolved | | | | | Well, my previous answer was later than your response....the problem | I have reported here also happens in 1.4. | | | | | So, right now it seems that there are some serious Pharo-2.0 issues | with package loading independent of Metacello. | | | | | indeed. The only pending one is | http://code.google.com/p/pharo/issues/detail?id=6461 | | | | | As I said, I'll patiently wait until the base system stabilizes a bit | more before taking a chance that the load might work and that I | might get a chance to run my unit tests ... | | BTW, does anyone know if the Metacello unit tests are run by the | Jenkins server against 2.0? | | | | | no, because it is not included by default. | However, we can create a job for Metacello in 5 minutes. I think it | is worth. Do you want us to do it? | | | Thanks! | | | | | Dale | | [1] http://code.google.com/p/pharo/issues/detail?id=6336 | [2] http://code.google.com/p/pharo/issues/detail?id=6295 | [3] http://code.google.com/p/pharo/issues/detail?id=6461 | | | ----- Original Message ----- | | From: "Sean P. DeNigris" < [hidden email] > | | To: [hidden email] | | | | Sent: Thursday, August 2, 2012 1:35:08 PM | | Subject: [Metacello] Re: collecting all packages of a configuration | | | | | | Dale Henrichs wrote | | > | | > I assume that the issue is a problem in Pharo-2.0. | | | | +1. This sounds to me like | | http://code.google.com/p/pharo/issues/detail?id=6461 | | | | Try loading in #20232 to confirm... | | | | Sean | | | | | | | | -- | | View this message in context: | | http://forum.world.st/collecting-all-packages-of-a-configuration-tp4079913p4642748.html | | Sent from the Metacello mailing list archive at Nabble.com. | | | | | | | -- | Mariano | http://marianopeck.wordpress.com | | |
Re: collecting all packages of a configuration
|
|
In reply to this post by Mariano Martinez Peck
Mariano,
Metacello is written to run on multiple Smalltalk dialects. I cannot just replace SystemChangeNotifier with SystemAnnouncer without considering how that code will affect the other platforms the Metacello runs on ... it's not a simple matter. ----- Original Message ----- | From: "Mariano Martinez Peck" <[hidden email]> | To: [hidden email] | Sent: Thursday, August 2, 2012 2:44:15 PM | Subject: Re: [Metacello] Re: collecting all packages of a configuration | | | | | On Thu, Aug 2, 2012 at 11:00 PM, Dale Henrichs < [hidden email] | > wrote: | | | Issue 6295[2] was the first bug that shut me down and then when I | went to try loading Metacello again (with a new vm) I hit Issue | 6336[1] so I have yet to validate whether Issue 6295 is fixed or not | (the resolution comment is not confidence inspiring).... | | Sean hit Issue 6461[3] a week ago and it is still open... | | Mariano, you hit 6336 a couple of days ago (I just reopened it). | | And now you've hit another issue that smells an awful lot like the | other two issues ... that are still unresolved | | So, right now it seems that there are some serious Pharo-2.0 issues | with package loading independent of Metacello. | | As I said, I'll patiently wait until the base system stabilizes a bit | more before taking a chance that the load might work and that I | might get a chance to run my unit tests ... | | | | | This week, SystemChangeNotifier was removed. If you just change its | references to SystemAnnouncer in Metacello, I got the following | (using last Metacello version) | | | | 678 run, 667 passes, 0 expected failures, 0 failures, 11 errors, 0 | unexpected passes | Failures: | | | Errors: | MetacelloDevelopmentCycleTutorialTests>>#testCreateNewBaseline | MetacelloDevelopmentCycleTutorialTests>>#testCreateNewBaseline | MetacelloDevelopmentCycleTutorialTests>>#testCreateNewDevelopment | MetacelloDevelopmentCycleTutorialTests>>#testCreateNewDevelopment | MetacelloDevelopmentCycleTutorialTests>>#testReleaseDevelopment | MetacelloDevelopmentCycleTutorialTests>>#testReleaseDevelopment | MetacelloDevelopmentCycleTutorialTests>>#testValidateAndSave | MetacelloDevelopmentCycleTutorialTests>>#testValidateAndSave | MetacelloInsideToolBoxTutorialTests>>#testExamples | MetacelloIssue136TestCase>>#testCachedIssue136 | MetacelloIssue136TestCase>>#testIssue136 | | | | | | | BTW, does anyone know if the Metacello unit tests are run by the | Jenkins server against 2.0? | | Dale | | [1] http://code.google.com/p/pharo/issues/detail?id=6336 | [2] http://code.google.com/p/pharo/issues/detail?id=6295 | [3] http://code.google.com/p/pharo/issues/detail?id=6461 | | | ----- Original Message ----- | | From: "Sean P. DeNigris" < [hidden email] > | | To: [hidden email] | | | | Sent: Thursday, August 2, 2012 1:35:08 PM | | Subject: [Metacello] Re: collecting all packages of a configuration | | | | | | Dale Henrichs wrote | | > | | > I assume that the issue is a problem in Pharo-2.0. | | | | +1. This sounds to me like | | http://code.google.com/p/pharo/issues/detail?id=6461 | | | | Try loading in #20232 to confirm... | | | | Sean | | | | | | | | -- | | View this message in context: | | http://forum.world.st/collecting-all-packages-of-a-configuration-tp4079913p4642748.html | | Sent from the Metacello mailing list archive at Nabble.com. | | | | | | | -- | Mariano | http://marianopeck.wordpress.com | | |
|
|
Hi Dale,
I think Metacello is probably the tool who will suffer more the changes we are doing for 2.0. For the majority of users, such changes (with the exception of FileDirectory and HTTP replacement) should be invisible. But of course, Metacello works in a deep level of the system, so, it is affected more for kernel changes. I understand your frustration... I'm sorry for that, is complicated to make changes without annoying people time to time :( Metacello is an important tool for us (I'm rewriting all the release process to use metacello, for instance), so I like to help you in the migration step. I will take a look next week about the changes needed to make it work in 2.0 and provide some feedback (I would like to have Metacello integrated in the core, btw). Esteban On Aug 3, 2012, at 2:12 AM, Dale Henrichs <[hidden email]> wrote: > Mariano, > > Metacello is written to run on multiple Smalltalk dialects. I cannot just replace SystemChangeNotifier with SystemAnnouncer without considering how that code will affect the other platforms the Metacello runs on ... it's not a simple matter. > > > ----- Original Message ----- > | From: "Mariano Martinez Peck" <[hidden email]> > | To: [hidden email] > | Sent: Thursday, August 2, 2012 2:44:15 PM > | Subject: Re: [Metacello] Re: collecting all packages of a configuration > | > | > | > | > | On Thu, Aug 2, 2012 at 11:00 PM, Dale Henrichs < [hidden email] > | > wrote: > | > | > | Issue 6295[2] was the first bug that shut me down and then when I > | went to try loading Metacello again (with a new vm) I hit Issue > | 6336[1] so I have yet to validate whether Issue 6295 is fixed or not > | (the resolution comment is not confidence inspiring).... > | > | Sean hit Issue 6461[3] a week ago and it is still open... > | > | Mariano, you hit 6336 a couple of days ago (I just reopened it). > | > | And now you've hit another issue that smells an awful lot like the > | other two issues ... that are still unresolved > | > | So, right now it seems that there are some serious Pharo-2.0 issues > | with package loading independent of Metacello. > | > | As I said, I'll patiently wait until the base system stabilizes a bit > | more before taking a chance that the load might work and that I > | might get a chance to run my unit tests ... > | > | > | > | > | This week, SystemChangeNotifier was removed. If you just change its > | references to SystemAnnouncer in Metacello, I got the following > | (using last Metacello version) > | > | > | > | 678 run, 667 passes, 0 expected failures, 0 failures, 11 errors, 0 > | unexpected passes > | Failures: > | > | > | Errors: > | MetacelloDevelopmentCycleTutorialTests>>#testCreateNewBaseline > | MetacelloDevelopmentCycleTutorialTests>>#testCreateNewBaseline > | MetacelloDevelopmentCycleTutorialTests>>#testCreateNewDevelopment > | MetacelloDevelopmentCycleTutorialTests>>#testCreateNewDevelopment > | MetacelloDevelopmentCycleTutorialTests>>#testReleaseDevelopment > | MetacelloDevelopmentCycleTutorialTests>>#testReleaseDevelopment > | MetacelloDevelopmentCycleTutorialTests>>#testValidateAndSave > | MetacelloDevelopmentCycleTutorialTests>>#testValidateAndSave > | MetacelloInsideToolBoxTutorialTests>>#testExamples > | MetacelloIssue136TestCase>>#testCachedIssue136 > | MetacelloIssue136TestCase>>#testIssue136 > | > | > | > | > | > | > | BTW, does anyone know if the Metacello unit tests are run by the > | Jenkins server against 2.0? > | > | Dale > | > | [1] http://code.google.com/p/pharo/issues/detail?id=6336 > | [2] http://code.google.com/p/pharo/issues/detail?id=6295 > | [3] http://code.google.com/p/pharo/issues/detail?id=6461 > | > | > | ----- Original Message ----- > | | From: "Sean P. DeNigris" < [hidden email] > > | | To: [hidden email] > | > | > | | Sent: Thursday, August 2, 2012 1:35:08 PM > | | Subject: [Metacello] Re: collecting all packages of a configuration > | | > | | > | | Dale Henrichs wrote > | | > > | | > I assume that the issue is a problem in Pharo-2.0. > | | > | | +1. This sounds to me like > | | http://code.google.com/p/pharo/issues/detail?id=6461 > | | > | | Try loading in #20232 to confirm... > | | > | | Sean > | | > | | > | | > | | -- > | | View this message in context: > | | http://forum.world.st/collecting-all-packages-of-a-configuration-tp4079913p4642748.html > | | Sent from the Metacello mailing list archive at Nabble.com. > | | > | > | > | > | > | -- > | Mariano > | http://marianopeck.wordpress.com > | > | |
Re: collecting all packages of a configuration
|
|
In reply to this post by Dale Henrichs
On Fri, Aug 3, 2012 at 1:45 AM, Dale Henrichs <[hidden email]> wrote: Mariano, Hi Dale. Thanks for your detailed email. To be honest, you don't need to justify. I do understand what you mean and it makes sense to develop on 1.4. I understand your pain and I also suffered it several times.
:)
Mariano http://marianopeck.wordpress.com |
Re: collecting all packages of a configuration
|
|
In reply to this post by Dale Henrichs
On Fri, Aug 3, 2012 at 2:05 AM, Dale Henrichs <[hidden email]> wrote: Mariano, Indeed, I do undersand and I agree. But I have the same opinion as Esteban. We all use Metacello. Really. I cannot work in and env where Metacello does not load. Ok, I don't use FileTree or anything related to git nor Versionner nor the toolbox (they are in my to-do hahaha). So I just use the "kernel" of Metacello.
So....merging with Esteban, what can we do to help? in other words, how can I be sure I can live with Pharo 2.0 ;) ? Dale Mariano http://marianopeck.wordpress.com |
Re: collecting all packages of a configuration
|
|
In reply to this post by Dale Henrichs
On Fri, Aug 3, 2012 at 2:12 AM, Dale Henrichs <[hidden email]> wrote: Mariano, I know. My email was to show you that after a single change we have MOST of the tests green, don't we? So it is not that broken. That's all I wanted to show.
I know it is not easy to change. I have the same problem in Fuel for example and how to make it work for different Pharo versions. I was thinking the other day and maybe I will end up rewriting each: "SystemChangeNotifier" to "FuelPortabilityLayer notifier" (the API is the same). And then I will have subclasses of FuelPortabilityLayer for different Pharo version...or overrides in the (already existing) compatibility packages, not sure...using Grease is overkilling in this case for me.
Mariano http://marianopeck.wordpress.com |
Re: collecting all packages of a configuration
|
|
On Fri, Aug 3, 2012 at 9:51 AM, Mariano Martinez Peck <[hidden email]> wrote:
Well, let's think together. From what I can see (let me know if it is not like that), you use SystemChangeNotifier just to make things silent.
So rather than doing, for example, SystemChangeNotifier uniqueInstance doSilently: [ super runCase ] we can do [ super runCase ] valueSilently
or change #doSilently to #withoutNotifications or whatever. Then we just implement those messages differently in different Pharo versions. what do you think?
Mariano http://marianopeck.wordpress.com |
|
|
+1 #withoutSystemNotifications ... is more intention revealing :)
On Aug 3, 2012, at 10:43 AM, Mariano Martinez Peck <[hidden email]> wrote:
|
Re: collecting all packages of a configuration
|
|
In reply to this post by EstebanLM
Esteban and Mariano,
I've been sort of holding my breath about Metacello and Pharo-2.0 wondering when it would explode, but I didn't expect the explosion to come from FileDirectory:) I've been deferring other work in an effort to get the Metacello Preview ready for use (which includes git/gitub support that is dependent on FileTree) and wasn't anticipating the need to completely rewrite FileTree .... today:) I appreciate your help here and I support your efforts to move Pharo-2.0 forward and the need to slash and burn along the way ... I don't want Metacello to be an anchor that holds Pharo-2.0 back, but on the other hand I do need to keep Metacello running on all of the supported platforms and I do have other work that demands my attention ... we're coming up on ESUG and I need to work on my talk as well. I can't afford to drop everything "right now" and fix all of the things that are broken in Pharo-2.0. When you remove FileDirectory one day and SystemChangeNotifier then next you REQUIRE that dependent packages act NOW in a system that is crippled relative to the dependent packages. I need to maintain a single code base that spans multiple versions of multiple dialects so I can't just rewrite major chunks of my app because FileDirectory or SystemChangeNotifier has vanished...they still exist on other platforms and need to be used. Frankly I am moving my code development to GitHub, because it is easier to maintain cross dialect changes by working in dialect-specific branches than it is to try to isolate all of the platform-specific changes into separate packages, but there are limits to that approach ... isolated changes can be accommodated, but when it comes to wholesale rewrites which the removal of FileDirectory entails ... The standard way of doing this is to deprecate the api first, then remove the api after a reasonable period of time. Perhaps you've been doing that with Pharo-2.0 but I can't tell because I've not been able to use Pharo-2.0 for the whole month of July because of Pharo-2.0 bugs ... I understand that you wanted to put a stake in the ground that says "Doggone it FileDirectory is not to be used in Pharo-2.0" but that stake is also a stake in the heart of developers. Instead of completely removing FileDirectory and SystemChangeNotifier, perhaps you can rename the classes to ObsoleteFileDirectory and ObsoleteSystemChanges ... changing file names (and not behavior) doesn't require wholesale rewrites. Dependent projects can make minor changes to get up and running again. I've got a different set of FileDirectory class names that I use for GLASS/GemStone so I know that renaming is not an issue for me. Anyone loading code that uses FileDirectory will get the immediate jolt of FileDirectory being missing, so they will be forced to learn the story that Filesystem needs to be used going forward. The Obsolete classes can then be removed in Pharo-2.1 which will give folks plenty of time to come up with solutions on their own.... I really want to get Metacello into 2.0 but as it stands I've got a fair amount of work that I dont have time for to do before that's possible ... BTW, the loss of SystemChangeNotifier isn't as traumatic as FileDirectory. The usage in Metacello is restricted to the tests and is not woven into the fabric of the project, like FileDirectory is for FileTree. Dale ----- Original Message ----- | From: "Esteban Lorenzano" <[hidden email]> | To: [hidden email] | Sent: Thursday, August 2, 2012 11:33:18 PM | Subject: Re: [Metacello] Re: collecting all packages of a configuration | | Hi Dale, | | I think Metacello is probably the tool who will suffer more the | changes we are doing for 2.0. For the majority of users, such | changes (with the exception of FileDirectory and HTTP replacement) | should be invisible. But of course, Metacello works in a deep level | of the system, so, it is affected more for kernel changes. | I understand your frustration... I'm sorry for that, is complicated | to make changes without annoying people time to time :( | | Metacello is an important tool for us (I'm rewriting all the release | process to use metacello, for instance), so I like to help you in | the migration step. I will take a look next week about the changes | needed to make it work in 2.0 and provide some feedback (I would | like to have Metacello integrated in the core, btw). | | Esteban | | On Aug 3, 2012, at 2:12 AM, Dale Henrichs <[hidden email]> | wrote: | | > Mariano, | > | > Metacello is written to run on multiple Smalltalk dialects. I | > cannot just replace SystemChangeNotifier with SystemAnnouncer | > without considering how that code will affect the other platforms | > the Metacello runs on ... it's not a simple matter. | > | > | > ----- Original Message ----- | > | From: "Mariano Martinez Peck" <[hidden email]> | > | To: [hidden email] | > | Sent: Thursday, August 2, 2012 2:44:15 PM | > | Subject: Re: [Metacello] Re: collecting all packages of a | > | configuration | > | | > | | > | | > | | > | On Thu, Aug 2, 2012 at 11:00 PM, Dale Henrichs < | > | [hidden email] | > | > wrote: | > | | > | | > | Issue 6295[2] was the first bug that shut me down and then when I | > | went to try loading Metacello again (with a new vm) I hit Issue | > | 6336[1] so I have yet to validate whether Issue 6295 is fixed or | > | not | > | (the resolution comment is not confidence inspiring).... | > | | > | Sean hit Issue 6461[3] a week ago and it is still open... | > | | > | Mariano, you hit 6336 a couple of days ago (I just reopened it). | > | | > | And now you've hit another issue that smells an awful lot like | > | the | > | other two issues ... that are still unresolved | > | | > | So, right now it seems that there are some serious Pharo-2.0 | > | issues | > | with package loading independent of Metacello. | > | | > | As I said, I'll patiently wait until the base system stabilizes a | > | bit | > | more before taking a chance that the load might work and that I | > | might get a chance to run my unit tests ... | > | | > | | > | | > | | > | This week, SystemChangeNotifier was removed. If you just change | > | its | > | references to SystemAnnouncer in Metacello, I got the following | > | (using last Metacello version) | > | | > | | > | | > | 678 run, 667 passes, 0 expected failures, 0 failures, 11 errors, | > | 0 | > | unexpected passes | > | Failures: | > | | > | | > | Errors: | > | MetacelloDevelopmentCycleTutorialTests>>#testCreateNewBaseline | > | MetacelloDevelopmentCycleTutorialTests>>#testCreateNewBaseline | > | MetacelloDevelopmentCycleTutorialTests>>#testCreateNewDevelopment | > | MetacelloDevelopmentCycleTutorialTests>>#testCreateNewDevelopment | > | MetacelloDevelopmentCycleTutorialTests>>#testReleaseDevelopment | > | MetacelloDevelopmentCycleTutorialTests>>#testReleaseDevelopment | > | MetacelloDevelopmentCycleTutorialTests>>#testValidateAndSave | > | MetacelloDevelopmentCycleTutorialTests>>#testValidateAndSave | > | MetacelloInsideToolBoxTutorialTests>>#testExamples | > | MetacelloIssue136TestCase>>#testCachedIssue136 | > | MetacelloIssue136TestCase>>#testIssue136 | > | | > | | > | | > | | > | | > | | > | BTW, does anyone know if the Metacello unit tests are run by the | > | Jenkins server against 2.0? | > | | > | Dale | > | | > | [1] http://code.google.com/p/pharo/issues/detail?id=6336 | > | [2] http://code.google.com/p/pharo/issues/detail?id=6295 | > | [3] http://code.google.com/p/pharo/issues/detail?id=6461 | > | | > | | > | ----- Original Message ----- | > | | From: "Sean P. DeNigris" < [hidden email] > | > | | To: [hidden email] | > | | > | | > | | Sent: Thursday, August 2, 2012 1:35:08 PM | > | | Subject: [Metacello] Re: collecting all packages of a | > | | configuration | > | | | > | | | > | | Dale Henrichs wrote | > | | > | > | | > I assume that the issue is a problem in Pharo-2.0. | > | | | > | | +1. This sounds to me like | > | | http://code.google.com/p/pharo/issues/detail?id=6461 | > | | | > | | Try loading in #20232 to confirm... | > | | | > | | Sean | > | | | > | | | > | | | > | | -- | > | | View this message in context: | > | | http://forum.world.st/collecting-all-packages-of-a-configuration-tp4079913p4642748.html | > | | Sent from the Metacello mailing list archive at Nabble.com. | > | | | > | | > | | > | | > | | > | -- | > | Mariano | > | http://marianopeck.wordpress.com | > | | > | | | |
Re: collecting all packages of a configuration
|
|
In reply to this post by Mariano Martinez Peck
Mariano,
I'm running the load expression in Pharo-1.4 and I hit the warning about needing ImageSegments, so I can't complete the load in Pharo-1.4 ... I need a bit more info about how you get past needing ImageSegments problem before I can proceed... Dale ----- Original Message ----- | From: "Mariano Martinez Peck" <[hidden email]> | To: [hidden email] | Sent: Thursday, August 2, 2012 9:56:40 AM | Subject: Re: [Metacello] collecting all packages of a configuration | | Hi Dale. I find myself again, trying to collect the packages loaded | (and their order). There is something that does not work and I | cannot figure out what is happening. At least, it is reproducible ;) | | | I took the last Pharo 2.0 available from Jenkins, and I install | seaside and pier as following: | | | | Gofer it | squeaksource: 'MetacelloRepository'; | package: 'ConfigurationOfSeaside30'; | load. | | | ((Smalltalk at: #ConfigurationOfSeaside30) project version: #stable) | load: #('Base' 'Zinc-Seaside' 'Base Tests' 'RSS-Core' | 'Javascript-Core' 'Prototype-Core' 'Scriptaculous-Core' | 'JQuery-Core' 'JQuery-UI' 'Seaside-Email' 'Seaside-HTML5' | 'Seaside-InternetExplorer' 'Seaside-Examples' 'RSS-Examples' | 'Seaside-Tools-Web' 'Scriptaculous-Components' 'Seaside-Welcome' | 'Seaside-FileSystem' 'RSS-Tests-Core' 'Javascript-Tests-Core' | 'Seaside-Tests-Email' 'Seaside-Tests-Functional' | 'Prototype-Tests-Core' 'Scriptaculous-Tests-Core' | 'Scriptaculous-Tests-Components' 'JQuery-Tests-Core' | 'JQuery-Tests-UI' 'Seaside-Tests-HTML5' | 'Seaside-Tests-InternetExplorer' 'Seaside-Tests-Examples' | 'Seaside-Tests-Tools-Web' 'Seaside-Tests-UTF8' | 'Seaside-Tests-FileSystem' 'Seaside-Tests-Welcome'). | | Gofer it | squeaksource: 'MetacelloRepository'; | package: 'ConfigurationOfPier2'; | load. | | | ((Smalltalk at: #ConfigurationOfPier2) project version: #stable) | load. | | | | | Gofer it | squeaksource: 'MetacelloRepository'; | package: 'ConfigurationOfPierAddOns2'; | load. | | | | | | ((Smalltalk at: #ConfigurationOfPierAddOns2) project version: | #stable) load: #('default' 'Pier-Shout' 'Pier-Design' ). | | | | | Now...while loading that, I have an popup saying I am about to load a | new version of XML-Parser (see attachment). Ok, I say "load" and | everything loads fine after. | | | The problem is that if now I ask Metacello the loaded packages: | | | | | | | >> packagesFromConf: confName version: versionString loading: | >> packageOrGroups | | loader pkgs | | | loader := ((Smalltalk at: confName asSymbol) project version: | versionString) | ignoreImage: true; | record: packageOrGroups. | pkgs := OrderedCollection new. | loader loadDirective packageDirectivesDo: [:directive | pkgs add: | directive spec name ]. | ^ pkgs | | | | | >> seasidePackages | | packages loader | | packages := OrderedCollection new. | packages addAll: (self packagesFromConf: #ConfigurationOfSeaside30 | version: #stable loading: #('Base' 'Zinc-Seaside' 'Base Tests' | 'RSS-Core' 'Javascript-Core' 'Prototype-Core' 'Scriptaculous-Core' | 'JQuery-Core' 'JQuery-UI' 'Seaside-Email' 'Seaside-HTML5' | 'Seaside-InternetExplorer' 'Seaside-Examples' 'RSS-Examples' | 'Seaside-Tools-Web' 'Scriptaculous-Components' 'Seaside-Welcome' | 'Seaside-FileSystem' 'RSS-Tests-Core' 'Javascript-Tests-Core' | 'Seaside-Tests-Email' 'Seaside-Tests-Functional' | 'Prototype-Tests-Core' 'Scriptaculous-Tests-Core' | 'Scriptaculous-Tests-Components' 'JQuery-Tests-Core' | 'JQuery-Tests-UI' 'Seaside-Tests-HTML5' | 'Seaside-Tests-InternetExplorer' 'Seaside-Tests-Examples' | 'Seaside-Tests-Tools-Web' 'Seaside-Tests-UTF8' | 'Seaside-Tests-FileSystem' 'Seaside-Tests-Welcome' | )). | | | packages addAll: (self packagesFromConf: #ConfigurationOfPier2 | version: #stable loading: #('default')). | packages addAll: (self packagesFromConf: #ConfigurationOfPierAddOns2 | version: #stable loading: #('default' 'Pier-Shout' 'Pier-Design' )). | packages addAll: #('Pier-FuelPersistence-Core' | 'Pier-FuelPersistence-Test'). | | packages := packages removeDuplicates. | | ^ packages | | | | | | | | There are some packages that do not appear, like | 'Collections-BitmapCharacterSet' or | 'Collections-OrderPreservingDictionary', which are needed by | ConfigurationOfXMLSupport . And....this is related to the error I | got popup (saying I was loading a new version) | | | So...all in all, do you have something in mind that could be | happening? Sorry for not being able to dig deeper. | | | Thanks!!! | | | | | | | On Sun, May 13, 2012 at 5:05 PM, Dale Henrichs < [hidden email] | > wrote: | | | Mariano, | | The loadDirectives are actually used for the Metacello load, so you | are getting the load order from the horse's mouth... | | Seaside-Core is one of the first packages that needs to be loaded so | Seaside-Tools-Core should be loaded _after_ Seaside-Core ... | | WARegistry class is in Seaside-Core, but the method WARegistry | class>>#clearAllHandlers is actually in the Seaside-Tools-Core | package (*seaside-tools-core) so everything is consistent... | | | Dale | | ----- Original Message ----- | | From: "Mariano Martinez Peck" < [hidden email] > | | To: [hidden email] | | | | Sent: Sunday, May 13, 2012 6:50:18 AM | | Subject: Re: [Metacello] collecting all packages of a configuration | | | | Hi Dale. For a different purpose, I need again something related to | | this. | | What I actually need is to ask Metacello the list of packages I | | need | | when I do load: xxx SORTED by the load order. I mean, I want they | | to | | be sorted in the way that those that need to be loaded first go | | first. | | | | Take this example. I have download seaside this way: | | | | | | ((Smalltalk at: #ConfigurationOfSeaside30) project version: | | #stable) | | load: #('Base' 'Zinc-Seaside' 'Base Tests' 'RSS-Core' | | 'Javascript-Core' 'Prototype-Core' 'Scriptaculous-Core' | | 'JQuery-Core' 'JQuery-UI' 'Seaside-Email' 'Seaside-HTML5' | | 'Seaside-InternetExplorer' 'Seaside-Examples' 'RSS-Examples' | | 'Seaside-Tools-Web' 'Scriptaculous-Components' 'Seaside-Welcome' | | 'Seaside-FileSystem' 'RSS-Tests-Core' 'Javascript-Tests-Core' | | 'Seaside-Tests-Email' 'Seaside-Tests-Functional' | | 'Prototype-Tests-Core' 'Scriptaculous-Tests-Core' | | 'Scriptaculous-Tests-Components' 'JQuery-Tests-Core' | | 'JQuery-Tests-UI' 'Seaside-Tests-HTML5' | | 'Seaside-Tests-InternetExplorer' 'Seaside-Tests-Examples' | | 'Seaside-Tests-Tools-Web' 'Seaside-Tests-UTF8' | | 'Seaside-Tests-FileSystem' 'Seaside-Tests-Welcome' | | ). | | | | But those pacakages/groups have another dependencies etc etc. So I | | am | | using this to query: | | | | | pkgs loader | | | loader := ((Smalltalk at: #ConfigurationOfSeaside30) project | | version: | | '3.0.6.3') | | ignoreImage: true; | | record: #('Base' 'Zinc-Seaside' 'Base Tests' 'RSS-Core' | | 'Javascript-Core' 'Prototype-Core' 'Scriptaculous-Core' | | 'JQuery-Core' 'JQuery-UI' 'Seaside-Email' 'Seaside-HTML5' | | 'Seaside-InternetExplorer' 'Seaside-Examples' 'RSS-Examples' | | 'Seaside-Tools-Web' 'Scriptaculous-Components' 'Seaside-Welcome' | | 'Seaside-FileSystem' 'RSS-Tests-Core' 'Javascript-Tests-Core' | | 'Seaside-Tests-Email' 'Seaside-Tests-Functional' | | 'Prototype-Tests-Core' 'Scriptaculous-Tests-Core' | | 'Scriptaculous-Tests-Components' 'JQuery-Tests-Core' | | 'JQuery-Tests-UI' 'Seaside-Tests-HTML5' | | 'Seaside-Tests-InternetExplorer' 'Seaside-Tests-Examples' | | 'Seaside-Tests-Tools-Web' 'Seaside-Tests-UTF8' | | 'Seaside-Tests-FileSystem' 'Seaside-Tests-Welcome' | | ). | | pkgs := OrderedCollection new. | | loader loadDirective packageDirectivesDo: [:directive | pkgs add: | | directive spec name ]. | | ^ pkgs | | | | | | It loooks like if that would answer the list of packages in load | | order, but this is not true. If you inspect that, you obtain this: | | | | an OrderedCollection('ConfigurationOfGrease' | | 'ConfigurationOfGrease' | | 'ConfigurationOfSPort2' 'ConfigurationOfZincHTTPComponents' | | 'Grease-Core' 'Grease-Pharo-Core' 'Grease-Core' 'Grease-Pharo-Core' | | 'Grease-Tests-Core' 'Grease-Tests-Pharo-Core' 'Zinc-HTTP' | | 'Seaside-Core' 'Seaside-Pharo-Core' 'Seaside-Component' | | 'Seaside-Canvas' 'Seaside-Pharo-Canvas' 'RSS-Core' | | 'Javascript-Core' | | 'Javascript-Pharo-Core' 'Prototype-Core' 'Scriptaculous-Core' | | 'JQuery-Core' 'JQuery-UI' 'Seaside-Email' 'Seaside-Pharo-Email' | | 'Seaside-HTML5' 'Seaside-InternetExplorer' 'Seaside-Session' | | 'Seaside-RenderLoop' 'Seaside-Tools-Core' 'Seaside-Flow' | | 'Seaside-Examples' 'RSS-Examples' 'Seaside-Widgets' | | 'Seaside-Tools-Web' 'Seaside-Pharo-Tools-Web' 'Seaside-Environment' | | 'Seaside-Pharo-Environment' 'Seaside-Development' | | 'Scriptaculous-Components' 'Zinc-Seaside' 'Seaside-Tests-Core' | | 'Seaside-Tests-Pharo-Core' 'Seaside-Tests-Session' | | 'Seaside-Tests-RenderLoop' 'Seaside-Tests-Component' | | 'Seaside-Tests-Canvas' 'Seaside-Tests-Environment' 'RSS-Tests-Core' | | 'Javascript-Tests-Core' 'Javascript-Tests-Pharo-Core' | | 'Seaside-Tests-Email' 'Seaside-Tests-Functional' | | 'Seaside-Tests-Pharo-Functional' 'Seaside-Tests-Flow' | | 'Seaside-Welcome' 'Seaside-Pharo-Welcome' 'Prototype-Tests-Core' | | 'Scriptaculous-Tests-Core' 'Scriptaculous-Tests-Components' | | 'JQuery-Tests-Core' 'JQuery-Tests-UI' 'Seaside-Tests-HTML5' | | 'Seaside-Tests-InternetExplorer' 'Seaside-Tests-Examples' | | 'Seaside-Tests-Tools-Web' 'Seaside-Tests-UTF8' | | 'Seaside-Tests-Welcome' 'Sport' 'Seaside-FileSystem' | | 'Seaside-Tests-FileSystem' 'Seaside-Pharo-Continuation' | | 'Seaside-Tests-Pharo-Continuation' 'Seaside-Pharo-Flow' | | 'Seaside-Pharo-Development') | | | | As you can see, for example, 'Seaside-Tools-Core' is AFTER | | 'Seaside-Core'. Right? However, for example, WARegistry >> | | #clearAllHandlers (package 'Seaside-Core') has references to | | WAAdmin | | (present in 'Seaside-Tools-Core''). So? is 'Seaside-Tools-Core' | | actually loaded before 'Seaside-Core'? if true, how can I query | | that | | to Metacello. If false, why don't you get the ugly Monticello popup | | saying you that you have dependencies on ... | | | | Thanks! | | | | | | | | | | | | On Mon, Dec 5, 2011 at 6:53 PM, Dale Henrichs < [hidden email] | | > | | wrote: | | | | | | Mariano, | | | | Regarding your complaint about having the OmniBrowser packages show | | up when you are using the #loadDirective based variant. The 'Core' | | group for Seaside includes Seaside-Tools-OmniBrowser, so when you | | load the 'Core' group OmniBrowser is a required package. You are | | sitting in a Pharo image that already has OmniBrowser loaded, so | | when you load Seaside30 you don't see the OB packages getting | | loaded. However, in the #loadDirective variant, you are using | | #ignoreImage: and when Metacello ignores the image, it ignores the | | fact that OB is already loaded as well ... If you want to know what | | would be loaded into the current image, then don't set #ignoreImage | | to true ... the OmniBrowser packages and any other packages that | | are | | already loaded won't show up ... | | | | If there is a set of configs that you would like to | | include/exclude, | | then a more complex load directive algorithm can be used... | | | | Regarding the duplication of packages, I would say that since you | | are | | only interested in the list of packages that would be loaded, you | | can safely ignore the duplicates. | | | | Regarding the inclusion of the ConfigurationOfXXX files, | | technically, | | those files are needed for a load. No version information is | | associated with the configuration file, because config files always | | have their latest available version loaded ... If you want to | | filter | | those files out, then there is a more complex loadDirective | | traversal algorithm you could use, or you can filter out the | | configs | | with #beginsWith:... | | | | | | Dale | | | | ----- Original Message ----- | | | | | From: "Mariano Martinez Peck" < [hidden email] > | | | To: [hidden email] | | | Sent: Saturday, December 3, 2011 4:27:13 PM | | | | | | | Subject: Re: [Metacello] collecting all packages of a | | | configuration | | | | | | | | | | | | | | | On Thu, Nov 17, 2011 at 6:57 PM, Dale Henrichs < | | | [hidden email] | | | > wrote: | | | | | | | | | Jannik, | | | | | | There are two routes you can take to answer your question. | | | Firstly, | | | you can directly query the version itself: | | | | | | ((ConfigurationOfMetacello project currentVersion) | | | allPackagesForSpecNamed: 'ALL') | | | collect: [:spec | spec file ]. | | | | | | Or you can use #record: and then collect the information you | | | want: | | | | | | | pkgs loader | | | | loader := (ConfigurationOfMetacello project currentVersion) | | | ignoreImage: true; | | | record: 'ALL'. | | | pkgs := OrderedCollection new. | | | loader loadDirective packageDirectivesDo: [:directive |pkgs add: | | | directive spec file ]. | | | pkgs. | | | | | | | | | | | | Hi Dale. I have notice that both ways are different. For example, | | | the | | | first one does not take into account those ConfigurationOfXXX | | | packages, whereas the second one does. Moreoever, in the second | | | one, | | | I see that there are repetitions. For example: | | | | | | | pkgs loader | | | | loader := ((Smalltalk at: #ConfigurationOfSeaside30) project | | | version: | | | ' 3.0.6.3 ') | | | ignoreImage: true; | | | record: #('Core' 'Tests' 'Zinc-Seaside' ). | | | pkgs := OrderedCollection new. | | | loader loadDirective packageDirectivesDo: [:directive |pkgs add: | | | directive spec file ]. | | | pkgs. | | | | | | size gives me 127, but asSet size, 106. It seems some packages | | | appear | | | more than once like ConfigurationOfGrease. | | | | | | ConfigurationOfXXX do not have version number in their name, but | | | the | | | rest do have. | | | | | | Now, the main problem is that none of them is what I need: I need | | | ALL | | | the required packages that are needed to load such project with | | | metacello. I want to capture the exact list of packages needed | | | when | | | I do, for example: | | | ((Smalltalk at: #ConfigurationOfSeaside30) project version: | | | ' 3.0.6.3 ') | | | load: #('Core' 'Tests' 'Zinc-Seaside' ). | | | | | | The first one doesn't even take into account ConfigurationOfXX, | | | so | | | it | | | doesn't help me. The second one, not only has repetitions, but | | | also | | | it lists packages that I really don't need. For example, | | | OB-Morphic-lr.164 and Seaside-Tools-OmniBrowser-lr.25. I don't | | | understand how those packages arrived to the list. If I take a | | | clean | | | image, and install Seaside with the way I showed you, those | | | packages | | | are not even downloaded. So why do they appear here? | | | | | | So...all in all, what I need is a list of the exact packages I | | | need | | | to reproduce something I have loaded with Metacello. In other | | | words, | | | if I start an image with an empty package-cache, and execute the | | | load of seaside, how can I know the list of packages that were | | | downloaded? of course, not inspecting the package-cache ;) | | | | | | Thanks in advance Dale!!! | | | | | | | | | | | | | | | Dale | | | | | | | | | | | | ----- Original Message ----- | | | | From: "jannik.laval" < [hidden email] > | | | | To: [hidden email] | | | | Sent: Thursday, November 17, 2011 5:11:09 AM | | | | Subject: [Metacello] collecting all packages of a configuration | | | | | | | | | | | | | | | | | | | | | | | | Hi guys, | | | | | | | | | | | | With mariano, we had a discussion about a problem I have: | | | | How can I collect all packages from a configuration with | | | | resolving | | | | all sub projects ? | | | | | | | | | | | | Thank you for your help. | | | | Cheers, | | | | Jannik | | | | | | | | | | | | | | | | Begin forwarded message: | | | | | | | | | | | | | | | | From: Mariano Martinez Peck < [hidden email] > | | | | | | | | Subject: Re: Metacello question | | | | | | | | Date: November 16, 2011 4:09:38 PM GMT+01:00 | | | | | | | | To: "jannik.laval" < [hidden email] > | | | | | | | | | | | | | | | | | | | | On Wed, Nov 16, 2011 at 11:57 AM, jannik.laval < | | | | [hidden email] > wrote: | | | | | | | | | | | | | | | | | | | | Hi Mariano, | | | | | | | | | | | | I understand your code and It seems to be the same as mine. | | | | version40 make the same as "project version: '4.0'". | | | | | | | | | | | | The problem is the resolution of internal projects. | | | | We should collect the methods recursively... and possibly with | | | | circular dependencies. | | | | So, Metacello can resolve them, but I do not know Metacello :( | | | | | | | | | | | | | | | | | | | | I have no idea :( | | | | Ask in metacello mailing list: [hidden email] , | | | | | | | | good luck | | | | | | | | | | | | | | | | | | | | | | | | Jannik | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Nov 16, 2011, at 15:36 , Mariano Martinez Peck wrote: | | | | | | | | | | | | | | | | | | | | | | | | On Wed, Nov 16, 2011 at 6:59 AM, jannik.laval < | | | | [hidden email] > wrote: | | | | | | | | | | | | Hi Mariano, | | | | How are you ? | | | | Here, at Bordeaux, I am fine, and all the family too :) | | | | | | | | | | | | | | | | Excellent, nice to hear that :) | | | | I am in Argentina in holidays (after Smalltalks) and all | | | | familiy | | | | good | | | | as well hahahahah | | | | | | | | | | | | | | | | I have a question about Metacello, and you know well Metacello | | | | :) | | | | I would like to collect all the files to load of a | | | | Configuration | | | | with | | | | all dependencies already resolved. | | | | | | | | For now, I have this code in a transcript: | | | | === | | | | ConfigurationOfMoose version40 spec packages map select:[:e | e | | | | isKindOf: MetacelloPackageSpec ] | | | | thenCollect: [:e | e repositories list isEmpty | | | | ifTrue: [e file] | | | | ifFalse: [e repositories list first name, '/' , e file]]. | | | | === | | | | It allows me to have all files in ConfigurationOfMoose, but I | | | | have | | | | two problems: | | | | | | | | - if I change version40 by version42, I have no more the name | | | | of | | | | packages. | | | | Here is an example: | | | | with version40, the first value of my collection is: ' | | | | http://www.squeaksource.com/Arki/Arki-Reporter-tg.3 ' | | | | with version42, it is: ' | | | | http://www.squeaksource.com/Arki/Arki-Reporter-Browser ' | | | | ==> I have no more the versions to load. | | | | | | | | | | | | | | | | (ConfigurationOfMoose project version: '4.0') packages collect: | | | | [ | | | | :each | each name ] as: Set. | | | | | | | | or .. | | | | | | | | (ConfigurationOfMoose project version: '4.2') packages collect: | | | | [ | | | | :each | each name ] as: Set. | | | | | | | | does that help ? | | | | | | | | | | | | | | | | - the second problem is about depending project. Moose load | | | | other | | | | projects, and there are some cyclic dependencies between the | | | | loads: | | | | for example DSM needs Moose, and Moose loads DSM..... | | | | I know that Metacello resolves this kind of problems. | | | | | | | | So, my question is: is it possible to obtain a list of all | | | | packages | | | | of a configuration ? | | | | | | | | Thank you | | | | --- | | | | Jannik Laval | | | | | | | | | | | | | | | | | | | | -- | | | | Mariano | | | | http://marianopeck.wordpress.com | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --- | | | | Jannik Laval | | | | | | | | | | | | | | | | -- | | | | Mariano | | | | http://marianopeck.wordpress.com | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --- | | | | Jannik Laval | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --- | | | | Jannik Laval | | | | | | | | | | | | | | | | -- | | | Mariano | | | http://marianopeck.wordpress.com | | | | | | | | | | | | | | -- | | Mariano | | http://marianopeck.wordpress.com | | | | | | | | | -- | Mariano | http://marianopeck.wordpress.com | | |
Re: collecting all packages of a configuration
|
|
On Fri, Aug 3, 2012 at 7:17 PM, Dale Henrichs <[hidden email]> wrote: Mariano, Hi Dale. Thanks for trying to reproduce it. Indeed, I also had that problem of ImageSegment as well as another one for BlockContext. I just clicked on "proceed".
I think the problem is more or less like this: ConfigurationOfPierAddOns loads an old version of XML-Parser (1.0.1) then another project install a newer version of XML-Parser and there appears the popup. At the same time, those packages I mention that do not appear ('Collections-BitmapCharacterSet' or 'Collections-OrderPreservingDictionary') are ONLY present in the new version of ConfigurationOfXMLSupport (not in the old 1.0.1). So...I think that what happens is that you load version XXX of something, but then YYY (which may need other packages). However, when you query Metacello, he only remember about XXX. Can it be something like that?
Thanks!
Mariano http://marianopeck.wordpress.com |
Re: collecting all packages of a configuration
|
|
On Fri, Aug 3, 2012 at 7:24 PM, Mariano Martinez Peck <[hidden email]> wrote:
In fact, if I change ConfigurationOfPierAddOns2 >> version210: and change project: 'XML Parser' with: '1.0.1'.
to project: 'XML Parser' with: #stable. the popup disappear and the packages are included when I query Metacello.
Mariano http://marianopeck.wordpress.com |
«
Return to Metacello
|
1 view|%1 views
| Free forum by Nabble | Edit this page |