[Seaside] Re: [Metacello] collecting all packages of a configuration

Thu May 17 18:13:41 UTC 2012

On Thu, May 17, 2012 at 7:37 PM, Dale Henrichs <dhenrich at vmware.com> 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" <marianopeck at gmail.com>
> | To: metacello at googlegroups.com
> | Cc: "Seaside - general discussion" <seaside at lists.squeakfoundation.org>
> | 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 < 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
> |
> |
>

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20120517/1280804f/attachment-0001.htm