October 2014 - Pharo-dev - lists.pharo.org

logCr and friends, why deprecation in 30?Â²

by phil＠highoctane.be

Hello I wanted to know why we deprecated logCr etc. TIA Phil

Oct. 12, 2014

Mysteries of the compiler

by Nicolai Hess

I tried to solve issues "13260 inspecting variables in the debugger fails in some cases" and "14058 Inconsistent information in debugger" and found some oddities in the way opal (compiler and the debuggermap) handles tempory variables. I am not sure if these are bugs. 1. order of temporaries: Evaluating this method |a b c| a:=1. b:=2. c:=3. thisContext tempNames logCr. ["in a block ! " thisContext tempNames logCr . a+b+c ] value. prints in the transcript #(#a #b #c) #(#a #b #c) - ok, both contexts, the method and block context, use the same ordering for the tempories writing on one variable in the block context require an indirection vector for the variable |a b c| a:=1. b:=2. c:=3. thisContext tempNames logCr. [b:=1. thisContext tempNames logCr. a+b+c ] value. here the variable b is written within the block context. This method prints #(#b #a #c) #(#a #c #b) - strange the variable order has changed and is not the same in both contexts. 2. OCOptimizedBlockScope Consider a whileTrue: call ["A-Block"] whileTrue:["B-Block"] or an ifTrue: ("some boolean value") ifTrue:["C-Block"] stepping into the blocks with the debugger and reading the values for a tempoariy variable shows that every block has an OCOpotimizedBlockScope as its scope. Are all 3 blocks the same kind of "optimized blocks"? because -> 3. Blocks within optimized blocks This method prints the number of tempories on the Transcript (the on:do: call is just a dummy for an "block within a block" but the important part is the usage of the three variables in the do-block) |a b c| a:=1. b:=2. c:=3. (c>0) ifTrue:[ [ a asString ] on:Error do:[:ex | a value:a value:b value:c]. ]. thisContext method numTemps logCr. a The output on the transcript is "3" - ok This method is like the one above, but the nested block is in the receiver of the whileTrue:[] call (again, an optimized block, right?) |a b c| a:=1. b:=2. c:=3. [ [ a asString ] on:Error do:[:ex | a value:a value:b value:c]. c <0 ] whileTrue:[]. thisContext method numTemps logCr. a The output on the Transcript is "1" And it depends on the number of used variables in the do-Block The same method but with the do-Block do:[:ex | a value:a value:b] would print 2 as number of temporaries. nicolai

Oct. 12, 2014

Re: [Pharo-dev] OSProcess in 3.0

by David T. Lewis

On Fri, Oct 10, 2014 at 01:32:27PM -0400, David T. Lewis wrote: > > Le 10/10/2014 17:52, David T. Lewis a ?crit : > >>> 2014-10-10 14:09 GMT+02:00 David T. Lewis <lewis(a)mail.msen.com>: > >>> > >>>> > >>>> Right. But please do test it in your applications to be sure, I really > >>>> only > >>>> did simple testing and I am sure there may still chances for problems > >>>> in > >>>> this area. > >>>> > >>> > >>> Hi Dave, > >>> > >>> Would it has a chance of slowing down things a lot? > >>> > >>> There is apparently something going very very slow compared to > >>> OSProcess > >>> 4.5.11 when used from GitFileTree. So slow that I killed the image > >>> building > >>> script before it was over. Reverting GitFileTree to 4.5.11 solved it. > >>> > >> > >> I don't this so, but I am not certain. The update for PipeableOSProcess > >> affects only the methods in PipeableOSProcess class>>command: and > >> closely > >> related methods. If GitFileTree is using that idiom, then it is > >> certainly > >> possible that I have introduced a bug that does not show up in my unit > >> tests. > > > > Typical code in GitFileTree is this: > > > > [ > > c := PipeableOSProcess command: ''. > > output := c output. > > ... > > ] ensure: [c closePipes] > > > > Maybe it's triggering something. > > > > Thierry > > > > Hmmm... I wonder if the #closePipes is causing a problem now. I don't know > if I ever tested to see if sending closePipes works after the pipes are > already closed, and my recent change closes the pipes after #output is > evaluated. I'll check it when I get home. > I tried this in both Squeak trunk and Pharo 3.0: (1 to: 100) collect: [:e | | c output | [c := PipeableOSProcess command: 'ls -lt'. output := c output. ] ensure: [c closePipes]. output ]. I get the expected results, and no open file handles left over. The #closePipes is no longer needed, so this can now be simplified as follows, which also leaves no open file handles: (1 to: 100) collect: [:e | (PipeableOSProcess command: 'ls -lt') output]. I am not sure what the issue is when used with GitFileTree, but it does not look like the change to PipeableOSProcess class>> command: is directly involved. But ... I'm probably missing something. If you are fairly sure the that problem is related to the the PipeableOSProcess change, then the only other thing I can think of right now is that there may be some other places in GitFileTree where PipeableOSProcess is being used in a different way, and maybe I caused a problem there due the the change in the #command: methods. But this a a complete guess, I really do not know. Dave

Oct. 11, 2014

[Pharo4] just 5 tests failing

by Marcus Denker

Here are all the Failing tests in Pharo4, with a link to the issue tracker. We should try to get it green, not much left to do: Related to NativeBoost: ââââââââââââ ReleaseTest>>#testMethodsWithUnboundGlobals https://pharo.fogbugz.com/f/cases/13982 <https://pharo.fogbugz.com/f/cases/13982> AJx64AssemblerTests>>#testStringOps64Mnemonics https://pharo.fogbugz.com/f/cases/14033 <https://pharo.fogbugz.com/f/cases/14033> Related to GT: âââââââ ReleaseTest>>#testUndeclared https://pharo.fogbugz.com/f/cases/14168 <https://pharo.fogbugz.com/f/cases/14168> ClassTest>>#testClassRespectsPolymorphismWithTrait https://pharo.fogbugz.com/f/cases/14172 <https://pharo.fogbugz.com/f/cases/14172> ReleaseTest ââââââââ ObsoleteTest>>#testFixObsoleteSharedPools https://pharo.fogbugz.com/f/cases/14165 <https://pharo.fogbugz.com/f/cases/14165>

Oct. 11, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40298 Home: https://github.com/pharo-project/pharo-core

Oct. 11, 2014

[pharo-project/pharo-core] e02b61: 40298

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: e02b61b339b6a93f43e7d05042b8de38244c30c3 https://github.com/pharo-project/pharo-core/commit/e02b61b339b6a93f43e7d050… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-11 (Sat, 11 Oct 2014) Changed paths: M Manifest-Core.package/extension/RBClassEnvironment/instance/smallLintCritics.st A Manifest-Core.package/extension/RBDoNotSendSuperInitializeInClassSideRule/class/uniqueIdentifierName.st A Manifest-Core.package/extension/RBDoNotSendSuperInitializeInClassSideRule/instance/category.st M Manifest-Core.package/extension/RBVariableEnvironment/instance/smallLintCritics.st M Monticello.package/MCPackageManager.class/class/event registration/registerInterestOnSystemChangesOnAnnouncer_.st A Refactoring-Critics.package/RBDoNotSendSuperInitializeInClassSideRule.class/README.md A Refactoring-Critics.package/RBDoNotSendSuperInitializeInClassSideRule.class/definition.st A Refactoring-Critics.package/RBDoNotSendSuperInitializeInClassSideRule.class/instance/accessing/group.st A Refactoring-Critics.package/RBDoNotSendSuperInitializeInClassSideRule.class/instance/accessing/name.st A Refactoring-Critics.package/RBDoNotSendSuperInitializeInClassSideRule.class/instance/initialization/initialize.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script298.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40298.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40298 14213 Replace Announcer>>#on:send:to:s senders in Monticello https://pharo.fogbugz.com/f/cases/14213 14098 allClassesAndTraits significantly different from allClassesAndTraitsDo: https://pharo.fogbugz.com/f/cases/14098 10288 Add a lint rule to check that class initialize method does not calls super initialize https://pharo.fogbugz.com/f/cases/10288 http://files.pharo.org/image/40/40298.zip

Oct. 11, 2014

Re: [Pharo-dev] Some methods missing in Behavior

by Marcus Denker

> On 10 Oct 2014, at 15:25, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 10 Oct 2014, at 14:36, jdelgado(a)lsi.upc.edu <mailto:jdelgado@lsi.upc.edu> wrote: >> >> Yes, evaluate: >> >> (Behavior new) compile: 'thisIsATest ^2' >> >> > ah, that indeed should workâ¦ I will check and fix it in Pharo3 and Pharo4 > > For Pharo4: https://pharo.fogbugz.com/f/cases/14215/Fix-for-Behavior-new-compile

Oct. 11, 2014

Serious problem with ConfigurationOfBootstrap - Error: Apparent loop in import expansion

by phil＠highoctane.be

Hello, The load of the 0.12.2 version gives a error. Quite annoying as Boostrap is quite needed for webdev :-( What changed? Loading 0.12.2 of ConfigurationOfBootstrap...'Errors in script loaded from /Users/philippeback/project/BuildBaseWorker.st' Error: Apparent loop in import expansion MetacelloVersionConstructor(Object)>>error: MetacelloVersionConstructor>>collectAllVersionsFromVersionImportPragmasInto:using:satisfiedPragmas: MetacelloVersionConstructor>>calculate:project: MetacelloVersionConstructor>>on:project: in Block: [ :cache | ... MetacelloPharo30Platform(MetacelloPlatform)>>stackCacheFor:cacheClass:at:doing: in Block: [ :dict | ... MetacelloPharo30Platform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: in Block: [ ^ aBlock value: dict ] BlockClosure>>on:do: MetacelloPharo30Platform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: MetacelloPharo30Platform(MetacelloPlatform)>>stackCacheFor:cacheClass:at:doing: MetacelloPharo30Platform(MetacelloPlatform)>>stackCacheFor:at:doing: MetacelloVersionConstructor>>on:project: MetacelloVersionConstructor class>>on:project: ConfigurationOfSeaside3>>project MetacelloMCProjectSpec>>projectClassProject MetacelloMCProjectSpec>>version MetacelloMCProjectSpec(MetacelloProjectSpec)>>versionOrNil in Block: [ self version ] BlockClosure>>on:do: MetacelloMCProjectSpec(MetacelloProjectSpec)>>versionOrNil MetacelloMCProjectSpec>>loadPackageList MetacelloMCVersion>>packageAndProjectNamesToLoad:loader: in Block: [ :prj | ... OrderedCollection>>do: MetacelloMCVersion>>packageAndProjectNamesToLoad:loader: MetacelloMCVersion>>defaultPackageNamesToLoad: MetacelloMCVersion>>doLoadRequiredFromArray: in Block: [ ... BlockClosure>>ensure: MetacelloMCVersion>>doLoadRequiredFromArray: MetacelloMCVersion>>load GoferMetacelloLoad>>loadConfiguration GoferMetacelloLoad>>execute Gofer>>execute:do:

Oct. 11, 2014

Re: [Pharo-dev] About ways to participate in community and general negativity

by Ben Coman

Tim Mackinnon wrote: > Hi guys - this was an interesting thread - and exactly the reason why I brought up âZapp Empowermentâ at ESUG this year. just to let you know, based on your enthusiasm for this book, I bought it (but not yet read it). And one minor thought on the original post that didn't otherwise warrant its own reply earlier... I think its important not to quash negativity. Its a reflection of frustrations that community members sometimes feel (as in any situation), and feeling unable to vent is a risk for people drifting away from the community. "Feeling" free to be negative is part of what helps people feel part of a community - but its about how that is done. I felt a bit that the take-away-message from the original post was "be positive" (which some people had issue with) but I think the intent was "be constructive" is criticism. cheers -ben > > I felt the passion from every single one of you - and in fact, everyone had an interesting point to make. I got a bit nervous as I worked up the 40+ replies, but I was pleased that no-one seemed to take great offence as we covered a wide range of related ideas. > > If I could make one small comment - sometimes I think the gems in a reply can easily get lost if you donât pay special attention to how the person(s) reading it might react. I think we all agree that we do like this community and the amazing work it has done (and continues to do) - and so its worth acknowledging someoneâs ideas and then building on them. If you disagree with them however - try acknowledging what they have said and then suggest that there is an equally valid point of view/idea that they can also consider. > > But Iâm also glad we arenât afraid to cover difficult conversations. I do think we can all practice giving and receiving feedback in a way that can keep the energy high. > > Personally I really like that many of the old things are being modernised (GT Inspector blew me away - as it has done for colleagues who donât even use Smalltalk). Equally, finding a way to get some community input via a survey/vote sounds quite interesting to prioritise a few things (possibly not for everything - as we are asking people to invest their spare time and energy on a labor of love - so we should go where the energy is). Equally, anything we can do to help keep the engineering high is equally appreciated - and I have seen it get better and better over the years. > > Tim > > > On 3 Oct 2014, at 12:44, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> Hi, >> >> Iâm writing this because Iâm sad about what is happening in this list. >> Iâm seeing a lot of general negativity and non constructive ways to discuss things. >> Iâm also seeing more and more people using Pharo for their particular interests (which is of course a good thing) but less and less people who contribute back to Pharo. >> Finally, Iâm seeing more frequently an attitude of âcustomerâ, more than the conviction than this, Pharo, is also yoursâ¦ >> >> Please people, we (the pharo âcoreâ team) cannot do everything. We do not have the manpower or the resources to hire manpower. We would like, but we just do not have the resources (is already a blessing that we can work on this, for now: INRIA is paying, but what it pays is *research*, not âpharo the languageâ, so this is a collateral advantageâ¦.) >> >> So, having an OPEN SOURCE project, with limited resources means that there is a lot of things that depend on the community. >> It depends on the community not just to fix, but to enlarge the ecosystem in general too. >> >> So, I refuse to believe that we cannot be a cool and helpful community. >> I refuse to believe that general negativity and bad humor can overcome the joy of participating in this collective effort. >> >> So, here some recommendations for enhance the way we participate: >> >> - Be positive. Just âthis is a s**tâ does not help. Even if it is. >> - Be propositional. Just âthis is a s**tâ, and not telling what you want/prefer does not help. >> - Be proactive. Just âthis is a s**tâ, and not report, discuss and (at least time to time) provide a fix/enhancement does not help. >> >> In conclusion: not helping does not help :) >> After all, this is the âpharo-devâ list. I mean, the list of people wanting to participate from this great, community effort. >> >> cheers, >> Esteban, still grateful of belonging to this community >> >> >> > > >

Oct. 11, 2014

Re: [Pharo-dev] [Moose-dev] [ANN] Test Coverage with Hapao

by Alexandre Bergel

Hi Pavel! Glad to hear that Hapao works on Pharo-minimal. You have raised good points. We will work on this Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Oct 10, 2014, at 3:21 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi Alexandre, > > I would like to see Hapao to be used for coverage testing of the Pharo > kernel classes. I checked that it is possible run it on Pharo-minimal: > > wget http://files.pharo.org/image/40/latest-minimal.zip > > unzip latest-minimal.zip > > ./pharo config http://smalltalkhub.com/mc/Pharo/SystemConfigurations/main > ConfigurationOfSUnit --group=Core,Tests --install=bleedingEdge > > ./pharo Pharo-minimal hapao.st > > where hapao.st loads S2py and Fuel, runs the analysis and exports > result to the a Fuel file: > > Gofer new smalltalkhubUser: 'ObjectProfile' > project: 'S2py'; > package: 'S2py'; > load. > Gofer new smalltalkhubUser: 'Pharo' > project: 'Pharo40'; > package: 'Fuel'; > load. > ! > FLSerializer serialize: (Hapao2 runTestsForClasses: {SUnitTest }) > toFileNamed: 'hapao.fuel'. > Smalltalk exitSuccess. > > > The result can be loaded to the full image with Roassal: > > (FLMaterializer materializeFromFileNamed: 'hapao.fuel' ) visualize. > > It would be great if you will extract all visualisaton code and > MessageTally extensions from the S2py package. > > What are the limitations of Hapao for testing of the core classes? > > Cheers, > -- Pavel > > > 2014-10-07 16:06 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: >> Thanks Maximiliano for your kind words. >> >> Regarding your particular menu entry, I guess I understand well how you did >> it. No need to share it with me then. >> >> Let us know how to adapt Hapao. We will improve it. For example, the small >> window popup at the bottom of the window is not that useful. We will fix >> this... >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> On Oct 6, 2014, at 12:49 PM, Maximiliano Taborda <mtaborda(a)gmail.com> wrote: >> >> Hi Alexandre. >> >> Perfect about the legends problem. Thanks. >> >> And about the best way to exclude some methods, I don't know what it is. I >> use the world menu to run Hapao. In fact, I made a new entry in the world >> menu that fit with my needs, that is: >> - excludes all initialization methods, i.e. selectors named like >> #initialize* >> - excludes all the #new methods >> - excludes all methods that are defined in a protocol named as private, >> i.e. 'accessing - private' >> This new entry checks the coverage over a class/es hierarchy and, also, >> - run only the tests related to this hierarchy >> - not take into account the abstract methods when computing the covered >> percentage; if I have an abstract method without a concrete one implemented >> in all the subclasses, I have a design error, so my real problem is the >> absence of the concrete method and not the absence of the test. >> >> If you are interested I leave you attached to this email the code related to >> this entry. Maybe is not the best way to implement what I need, but is a >> quickly one. >> >> Congratulations for this tool, is great to easily visualize what portion of >> my model are not covered by tests. >> >> Regards. >> Maximiliano >> >> >> >> 2014-10-05 22:27 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: >>> >>> Hi Maximiliano! >>> >>> The legend problem is now fixed. Can you double check please? >>> >>> What would be the best way to exclude some methods? This question slightly >>> rephrased: how do you run Hapao? Programmatically or using the World menu? >>> >>> Cheers, >>> Alexandre >>> >>> >>> On Oct 2, 2014, at 11:34 PM, Maximiliano Taborda <mtaborda(a)gmail.com> >>> wrote: >>> >>>> Hi Alexandre. >>>> >>>> Yes, now it works. Thank you. But, the box with the legends don't show >>>> very well. Like in the attached image: >>>> >>>> <RelativeDate.png> >>>> >>>> And, a question. Is there a way to exclude some methods from the >>>> analysis? I have some class methods, used for initialize some singletons for >>>> example, that I do not want to be considered for coverage. >>>> >>>> Regards. >>>> Maxi >>>> >>>> 2014-10-02 18:39 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: >>>> Hi! >>>> >>>> Sorry, we somehow slightly messed up with the configurations. >>>> I just took the last Pharo 4.0, and loaded Roassal2: >>>> >>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>> Gofer new smalltalkhubUser: 'ObjectProfile' >>>> project: 'Roassal2'; >>>> package: 'ConfigurationOfRoassal2'; >>>> load. >>>> (Smalltalk at: #ConfigurationOfRoassal2) loadDevelopment >>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>> >>>> Then I loaded S2py: >>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>> Gofer new smalltalkhubUser: 'ObjectProfile' >>>> project: 'S2py'; >>>> package: 'S2py'; >>>> load. >>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>> >>>> It works here. >>>> Can you confirm? >>>> >>>> Sorry for having taken long to answer... >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> On Sep 24, 2014, at 8:24 PM, Maximiliano Taborda <mtaborda(a)gmail.com> >>>> wrote: >>>> >>>>> Hi Alexandre, >>>>> >>>>> I want to try Hapao2 to check the coverage level of Chalten, but it's >>>>> not working (at least for me). >>>>> I load Roassal2 and S2py in a fresh 3.0 image like you say and the new >>>>> entries appear in the world menu, but the only option that partially works >>>>> is the one for a particular class (Hapao @ Class ...) and after run all the >>>>> tests (I see the progress showing that) a MNU is raised in the method >>>>> #addMethodEdges:scope:view: of Hapa2 class because RTEdgeBuilder is not >>>>> loaded. >>>>> >>>>> So, could you tell me what I missed please? I need to load another >>>>> thing, which?, at least the package which defines RTEdgeBuilder. >>>>> >>>>> Thanks for your help. >>>>> >>>>> Regards. >>>>> Maxi >>>>> >>>>> 2014-09-16 20:10 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: >>>>> Excellent! >>>>> >>>>> Alexandre >>>>> >>>>> Le 16-09-2014 Ã 16:15, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : >>>>> >>>>>> Great! >>>>>> >>>>>> I will go over it more thoroughly in the following weeks and get back >>>>>> to you with feedback. >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Sep 16, 2014 at 6:03 PM, Alexandre Bergel >>>>>> <alexandre.bergel(a)me.com> wrote: >>>>>> Dear all, >>>>>> >>>>>> We are happy to release Hapao2 for Pharo. Ricard Jacas and Alejandro >>>>>> Infante put quite some work on Spy2 (an Ã¼ber cool profiling framework for >>>>>> Pharo) and Hapao2. >>>>>> Hapao2 is about assessing the test coverage of your code and is a >>>>>> major revamp of Hapao1, which was presented a couple of years ago by >>>>>> Vanessa. >>>>>> Hapao2 does not only list covered and uncovered methods, as most test >>>>>> coverage tool on Earth will do. Hapao gives a great visualization to easily >>>>>> navigate in your code, assess its complexity, and give you a great visual >>>>>> output telling its coverage. >>>>>> >>>>>> You need Roassal in your image: >>>>>> >>>>>> Gofer new smalltalkhubUser: 'ObjectProfile' >>>>>> project: 'Roassal2'; >>>>>> package: 'ConfigurationOfRoassal2'; >>>>>> load. >>>>>> (Smalltalk at: #ConfigurationOfRoassal2) load >>>>>> >>>>>> >>>>>> and you need S2py: >>>>>> MCHttpRepository >>>>>> location: 'http://smalltalkhub.com/mc/ObjectProfile/S2py/main' >>>>>> user: '' >>>>>> password: '' >>>>>> >>>>>> >>>>>> New entries will appear in the world menu: >>>>>> <Screen Shot 2014-09-16 at 11.49.06 AM.png> >>>>>> >>>>>> You can run the test coverage on : >>>>>> - the class classes you have modified, >>>>>> - on a particular >>>>>> - on a particular class category >>>>>> - on the last class categories you have modified >>>>>> - on the last packages you have modified >>>>>> >>>>>> Here is a portion of a large coverage: >>>>>> >>>>>> <Screen Shot 2014-09-16 at 12.00.11 PM.png> >>>>>> >>>>>> A technical description of Hapao may be found on >>>>>> http://bergel.eu/download/papers/Berg12c-HapaoSCP.pdf >>>>>> >>>>>> We are daily using Hapao to help us understand our tests. >>>>>> >>>>>> Cheers, >>>>>> Ricardo, Alejandro & Alexandre >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev(a)iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Every thing has its own flow" >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >> >> <S2py-MaximilianoTaborda.73.mcz> >> >> >

Oct. 10, 2014