August 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Launcher Opening Tiny Windows

by Stephane Ducasse

Thanks eliot. Esteban will look at it. Stef On Wed, Aug 23, 2017 at 4:03 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi, > > I think I have a fix for this. It'll only work if the image has a > non-zero screen size to start with. But it arranges that if the effective > screen size is zero (as it is for headless images) then the VM writes the > savedWindowSize (the windows size the image had in the first place) to the > snapshot instead of the current zero-extent headless screen size. This is > in commit VMMaker.oscog-eem.2265/4bbcf27fb7aab94beb77e4d517ca414d6766e34d. > Please test and let me know if it works or not. > > On Tue, Aug 22, 2017 at 4:28 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Yes I experienced this problem too. I have the impression that during >> the build the size of the window are messed up. >> >> Stef >> >> On Sun, Aug 20, 2017 at 2:44 AM, Tim Mackinnon <tim(a)testit.works> wrote: >> > It's a known problem for any image that was saved in headless mode (not >> > just launcher) - we should find a way to resolve this. >> > >> > Tim >> > >> > Sent from my iPhone >> > >> >> On 20 Aug 2017, at 00:35, Sean P. DeNigris <sean(a)clipperadams.com> >> >> wrote: >> >> >> >> Check out this screenshot. >> >> <http://forum.world.st/file/n4962615/Screenshot_2017-08-19_19.png> >> >> >> >> The red arrow points to an open "window" of a newly created Pharo 6.0 >> >> based >> >> image, minimized to the point of barely being visible. Clicking on it >> >> makes >> >> a title bar somewhat more visible, the edges of which can then be >> >> dragged as >> >> any other window. >> >> >> >> Anyone else seeing this? >> >> >> >> >> >> >> >> ----- >> >> Cheers, >> >> Sean >> >> -- >> >> View this message in context: >> >> http://forum.world.st/Launcher-Opening-Tiny-Windows-tp4962615.html >> >> Sent from the Pharo Smalltalk Developers mailing list archive at >> >> Nabble.com. >> >> >> > >> > >> > > > > -- > _,,,^..^,,,_ > best, Eliot

Aug. 23, 2017

Re: [Pharo-dev] [Pharo-users] TechTalk Dates for the rest of 2017

by Norbert Hartl

I would be in, too. It'll be on 17th of october fix? Norbert > Am 21.08.2017 um 18:38 schrieb Alexandre Bergel <alexandre.bergel(a)me.com>: > > Hi! > > I am currently giving a lecture on Neural Networks and Genetic Algorithm/Programming. > Maybe I could turn this into an express 2 hours mini-lecture. Would this work? > > Anyone is interesting in programming, from scratch, a small artificial intelligence? > > Cheers, > Alexandre > > >> On Aug 21, 2017, at 10:32 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Hi, >> >> We have added dates for tech talk discussions / Demos for the rest of 2017: >> https://association.pharo.org/events >> >> We need to find some topics. In the past we had often formal âtalksâ or demos about >> a topic with discussion afterwards, but a more relaxed form of just an open discussion >> about a topic is possible, too, >> >> If you like to lead one of the dates (all but the November dates are available still), this >> would be great. >> >> If a date does find a topic, we keep it as an open discussion round. >> >> Marcus > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 23, 2017

Re: [Pharo-dev] Launcher Opening Tiny Windows

by Eliot Miranda

Hi, I think I have a fix for this. It'll only work if the image has a non-zero screen size to start with. But it arranges that if the effective screen size is zero (as it is for headless images) then the VM writes the savedWindowSize (the windows size the image had in the first place) to the snapshot instead of the current zero-extent headless screen size. This is in commit VMMaker.oscog-eem.2265/4bbcf27fb7aab94beb77e4d517ca414d6766e34d. Please test and let me know if it works or not. On Tue, Aug 22, 2017 at 4:28 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Yes I experienced this problem too. I have the impression that during > the build the size of the window are messed up. > > Stef > > On Sun, Aug 20, 2017 at 2:44 AM, Tim Mackinnon <tim(a)testit.works> wrote: > > It's a known problem for any image that was saved in headless mode (not > just launcher) - we should find a way to resolve this. > > > > Tim > > > > Sent from my iPhone > > > >> On 20 Aug 2017, at 00:35, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> > >> Check out this screenshot. > >> <http://forum.world.st/file/n4962615/Screenshot_2017-08-19_19.png> > >> > >> The red arrow points to an open "window" of a newly created Pharo 6.0 > based > >> image, minimized to the point of barely being visible. Clicking on it > makes > >> a title bar somewhat more visible, the edges of which can then be > dragged as > >> any other window. > >> > >> Anyone else seeing this? > >> > >> > >> > >> ----- > >> Cheers, > >> Sean > >> -- > >> View this message in context: http://forum.world.st/ > Launcher-Opening-Tiny-Windows-tp4962615.html > >> Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >> > > > > > > -- _,,,^..^,,,_ best, Eliot

Aug. 23, 2017

Re: [Pharo-dev] Catalog statistics (Who know this projects?)

by Dimitris Chloupis

Unfortunately making something beginner friendly is A LOT of work, its indeed super important but for most people, which is logical, getting the code to work first is the no 1 priority. Indeed as a beginner you dont see even 0.00001% of Pharo capabilities. This is why I started a wiki to expose some of the hidden corners of Pharo because if you follow the mailing list you will find a ton of things that you are not aware of and that applies to me that I am not new to Pharo. I have been using Pharo since 2011. So definetly do not think we do not understand the pain for a beginner to get into all this but on the other hand, the hand holding in other programming languages is also very limited. Even with python the material is great to get you started but once you are outside the beginner gate you are all alone digging stack overflow and the dark corners of google search. In the end you will figure out that searching for the answer yourself will become more and more fast than googling it, especially if the answer is not that obvious. Its all part of being a coder :) Remember contributing back even little, counts for a lot. Afterall as Stef so elegant puts it, Pharo belongs to all of us. On Tue, Aug 22, 2017 at 10:08 PM ghoetker <ghoetker(a)me.com> wrote: > Many thanks to Esteban for starting this effort and to everyone who has > contributed. As a newish member of the community, the lack of such > descriptions creates a huge barrier. Not so much that I need to know what > "FlyingMongoose" does, but the presence of so many documented projects in > the catalog makes me feel like I must be "missing" a big part of the Pharo > picture. It gives an unwelcoming face to one of the most welcoming > communities I've encountered in the software world. > > So, extra encouragement to those pitching in and thanks again. > > > > ----- > Glenn Hoetker > ghoetker(a)me.com > http://hoetker.faculty.asu.edu > -- > View this message in context: > http://forum.world.st/Catalog-statistics-Who-know-this-projects-tp4869315p4… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Aug. 22, 2017

Re: [Pharo-dev] Catalog statistics (Who know this projects?)

by Stephane Ducasse

Thanks for the encouragement. I would love to have a crawler that automatically validates distribution where projects available in the distribution are validated (tests green, ...) but we always find something more important to do. Stef On Tue, Aug 22, 2017 at 9:05 PM, ghoetker <ghoetker(a)me.com> wrote: > Many thanks to Esteban for starting this effort and to everyone who has > contributed. As a newish member of the community, the lack of such > descriptions creates a huge barrier. Not so much that I need to know what > "FlyingMongoose" does, but the presence of so many documented projects in > the catalog makes me feel like I must be "missing" a big part of the Pharo > picture. It gives an unwelcoming face to one of the most welcoming > communities I've encountered in the software world. > > So, extra encouragement to those pitching in and thanks again. > > > > ----- > Glenn Hoetker > ghoetker(a)me.com > http://hoetker.faculty.asu.edu > -- > View this message in context: http://forum.world.st/Catalog-statistics-Who-know-this-projects-tp4869315p4… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Aug. 22, 2017

Re: [Pharo-dev] Catalog statistics (Who know this projects?)

by ghoetker

Many thanks to Esteban for starting this effort and to everyone who has contributed. As a newish member of the community, the lack of such descriptions creates a huge barrier. Not so much that I need to know what "FlyingMongoose" does, but the presence of so many documented projects in the catalog makes me feel like I must be "missing" a big part of the Pharo picture. It gives an unwelcoming face to one of the most welcoming communities I've encountered in the software world. So, extra encouragement to those pitching in and thanks again. ----- Glenn Hoetker ghoetker(a)me.com http://hoetker.faculty.asu.edu -- View this message in context: http://forum.world.st/Catalog-statistics-Who-know-this-projects-tp4869315p4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 22, 2017

Re: [Pharo-dev] [ Pharo 70 ] Build 52 to 54

by Stephane Ducasse

I started the list of fleaky tests at the end of this document https://docs.google.com/document/d/13Zv-za9V54aurmRwHSgObqGecN9PY8rc-t8U_oI… On Tue, Aug 22, 2017 at 7:12 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi denis > > you can have a look at > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > I started to crawl this list and log the sporadic failing tests. > But I do it when integrating. > > Stef > > On Tue, Aug 22, 2017 at 6:41 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> Hi. >> >>> >>> 1) we have some sporadic test failures (sometimes network, sometimes >>> some mutex or delay issues). They do not happen all the time and >>> that's why sometimes there is one or two failing tests. We should >>> detect these tests and fix them to be more robust >> >> >> I thing I am responsible for Mutex problems because I wrote a bit naive >> waiting logic in some tests (with the hope that with green threads it will >> not fail). >> So if you have list of failing Mutex tests send it to me. I will fix them. >> >> 2017-08-22 17:51 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>> >>> Hi Marcus, >>> >>> Please, do not relaunch the build if there is a test failure. That >>> simply does not fix the problem, it just adds noise. There are two >>> problems: >>> >>> 1) we have some sporadic test failures (sometimes network, sometimes >>> some mutex or delay issues). They do not happen all the time and >>> that's why sometimes there is one or two failing tests. We should >>> detect these tests and fix them to be more robust >>> >>> >> Note, is there some brave soul that would like to take action here? >>> >>> 2) sometimes the vm crashes while running the tests. We should detect >>> the bug and fix it. >>> >>> >> Note, is there some brave soul that would like to take action here? >>> >>> Now, if we are integrating a fix, this means that the PR was **already >>> validated as green**. That means that the integrated commit can be >>> bootstrapped and tested (and all tests are green). >>> >>> Moreover, running the tests after integration (and its build color) >>> does not change the integration in itself: the commit was already >>> merged and pushed into the main branch, so even if it fails always, >>> it's too late. So, relaunching the build does not really change >>> anything (besides the impression we may have about the build). >>> >>> A complementary solution (that should go together with fixing the >>> tests) is to add a retry policy while running tests in the CI. >>> >>> >> Note, is there some brave soul that would like to take action here? >>> >>> Guille, on holidays from the phone. >>> >>> On 8/22/17, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> > [ Pharo 70 ] Build 52 PR 205 >>> > index-inst-var-should-move-from-Slot-to-IndexedSlot >>> > https://github.com/pharo-project/pharo/pull/205 >>> > https://pharo.fogbugz.com/f/cases/20191 >>> > >>> > Build 53: failed, redone as 54 >>> > >>> > [ Pharo 70 ] Build 54 PR 193 Integrate WebBrowser-Core package to be >>> > able to >>> > open a browser on a URL >>> > https://pharo.fogbugz.com/f/cases/20304 >>> > https://github.com/pharo-project/pharo/pull/193 >>> > >>> > Build 55: failed, redone as 56 (I do not like to use this build numberâ¦ >>> > with builds failing, we will always get the >>> > question âand what was in build XX?). >>> > >>> > [ Pharo 70 ] Build 56 PR 174 >>> > 20260-FastTable-not-support-cell-morphs-with-stepping-animation #174 >>> > https://github.com/pharo-project/pharo/pull/174 >>> > https://pharo.fogbugz.com/f/cases/20260/ >>> > >>> > >>> > >>> >>> >>> -- >>> >>> >>> >>> >>> Guille Polito >>> >>> >>> Research Engineer >>> >>> French National Center for Scientific Research - *http://www.cnrs.fr* >>> <http://www.cnrs.fr> >>> >>> >>> >>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>> >>> *Phone: *+33 06 52 70 66 13 >>> >>

Aug. 22, 2017

Re: [Pharo-dev] [ Pharo 70 ] Build 52 to 54

by Stephane Ducasse

Hi denis you can have a look at https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… I started to crawl this list and log the sporadic failing tests. But I do it when integrating. Stef On Tue, Aug 22, 2017 at 6:41 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > >> >> 1) we have some sporadic test failures (sometimes network, sometimes >> some mutex or delay issues). They do not happen all the time and >> that's why sometimes there is one or two failing tests. We should >> detect these tests and fix them to be more robust > > > I thing I am responsible for Mutex problems because I wrote a bit naive > waiting logic in some tests (with the hope that with green threads it will > not fail). > So if you have list of failing Mutex tests send it to me. I will fix them. > > 2017-08-22 17:51 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >> >> Hi Marcus, >> >> Please, do not relaunch the build if there is a test failure. That >> simply does not fix the problem, it just adds noise. There are two >> problems: >> >> 1) we have some sporadic test failures (sometimes network, sometimes >> some mutex or delay issues). They do not happen all the time and >> that's why sometimes there is one or two failing tests. We should >> detect these tests and fix them to be more robust >> >> >> Note, is there some brave soul that would like to take action here? >> >> 2) sometimes the vm crashes while running the tests. We should detect >> the bug and fix it. >> >> >> Note, is there some brave soul that would like to take action here? >> >> Now, if we are integrating a fix, this means that the PR was **already >> validated as green**. That means that the integrated commit can be >> bootstrapped and tested (and all tests are green). >> >> Moreover, running the tests after integration (and its build color) >> does not change the integration in itself: the commit was already >> merged and pushed into the main branch, so even if it fails always, >> it's too late. So, relaunching the build does not really change >> anything (besides the impression we may have about the build). >> >> A complementary solution (that should go together with fixing the >> tests) is to add a retry policy while running tests in the CI. >> >> >> Note, is there some brave soul that would like to take action here? >> >> Guille, on holidays from the phone. >> >> On 8/22/17, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> > [ Pharo 70 ] Build 52 PR 205 >> > index-inst-var-should-move-from-Slot-to-IndexedSlot >> > https://github.com/pharo-project/pharo/pull/205 >> > https://pharo.fogbugz.com/f/cases/20191 >> > >> > Build 53: failed, redone as 54 >> > >> > [ Pharo 70 ] Build 54 PR 193 Integrate WebBrowser-Core package to be >> > able to >> > open a browser on a URL >> > https://pharo.fogbugz.com/f/cases/20304 >> > https://github.com/pharo-project/pharo/pull/193 >> > >> > Build 55: failed, redone as 56 (I do not like to use this build numberâ¦ >> > with builds failing, we will always get the >> > question âand what was in build XX?). >> > >> > [ Pharo 70 ] Build 56 PR 174 >> > 20260-FastTable-not-support-cell-morphs-with-stepping-animation #174 >> > https://github.com/pharo-project/pharo/pull/174 >> > https://pharo.fogbugz.com/f/cases/20260/ >> > >> > >> > >> >> >> -- >> >> >> >> >> Guille Polito >> >> >> Research Engineer >> >> French National Center for Scientific Research - *http://www.cnrs.fr* >> <http://www.cnrs.fr> >> >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 >> >

Aug. 22, 2017

Re: [Pharo-dev] [ Pharo 70 ] Build 52 to 54

by Stephane Ducasse

On Tue, Aug 22, 2017 at 5:51 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi Marcus, > > Please, do not relaunch the build if there is a test failure. That > simply does not fix the problem, it just adds noise. There are two > problems: > > 1) we have some sporadic test failures (sometimes network, sometimes > some mutex or delay issues). They do not happen all the time and > that's why sometimes there is one or two failing tests. We should > detect these tests and fix them to be more robust > > >> Note, is there some brave soul that would like to take action here? I started to make a log of these tests. > 2) sometimes the vm crashes while running the tests. We should detect > the bug and fix it. > > >> Note, is there some brave soul that would like to take action here? > > Now, if we are integrating a fix, this means that the PR was **already > validated as green**. That means that the integrated commit can be > bootstrapped and tested (and all tests are green). > > Moreover, running the tests after integration (and its build color) > does not change the integration in itself: the commit was already > merged and pushed into the main branch, so even if it fails always, > it's too late. So, relaunching the build does not really change > anything (besides the impression we may have about the build). > > A complementary solution (that should go together with fixing the > tests) is to add a retry policy while running tests in the CI. > > >> Note, is there some brave soul that would like to take action here? > > Guille, on holidays from the phone. Enjoy your vacation :) > > On 8/22/17, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> [ Pharo 70 ] Build 52 PR 205 >> index-inst-var-should-move-from-Slot-to-IndexedSlot >> https://github.com/pharo-project/pharo/pull/205 >> https://pharo.fogbugz.com/f/cases/20191 >> >> Build 53: failed, redone as 54 >> >> [ Pharo 70 ] Build 54 PR 193 Integrate WebBrowser-Core package to be able to >> open a browser on a URL >> https://pharo.fogbugz.com/f/cases/20304 >> https://github.com/pharo-project/pharo/pull/193 >> >> Build 55: failed, redone as 56 (I do not like to use this build numberâ¦ >> with builds failing, we will always get the >> question âand what was in build XX?). >> >> [ Pharo 70 ] Build 56 PR 174 >> 20260-FastTable-not-support-cell-morphs-with-stepping-animation #174 >> https://github.com/pharo-project/pharo/pull/174 >> https://pharo.fogbugz.com/f/cases/20260/ >> >> >> > > > -- > > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 >

Aug. 22, 2017

Re: [Pharo-dev] SystemVersion>>highestUpdate causes FFISharedPool class>>initialize to fail

by Stephane Ducasse

Ok I checked and the Session manager is not the toolRegistry. I do not like the design of the latter: a global variable used from anywhere. Now the alternative is that each tool access other tools via a context object but the question is how to update such context when we have a new tool loaded. Stef On Tue, Aug 22, 2017 at 7:03 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > My impression is that this code is old and we should rewrite it. > Now I wonder why the session manager register itself to the tools. > The idea of the tool registration was that we can swap them to get > different suite of tools. > This was never really used and I would replace that by a tool context > passed around instead of an ugly > global variable (because this is what it is). > > So I wonder why the logic is like that. > SessionManager default registerToolClassNamed: self name > I hope that code relying on the DNU aspect of the tool registry does not > exist. > > Now may be I'm confusing the sessionManager tool registry with the > toolregistry. > > We should really reassess some of the solutions we have. > > stef > > On Tue, Aug 22, 2017 at 6:58 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> >> Le mar. 22 aoÃ»t 2017 Ã 18:33, Alistair Grant <akgrant0710(a)gmail.com> a >> Ã©crit : >> >>> Hi Guille, >>> >>> On Tue, Aug 22, 2017 at 05:55:22PM +0200, Guillermo Polito wrote: >>> > I don't think so... Build number only works from the CI. This means >>> > that if you build your image in your machine you'll have no build >>> > number and then this piece of code will not work neither. Thus maybe >>> > we need to find a separate solution for it? >>> >>> P.S. Shouldn't the highestUpdate still be set as described below? >> >> >> But how do you do it? Imagine I build my image from outsider the ci. >> Where do I get the build number ? In my machine I have no thing such as a >> build or a job. >> >> Pharo should work independently from where it is build. >> >> We should not mistake build number for version number. They do not mean >> the same. >> >> >>> >>> This is an image that presumably came from the CI >>> (http://files.pharo.org/image/70/latest.zip) >>> >>> Thanks, >>> Alistair >>> >>> >>> > On 8/22/17, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> > > Hi Everyone, >>> > > >>> > > I'm attempting to update to the latest Pharo7 image (918efe2, 32 >>> bit), >>> > > but am getting an error while loading OSsubprocess. >>> > > >>> > > The error occurs in FFISharedPool class>>initialize: >>> > > >>> > > >>> > > initialize >>> > > self flag: #removeIt. >>> > > "This IF will be eliminated soon...only here temporary" >>> > > (SystemVersion current highestUpdate >= 50558) >>> > > ifTrue: [ >>> > > SessionManager default registerToolClassNamed: >>> self name >>> > > ] >>> > > ifFalse: [ >>> > > Smalltalk addToStartUpList: self. >>> > > ] >>> > > >>> > > >>> > > because #highestUpdate is nil. >>> > > >>> > > >>> > > The top of the stack is: >>> > > >>> > > UndefinedObject(Object)>>doesNotUnderstand: #'>=' >>> > > FFISharedPool class>>initialize >>> > > MCMethodDefinition>>postloadOver: >>> > > [ :each | each postloadOver: (self obsoletionFor: each) ] in >>> > > MCPackageLoader>>basicLoadDefinitions in Block: [ :each | each >>> postloadOver: >>> > > (self obsoletionFor: ...etc... >>> > > >>> > > >>> > > Based on the method above, it looks like highestUpdate used to be set >>> > > based on the image number, and has presumably broken during the move >>> to >>> > > Pharo 7 and git. >>> > > >>> > > Earlier Pharo 7 images had it set to 0, which doesn't sound right. >>> > > >>> > > Since a build number was recently introduced (fogbugz 20321), should >>> the >>> > > highestUpdate be set to 70000+buildNumber? >>> > > >>> > > E.g. this image has an identifier of: >>> > > >>> > > Pharo 7.0 >>> > > Build information: >>> > > alpha.build.56.sha.918efe28fa3e6ad485b059dbf4ce675fd4086cf6 >>> > > >>> > > So highestUpdate would be 70056. >>> > > >>> > > >>> > > Thanks! >>> > > Alistair >>> > > >>> > > >>> > >>> > >>> > -- >>> > >>> > >>> > >>> > >>> > Guille Polito >>> > >>> > >>> > Research Engineer >>> > >>> > French National Center for Scientific Research - *http://www.cnrs.fr* >>> > <http://www.cnrs.fr> >>> > >>> > >>> > >>> > *Web:* *http://guillep.github.io* <http://guillep.github.io> >>> > >>> > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>> > >>> >>> -- >> >> >> >> Guille Polito >> >> >> Research Engineer >> >> French National Center for Scientific Research - *http://www.cnrs.fr* >> <http://www.cnrs.fr> >> >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> > >

Aug. 22, 2017