Smalltalk › Frameworks & Tools › Seaside › Seaside General

Re: [Metacello] collecting all packages of a configuration

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 4 messages Options
Mariano Martinez Peck
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [Metacello] collecting all packages of a configuration

Mariano Martinez Peck
Hi Dale. Now I was a little bit more sucessful. But still, I have a problem during the initialization of classes. More precisily in:

WAWalkbackErrorHandler class >> initialize
    WAAdmin applicationExceptionHandlingDefaults at: #exceptionHandler put: self

I get a WAAttributeNotFound with #exceptionHandler ...  what I do is I follow the order of packages as Metacello answered me, and then I do something like:

(packageNames collect: [:each | PackageInfo named: each])
            do: [:aPackage |
                "We should not send #initialize to traits"
                ((aPackage classes select: [:each | each isBehavior])
                     sort: [:a :b | a allSuperclasses size < b allSuperclasses size ])
                         do: [:aClass |
                            Transcript show: 'Initializing class named: ', aClass name; cr.
                            aClass initializeOnLoad]
            ].   
        ]   


I have debugged a little bit and it looks like

WAAdmin applicationExceptionHandlingDefaults allAttributes -> an IdentityDictionary()
WAAdmin applicationExceptionHandlingDefaults ancestors -> an IdentitySet() 
 
so something is not good. I saw your issue http://code.google.com/p/seaside/issues/detail?id=643
but evaluating

(Smalltalk at: #WASystemConfiguration) allSubclasses do: [ :each |
        each instance perform: #clearSearchContexts.
        each instance perform: #clearDescription ].

did not help.

Any ideas?

thanks

On Sun, May 13, 2012 at 6:04 PM, Dale Henrichs <[hidden email]> wrote:
Mariano,

I've said it before and I'll say it again ... I'd rather have noise than real problems go unreported ...

Thanks for taking the time to characterize the problem in detail...

Dale

----- Original Message -----
| From: "Mariano Martinez Peck" <[hidden email]>
| To: [hidden email]
| Sent: Sunday, May 13, 2012 8:39:52 AM
| Subject: Re: [Metacello] collecting all packages of a configuration
|
|
|
|
| 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...
|
|
| hehehehehe interesting....you discovered a bad side effect of my
| experiment ;) sorry, I though I was checking in a "clean" image but
| a bad side effect of my experiment changed the category for
| extension methods. So...indeed, you are right and the method I have
| is that I need.
|
| Thanks Dale and sorry for the noise.
|
|
|
|
| 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:
| | ' <a href="tel:3.0.6.3" value="+333063">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:
| | | ' <a href="tel:3.0.6.3" value="+333063">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:
| | | ' <a href="tel:3.0.6.3" value="+333063">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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Dale Henrichs
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [Metacello] collecting all packages of a configuration

Dale Henrichs
Mariano,

I guess you are trying to upgrade an existing Seaside application?

Are you having trouble doing this upgrade using Metacello, or is this a problem trying to do the upgrade using the package order derived from the loadDirectives?

If the Metacello load works fine, then I would guess that you're not running your initializers in the right order at the right time. Your little loop over packageNames looks close to what Monticello does when it fires the initializers, but it's not quite the same ... for example Monticello only fires initializers for class initialization methods that are changed/new during the load.

Also, if I remember correctly Metacello fires the initializers for Seaside packages immediately after the package is loaded and does not wait until the end to fire initializers ...

I'd focus on duplicating the initialization pattern of Metacello (instrumenting the Monticello loader where the initializations are fired would give you that info).

Dale

----- Original Message -----
| From: "Mariano Martinez Peck" <[hidden email]>
| To: [hidden email]
| Cc: "Seaside - general discussion" <[hidden email]>
| Sent: Thursday, May 17, 2012 6:13:30 AM
| Subject: Re: [Metacello] collecting all packages of a configuration
|
| Hi Dale. Now I was a little bit more sucessful. But still, I have a
| problem during the initialization of classes. More precisily in:
|
| WAWalkbackErrorHandler class >> initialize
| WAAdmin applicationExceptionHandlingDefaults at: #exceptionHandler
| put: self
|
| I get a WAAttributeNotFound with #exceptionHandler ... what I do is I
| follow the order of packages as Metacello answered me, and then I do
| something like:
|
| (packageNames collect: [:each | PackageInfo named: each])
| do: [:aPackage |
| "We should not send #initialize to traits"
| ((aPackage classes select: [:each | each isBehavior])
| sort: [:a :b | a allSuperclasses size < b allSuperclasses size ])
| do: [:aClass |
| Transcript show: 'Initializing class named: ', aClass name; cr.
| aClass initializeOnLoad]
| ].
| ]
|
|
| I have debugged a little bit and it looks like
|
| WAAdmin applicationExceptionHandlingDefaults allAttributes -> an
| IdentityDictionary()
| WAAdmin applicationExceptionHandlingDefaults ancestors -> an
| IdentitySet()
|
| so something is not good. I saw your issue
| http://code.google.com/p/seaside/issues/detail?id=643
| but evaluating
|
| (Smalltalk at: #WASystemConfiguration) allSubclasses do: [ :each |
| each instance perform: #clearSearchContexts.
| each instance perform: #clearDescription ].
|
| did not help.
|
| Any ideas?
|
| thanks
|
|
| On Sun, May 13, 2012 at 6:04 PM, Dale Henrichs < [hidden email]
| > wrote:
|
|
| Mariano,
|
| I've said it before and I'll say it again ... I'd rather have noise
| than real problems go unreported ...
|
| Thanks for taking the time to characterize the problem in detail...
|
|
| Dale
|
| ----- Original Message -----
| | From: "Mariano Martinez Peck" < [hidden email] >
| | To: [hidden email]
|
|
| | Sent: Sunday, May 13, 2012 8:39:52 AM
| | Subject: Re: [Metacello] collecting all packages of a configuration
| |
| |
| |
| |
| | 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...
| |
| |
| | hehehehehe interesting....you discovered a bad side effect of my
| | experiment ;) sorry, I though I was checking in a "clean" image but
| | a bad side effect of my experiment changed the category for
| | extension methods. So...indeed, you are right and the method I have
| | is that I need.
| |
| | Thanks Dale and sorry for the noise.
| |
| |
| |
| |
| | 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
|
|
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Mariano Martinez Peck
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [Metacello] collecting all packages of a configuration

Mariano Martinez Peck


On Thu, May 17, 2012 at 7:37 PM, Dale Henrichs <[hidden email]> wrote:
Mariano,

I guess you are trying to upgrade an existing Seaside application?

Are you having trouble doing this upgrade using Metacello, or is this a problem trying to do the upgrade using the package order derived from the loadDirectives?


I should explain what I am doing. I am exporting packages using Fuel. What I do is to query Metacello to know which packages I need and the order (for the future load).
Then, during load, after having materialized all packages, I iterate over the packages (in the order I stored during the export), and I initialize the classes for each package.

In this example, I am NOT upgrading nothing. I am just trying to import seaside in a clean image using Fuel.

 
If the Metacello load works fine,

indeed, it works fine.
 
then I would guess that you're not running your initializers in the right order at the right time.

Indeed, I also thought that I have a problem with the initialization. I sent this mail because maybe this particular problem moves some bell ;)
 
Your little loop over packageNames looks close to what Monticello does when it fires the initializers,


You mean MCMethodDefinition >> postloadOver:  right?  
 
but it's not quite the same ... for example Monticello only fires initializers for class initialization methods that are changed/new during the load.

yes, you mean the if:    self source ~= aDefinition source   right? 
In my case, I am loading methods that DO NOT have source code. So..
 

Also, if I remember correctly Metacello fires the initializers for Seaside packages immediately after the package is loaded and does not wait until the end to fire initializers ...


mmmm #atomic  loader type?  where can I see more info about this?

 
I'd focus on duplicating the initialization pattern of Metacello (instrumenting the Monticello loader where the initializations are fired would give you that info).


where can I see this?

Thanks
 
Dale

----- Original Message -----
| From: "Mariano Martinez Peck" <[hidden email]>
| To: [hidden email]
| Cc: "Seaside - general discussion" <[hidden email]>
| Sent: Thursday, May 17, 2012 6:13:30 AM
| Subject: Re: [Metacello] collecting all packages of a configuration
|
| Hi Dale. Now I was a little bit more sucessful. But still, I have a
| problem during the initialization of classes. More precisily in:
|
| WAWalkbackErrorHandler class >> initialize
| WAAdmin applicationExceptionHandlingDefaults at: #exceptionHandler
| put: self
|
| I get a WAAttributeNotFound with #exceptionHandler ... what I do is I
| follow the order of packages as Metacello answered me, and then I do
| something like:
|
| (packageNames collect: [:each | PackageInfo named: each])
| do: [:aPackage |
| "We should not send #initialize to traits"
| ((aPackage classes select: [:each | each isBehavior])
| sort: [:a :b | a allSuperclasses size < b allSuperclasses size ])
| do: [:aClass |
| Transcript show: 'Initializing class named: ', aClass name; cr.
| aClass initializeOnLoad]
| ].
| ]
|
|
| I have debugged a little bit and it looks like
|
| WAAdmin applicationExceptionHandlingDefaults allAttributes -> an
| IdentityDictionary()
| WAAdmin applicationExceptionHandlingDefaults ancestors -> an
| IdentitySet()
|
| so something is not good. I saw your issue
| http://code.google.com/p/seaside/issues/detail?id=643
| but evaluating
|
| (Smalltalk at: #WASystemConfiguration) allSubclasses do: [ :each |
| each instance perform: #clearSearchContexts.
| each instance perform: #clearDescription ].
|
| did not help.
|
| Any ideas?
|
| thanks
|
|
| On Sun, May 13, 2012 at 6:04 PM, Dale Henrichs < [hidden email]
| > wrote:
|
|
| Mariano,
|
| I've said it before and I'll say it again ... I'd rather have noise
| than real problems go unreported ...
|
| Thanks for taking the time to characterize the problem in detail...
|
|
| Dale
|
| ----- Original Message -----
| | From: "Mariano Martinez Peck" < [hidden email] >
| | To: [hidden email]
|
|
| | Sent: Sunday, May 13, 2012 8:39:52 AM
| | Subject: Re: [Metacello] collecting all packages of a configuration
| |
| |
| |
| |
| | 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...
| |
| |
| | hehehehehe interesting....you discovered a bad side effect of my
| | experiment ;) sorry, I though I was checking in a "clean" image but
| | a bad side effect of my experiment changed the category for
| | extension methods. So...indeed, you are right and the method I have
| | is that I need.
| |
| | Thanks Dale and sorry for the noise.
| |
| |
| |
| |
| | 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:
| | | ' <a href="tel:3.0.6.3" value="+333063">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:
| | | | ' <a href="tel:3.0.6.3" value="+333063">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:
| | | | ' <a href="tel:3.0.6.3" value="+333063">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
|
|



--
Mariano
http://marianopeck.wordpress.com


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Dale Henrichs
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [Metacello] collecting all packages of a configuration

Dale Henrichs
Mariano,

Metacello let's Monticello do the initialization, but decides which sets of packages to load at the same time ... #atomic projects load all of the packages at once, then initialize. While #linear projects load and initialize each package individually ... I believe that Seaside is #linear.

Things can get a bit complicated when #atomic and #linear projects are intermixed (via dependencies)

If you throw a `Transcript show` into the postLoadOver: method (at least that seems like the right one) and run Metacello, you'll have a record of when each package was initialiazed during the load.

You should be able to tell from loadDirective structure what's going to happen...oh wait there are preload and postload doits besides the standard initialization stuff ... but that too is in the loadDirective structure ... typically the ExplicitLoadDirective is used to get a Configuration loaded "right now" during fetch, so focus on the AtomicLoadDirective and LinearLoadDiretives...

If you want to duplicate what Metacello does, you should consider serializing the loadDirectives (in some fashion) so that you can guarantee that you track any behavior changes that I might introduce into Metacello ... I don't have any planned, but you never know when some changes will be called for ...

Dale


----- Original Message -----
| From: "Mariano Martinez Peck" <[hidden email]>
| To: [hidden email]
| Cc: "Seaside - general discussion" <[hidden email]>
| Sent: Thursday, May 17, 2012 11:13:41 AM
| Subject: Re: [Metacello] collecting all packages of a configuration
|
|
|
|
| On Thu, May 17, 2012 at 7:37 PM, Dale Henrichs < [hidden email]
| > wrote:
|
|
| Mariano,
|
| I guess you are trying to upgrade an existing Seaside application?
|
| Are you having trouble doing this upgrade using Metacello, or is this
| a problem trying to do the upgrade using the package order derived
| from the loadDirectives?
|
|
|
| I should explain what I am doing. I am exporting packages using Fuel.
| What I do is to query Metacello to know which packages I need and
| the order (for the future load).
| Then, during load, after having materialized all packages, I iterate
| over the packages (in the order I stored during the export), and I
| initialize the classes for each package.
|
| In this example, I am NOT upgrading nothing. I am just trying to
| import seaside in a clean image using Fuel.
|
|
|
| If the Metacello load works fine,
|
| indeed, it works fine.
|
|
| then I would guess that you're not running your initializers in the
| right order at the right time.
|
| Indeed, I also thought that I have a problem with the initialization.
| I sent this mail because maybe this particular problem moves some
| bell ;)
|
|
| Your little loop over packageNames looks close to what Monticello
| does when it fires the initializers,
|
|
| You mean MCMethodDefinition >> postloadOver: right?
|
|
| but it's not quite the same ... for example Monticello only fires
| initializers for class initialization methods that are changed/new
| during the load.
|
|
| yes, you mean the if: self source ~= aDefinition source right?
| In my case, I am loading methods that DO NOT have source code. So..
|
|
|
| Also, if I remember correctly Metacello fires the initializers for
| Seaside packages immediately after the package is loaded and does
| not wait until the end to fire initializers ...
|
|
|
| mmmm #atomic loader type? where can I see more info about this?
|
|
|
| I'd focus on duplicating the initialization pattern of Metacello
| (instrumenting the Monticello loader where the initializations are
| fired would give you that info).
|
|
|
|
| where can I see this?
|
| Thanks
|
|
|
| Dale
|
| ----- Original Message -----
| | From: "Mariano Martinez Peck" < [hidden email] >
| | To: [hidden email]
|
|
| | Cc: "Seaside - general discussion" <
| | [hidden email] >
| | Sent: Thursday, May 17, 2012 6:13:30 AM
| | Subject: Re: [Metacello] collecting all packages of a configuration
| |
| | Hi Dale. Now I was a little bit more sucessful. But still, I have a
| | problem during the initialization of classes. More precisily in:
| |
| | WAWalkbackErrorHandler class >> initialize
| | WAAdmin applicationExceptionHandlingDefaults at: #exceptionHandler
| | put: self
| |
| | I get a WAAttributeNotFound with #exceptionHandler ... what I do is
| | I
| | follow the order of packages as Metacello answered me, and then I
| | do
| | something like:
| |
| | (packageNames collect: [:each | PackageInfo named: each])
| | do: [:aPackage |
| | "We should not send #initialize to traits"
| | ((aPackage classes select: [:each | each isBehavior])
| | sort: [:a :b | a allSuperclasses size < b allSuperclasses size ])
| | do: [:aClass |
| | Transcript show: 'Initializing class named: ', aClass name; cr.
| | aClass initializeOnLoad]
| | ].
| | ]
| |
| |
| | I have debugged a little bit and it looks like
| |
| | WAAdmin applicationExceptionHandlingDefaults allAttributes -> an
| | IdentityDictionary()
| | WAAdmin applicationExceptionHandlingDefaults ancestors -> an
| | IdentitySet()
| |
| | so something is not good. I saw your issue
| | http://code.google.com/p/seaside/issues/detail?id=643
| | but evaluating
| |
| | (Smalltalk at: #WASystemConfiguration) allSubclasses do: [ :each |
| | each instance perform: #clearSearchContexts.
| | each instance perform: #clearDescription ].
| |
| | did not help.
| |
| | Any ideas?
| |
| | thanks
| |
| |
| | On Sun, May 13, 2012 at 6:04 PM, Dale Henrichs <
| | [hidden email]
| | > wrote:
| |
| |
| | Mariano,
| |
| | I've said it before and I'll say it again ... I'd rather have noise
| | than real problems go unreported ...
| |
| | Thanks for taking the time to characterize the problem in detail...
| |
| |
| | Dale
| |
| | ----- Original Message -----
| | | From: "Mariano Martinez Peck" < [hidden email] >
| | | To: [hidden email]
| |
| |
| | | Sent: Sunday, May 13, 2012 8:39:52 AM
| | | Subject: Re: [Metacello] collecting all packages of a
| | | configuration
| | |
| | |
| | |
| | |
| | | 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...
| | |
| | |
| | | hehehehehe interesting....you discovered a bad side effect of my
| | | experiment ;) sorry, I though I was checking in a "clean" image
| | | but
| | | a bad side effect of my experiment changed the category for
| | | extension methods. So...indeed, you are right and the method I
| | | have
| | | is that I need.
| | |
| | | Thanks Dale and sorry for the noise.
| | |
| | |
| | |
| | |
| | | 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
| |
| |
|
|
|
| --
| Mariano
| http://marianopeck.wordpress.com
|
|
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Free forum by Nabble Edit this page