[Seaside] Re: [Metacello] collecting all packages of a configuration
Mariano Martinez Peck
marianopeck at gmail.com
Thu May 17 13:13:30 UTC 2012
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 <dhenrich at vmware.com> 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" <marianopeck at gmail.com>
> | To: metacello at googlegroups.com
> | 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 < dhenrich at vmware.com
> | > 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" < marianopeck at gmail.com >
> | | To: metacello at googlegroups.com
> |
> |
> | | 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 < dhenrich at vmware.com
> | | >
> | | 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" < marianopeck at gmail.com >
> | | | To: metacello at googlegroups.com
> | | | 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 <
> | | | dhenrich at vmware.com
> | | | > 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" < jannik.laval at gmail.com >
> | | | | To: metacello at googlegroups.com
> | | | | 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 < marianopeck at gmail.com >
> | | | |
> | | | | Subject: Re: Metacello question
> | | | |
> | | | | Date: November 16, 2011 4:09:38 PM GMT+01:00
> | | | |
> | | | | To: "jannik.laval" < jannik.laval at gmail.com >
> | | | |
> | | | |
> | | | |
> | | | |
> | | | | On Wed, Nov 16, 2011 at 11:57 AM, jannik.laval <
> | | | | jannik.laval at gmail.com > 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: metacello at googlegroups.com ,
> | | | |
> | | | | 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 <
> | | | | jannik.laval at gmail.com > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20120517/ae6a3fc5/attachment-0001.htm
More information about the seaside
mailing list