March 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by Aliaksei Syrel

On Wed, Mar 25, 2015 at 5:32 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > I would like to see more opinions or proposals from others. ;) > I agree with Doru. Just checked the image and it seems that there is already quite a number of methods with <example> annotation that behave exactly the same behaviour described by Doru. So maybe we could continue having <example> to show how to create a valid instance of the class that have some value and can work? One benefit is that we could based on <example> show some usefull preview of the class in inspector. Assume having a MultistateButtonMorph with <example> pragma. You can inspect MultistateButtonMorph (class) and will get as preview morph instance of the button. Cheers, Alex

March 25, 2015

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by Torsten Bergmann

"Ben Coman" wrote >The word that I feel best applies to Doru's need is <sample>, to return a fully initialised sample instance that you can play with in the >Inspector.Â When you double-click a method so tagged you can think of it as "give me a sample" of yourself. What would you think of "exemplar" and "give me an examplar of yourself"? Thanks T.

March 25, 2015

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by Torsten Bergmann

March 25, 2015

Re: [Pharo-dev] String>>howManyMatch: Bug or feature ?

by Noury Bouraqadi

Hi Nicolas, > On 24 Mar 2015, at 16:32, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I think you're looking after the number of common chars only at beginning. > Wouldn't the method finder hit a better match? > Yes. your right. I found the method I was actually needing that gives me the behavior I expected. String>>charactersExactlyMatching: > The method works as advertised in the comment. Though I find it very questionnable: > Doesn't "match" imply some other semantic like pattern matching (and thus things like wild character etc...)? > Is such specific behavior usefull? Really? Why/Where? > What is misleading is that the howManyMatch: is in String. I believe it should be moved up to SequencableCollection Noury

March 25, 2015

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by Tudor Girba

The word example is based on previous research. For example: - Modeling Examples to Test and Understand Software, Markus Gaelli, PhD Thesis, 2006 http://scg.unibe.ch/archive/phd/gaelli-phd.pdf - JExample: Exploiting Dependencies Between Tests to Improve Defect Localization, Kuhn etal, 2008 http://scg.unibe.ch/archive/papers/Kuhn08aJExample.pdf (Phexample is also available on SmalltalkHub) The idea is that you learn from concrete (examples) to abstract, and objects are but examples of classes. I think this is a powerful concept that is underutilized and I also think that we will see more of it in the future if we support it a first class concept in our tools. Nevertheless, please, let's focus on the release that comes in a few days. Cheers, Doru On Wed, Mar 25, 2015 at 1:40 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Wed, Mar 25, 2015 at 7:34 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi Torsten, >> >> I think there can be some value in having example code that shows things >> beyond just returning an object. However, I think there is significantly >> more value in examples that do return objects. That is why I would want to >> have example for the more valuable piece, and to eliminate confusions I >> would not even call the others example, but another word, like script: >> >> exampleThatReturnsOneObject >> <example> >> ^ ... >> >> snippetThatDoesOrShowsSomething >> <script> / <exampleScript> / <exampleCode> >> ^ ... >> >> I still think that <script> is enough. The goal of these methods is to >> get the person to run them and observe the side effect, without reusing the >> result. That is what scripts typically do. It should be enough. As for the >> example* methods, most of them can be nicely decomposed into an <example> >> and possibly a <script>. It would be enough. >> > > > I'm not sure of the correct solution, but this semantic doesn't feel right > to me. I've never thought I needed to inspect the result of an example. > An example "does something", like a doIt. I want it to "show" me > something. If the aim of the example was to give an object to Inspect, > then it should explicitly open an Inspector. > > To me a script is definitely NOT an example. A script is something that > provides convenience for performing system maintenance. For example, it > might change system state by resetting a cache. > > The word that I feel best applies to Doru's need is <sample>, to return a > fully initialised sample instance that you can play with in the Inspector. > When you double-click a method so tagged you can think of it as "give me a > sample" of yourself. > > cheers -ben > > > > >> >> Here is more reasons why I would not change <example> now. Until now, >> nobody is really using the <example> except the code that is packaged in >> GT. The only problematic part is: >> >> TigerDemo>> runDemo >> <example> >> ^ self new runDemo >> >> But this one does not even fit your definition of an example of code. >> It's merely a way to trigger the running of the instance. It so happens >> that the class is an example for something else, but this code is not an >> example. It's a script. So, it should be: >> TigerDemo>> runDemo >> <script> >> ^ self new runDemo >> (this solution is already committed in the Athens repo) >> >> This would not even be a new interpretation. In the image, there already >> exists scripts that trigger an example class: >> DynamicSpecExample>> openOnNil >> <script: '(DynamicSpecExample object: nil) open'> >> ... >> ui openWithSpecLayout: layout. >> >> Btw, the <example> check in the CompiledMethod>>isExampleMethod was added >> after the discussion about introducing <example> and this tended to unify >> the meaning with the current example* selectors. We did not catch this >> distinction at that time, but it is clearly a mismatch. So, the actual >> intention of <example> did not change at all, but isExampleMethod enforces >> a new contract on the original one. >> >> So, really, let's not make a larger thing than we have to out of this. We >> really have *one* problem that is not even a problem. The solution from >> Athens should be fine now, and we could remove the <example> pragma check >> from isExampleMethod for now. >> >> Cheers, >> Doru >> >> >> >> On Wed, Mar 25, 2015 at 9:57 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >> >>> Hi Tudor, >>> >>> stay serious: the methods you are talking about were introduced as GT >>> extension following YOUR definition of >>> an example. >>> >>> We could argue what/who was first with <example>, who discussed/patented >>> it first, who has to change the most >>> code now ... but would it move us forward? We do not need a long >>> discussion, we need a solution. >>> >>> The situation is that we have a conflict in the usage of <example> >>> Pragma: >>> >>> We wanted a way to find out the examples given in methods (often >>> hidden in the image and external packages) >>> and also remove the limitation that they have to start with >>> exampleXXX. >>> So I took action to be able to explicitly mark methods that are >>> intended by the author as >>> an "example" by using the <example> pragma. This was integrated in >>> Pharo 4 and is also in use, not in >>> the image but in loadable packages already. My definition of an >>> example is "a general code example". >>> >>> You had another discussion in the context of GT Tools about renaming >>> the <gtExample> into >>> <example> and also meanwhile took action to use use <example>. >>> >>> But you also put the ADDITIONAL meaning behind the pragma that >>> methods marked with <example> >>> should always return an initialized object. >>> >>> And this last part is the only part where our point of views collide. >>> There is no need to explain from your side >>> that it is often valuable to have such example methods that return >>> initialized instance. One can use >>> them to construct other initialized instances, ... >>> >>> Anything I say is that not all "examples" and "example methods" are >>> providing such example instances. >>> So we can not (and should not) ignore the fact that not all methods >>> intended by the author as "examples" >>> follow this additional definition/requirement. >>> >>> So the only difference in our point of view is that you want to mark all >>> of them equally with >>> <example> and assume that all of them return an instance of the same >>> class while I will not >>> because not all examples do that. Some of them are just example methods >>> to demonstrate how >>> to use the class or combine objects or do some action where the return >>> value of the method is >>> uninteresting. >>> >>> So in your definition of <example> pragma you talk about the need for >>> marking methods >>> with "example instances" while I talk about more general examples >>> (examples of code) that >>> can but do not necessarily have to provide such initialized instances. >>> >>> >>> So my proposal is simple and should satisfy both needs: >>> ======================================================= >>> >>> 1. The <example> Pragma can used to mark a method as an "example" >>> method. An example >>> is a method that is intended as an "example of code": >>> >>> tryThisOut >>> <example> >>> >>> Transcript show: 'An example on how to write to the >>> transcript' >>> >>> >>> 2. The <exampleInstance> Pragma can be used to mark methods that >>> return an >>> an example instance: >>> >>> anInstanceA >>> <exampleInstance> >>> >>> ^$A >>> >>> >>> This will solve the issue easily and it will be more clear as THE >>> INTENTION OF THE PRAGMA in >>> both cases FITS WITH THE NAME. Also a tool can query for one or both >>> pragmas and decide if >>> if it wants to inspect/display the result after performing the method or >>> just run it. >>> >>> So this is my proposal to satisfy both POV's. You can argue agains it >>> but not without >>> making another proposal that satisfies both needs. >>> >>> Thanks >>> T. >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

March 25, 2015

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by Ben Coman

On Wed, Mar 25, 2015 at 7:34 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Torsten, > > I think there can be some value in having example code that shows things > beyond just returning an object. However, I think there is significantly > more value in examples that do return objects. That is why I would want to > have example for the more valuable piece, and to eliminate confusions I > would not even call the others example, but another word, like script: > > exampleThatReturnsOneObject > <example> > ^ ... > > snippetThatDoesOrShowsSomething > <script> / <exampleScript> / <exampleCode> > ^ ... > > I still think that <script> is enough. The goal of these methods is to get > the person to run them and observe the side effect, without reusing the > result. That is what scripts typically do. It should be enough. As for the > example* methods, most of them can be nicely decomposed into an <example> > and possibly a <script>. It would be enough. > I'm not sure of the correct solution, but this semantic doesn't feel right to me. I've never thought I needed to inspect the result of an example. An example "does something", like a doIt. I want it to "show" me something. If the aim of the example was to give an object to Inspect, then it should explicitly open an Inspector. To me a script is definitely NOT an example. A script is something that provides convenience for performing system maintenance. For example, it might change system state by resetting a cache. The word that I feel best applies to Doru's need is <sample>, to return a fully initialised sample instance that you can play with in the Inspector. When you double-click a method so tagged you can think of it as "give me a sample" of yourself. cheers -ben > > Here is more reasons why I would not change <example> now. Until now, > nobody is really using the <example> except the code that is packaged in > GT. The only problematic part is: > > TigerDemo>> runDemo > <example> > ^ self new runDemo > > But this one does not even fit your definition of an example of code. It's > merely a way to trigger the running of the instance. It so happens that the > class is an example for something else, but this code is not an example. > It's a script. So, it should be: > TigerDemo>> runDemo > <script> > ^ self new runDemo > (this solution is already committed in the Athens repo) > > This would not even be a new interpretation. In the image, there already > exists scripts that trigger an example class: > DynamicSpecExample>> openOnNil > <script: '(DynamicSpecExample object: nil) open'> > ... > ui openWithSpecLayout: layout. > > Btw, the <example> check in the CompiledMethod>>isExampleMethod was added > after the discussion about introducing <example> and this tended to unify > the meaning with the current example* selectors. We did not catch this > distinction at that time, but it is clearly a mismatch. So, the actual > intention of <example> did not change at all, but isExampleMethod enforces > a new contract on the original one. > > So, really, let's not make a larger thing than we have to out of this. We > really have *one* problem that is not even a problem. The solution from > Athens should be fine now, and we could remove the <example> pragma check > from isExampleMethod for now. > > Cheers, > Doru > > > > On Wed, Mar 25, 2015 at 9:57 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> Hi Tudor, >> >> stay serious: the methods you are talking about were introduced as GT >> extension following YOUR definition of >> an example. >> >> We could argue what/who was first with <example>, who discussed/patented >> it first, who has to change the most >> code now ... but would it move us forward? We do not need a long >> discussion, we need a solution. >> >> The situation is that we have a conflict in the usage of <example> Pragma: >> >> We wanted a way to find out the examples given in methods (often >> hidden in the image and external packages) >> and also remove the limitation that they have to start with exampleXXX. >> So I took action to be able to explicitly mark methods that are >> intended by the author as >> an "example" by using the <example> pragma. This was integrated in >> Pharo 4 and is also in use, not in >> the image but in loadable packages already. My definition of an >> example is "a general code example". >> >> You had another discussion in the context of GT Tools about renaming >> the <gtExample> into >> <example> and also meanwhile took action to use use <example>. >> >> But you also put the ADDITIONAL meaning behind the pragma that methods >> marked with <example> >> should always return an initialized object. >> >> And this last part is the only part where our point of views collide. >> There is no need to explain from your side >> that it is often valuable to have such example methods that return >> initialized instance. One can use >> them to construct other initialized instances, ... >> >> Anything I say is that not all "examples" and "example methods" are >> providing such example instances. >> So we can not (and should not) ignore the fact that not all methods >> intended by the author as "examples" >> follow this additional definition/requirement. >> >> So the only difference in our point of view is that you want to mark all >> of them equally with >> <example> and assume that all of them return an instance of the same >> class while I will not >> because not all examples do that. Some of them are just example methods >> to demonstrate how >> to use the class or combine objects or do some action where the return >> value of the method is >> uninteresting. >> >> So in your definition of <example> pragma you talk about the need for >> marking methods >> with "example instances" while I talk about more general examples >> (examples of code) that >> can but do not necessarily have to provide such initialized instances. >> >> >> So my proposal is simple and should satisfy both needs: >> ======================================================= >> >> 1. The <example> Pragma can used to mark a method as an "example" >> method. An example >> is a method that is intended as an "example of code": >> >> tryThisOut >> <example> >> >> Transcript show: 'An example on how to write to the transcript' >> >> >> 2. The <exampleInstance> Pragma can be used to mark methods that return >> an >> an example instance: >> >> anInstanceA >> <exampleInstance> >> >> ^$A >> >> >> This will solve the issue easily and it will be more clear as THE >> INTENTION OF THE PRAGMA in >> both cases FITS WITH THE NAME. Also a tool can query for one or both >> pragmas and decide if >> if it wants to inspect/display the result after performing the method or >> just run it. >> >> So this is my proposal to satisfy both POV's. You can argue agains it but >> not without >> making another proposal that satisfies both needs. >> >> Thanks >> T. >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

March 25, 2015

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by Tudor Girba

Hi Torsten, I think there can be some value in having example code that shows things beyond just returning an object. However, I think there is significantly more value in examples that do return objects. That is why I would want to have example for the more valuable piece, and to eliminate confusions I would not even call the others example, but another word, like script: exampleThatReturnsOneObject <example> ^ ... snippetThatDoesOrShowsSomething <script> / <exampleScript> / <exampleCode> ^ ... I still think that <script> is enough. The goal of these methods is to get the person to run them and observe the side effect, without reusing the result. That is what scripts typically do. It should be enough. As for the example* methods, most of them can be nicely decomposed into an <example> and possibly a <script>. It would be enough. Here is more reasons why I would not change <example> now. Until now, nobody is really using the <example> except the code that is packaged in GT. The only problematic part is: TigerDemo>> runDemo <example> ^ self new runDemo But this one does not even fit your definition of an example of code. It's merely a way to trigger the running of the instance. It so happens that the class is an example for something else, but this code is not an example. It's a script. So, it should be: TigerDemo>> runDemo <script> ^ self new runDemo (this solution is already committed in the Athens repo) This would not even be a new interpretation. In the image, there already exists scripts that trigger an example class: DynamicSpecExample>> openOnNil <script: '(DynamicSpecExample object: nil) open'> ... ui openWithSpecLayout: layout. Btw, the <example> check in the CompiledMethod>>isExampleMethod was added after the discussion about introducing <example> and this tended to unify the meaning with the current example* selectors. We did not catch this distinction at that time, but it is clearly a mismatch. So, the actual intention of <example> did not change at all, but isExampleMethod enforces a new contract on the original one. So, really, let's not make a larger thing than we have to out of this. We really have *one* problem that is not even a problem. The solution from Athens should be fine now, and we could remove the <example> pragma check from isExampleMethod for now. Cheers, Doru On Wed, Mar 25, 2015 at 9:57 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Tudor, > > stay serious: the methods you are talking about were introduced as GT > extension following YOUR definition of > an example. > > We could argue what/who was first with <example>, who discussed/patented > it first, who has to change the most > code now ... but would it move us forward? We do not need a long > discussion, we need a solution. > > The situation is that we have a conflict in the usage of <example> Pragma: > > We wanted a way to find out the examples given in methods (often hidden > in the image and external packages) > and also remove the limitation that they have to start with exampleXXX. > So I took action to be able to explicitly mark methods that are > intended by the author as > an "example" by using the <example> pragma. This was integrated in > Pharo 4 and is also in use, not in > the image but in loadable packages already. My definition of an example > is "a general code example". > > You had another discussion in the context of GT Tools about renaming > the <gtExample> into > <example> and also meanwhile took action to use use <example>. > > But you also put the ADDITIONAL meaning behind the pragma that methods > marked with <example> > should always return an initialized object. > > And this last part is the only part where our point of views collide. > There is no need to explain from your side > that it is often valuable to have such example methods that return > initialized instance. One can use > them to construct other initialized instances, ... > > Anything I say is that not all "examples" and "example methods" are > providing such example instances. > So we can not (and should not) ignore the fact that not all methods > intended by the author as "examples" > follow this additional definition/requirement. > > So the only difference in our point of view is that you want to mark all > of them equally with > <example> and assume that all of them return an instance of the same class > while I will not > because not all examples do that. Some of them are just example methods to > demonstrate how > to use the class or combine objects or do some action where the return > value of the method is > uninteresting. > > So in your definition of <example> pragma you talk about the need for > marking methods > with "example instances" while I talk about more general examples > (examples of code) that > can but do not necessarily have to provide such initialized instances. > > > So my proposal is simple and should satisfy both needs: > ======================================================= > > 1. The <example> Pragma can used to mark a method as an "example" > method. An example > is a method that is intended as an "example of code": > > tryThisOut > <example> > > Transcript show: 'An example on how to write to the transcript' > > > 2. The <exampleInstance> Pragma can be used to mark methods that return > an > an example instance: > > anInstanceA > <exampleInstance> > > ^$A > > > This will solve the issue easily and it will be more clear as THE > INTENTION OF THE PRAGMA in > both cases FITS WITH THE NAME. Also a tool can query for one or both > pragmas and decide if > if it wants to inspect/display the result after performing the method or > just run it. > > So this is my proposal to satisfy both POV's. You can argue agains it but > not without > making another proposal that satisfies both needs. > > Thanks > T. > > -- www.tudorgirba.com "Every thing has its own flow"

March 25, 2015

Re: [Pharo-dev] GTSpotter initial notice on dark theme

by Tudor Girba

Could you please open an issue for this? Doru On Wed, Mar 25, 2015 at 11:12 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > I am just letting you know :) > > > On 25 Mar 2015, at 11:03, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > It's a bug :) > > Cheers, > Andrei > > On Wed, Mar 25, 2015 at 10:49 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > wrote: > >> Did you notice, that initial notice is not readable on dark theme? >> >> <Screen Shot 2015-03-25 at 10.47.59.png> >> > > > -- www.tudorgirba.com "Every thing has its own flow"

March 25, 2015

Re: [Pharo-dev] collecting Pharo 4.0 Contributors

by Esteban Lorenzano

> On 25 Mar 2015, at 08:57, stepharo <stepharo(a)free.fr> wrote: > > monty should be the guy doing the xml parser improvements > > monty.os(a)engineer.com <mailto:monty.os@engineer.com> still. I would like to have a name :) > > Stef > > Le 24/3/15 15:39, Esteban Lorenzano a Ã©crit : >> Hi, >> >> Iâm collection the list of contributors for this version. >> Since we detect contributors by author stamps: >> >> - some times who made the commit does not reflect all the people who worked on a problem, >> - we consider contributors to Pharo all people who has contributed in any way: discussing things, commenting bugs, doing videos or any kind of documentation, etc. >> the list will be incomplete, so please look for yourself on it and let me know if you are missing: >> >> also, I would like to know who are this two guys: >> - aaef >> - monty >> >> (btwâ¦ we collected so far 76 contributorsâ¦ not bat at all, for a dead language ;) ) >> >> Clara Allende >> Jean Baptiste Arnaud >> Philippe Back >> Clement Bera >> Alexandre Bergel >> Torsten Bergmann >> Vincent Blondeau >> Noury Bouraqadi >> Santiago Bragagnolo >> Johan Brichau >> Sven Van Caekenberghe >> Damien Cassou >> Nicolas Cellier >> Guido Chari >> Dimitris Chloupis >> Andrei Chis >> Ben Coman >> Bernardo Contreras >> Tommaso Dal Sasso >> Jan Van De Sandt >> Christophe Demarey >> Sean DeNigris >> Marcus Denker >> Martin Dias >> Stephane Ducasse >> Stephan Eggermont >> Luc Fabresse >> Johan Fabry >> Hilaire Fernandes >> Jerome Garcia >> Tudor Girba >> Thierry Goubier >> Kris Gybels >> Norbert Hartl >> Dale Henrichs >> Pablo Herrero >> Nicolai Hess >> Pavel Krivanek >> Juraj Kubelka >> Jan Kurs >> Laurent Laffont >> Jannik Laval >> Kevin Lanvin >> Max Leske >> David Lewis >> Diego Lont >> Esteban Lorenzano >> Esteban Maringolo >> Stefan Marr >> Tim Mackinnon >> Max Mattone >> Martin Mc Clure >> Eliot Miranda >> Sean De Nigris >> Alain Plantec >> Guillermo Polito >> Damien Pollet >> Stefan Reichhart >> Mark Rizun >> Udo Schneider >> Ignacio Sniechowski >> Henrik Sperre Johansen >> Igor Stasenko >> Aliaksei Syrel >> Ciprian Teodorov >> Camille Teruel >> Sebastian Tleye >> Yuriy Tymchuk >> Peter Uhnak >> Andres Valloud >> Sven Van Caekenberghe >> Thomas Vincent >> Martin Walk >> Richard Wettel >> >> thanks, >> Esteban >> > >

March 25, 2015

Re: [Pharo-dev] collecting Pharo 4.0 Contributors

by Esteban Lorenzano

> On 24 Mar 2015, at 17:37, kilon alios <kilon.alios(a)gmail.com> wrote: > > I am Dimitris Chloupis, always a honor to contribute to such an awesome project like Pharo. I have not contributed bug fixes but I have contributed with a lot of documentation by porting 5 chapters of PBE to Pharo 3 and many video tutorials. I know you are Kilon. Last year I had to force you to confess :P And we are very grateful for your contributions, they are really important! Esteban > > You cant be a dead language and still the king of live coding , that would be ironic :D > > Nope Pharo is alive and kicking ass . Thanks to all the contributors . > > On Tue, Mar 24, 2015 at 4:39 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > Hi, > > Iâm collection the list of contributors for this version. > Since we detect contributors by author stamps: > > - some times who made the commit does not reflect all the people who worked on a problem, > - we consider contributors to Pharo all people who has contributed in any way: discussing things, commenting bugs, doing videos or any kind of documentation, etc. > > the list will be incomplete, so please look for yourself on it and let me know if you are missing: > > also, I would like to know who are this two guys: > - aaef > - monty > > (btwâ¦ we collected so far 76 contributorsâ¦ not bat at all, for a dead language ;) ) > > Clara Allende > Jean Baptiste Arnaud > Philippe Back > Clement Bera > Alexandre Bergel > Torsten Bergmann > Vincent Blondeau > Noury Bouraqadi > Santiago Bragagnolo > Johan Brichau > Sven Van Caekenberghe > Damien Cassou > Nicolas Cellier > Guido Chari > Dimitris Chloupis > Andrei Chis > Ben Coman > Bernardo Contreras > Tommaso Dal Sasso > Jan Van De Sandt > Christophe Demarey > Sean DeNigris > Marcus Denker > Martin Dias > Stephane Ducasse > Stephan Eggermont > Luc Fabresse > Johan Fabry > Hilaire Fernandes > Jerome Garcia > Tudor Girba > Thierry Goubier > Kris Gybels > Norbert Hartl > Dale Henrichs > Pablo Herrero > Nicolai Hess > Pavel Krivanek > Juraj Kubelka > Jan Kurs > Laurent Laffont > Jannik Laval > Kevin Lanvin > Max Leske > David Lewis > Diego Lont > Esteban Lorenzano > Esteban Maringolo > Stefan Marr > Tim Mackinnon > Max Mattone > Martin Mc Clure > Eliot Miranda > Sean De Nigris > Alain Plantec > Guillermo Polito > Damien Pollet > Stefan Reichhart > Mark Rizun > Udo Schneider > Ignacio Sniechowski > Henrik Sperre Johansen > Igor Stasenko > Aliaksei Syrel > Ciprian Teodorov > Camille Teruel > Sebastian Tleye > Yuriy Tymchuk > Peter Uhnak > Andres Valloud > Sven Van Caekenberghe > Thomas Vincent > Martin Walk > Richard Wettel > > thanks, > Esteban >

March 25, 2015