Hi Dale. Now I was a little bit more sucessful. But still, I have a problem during the initialization of classes. More precisily in:<br><br>WAWalkbackErrorHandler class >> initialize<br> WAAdmin applicationExceptionHandlingDefaults at: #exceptionHandler put: self<br>
<br>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:<br><br>(packageNames collect: [:each | PackageInfo named: each])<br>
do: [:aPackage |<br> "We should not send #initialize to traits"<br> ((aPackage classes select: [:each | each isBehavior])<br> sort: [:a :b | a allSuperclasses size < b allSuperclasses size ])<br>
do: [:aClass | <br> Transcript show: 'Initializing class named: ', aClass name; cr.<br> aClass initializeOnLoad]<br> ]. <br>
] <br><br><br>I have debugged a little bit and it looks like <br><br>WAAdmin applicationExceptionHandlingDefaults allAttributes -> an IdentityDictionary() <br>WAAdmin applicationExceptionHandlingDefaults ancestors -> an IdentitySet() <br>
<br>so something is not good. I saw your issue <a href="http://code.google.com/p/seaside/issues/detail?id=643">http://code.google.com/p/seaside/issues/detail?id=643</a><br>but evaluating <br><br>(Smalltalk at: #WASystemConfiguration) allSubclasses do: [ :each | <br>
each instance perform: #clearSearchContexts.<br> each instance perform: #clearDescription ].<br><br>did not help. <br><br>Any ideas?<br><br>thanks<br><br><div class="gmail_quote">On Sun, May 13, 2012 at 6:04 PM, Dale Henrichs <span dir="ltr"><<a href="mailto:dhenrich@vmware.com" target="_blank">dhenrich@vmware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Mariano,<br>
<br>
I've said it before and I'll say it again ... I'd rather have noise than real problems go unreported ...<br>
<br>
Thanks for taking the time to characterize the problem in detail...<br>
<div class="im HOEnZb"><br>
Dale<br>
<br>
----- Original Message -----<br>
| From: "Mariano Martinez Peck" <<a href="mailto:marianopeck@gmail.com">marianopeck@gmail.com</a>><br>
| To: <a href="mailto:metacello@googlegroups.com">metacello@googlegroups.com</a><br>
</div><div class="HOEnZb"><div class="h5">| Sent: Sunday, May 13, 2012 8:39:52 AM<br>
| Subject: Re: [Metacello] collecting all packages of a configuration<br>
|<br>
|<br>
|<br>
|<br>
| On Sun, May 13, 2012 at 5:05 PM, Dale Henrichs < <a href="mailto:dhenrich@vmware.com">dhenrich@vmware.com</a><br>
| > wrote:<br>
|<br>
|<br>
| Mariano,<br>
|<br>
| The loadDirectives are actually used for the Metacello load, so you<br>
| are getting the load order from the horse's mouth...<br>
|<br>
| Seaside-Core is one of the first packages that needs to be loaded so<br>
| Seaside-Tools-Core should be loaded _after_ Seaside-Core ...<br>
|<br>
| WARegistry class is in Seaside-Core, but the method WARegistry<br>
| class>>#clearAllHandlers is actually in the Seaside-Tools-Core<br>
| package (*seaside-tools-core) so everything is consistent...<br>
|<br>
|<br>
| hehehehehe interesting....you discovered a bad side effect of my<br>
| experiment ;) sorry, I though I was checking in a "clean" image but<br>
| a bad side effect of my experiment changed the category for<br>
| extension methods. So...indeed, you are right and the method I have<br>
| is that I need.<br>
|<br>
| Thanks Dale and sorry for the noise.<br>
|<br>
|<br>
|<br>
|<br>
| Dale<br>
|<br>
| ----- Original Message -----<br>
| | From: "Mariano Martinez Peck" < <a href="mailto:marianopeck@gmail.com">marianopeck@gmail.com</a> ><br>
| | To: <a href="mailto:metacello@googlegroups.com">metacello@googlegroups.com</a><br>
|<br>
|<br>
| | Sent: Sunday, May 13, 2012 6:50:18 AM<br>
| | Subject: Re: [Metacello] collecting all packages of a configuration<br>
| |<br>
| | Hi Dale. For a different purpose, I need again something related to<br>
| | this.<br>
| | What I actually need is to ask Metacello the list of packages I<br>
| | need<br>
| | when I do load: xxx SORTED by the load order. I mean, I want they<br>
| | to<br>
| | be sorted in the way that those that need to be loaded first go<br>
| | first.<br>
| |<br>
| | Take this example. I have download seaside this way:<br>
| |<br>
| |<br>
| | ((Smalltalk at: #ConfigurationOfSeaside30) project version:<br>
| | #stable)<br>
| | load: #('Base' 'Zinc-Seaside' 'Base Tests' 'RSS-Core'<br>
| | 'Javascript-Core' 'Prototype-Core' 'Scriptaculous-Core'<br>
| | 'JQuery-Core' 'JQuery-UI' 'Seaside-Email' 'Seaside-HTML5'<br>
| | 'Seaside-InternetExplorer' 'Seaside-Examples' 'RSS-Examples'<br>
| | 'Seaside-Tools-Web' 'Scriptaculous-Components' 'Seaside-Welcome'<br>
| | 'Seaside-FileSystem' 'RSS-Tests-Core' 'Javascript-Tests-Core'<br>
| | 'Seaside-Tests-Email' 'Seaside-Tests-Functional'<br>
| | 'Prototype-Tests-Core' 'Scriptaculous-Tests-Core'<br>
| | 'Scriptaculous-Tests-Components' 'JQuery-Tests-Core'<br>
| | 'JQuery-Tests-UI' 'Seaside-Tests-HTML5'<br>
| | 'Seaside-Tests-InternetExplorer' 'Seaside-Tests-Examples'<br>
| | 'Seaside-Tests-Tools-Web' 'Seaside-Tests-UTF8'<br>
| | 'Seaside-Tests-FileSystem' 'Seaside-Tests-Welcome'<br>
| | ).<br>
| |<br>
| | But those pacakages/groups have another dependencies etc etc. So I<br>
| | am<br>
| | using this to query:<br>
| |<br>
| | | pkgs loader |<br>
| | loader := ((Smalltalk at: #ConfigurationOfSeaside30) project<br>
| | version:<br>
| | ' <a href="tel:3.0.6.3" value="+333063">3.0.6.3</a> ')<br>
| | ignoreImage: true;<br>
| | record: #('Base' 'Zinc-Seaside' 'Base Tests' 'RSS-Core'<br>
| | 'Javascript-Core' 'Prototype-Core' 'Scriptaculous-Core'<br>
| | 'JQuery-Core' 'JQuery-UI' 'Seaside-Email' 'Seaside-HTML5'<br>
| | 'Seaside-InternetExplorer' 'Seaside-Examples' 'RSS-Examples'<br>
| | 'Seaside-Tools-Web' 'Scriptaculous-Components' 'Seaside-Welcome'<br>
| | 'Seaside-FileSystem' 'RSS-Tests-Core' 'Javascript-Tests-Core'<br>
| | 'Seaside-Tests-Email' 'Seaside-Tests-Functional'<br>
| | 'Prototype-Tests-Core' 'Scriptaculous-Tests-Core'<br>
| | 'Scriptaculous-Tests-Components' 'JQuery-Tests-Core'<br>
| | 'JQuery-Tests-UI' 'Seaside-Tests-HTML5'<br>
| | 'Seaside-Tests-InternetExplorer' 'Seaside-Tests-Examples'<br>
| | 'Seaside-Tests-Tools-Web' 'Seaside-Tests-UTF8'<br>
| | 'Seaside-Tests-FileSystem' 'Seaside-Tests-Welcome'<br>
| | ).<br>
| | pkgs := OrderedCollection new.<br>
| | loader loadDirective packageDirectivesDo: [:directive | pkgs add:<br>
| | directive spec name ].<br>
| | ^ pkgs<br>
| |<br>
| |<br>
| | It loooks like if that would answer the list of packages in load<br>
| | order, but this is not true. If you inspect that, you obtain this:<br>
| |<br>
| | an OrderedCollection('ConfigurationOfGrease'<br>
| | 'ConfigurationOfGrease'<br>
| | 'ConfigurationOfSPort2' 'ConfigurationOfZincHTTPComponents'<br>
| | 'Grease-Core' 'Grease-Pharo-Core' 'Grease-Core' 'Grease-Pharo-Core'<br>
| | 'Grease-Tests-Core' 'Grease-Tests-Pharo-Core' 'Zinc-HTTP'<br>
| | 'Seaside-Core' 'Seaside-Pharo-Core' 'Seaside-Component'<br>
| | 'Seaside-Canvas' 'Seaside-Pharo-Canvas' 'RSS-Core'<br>
| | 'Javascript-Core'<br>
| | 'Javascript-Pharo-Core' 'Prototype-Core' 'Scriptaculous-Core'<br>
| | 'JQuery-Core' 'JQuery-UI' 'Seaside-Email' 'Seaside-Pharo-Email'<br>
| | 'Seaside-HTML5' 'Seaside-InternetExplorer' 'Seaside-Session'<br>
| | 'Seaside-RenderLoop' 'Seaside-Tools-Core' 'Seaside-Flow'<br>
| | 'Seaside-Examples' 'RSS-Examples' 'Seaside-Widgets'<br>
| | 'Seaside-Tools-Web' 'Seaside-Pharo-Tools-Web' 'Seaside-Environment'<br>
| | 'Seaside-Pharo-Environment' 'Seaside-Development'<br>
| | 'Scriptaculous-Components' 'Zinc-Seaside' 'Seaside-Tests-Core'<br>
| | 'Seaside-Tests-Pharo-Core' 'Seaside-Tests-Session'<br>
| | 'Seaside-Tests-RenderLoop' 'Seaside-Tests-Component'<br>
| | 'Seaside-Tests-Canvas' 'Seaside-Tests-Environment' 'RSS-Tests-Core'<br>
| | 'Javascript-Tests-Core' 'Javascript-Tests-Pharo-Core'<br>
| | 'Seaside-Tests-Email' 'Seaside-Tests-Functional'<br>
| | 'Seaside-Tests-Pharo-Functional' 'Seaside-Tests-Flow'<br>
| | 'Seaside-Welcome' 'Seaside-Pharo-Welcome' 'Prototype-Tests-Core'<br>
| | 'Scriptaculous-Tests-Core' 'Scriptaculous-Tests-Components'<br>
| | 'JQuery-Tests-Core' 'JQuery-Tests-UI' 'Seaside-Tests-HTML5'<br>
| | 'Seaside-Tests-InternetExplorer' 'Seaside-Tests-Examples'<br>
| | 'Seaside-Tests-Tools-Web' 'Seaside-Tests-UTF8'<br>
| | 'Seaside-Tests-Welcome' 'Sport' 'Seaside-FileSystem'<br>
| | 'Seaside-Tests-FileSystem' 'Seaside-Pharo-Continuation'<br>
| | 'Seaside-Tests-Pharo-Continuation' 'Seaside-Pharo-Flow'<br>
| | 'Seaside-Pharo-Development')<br>
| |<br>
| | As you can see, for example, 'Seaside-Tools-Core' is AFTER<br>
| | 'Seaside-Core'. Right? However, for example, WARegistry >><br>
| | #clearAllHandlers (package 'Seaside-Core') has references to<br>
| | WAAdmin<br>
| | (present in 'Seaside-Tools-Core''). So? is 'Seaside-Tools-Core'<br>
| | actually loaded before 'Seaside-Core'? if true, how can I query<br>
| | that<br>
| | to Metacello. If false, why don't you get the ugly Monticello popup<br>
| | saying you that you have dependencies on ...<br>
| |<br>
| | Thanks!<br>
| |<br>
| |<br>
| |<br>
| |<br>
| |<br>
| | On Mon, Dec 5, 2011 at 6:53 PM, Dale Henrichs < <a href="mailto:dhenrich@vmware.com">dhenrich@vmware.com</a><br>
| | ><br>
| | wrote:<br>
| |<br>
| |<br>
| | Mariano,<br>
| |<br>
| | Regarding your complaint about having the OmniBrowser packages show<br>
| | up when you are using the #loadDirective based variant. The 'Core'<br>
| | group for Seaside includes Seaside-Tools-OmniBrowser, so when you<br>
| | load the 'Core' group OmniBrowser is a required package. You are<br>
| | sitting in a Pharo image that already has OmniBrowser loaded, so<br>
| | when you load Seaside30 you don't see the OB packages getting<br>
| | loaded. However, in the #loadDirective variant, you are using<br>
| | #ignoreImage: and when Metacello ignores the image, it ignores the<br>
| | fact that OB is already loaded as well ... If you want to know what<br>
| | would be loaded into the current image, then don't set #ignoreImage<br>
| | to true ... the OmniBrowser packages and any other packages that<br>
| | are<br>
| | already loaded won't show up ...<br>
| |<br>
| | If there is a set of configs that you would like to<br>
| | include/exclude,<br>
| | then a more complex load directive algorithm can be used...<br>
| |<br>
| | Regarding the duplication of packages, I would say that since you<br>
| | are<br>
| | only interested in the list of packages that would be loaded, you<br>
| | can safely ignore the duplicates.<br>
| |<br>
| | Regarding the inclusion of the ConfigurationOfXXX files,<br>
| | technically,<br>
| | those files are needed for a load. No version information is<br>
| | associated with the configuration file, because config files always<br>
| | have their latest available version loaded ... If you want to<br>
| | filter<br>
| | those files out, then there is a more complex loadDirective<br>
| | traversal algorithm you could use, or you can filter out the<br>
| | configs<br>
| | with #beginsWith:...<br>
| |<br>
| |<br>
| | Dale<br>
| |<br>
| | ----- Original Message -----<br>
| |<br>
| | | From: "Mariano Martinez Peck" < <a href="mailto:marianopeck@gmail.com">marianopeck@gmail.com</a> ><br>
| | | To: <a href="mailto:metacello@googlegroups.com">metacello@googlegroups.com</a><br>
| | | Sent: Saturday, December 3, 2011 4:27:13 PM<br>
| |<br>
| |<br>
| | | Subject: Re: [Metacello] collecting all packages of a<br>
| | | configuration<br>
| | |<br>
| | |<br>
| | |<br>
| | |<br>
| | | On Thu, Nov 17, 2011 at 6:57 PM, Dale Henrichs <<br>
| | | <a href="mailto:dhenrich@vmware.com">dhenrich@vmware.com</a><br>
| | | > wrote:<br>
| | |<br>
| | |<br>
| | | Jannik,<br>
| | |<br>
| | | There are two routes you can take to answer your question.<br>
| | | Firstly,<br>
| | | you can directly query the version itself:<br>
| | |<br>
| | | ((ConfigurationOfMetacello project currentVersion)<br>
| | | allPackagesForSpecNamed: 'ALL')<br>
| | | collect: [:spec | spec file ].<br>
| | |<br>
| | | Or you can use #record: and then collect the information you<br>
| | | want:<br>
| | |<br>
| | | | pkgs loader |<br>
| | | loader := (ConfigurationOfMetacello project currentVersion)<br>
| | | ignoreImage: true;<br>
| | | record: 'ALL'.<br>
| | | pkgs := OrderedCollection new.<br>
| | | loader loadDirective packageDirectivesDo: [:directive |pkgs add:<br>
| | | directive spec file ].<br>
| | | pkgs.<br>
| | |<br>
| | |<br>
| | |<br>
| | | Hi Dale. I have notice that both ways are different. For example,<br>
| | | the<br>
| | | first one does not take into account those ConfigurationOfXXX<br>
| | | packages, whereas the second one does. Moreoever, in the second<br>
| | | one,<br>
| | | I see that there are repetitions. For example:<br>
| | |<br>
| | | | pkgs loader |<br>
| | | loader := ((Smalltalk at: #ConfigurationOfSeaside30) project<br>
| | | version:<br>
| | | ' <a href="tel:3.0.6.3" value="+333063">3.0.6.3</a> ')<br>
| | | ignoreImage: true;<br>
| | | record: #('Core' 'Tests' 'Zinc-Seaside' ).<br>
| | | pkgs := OrderedCollection new.<br>
| | | loader loadDirective packageDirectivesDo: [:directive |pkgs add:<br>
| | | directive spec file ].<br>
| | | pkgs.<br>
| | |<br>
| | | size gives me 127, but asSet size, 106. It seems some packages<br>
| | | appear<br>
| | | more than once like ConfigurationOfGrease.<br>
| | |<br>
| | | ConfigurationOfXXX do not have version number in their name, but<br>
| | | the<br>
| | | rest do have.<br>
| | |<br>
| | | Now, the main problem is that none of them is what I need: I need<br>
| | | ALL<br>
| | | the required packages that are needed to load such project with<br>
| | | metacello. I want to capture the exact list of packages needed<br>
| | | when<br>
| | | I do, for example:<br>
| | | ((Smalltalk at: #ConfigurationOfSeaside30) project version:<br>
| | | ' <a href="tel:3.0.6.3" value="+333063">3.0.6.3</a> ')<br>
| | | load: #('Core' 'Tests' 'Zinc-Seaside' ).<br>
| | |<br>
| | | The first one doesn't even take into account ConfigurationOfXX,<br>
| | | so<br>
| | | it<br>
| | | doesn't help me. The second one, not only has repetitions, but<br>
| | | also<br>
| | | it lists packages that I really don't need. For example,<br>
| | | OB-Morphic-lr.164 and Seaside-Tools-OmniBrowser-lr.25. I don't<br>
| | | understand how those packages arrived to the list. If I take a<br>
| | | clean<br>
| | | image, and install Seaside with the way I showed you, those<br>
| | | packages<br>
| | | are not even downloaded. So why do they appear here?<br>
| | |<br>
| | | So...all in all, what I need is a list of the exact packages I<br>
| | | need<br>
| | | to reproduce something I have loaded with Metacello. In other<br>
| | | words,<br>
| | | if I start an image with an empty package-cache, and execute the<br>
| | | load of seaside, how can I know the list of packages that were<br>
| | | downloaded? of course, not inspecting the package-cache ;)<br>
| | |<br>
| | | Thanks in advance Dale!!!<br>
| | |<br>
| | |<br>
| | |<br>
| | |<br>
| | | Dale<br>
| | |<br>
| | |<br>
| | |<br>
| | | ----- Original Message -----<br>
| | | | From: "jannik.laval" < <a href="mailto:jannik.laval@gmail.com">jannik.laval@gmail.com</a> ><br>
| | | | To: <a href="mailto:metacello@googlegroups.com">metacello@googlegroups.com</a><br>
| | | | Sent: Thursday, November 17, 2011 5:11:09 AM<br>
| | | | Subject: [Metacello] collecting all packages of a configuration<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | | Hi guys,<br>
| | | |<br>
| | | |<br>
| | | | With mariano, we had a discussion about a problem I have:<br>
| | | | How can I collect all packages from a configuration with<br>
| | | | resolving<br>
| | | | all sub projects ?<br>
| | | |<br>
| | | |<br>
| | | | Thank you for your help.<br>
| | | | Cheers,<br>
| | | | Jannik<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | | Begin forwarded message:<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | | From: Mariano Martinez Peck < <a href="mailto:marianopeck@gmail.com">marianopeck@gmail.com</a> ><br>
| | | |<br>
| | | | Subject: Re: Metacello question<br>
| | | |<br>
| | | | Date: November 16, 2011 4:09:38 PM GMT+01:00<br>
| | | |<br>
| | | | To: "jannik.laval" < <a href="mailto:jannik.laval@gmail.com">jannik.laval@gmail.com</a> ><br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | | On Wed, Nov 16, 2011 at 11:57 AM, jannik.laval <<br>
| | | | <a href="mailto:jannik.laval@gmail.com">jannik.laval@gmail.com</a> > wrote:<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | | Hi Mariano,<br>
| | | |<br>
| | | |<br>
| | | | I understand your code and It seems to be the same as mine.<br>
| | | | version40 make the same as "project version: '4.0'".<br>
| | | |<br>
| | | |<br>
| | | | The problem is the resolution of internal projects.<br>
| | | | We should collect the methods recursively... and possibly with<br>
| | | | circular dependencies.<br>
| | | | So, Metacello can resolve them, but I do not know Metacello :(<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | | I have no idea :(<br>
| | | | Ask in metacello mailing list: <a href="mailto:metacello@googlegroups.com">metacello@googlegroups.com</a> ,<br>
| | | |<br>
| | | | good luck<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | | Jannik<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | | On Nov 16, 2011, at 15:36 , Mariano Martinez Peck wrote:<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | | On Wed, Nov 16, 2011 at 6:59 AM, jannik.laval <<br>
| | | | <a href="mailto:jannik.laval@gmail.com">jannik.laval@gmail.com</a> > wrote:<br>
| | | |<br>
| | | |<br>
| | | | Hi Mariano,<br>
| | | | How are you ?<br>
| | | | Here, at Bordeaux, I am fine, and all the family too :)<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | | Excellent, nice to hear that :)<br>
| | | | I am in Argentina in holidays (after Smalltalks) and all<br>
| | | | familiy<br>
| | | | good<br>
| | | | as well hahahahah<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | | I have a question about Metacello, and you know well Metacello<br>
| | | | :)<br>
| | | | I would like to collect all the files to load of a<br>
| | | | Configuration<br>
| | | | with<br>
| | | | all dependencies already resolved.<br>
| | | |<br>
| | | | For now, I have this code in a transcript:<br>
| | | | ===<br>
| | | | ConfigurationOfMoose version40 spec packages map select:[:e | e<br>
| | | | isKindOf: MetacelloPackageSpec ]<br>
| | | | thenCollect: [:e | e repositories list isEmpty<br>
| | | | ifTrue: [e file]<br>
| | | | ifFalse: [e repositories list first name, '/' , e file]].<br>
| | | | ===<br>
| | | | It allows me to have all files in ConfigurationOfMoose, but I<br>
| | | | have<br>
| | | | two problems:<br>
| | | |<br>
| | | | - if I change version40 by version42, I have no more the name<br>
| | | | of<br>
| | | | packages.<br>
| | | | Here is an example:<br>
| | | | with version40, the first value of my collection is: '<br>
| | | | <a href="http://www.squeaksource.com/Arki/Arki-Reporter-tg.3" target="_blank">http://www.squeaksource.com/Arki/Arki-Reporter-tg.3</a> '<br>
| | | | with version42, it is: '<br>
| | | | <a href="http://www.squeaksource.com/Arki/Arki-Reporter-Browser" target="_blank">http://www.squeaksource.com/Arki/Arki-Reporter-Browser</a> '<br>
| | | | ==> I have no more the versions to load.<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | | (ConfigurationOfMoose project version: '4.0') packages collect:<br>
| | | | [<br>
| | | | :each | each name ] as: Set.<br>
| | | |<br>
| | | | or ..<br>
| | | |<br>
| | | | (ConfigurationOfMoose project version: '4.2') packages collect:<br>
| | | | [<br>
| | | | :each | each name ] as: Set.<br>
| | | |<br>
| | | | does that help ?<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | | - the second problem is about depending project. Moose load<br>
| | | | other<br>
| | | | projects, and there are some cyclic dependencies between the<br>
| | | | loads:<br>
| | | | for example DSM needs Moose, and Moose loads DSM.....<br>
| | | | I know that Metacello resolves this kind of problems.<br>
| | | |<br>
| | | | So, my question is: is it possible to obtain a list of all<br>
| | | | packages<br>
| | | | of a configuration ?<br>
| | | |<br>
| | | | Thank you<br>
| | | | ---<br>
| | | | Jannik Laval<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | | --<br>
| | | | Mariano<br>
| | | | <a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | | ---<br>
| | | | Jannik Laval<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | | --<br>
| | | | Mariano<br>
| | | | <a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | | ---<br>
| | | | Jannik Laval<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | |<br>
| | | | ---<br>
| | | | Jannik Laval<br>
| | | |<br>
| | |<br>
| | |<br>
| | |<br>
| | | --<br>
| | | Mariano<br>
| | | <a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br>
| | |<br>
| | |<br>
| |<br>
| |<br>
| |<br>
| | --<br>
| | Mariano<br>
| | <a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br>
| |<br>
| |<br>
|<br>
|<br>
|<br>
| --<br>
| Mariano<br>
| <a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br>
|<br>
|<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br><br>