Help on using Git with Pharo
Hi! I have written a help to use Git in Pharo. Execute the following: Metacello new baseline: 'GitHelp'; repository: 'github://bergel/Git-Help:master'; load. It will load a Help topic, available on the Help Browser. If you wish to contribute: https://github.com/bergel/Git-Help One some point, I will propose an inclusion in the base image. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
## 1. Help in general: The in-image help sucks hard⦠monospaced walls of text, no formatting, no styling, no images, and zero discoverability. Some ideas â this is food for thought for moving forward, not something that I would expect anyone would do tomorrow: ### Simple-ish: online frontend * have an online frontend for all the help â because the first place most people will look is Google, and in-image help doesn't even have elementary search * use formatting⦠Pillar, Markdown, RST, AsciiDoc, whatever⦠for the web frontend it doesn't matter, there are nice outputs for all of them * even for the in-image help having some formatting markers might be better than nothing ### Complex-ish * improving in-image help⦠Offray is/was working on Jupyter ( https://try.jupyter.org/) style notebooks. That sounds like a good replacement. * have at least some basic formatting⦠some time ago there was in-image Pillar editor using GT, so it's doable. ## 2. Comments for the git help (I've just skimmed through it briefly) My impression is that it doesn't really describe git in Pharo, which is what we are pushing for⦠it is recommanded to tick the checkbox "Initialize this repository with a
README".
This will ease the initialization of the repository (you will be able to
immediately clone your repo).
GitHub is lying, you can clone it regardless Open the Monticello browser, accessible from the World menu. Add a
filetree:// repository
This is not really describing using Git in Pharo⦠with filetree you could use git forever. You now need to commit and push. These two operations have to be externally
to Pharo.
Only if you use filetree, because filetree doesn't know about git
As a user of Git, you need to know the following: - From Pharo you can _only_ save and load your code frmo the harddisk (see the chapter Alternative for more options)
Partially true. It will always go through disk (obviously), but with remote git repo you don't care about the local repo.
- Identifying difference between versions has to be done externally to Pharo. Actually, this is not that painful. GitKraken offers a nice user interface.
Not true for GitFileTree To sum it up: you've described how to use filetree:// with Git, which was possible years ago, so I am not entirely sure what's the objective. The push for git+pharo is to use git from within Pharo, which means gitfiletree, which allows you to commit, load, diff, push, pull directly from the image. So my point is: if we want to provide help for people, we should push them in the correct direction⦠that is towards git IN pharo. If we push them to not actually use git in Pharo, then we will push them away from our objectives. Peter On Sun, May 8, 2016 at 5:01 AM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi!
I have written a help to use Git in Pharo. Execute the following:
Metacello new baseline: 'GitHelp'; repository: 'github://bergel/Git-Help:master'; load.
It will load a Help topic, available on the Help Browser. If you wish to contribute: https://github.com/bergel/Git-Help
One some point, I will propose an inclusion in the base image.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Peter indeed Alex is not aware that we are actively working on a better integration with a distributed VCS (with for the moment git as target). But the solution should be nicely available. Stef Le 8/5/16 à 17:08, Peter Uhnák a écrit :
## 2. Comments for the git help (I've just skimmed through it briefly)
My impression is that it doesn't really describe git in Pharo, which is what we are pushing forâ¦
indeed Alex is not aware that we are actively working on a better integration with a distributed VCS (with for the moment git as target).
But the solution should be nicely available.
Anything to try ? Alexandre
Le 8/5/16 à 17:08, Peter Uhnák a écrit :
## 2. Comments for the git help (I've just skimmed through it briefly)
My impression is that it doesn't really describe git in Pharo, which is what we are pushing forâ¦
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
So my point is: if we want to provide help for people, we should push them in the correct direction⦠that is towards git IN pharo. If we push them to not actually use git in Pharo, then we will push them away from our objectives. +1
I do not want pharo to be bound to use external merging tools. Stef
So my point is: if we want to provide help for people, we should push them in the correct direction⦠that is towards git IN pharo. If we push them to not actually use git in Pharo, then we will push them away from our objectives. +1
I do not want pharo to be bound to use external merging tools.
Me neither. But the competition is really though. Anyway, letâs see what the future will bring :-) Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Thanks for having looked at it. I have written it because I need a easy-accessible place with code snippet. My underlying question was wether some other may find it useful. It is okay if no :-)
I understand the purpose, which is very important. I only question the content, whether we really want to push users in that direction. I agree with you. But there are several use cases here. Any professional
application has builtin-help. I usually use the built-in help for useful code snippets (e.g., how to add a gtInspector view for example).
Unfortunately I find the builtin-help very unpractical⦠I'd much rather look at actual code samples. In fact on Pharo Days this year Andrei did experiments with GTSpotter, and none of the participants (me included) looked at the builtin help, everyone was looking just at real samples of code. Most people do not seek understanding, only solving their problem⦠which is not bad of itself⦠but we should address both. Does remote git repo works well on OS X? And more importantly, merging is
something that we are still miles away to do it within Pharo, sadly.
I don't see why it wouldn't. There were problems on Windows, but that's related to ProcessWrapper, not gitfiletree. OSSubprocess has maybe fixed that on Windows? Merging will be, unfortunately still a challenge, although GitFileTree-Merger works surprisingly well. But if we push for in-image git, then tools will slowly emerge (as they already do)⦠if we push users out of the image, then there would be much less incentive. Besides anything that's available to you with FileTree, you also have available with GitFileTree (but not vice versa). The objective is to have a single place with that information, accessible
without at looking at videos and browsing mailing list archive :-)
That's why I mentioned centralized front-end for the help with nice search, formatting and everything. Currently achieving this in browser is trivial compared to the work necessary to do it in-imageâ¦
The push for git+pharo is to use git from within Pharo, which means gitfiletree, which allows you to commit, load, diff, push, pull directly from the image.
Yes, that would be great. It _is_. Present tense.
So my point is: if we want to provide help for people, we should push them in the correct direction⦠that is towards git IN pharo.
If we push them to not actually use git in Pharo, then we will push them away from our objectives.
Yes, but that will take years before getting there. And I need to use it now⦠and this help actually does help me (creating a baseline and configuration are unfortunately still serious challenges).
I've been using gitfiletree for more then year and a half without any (major) issues on gitfiletree side. It may take years to have a really good integration, but even now it's much better than just plain filetree, because you are not losing in-image diffs and history, and because you don't need to use an external tool. In any case, I will use this Help for me, and will not try to push it. Btw. if you need a place to store your snippets, take a look at Torsten's QuickAccess https://www.youtube.com/watch?v=j-dTp6i_P3s . I'm using it a lot and it's super cool for snippets. :) On Sun, May 8, 2016 at 6:31 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
So my point is: if we want to provide help for people, we should push them in the correct direction⦠that is towards git IN pharo. If we push them to not actually use git in Pharo, then we will push them away from our objectives. +1
I do not want pharo to be bound to use external merging tools.
Me neither. But the competition is really though.
Anyway, letâs see what the future will bring :-)
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Peter! Thanks for having looked at it. I have written it because I need a easy-accessible place with code snippet. My underlying question was wether some other may find it useful. It is okay if no :-)
The in-image help sucks hard⦠monospaced walls of text, no formatting, no styling, no images, and zero discoverability.
Some ideas â this is food for thought for moving forward, not something that I would expect anyone would do tomorrow:
I agree with you. But there are several use cases here. Any professional application has builtin-help. I usually use the built-in help for useful code snippets (e.g., how to add a gtInspector view for example).
### Simple-ish: online fronted ... ### Complex-ish â¦
Sure, would be great :-)
## 2. Comments for the git help (I've just skimmed through it briefly)
My impression is that it doesn't really describe git in Pharo, which is what we are pushing forâ¦
it is recommanded to tick the checkbox "Initialize this repository with a README". This will ease the initialization of the repository (you will be able to immediately clone your repo).
GitHub is lying, you can clone it regardless
Well.. I am okay living with this lie :-)
- From Pharo you can _only_ save and load your code frmo the harddisk (see the chapter Alternative for more options)
Partially true. It will always go through disk (obviously), but with remote git repo you don't care about the local repo.
Does remote git repo works well on OS X? And more importantly, merging is something that we are still miles away to do it within Pharo, sadly.
To sum it up: you've described how to use filetree:// with Git, which was possible years ago, so I am not entirely sure what's the objective.
The objective is to have a single place with that information, accessible without at looking at videos and browsing mailing list archive :-)
The push for git+pharo is to use git from within Pharo, which means gitfiletree, which allows you to commit, load, diff, push, pull directly from the image.
Yes, that would be great.
So my point is: if we want to provide help for people, we should push them in the correct direction⦠that is towards git IN pharo. If we push them to not actually use git in Pharo, then we will push them away from our objectives.
Yes, but that will take years before getting there. And I need to use it now⦠and this help actually does help me (creating a baseline and configuration are unfortunately still serious challenges). In any case, I will use this Help for me, and will not try to push it. Thanks for having a look at it :-) Cheers, Alexandre
On Sun, May 8, 2016 at 5:01 AM, Alexandre Bergel <alexandre.bergel@me.com> wrote: Hi!
I have written a help to use Git in Pharo. Execute the following:
Metacello new baseline: 'GitHelp'; repository: 'github://bergel/Git-Help:master'; load.
It will load a Help topic, available on the Help Browser. If you wish to contribute: https://github.com/bergel/Git-Help
One some point, I will propose an inclusion in the base image.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alexandre I do not understand why you are so negative. May be people are using git from within Pharo. May be your experience was not good. Now Nicolas is working to bring the possibility to publish on gitlike systems inside pharo. I imagine that when it will be ready to try we will know it. Stef Le 8/5/16 à 18:29, Alexandre Bergel a écrit :
Hi Peter!
Thanks for having looked at it. I have written it because I need a easy-accessible place with code snippet. My underlying question was wether some other may find it useful. It is okay if no :-)
The in-image help sucks hard⦠monospaced walls of text, no formatting, no styling, no images, and zero discoverability.
Some ideas â this is food for thought for moving forward, not something that I would expect anyone would do tomorrow: I agree with you. But there are several use cases here. Any professional application has builtin-help. I usually use the built-in help for useful code snippets (e.g., how to add a gtInspector view for example).
### Simple-ish: online fronted ... ### Complex-ish ⦠Sure, would be great :-)
## 2. Comments for the git help (I've just skimmed through it briefly)
My impression is that it doesn't really describe git in Pharo, which is what we are pushing forâ¦
it is recommanded to tick the checkbox "Initialize this repository with a README". This will ease the initialization of the repository (you will be able to immediately clone your repo).
GitHub is lying, you can clone it regardless Well.. I am okay living with this lie :-)
- From Pharo you can _only_ save and load your code frmo the harddisk (see the chapter Alternative for more options)
Partially true. It will always go through disk (obviously), but with remote git repo you don't care about the local repo. Does remote git repo works well on OS X? And more importantly, merging is something that we are still miles away to do it within Pharo, sadly.
To sum it up: you've described how to use filetree:// with Git, which was possible years ago, so I am not entirely sure what's the objective. The objective is to have a single place with that information, accessible without at looking at videos and browsing mailing list archive :-)
The push for git+pharo is to use git from within Pharo, which means gitfiletree, which allows you to commit, load, diff, push, pull directly from the image. Yes, that would be great.
So my point is: if we want to provide help for people, we should push them in the correct direction⦠that is towards git IN pharo. If we push them to not actually use git in Pharo, then we will push them away from our objectives. Yes, but that will take years before getting there. And I need to use it now⦠and this help actually does help me (creating a baseline and configuration are unfortunately still serious challenges).
In any case, I will use this Help for me, and will not try to push it. Thanks for having a look at it :-)
Cheers, Alexandre
On Sun, May 8, 2016 at 5:01 AM, Alexandre Bergel <alexandre.bergel@me.com> wrote: Hi!
I have written a help to use Git in Pharo. Execute the following:
Metacello new baseline: 'GitHelp'; repository: 'github://bergel/Git-Help:master'; load.
It will load a Help topic, available on the Help Browser. If you wish to contribute: https://github.com/bergel/Git-Help
One some point, I will propose an inclusion in the base image.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Sun, May 08, 2016 at 05:08:37PM +0200, Peter Uhnák wrote:
## 1. Help in general:
The in-image help sucks hard⦠monospaced walls of text, no formatting, no styling, no images, and zero discoverability.
Some ideas â this is food for thought for moving forward, not something that I would expect anyone would do tomorrow:
### Simple-ish: online frontend
* have an online frontend for all the help â because the first place most people will look is Google, and in-image help doesn't even have elementary search * use formatting⦠Pillar, Markdown, RST, AsciiDoc, whatever⦠for the web frontend it doesn't matter, there are nice outputs for all of them * even for the in-image help having some formatting markers might be better than nothing
### Complex-ish
* improving in-image help⦠Offray is/was working on Jupyter (https:// try.jupyter.org/) style notebooks. That sounds like a good replacement. * have at least some basic formatting⦠some time ago there was in-image Pillar editor using GT, so it's doable.
+1 How about WebDoc (or similar) serving up the API with class comments to make it searchable on the web, and a wiki that lowers the cost of contributing? The wiki would also act as a place where the documentation can evolve until it is considered stable enough to include in the image. It can also have links to other blogs, etc. that may not be appropriate for in-image documentation Speaking of wikis, what is the status of the collaborActive book? It usually appears near the top of my google searches, but appears to be quite out of date. I'd be happy to update it a bit while still in the learning phase of Pharo if someone can provide credentials. Cheers, Alistair
How about WebDoc (or similar) serving up the API with class comments to make it searchable on the web
Although the in-image help is really bad, I would argue that for the API itself it's quite the opposite. Pharo is centered around code, so there is a lot of different and amazing ways to search the API and easily find what you are looking for (including trivially scripted searching). I don't think that any web interface can compete with that (unless it's powered by Pharo itself). In fact there used to be WebDoc for Pharo API, however as there are no comments and examples it wasn't useful at all. You can do better search and actually try the code directly in the image, or search for examples. The wiki would also act as a place where the documentation can evolve
until it is considered stable enough to include in the image.
For this we have books imho. Simple documentation should be added to image.
also have links to other blogs, etc. that may not be appropriate for in-image documentation
I don't see why not, but it would be better to just copy the content without having to click (depends on the content).
On 09 May 2016, at 09:37, Peter Uhnák <i.uhnak@gmail.com> wrote:
How about WebDoc (or similar) serving up the API with class comments to make it searchable on the web
Although the in-image help is really bad, I would argue that for the API itself it's quite the opposite. Pharo is centered around code, so there is a lot of different and amazing ways to search the API and easily find what you are looking for (including trivially scripted searching). I don't think that any web interface can compete with that (unless it's powered by Pharo itself).
In fact there used to be WebDoc for Pharo API, however as there are no comments and examples it wasn't useful at all. You can do better search and actually try the code directly in the image, or search for examples.
See http://files.pharo.org/doc/ for WebDoc. I do totally agree with the fact that Pharo is first and foremost an in-image IDE, we should concentrate on that. The web based documentation is mostly relevant for search indexing and newcomers.
The wiki would also act as a place where the documentation can evolve until it is considered stable enough to include in the image.
For this we have books imho. Simple documentation should be added to image.
also have links to other blogs, etc. that may not be appropriate for in-image documentation
I don't see why not, but it would be better to just copy the content without having to click (depends on the content).
Search wise you can use GTSpotter to search help topic, I even added that myself as a plugin to GTSpotter at some point with even the ability to preview help inside GTSpotter. Look wise, sure pharo help isnt the prettiest thing but I would not it say it sucks, it does its job okish, it displays help text. If you want docs that are looking very good, Pillar is doing already that and it outputs in the most portable formats, html and pdf , that makes it easy to take documentation where you cannot use pharo, on tablets and smartphones. As a pharo developer I am very much against of cramming things that already exist outside pharo image and do an incredible good job that would take years if not decades for pharo to catch up , instead of putting things inside to make things harder with close to zero benefit. Lets face it the only reason to put things inside the pharo image is with the promise that we will be modifying , improving and extending them. Documentation however is a large effort by itself , so why not instead of worrying about a Pharo Documentation API , worry about the actual documentation ? Personally I am more interested in reducing the complexity of Pharo and increasing its documentation than the opposite. Funny fact: I used to be a big proponent of onboard/in-image documentation but the great work of the Pillar devs made me change my mind completely. Pillar for me documentation wise is the way forward and it already works incredible well. I would not even complain if the help tool was completely replaced with the a link to the pillar documentation , it does not contain much documentation anyway, nowhere close to the amount and quality of documentation produced by Pillar. On Mon, May 9, 2016 at 10:45 AM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 09 May 2016, at 09:37, Peter Uhnák <i.uhnak@gmail.com> wrote:
How about WebDoc (or similar) serving up the API with class comments to make it searchable on the web
Although the in-image help is really bad, I would argue that for the API itself it's quite the opposite. Pharo is centered around code, so there is a lot of different and amazing ways to search the API and easily find what you are looking for (including trivially scripted searching). I don't think that any web interface can compete with that (unless it's powered by Pharo itself).
In fact there used to be WebDoc for Pharo API, however as there are no comments and examples it wasn't useful at all. You can do better search and actually try the code directly in the image, or search for examples.
See http://files.pharo.org/doc/ for WebDoc.
I do totally agree with the fact that Pharo is first and foremost an in-image IDE, we should concentrate on that. The web based documentation is mostly relevant for search indexing and newcomers.
The wiki would also act as a place where the documentation can evolve until it is considered stable enough to include in the image.
For this we have books imho. Simple documentation should be added to image.
also have links to other blogs, etc. that may not be appropriate for in-image documentation
I don't see why not, but it would be better to just copy the content without having to click (depends on the content).
On 09 May 2016, at 11:10, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Search wise you can use GTSpotter to search help topic, I even added that myself as a plugin to GTSpotter at some point with even the ability to preview help inside GTSpotter.
this would be something nice to add :)
Look wise, sure pharo help isnt the prettiest thing but I would not it say it sucks, it does its job okish, it displays help text.
yes, but we need something better, in the future. Esteban
If you want docs that are looking very good, Pillar is doing already that and it outputs in the most portable formats, html and pdf , that makes it easy to take documentation where you cannot use pharo, on tablets and smartphones.
As a pharo developer I am very much against of cramming things that already exist outside pharo image and do an incredible good job that would take years if not decades for pharo to catch up , instead of putting things inside to make things harder with close to zero benefit.
Lets face it the only reason to put things inside the pharo image is with the promise that we will be modifying , improving and extending them. Documentation however is a large effort by itself , so why not instead of worrying about a Pharo Documentation API , worry about the actual documentation ?
Personally I am more interested in reducing the complexity of Pharo and increasing its documentation than the opposite.
Funny fact: I used to be a big proponent of onboard/in-image documentation but the great work of the Pillar devs made me change my mind completely. Pillar for me documentation wise is the way forward and it already works incredible well. I would not even complain if the help tool was completely replaced with the a link to the pillar documentation , it does not contain much documentation anyway, nowhere close to the amount and quality of documentation produced by Pillar.
On Mon, May 9, 2016 at 10:45 AM Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> wrote:
On 09 May 2016, at 09:37, Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>> wrote:
How about WebDoc (or similar) serving up the API with class comments to make it searchable on the web
Although the in-image help is really bad, I would argue that for the API itself it's quite the opposite. Pharo is centered around code, so there is a lot of different and amazing ways to search the API and easily find what you are looking for (including trivially scripted searching). I don't think that any web interface can compete with that (unless it's powered by Pharo itself).
In fact there used to be WebDoc for Pharo API, however as there are no comments and examples it wasn't useful at all. You can do better search and actually try the code directly in the image, or search for examples.
See http://files.pharo.org/doc/ <http://files.pharo.org/doc/> for WebDoc.
I do totally agree with the fact that Pharo is first and foremost an in-image IDE, we should concentrate on that. The web based documentation is mostly relevant for search indexing and newcomers.
The wiki would also act as a place where the documentation can evolve until it is considered stable enough to include in the image.
For this we have books imho. Simple documentation should be added to image.
also have links to other blogs, etc. that may not be appropriate for in-image documentation
I don't see why not, but it would be better to just copy the content without having to click (depends on the content).
Thanks for all your replies. I like having the in-image documentation, and the books are a great resource. However neither the in-image documentation or books encourage collaboration and updates make their way out relatviely slowly. (I'm assuming the Pillar documentation referred to by Dimitris are the books). I still think there is a place for a wiki. For information that can later be moved either in-image or to one of the books. Even just having pointers to the in-image information and relevant sections within the books will make the information more searchable (the in-image tools not withstanding) and will be useful for newcomers. It can also hold documentation about new features that aren't yet in the books or in-image (I made the same mistake in trying to use filtree with git, instead of gitfiletree). I'd still like to contribute to the collaborActive book (http://pharo.gemtalksystems.com/book). Is it possible to get credentials? Thanks! Alistair
In Pharo you can also load "PharoOnlineHelp" from Catalog Browser. It was an experiment (already back in Pharo 3) from me to provide a web based help system for Pharo. I updated it to work on Pharo 5 now. Primarily this is Zinc serving some HTTP pages. Tutorials can be written in Markdown with rendering in HTML. Bye T.
Gesendet: Dienstag, 10. Mai 2016 um 08:11 Uhr Von: "Alistair Grant" <akgrant0710@gmail.com> An: pharo-dev@lists.pharo.org Betreff: Re: [Pharo-dev] Online documentation (was: Help on using Git with Pharo)
Thanks for all your replies.
I like having the in-image documentation, and the books are a great resource. However neither the in-image documentation or books encourage collaboration and updates make their way out relatviely slowly. (I'm assuming the Pillar documentation referred to by Dimitris are the books).
I still think there is a place for a wiki. For information that can later be moved either in-image or to one of the books. Even just having pointers to the in-image information and relevant sections within the books will make the information more searchable (the in-image tools not withstanding) and will be useful for newcomers. It can also hold documentation about new features that aren't yet in the books or in-image (I made the same mistake in trying to use filtree with git, instead of gitfiletree).
I'd still like to contribute to the collaborActive book (http://pharo.gemtalksystems.com/book). Is it possible to get credentials?
Thanks! Alistair
participants (8)
-
Alexandre Bergel -
Alistair Grant -
Dimitris Chloupis -
Esteban Lorenzano -
Peter Uhnák -
stepharo -
Sven Van Caekenberghe -
Torsten Bergmann