SmalltalkHub bugs & hangs :-(
SmalltalkHub is slow, so donât click too fast :-( While Iâm grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We donât have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long... Itâs better to use some mainstream platform such as github. Weâll we have support for it in Pharo 4? It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo. Noury
My personal opinion on Github and Pharo is that it already works great with Pharo. The workflow with filetree is exactly the same as other languages that gives the added advantage that you can use all the powerful tools you use with other languages for commiting to git and github. I have not experienced any kind of issue of problem using github with Pharo nor my experience has been any worse than other languages. With the use of Baseline you dont even need git installed in your system to install any Pharo project that use git which is a feature I have not seen in other languages. It should be also relative simple to extend ConfigurationBrowser to support github projects via baseline with no need to commit configurations to smalltalkhub. Pharo is already very active in github, many people have ported their projects there including me. Maybe StHub should support also being a portal to github , or uses github as its backend though I have no clue how much work that would involve. Personally I have completely abandoned smaltlalkhub for github because my experience was really bad and I was already very familiar with github. On Thu, Nov 27, 2014 at 12:14 PM, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
SmalltalkHub is slow, so donât click too fast :-(
While Iâm grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We donât have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long...
Itâs better to use some mainstream platform such as github. Weâll we have support for it in Pharo 4?
It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo.
Noury
Hi Kilon, Do you have any documentation on how to use github in Pharo ? What should I install, how to use it ? Thank you. Jannik 2014-11-27 11:29 GMT+01:00 kilon alios <kilon.alios@gmail.com>:
My personal opinion on Github and Pharo is that it already works great with Pharo. The workflow with filetree is exactly the same as other languages that gives the added advantage that you can use all the powerful tools you use with other languages for commiting to git and github. I have not experienced any kind of issue of problem using github with Pharo nor my experience has been any worse than other languages.
With the use of Baseline you dont even need git installed in your system to install any Pharo project that use git which is a feature I have not seen in other languages.
It should be also relative simple to extend ConfigurationBrowser to support github projects via baseline with no need to commit configurations to smalltalkhub.
Pharo is already very active in github, many people have ported their projects there including me.
Maybe StHub should support also being a portal to github , or uses github as its backend though I have no clue how much work that would involve. Personally I have completely abandoned smaltlalkhub for github because my experience was really bad and I was already very familiar with github.
On Thu, Nov 27, 2014 at 12:14 PM, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
SmalltalkHub is slow, so donât click too fast :-(
While Iâm grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We donât have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long...
Itâs better to use some mainstream platform such as github. Weâll we have support for it in Pharo 4?
It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo.
Noury
-- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info http://car.mines-douai.fr/
You dont need anything installed to work with git , apart from git itself. The workflow is the same as with smalltalkhub + the standard workflow of git. I am using filteree which is already included with Pharo. These are the steps from absolute scratch 1) Download git and install it 2) Create an account in Github 3) add a repository in github 4) open the terminal (git in windows comes with its own terminal, macos and linux have own terminals) you can also optionally create a folder for putting all your git projects inside 5) config git using the git config command to add your email 6) copy the adress of your github repo , its on the right side of your central page of your github repo it has a button next to it to copy it 7) paste the adress after the git clone command and hit enter to clone the repo to your local drive 8) Go to pharo , open monticello and add for you new package a repo , choose gitfilete 9) filetree with open a file browser dialog, navigate to the folder you clone your gihub repo and press open 10) click save as usual to save code , add a commit message, I also copy the commit message to add it also in the git commit 11) go back to the terminal and cd to your git folder of your project 12) I use git status to see which files the filetree has created , Packages have their own folders and so does each class, with also a folder for instance and class side. Each methods has its own file, additional files exist for metadata. 13) git add the package folders. A simple git add of a folder will add all subfolders and files included in the folder. 14) git commit -am "paste here the copied message from monticello, or add your own commit message" 15) git push If you exclude step (8) and (9) the rest is normal git workflow Thats for setting up from there on for committing you will repeat only steps (10) - (15). There is also gitfiletree that automates this manual process but I like being in control to what is commited to my git repo. Gitfiletree has a chapter in Pharo For the Enterprise book. Github has extensive documentation for git and github. Git website also has documentation that is easy to follow and expose how powerful git really is. Its actually very simple and easy to do. On Thu, Nov 27, 2014 at 12:32 PM, jannik laval <jannik.laval@gmail.com> wrote:
Hi Kilon,
Do you have any documentation on how to use github in Pharo ? What should I install, how to use it ?
Thank you. Jannik
2014-11-27 11:29 GMT+01:00 kilon alios <kilon.alios@gmail.com>:
My personal opinion on Github and Pharo is that it already works great with Pharo. The workflow with filetree is exactly the same as other languages that gives the added advantage that you can use all the powerful tools you use with other languages for commiting to git and github. I have not experienced any kind of issue of problem using github with Pharo nor my experience has been any worse than other languages.
With the use of Baseline you dont even need git installed in your system to install any Pharo project that use git which is a feature I have not seen in other languages.
It should be also relative simple to extend ConfigurationBrowser to support github projects via baseline with no need to commit configurations to smalltalkhub.
Pharo is already very active in github, many people have ported their projects there including me.
Maybe StHub should support also being a portal to github , or uses github as its backend though I have no clue how much work that would involve. Personally I have completely abandoned smaltlalkhub for github because my experience was really bad and I was already very familiar with github.
On Thu, Nov 27, 2014 at 12:14 PM, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
SmalltalkHub is slow, so donât click too fast :-(
While Iâm grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We donât have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long...
Itâs better to use some mainstream platform such as github. Weâll we have support for it in Pharo 4?
It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo.
Noury
--
~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info http://car.mines-douai.fr/
Thank you Kilon, Jannik 2014-11-27 11:53 GMT+01:00 kilon alios <kilon.alios@gmail.com>:
You dont need anything installed to work with git , apart from git itself. The workflow is the same as with smalltalkhub + the standard workflow of git.
I am using filteree which is already included with Pharo. These are the steps from absolute scratch
1) Download git and install it
2) Create an account in Github
3) add a repository in github
4) open the terminal (git in windows comes with its own terminal, macos and linux have own terminals) you can also optionally create a folder for putting all your git projects inside
5) config git using the git config command to add your email
6) copy the adress of your github repo , its on the right side of your central page of your github repo it has a button next to it to copy it
7) paste the adress after the git clone command and hit enter to clone the repo to your local drive
8) Go to pharo , open monticello and add for you new package a repo , choose gitfilete
9) filetree with open a file browser dialog, navigate to the folder you clone your gihub repo and press open
10) click save as usual to save code , add a commit message, I also copy the commit message to add it also in the git commit
11) go back to the terminal and cd to your git folder of your project
12) I use git status to see which files the filetree has created , Packages have their own folders and so does each class, with also a folder for instance and class side. Each methods has its own file, additional files exist for metadata.
13) git add the package folders. A simple git add of a folder will add all subfolders and files included in the folder.
14) git commit -am "paste here the copied message from monticello, or add your own commit message"
15) git push
If you exclude step (8) and (9) the rest is normal git workflow
Thats for setting up from there on for committing you will repeat only steps (10) - (15).
There is also gitfiletree that automates this manual process but I like being in control to what is commited to my git repo. Gitfiletree has a chapter in Pharo For the Enterprise book.
Github has extensive documentation for git and github. Git website also has documentation that is easy to follow and expose how powerful git really is.
Its actually very simple and easy to do.
On Thu, Nov 27, 2014 at 12:32 PM, jannik laval <jannik.laval@gmail.com> wrote:
Hi Kilon,
Do you have any documentation on how to use github in Pharo ? What should I install, how to use it ?
Thank you. Jannik
2014-11-27 11:29 GMT+01:00 kilon alios <kilon.alios@gmail.com>:
My personal opinion on Github and Pharo is that it already works great with Pharo. The workflow with filetree is exactly the same as other languages that gives the added advantage that you can use all the powerful tools you use with other languages for commiting to git and github. I have not experienced any kind of issue of problem using github with Pharo nor my experience has been any worse than other languages.
With the use of Baseline you dont even need git installed in your system to install any Pharo project that use git which is a feature I have not seen in other languages.
It should be also relative simple to extend ConfigurationBrowser to support github projects via baseline with no need to commit configurations to smalltalkhub.
Pharo is already very active in github, many people have ported their projects there including me.
Maybe StHub should support also being a portal to github , or uses github as its backend though I have no clue how much work that would involve. Personally I have completely abandoned smaltlalkhub for github because my experience was really bad and I was already very familiar with github.
On Thu, Nov 27, 2014 at 12:14 PM, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
SmalltalkHub is slow, so donât click too fast :-(
While Iâm grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We donât have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long...
Itâs better to use some mainstream platform such as github. Weâll we have support for it in Pharo 4?
It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo.
Noury
--
~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info http://car.mines-douai.fr/
-- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info http://car.mines-douai.fr/
Le 27/11/2014 11:29, kilon alios a écrit :
My personal opinion on Github and Pharo is that it already works great with Pharo. The workflow with filetree is exactly the same as other languages that gives the added advantage that you can use all the powerful tools you use with other languages for commiting to git and github. I have not experienced any kind of issue of problem using github with Pharo nor my experience has been any worse than other languages.
With git, don't you lost the capability to browse the history of changes in your code? Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
2014-12-01 11:21 GMT+01:00 Hilaire <hilaire@drgeo.eu>:
Le 27/11/2014 11:29, kilon alios a écrit :
My personal opinion on Github and Pharo is that it already works great with Pharo. The workflow with filetree is exactly the same as other languages that gives the added advantage that you can use all the powerful tools you use with other languages for commiting to git and github. I have not experienced any kind of issue of problem using github with Pharo nor my experience has been any worse than other languages.
With git, don't you lost the capability to browse the history of changes in your code?
Not with GitFileTree. You get an as good or even better history (i.e. garanteed merge: its common to see long project histories in mcz with missing versions in history, with sometimes merge failures in Monticello as a consequence). You can also browse changes in subsets: all versions of a method across hundreds of packages versions, you could track all versions of a class, etc... All this is local and synchronized to the remote: you have a complete local history, which makes querying the history a lot easier (than downloading hundreds of mcz(s) from smalltalkhub). It is also convenient to be able to commit properly without an internet connection. A true competitor to Pharo+git is a database-based system with replication / merge. I think the Squeak side has it (I remember Eliot talking about that). Thierry
Hilaire
-- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
No of course not. That would have been a deal braker. Personally I prefer using Sourcetree to browser history of commits than using the pharo on board tools. Pharo is good on that respect, but sourcetree is better and smartgit I have used in the past. It also has nice visualisation for branches , merges etc. I have not shown these features in my video tutorial as I was planning to show them to a separate tutorial. I would not mind bypassing monticello completely since its usage is unnecessary at least to me with all these git tools that one can download and use for free. The same is true for other IDEs out there , generally people prefer using dedicate tools. Usually dedicate tools are hard to beat this is why I believe modularising Pharo is extremely important as will make integrating external tools way easier. I think however that Roassal can be used to visualise in similar way the history as Sourcetree does. So pharo is not far from it but as always its a matter of someone doing the hard work. On Mon, Dec 1, 2014 at 12:21 PM, Hilaire <hilaire@drgeo.eu> wrote:
Le 27/11/2014 11:29, kilon alios a écrit :
My personal opinion on Github and Pharo is that it already works great with Pharo. The workflow with filetree is exactly the same as other languages that gives the added advantage that you can use all the powerful tools you use with other languages for commiting to git and github. I have not experienced any kind of issue of problem using github with Pharo nor my experience has been any worse than other languages.
With git, don't you lost the capability to browse the history of changes in your code?
Hilaire
-- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
Am 01.12.14 12:34, schrieb kilon alios:
No of course not. That would have been a deal braker.
Personally I prefer using Sourcetree to browser history of commits than using the pharo on board tools. Pharo is good on that respect, but sourcetree is better Alas Sourcetree is only available for Windows and Mac OSX. Non-portable programs die with their system. Closed source programs die with their company.
That's one of the reasons I like Pharo: it's open source and I was able to port the VM to my prefered OS (Ok, NativeBoost is still missing (not working) but the rest is doing fine). Furthermore I really enjoy Squeak's and Pharo ecosystem. The more tools and frameworks are inside the less they depend on the underlying OS. Andreas
and smartgit I have used in the past. It also has nice visualisation for branches , merges etc. I have not shown these features in my video tutorial as I was planning to show them to a separate tutorial. I would not mind bypassing monticello completely since its usage is unnecessary at least to me with all these git tools that one can download and use for free. The same is true for other IDEs out there , generally people prefer using dedicate tools.
Usually dedicate tools are hard to beat this is why I believe modularising Pharo is extremely important as will make integrating external tools way easier.
I think however that Roassal can be used to visualise in similar way the history as Sourcetree does. So pharo is not far from it but as always its a matter of someone doing the hard work.
On Mon, Dec 1, 2014 at 12:21 PM, Hilaire <hilaire@drgeo.eu <mailto:hilaire@drgeo.eu>> wrote:
Le 27/11/2014 11:29, kilon alios a écrit : > My personal opinion on Github and Pharo is that it already works great > with Pharo. The workflow with filetree is exactly the same as other > languages that gives the added advantage that you can use all the > powerful tools you use with other languages for commiting to git and > github. I have not experienced any kind of issue of problem using github > with Pharo nor my experience has been any worse than other languages. >
With git, don't you lost the capability to browse the history of changes in your code?
Hilaire
-- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
El Mon Dec 01 2014 at 12:19:53 PM, Andreas Wacknitz <A.Wacknitz@gmx.de> escribió:
Am 01.12.14 12:34, schrieb kilon alios:
No of course not. That would have been a deal braker.
Personally I prefer using Sourcetree to browser history of commits than using the pharo on board tools. Pharo is good on that respect, but sourcetree is better
Alas Sourcetree is only available for Windows and Mac OSX. Non-portable programs die with their system. Closed source programs die with their company.
It's not a matter of SourceTree or other program, it's about your git GUI app of preference. You can use plain git from the command line if you prefer. The git repo is portable, the client is up to you.
"It's not a matter of SourceTree or other program, it's about your git GUI app of preference. You can use plain git from the command line if you prefer. The git repo is portable, the client is up to you." +1000 exactly and that is something I advocate. You cant use Sourcetree on linux ? no problemo use SmartGit you prefer using Emacs ? no problemo use magit. you prefer the terminal ? no problemo use the terminal. The cool thing is that it does not really matter what you choose because all tools follow the git workflow, the rest is just a matter of preference. The disadvantage of sticking just with Pharo ? you will be lucky to be able to use a single tool and you will be also lucky if that tool has a substantial fraction of the features of some of the external tools. Bigger community , bigger competition and cooperation. Quantity brings quality. "Non-portable programs die with their system." Good luck waiting for MacOS and Windows to die. "Closed source programs die with their company." a) if something "dies" that does not make it useless b) The beauty of capitalism is that as long there is demand there is going to be supply. So you will never run out of options. Aint working like that with open source I am afraid. I am all for open source, I am a huge fan and if I could I would use 100% open source if it satisfied me but you cant just push under the carpet the advantages of closed source software even if you are Richard Stallman. Plus we are MIT not GPL ;)
Am 01.12.14 um 19:56 schrieb kilon alios:
"It's not a matter of SourceTree or other program, it's about your git GUI app of preference. You can use plain git from the command line if you prefer.
The git repo is portable, the client is up to you."
+1000
exactly and that is something I advocate.
You cant use Sourcetree on linux ? no problemo use SmartGit
you prefer using Emacs ? no problemo use magit.
you prefer the terminal ? no problemo use the terminal. I prefer the Smalltalk environment.
The cool thing is that it does not really matter what you choose because all tools follow the git workflow, the rest is just a matter of preference.
The disadvantage of sticking just with Pharo ? you will be lucky to be able to use a single tool and you will be also lucky if that tool has a substantial fraction of the features of some of the external tools.
Bigger community , bigger competition and cooperation. Quantity brings quality.
Sorry, if that would be true then Java or C# would be of extraordinary quality. Smalltalk has been there for more than 30 years and will probably another 30 years. Hypes come and go. Quantity for me seems more like the opposite of quality.
"Non-portable programs die with their system."
Good luck waiting for MacOS and Windows to die. Why shouldn't they be able to die? There have been other successful companies before. Do you remember Netware? The market leader in networking, almost gone. What about DEC? Gone. Windows is already declining and the Microsoft desparately tries to find new ways to get back. Regarding Apple: They seem to be more interested in iPhone and iPad than in Macs. Obviously they earn a lot more in this field. IMO Apple and Microsoft have one thing in common these days: they make their products life style products that can be used by everybody. Alas for your work needs their operating systems get worse with every release. Windows XP and Snow Leopard are being seen as the best versions by some...
Nothing lasts forever so you can be sure that Windows and Mac OSX will die some day.
"Closed source programs die with their company."
a) if something "dies" that does not make it useless
b) The beauty of capitalism is that as long there is demand there is going to be supply. So you will never run out of options. Aint working like that with open source I am afraid.
That is not quite true. Look at what Oracle did with Solaris: They are not interested in the mass market. If you don't have millions (better billions) to spend they don't care about you. That's also possible in capitalism: you can ask very high prices so most people and companies cannot (or will not) be able to affort it or you can deny to sell a product. You don't even need a good explanation for it.
I am all for open source, I am a huge fan and if I could I would use 100% open source if it satisfied me but you cant just push under the carpet the advantages of closed source software even if you are Richard Stallman. Plus we are MIT not GPL ;)
My comment was not about discussing the pros and cons of closed versus open source software. My concerns are more about reliability. For me it's totally Ok to use git for versioning IF the tools are there. Squak and Pharo have decent versioning systems that suit their internal needs. There is room for improvements, that's for sure. For me Smalltalk is a system and not a simple language with some arbitrary tools that can be replaced easily. Andreas
My comment was not about discussing the pros and cons of closed versus open source software. My concerns are more about reliability. For me it's totally Ok to use git for versioning IF the tools are there. Squak and Pharo have decent versioning systems that suit their internal needs. There is room for improvements, that's for sure. For me Smalltalk is a system and not a simple language with some arbitrary tools that can be replaced easily.
The problem is whether the tools you choose for "commoditized" tasks (e.g. SCM) limit the amount of manpower that could contribute to your open source project. Forks and pull-requests are the way most open source projects fix bugs and integrates enhancements. You can't do branching with current tooling (read: Monticello) without suffering proportional to its complexity. No one said tools can be replaced easily, and that's the reason we still use Monticello, some of us backed by old mcz files, others already using some git behind it. Regards,
"I prefer the Smalltalk environment." so do I "Sorry, if that would be true then Java or C# would be of extraordinary quality. Smalltalk has been there for more than 30 years and will probably another 30 years. Hypes come and go. Quantity for me seems more like the opposite of quality." True ? Smalltalk cannot even begin to compete with the tools and library support of these two behemoths programming languages. That does not mean Java is not ugly or that some of the complain people have with it are not valid and justified complains but still does not change the fact that because of the size of the community it has produced a lot more top quality libraries and tools than any programming language. The "quantity brings quality" is not just a computer world rule its pretty much the fabric of our cosmos that through failures and bad designs more elegant and beautiful , sophisticate designs emerge. Its something that has been happening for billions of years and I doubt will change any time soon. "Why shouldn't they be able to die? products that can be used by everybody. Alas for your work needs their operating systems get worse with every release. Windows XP and Snow Leopard are being seen as the best versions by some... Nothing lasts forever so you can be sure that Windows and Mac OSX will die some day." Win XP is the crappiest OS I ever used win 7 dances around it , its still old crappy windows but way way better. Yosemite has its share of issues but for me so far with the excepetion of problematic CUDAS drivers, had no issues at all with it. I use also UBUNTU 14.04 it offers better support for my system and works like a charm. I seriously dont see this "OS get worse thing". Will one day those OS die ? sure but I doubt I will be alive so there is no reason for me to worry about it. "That's also possible in capitalism: you can ask very high prices so most people and companies cannot (or will not) be able to affort it" I am not going to debate capitalism and its problems, of course I agree that huge companies care only about making money and not for the well being of the consumers. This is why I am here , this is why I support open source and this is why I support Pharo but I cant just turn zealot and refuse the usefulness and expertise of much commercial software out there. All I said is that if there is demand there is going to be supply. Everybody wants to make money and this is why when and if a software dies it gets replaced by something else often better alternative. "For me Smalltalk is a system and not a simple language with some arbitrary tools that can be replaced easily." Its not as hard as you may think to kinda emulate Smalltalk with other programming languages. Actually Pharo has some fierce competition out there as languages are more and more interested into live coding and creating an enviroment for the developer. Smalltalk still has the edge on this because it had an early start but if the example of Swift is any indication its definetly a lesson that languages have not any issue catching up with the Smalltalk world. The question is not if but when other languages come side by side with the abilities of Pharo how you keep pharo developers with pharo ? I think the only answer is by making sure Pharo remains fresh , modern and in sync with modern technology. Git is just a small part of the equation. On the other hand you need also , what Pharo already does to a great extend, innovation to bring new more developers. So I think the right balance is "give something new but also allow me to use my old familiar tools". I am very glad that people behind Pharo realise and materialse this balance. On Mon, Dec 1, 2014 at 9:46 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
My comment was not about discussing the pros and cons of closed versus open source software. My concerns are more about reliability. For me it's totally Ok to use git for versioning IF the tools are there. Squak and Pharo have decent versioning systems that suit their internal needs. There is room for improvements, that's for sure. For me Smalltalk is a system and not a simple language with some arbitrary tools that can be replaced easily.
The problem is whether the tools you choose for "commoditized" tasks (e.g. SCM) limit the amount of manpower that could contribute to your open source project.
Forks and pull-requests are the way most open source projects fix bugs and integrates enhancements. You can't do branching with current tooling (read: Monticello) without suffering proportional to its complexity.
No one said tools can be replaced easily, and that's the reason we still use Monticello, some of us backed by old mcz files, others already using some git behind it.
Regards,
2014-12-02 6:22 GMT-03:00 kilon alios <kilon.alios@gmail.com>:
"I prefer the Smalltalk environment."
so do I
"Sorry, if that would be true then Java or C# would be of extraordinary quality. Smalltalk has been there for more than 30 years and will probably another 30 years. Hypes come and go. Quantity for me seems more like the opposite of quality."
True ? Smalltalk cannot even begin to compete with the tools and library support of these two behemoths programming languages. That does not mean Java is not ugly or that some of the complain people have with it are not valid and justified complains but still does not change the fact that because of the size of the community it has produced a lot more top quality libraries and tools than any programming language. The "quantity brings quality" is not just a computer world rule its pretty much the fabric of our cosmos that through failures and bad designs more elegant and beautiful , sophisticate designs emerge. Its something that has been happening for billions of years and I doubt will change any time soon.
Developers in Smalltalk community have higher standards for quality. What is perceived as a quality product in Python, Java or C# is not perceived the same for seasoned Smalltalk developers. On the other side, you should measure and compare the ratio of created OSS in Java projects versus which of them are viewed as "quality" and by whom. Of course Java has hundreds of libraries but when you go down to details many of them are not really well designed (for example try to adapt just one quality library - cited by hundreds of scientific papers - made for processing human genomes to other organisms, try to extend with new visualizations as Alex is doing with Roassal).
"Why shouldn't they be able to die?
products that can be used by everybody. Alas for your work needs their operating systems get worse with every release. Windows XP and Snow Leopard are being seen as the best versions by some...
Nothing lasts forever so you can be sure that Windows and Mac OSX will die some day."
Win XP is the crappiest OS I ever used win 7 dances around it , its still old crappy windows but way way better. Yosemite has its share of issues but for me so far with the excepetion of problematic CUDAS drivers, had no issues at all with it. I use also UBUNTU 14.04 it offers better support for my system and works like a charm. I seriously dont see this "OS get worse thing". Will one day those OS die ? sure but I doubt I will be alive so there is no reason for me to worry about it.
"That's also possible in capitalism: you can ask very high prices so most people and companies cannot (or will not) be able to affort it"
I am not going to debate capitalism and its problems, of course I agree that huge companies care only about making money and not for the well being of the consumers. This is why I am here , this is why I support open source and this is why I support Pharo but I cant just turn zealot and refuse the usefulness and expertise of much commercial software out there. All I said is that if there is demand there is going to be supply. Everybody wants to make money and this is why when and if a software dies it gets replaced by something else often better alternative.
"For me Smalltalk is a system and not a simple language with some arbitrary tools that can be replaced easily."
Its not as hard as you may think to kinda emulate Smalltalk with other programming languages. Actually Pharo has some fierce competition out there as languages are more and more interested into live coding and creating an enviroment for the developer. Smalltalk still has the edge on this because it had an early start but if the example of Swift is any indication its definetly a lesson that languages have not any issue catching up with the Smalltalk world.
The question is not if but when other languages come side by side with the abilities of Pharo how you keep pharo developers with pharo ? I think the only answer is by making sure Pharo remains fresh , modern and in sync with modern technology. Git is just a small part of the equation. On the other hand you need also , what Pharo already does to a great extend, innovation to bring new more developers. So I think the right balance is "give something new but also allow me to use my old familiar tools". I am very glad that people behind Pharo realise and materialse this balance.
On Mon, Dec 1, 2014 at 9:46 PM, Esteban A. Maringolo <emaringolo@gmail.com
wrote:
My comment was not about discussing the pros and cons of closed versus open source software. My concerns are more about reliability. For me it's totally Ok to use git for versioning IF the tools are there. Squak and Pharo have decent versioning systems that suit their internal needs. There is room for improvements, that's for sure. For me Smalltalk is a system and not a simple language with some arbitrary tools that can be replaced easily.
The problem is whether the tools you choose for "commoditized" tasks (e.g. SCM) limit the amount of manpower that could contribute to your open source project.
Forks and pull-requests are the way most open source projects fix bugs and integrates enhancements. You can't do branching with current tooling (read: Monticello) without suffering proportional to its complexity.
No one said tools can be replaced easily, and that's the reason we still use Monticello, some of us backed by old mcz files, others already using some git behind it.
Regards,
2014-12-02 12:22 GMT+03:00 kilon alios <kilon.alios@gmail.com>:
True ? Smalltalk cannot even begin to compete with the tools and library support of these two behemoths programming languages.
Just for few cents. If you group this million tools by logical functionality I'm sure it will be much less then smalltalk systems have. Most tools just repeat each other. And you know most smalltalk development tools are absent in other systems. And every year when I read ESUG presentations I see another batch of new tools. I'm not see such progress in another languages.
On Tue, Dec 2, 2014 at 5:21 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2014-12-02 12:22 GMT+03:00 kilon alios <kilon.alios@gmail.com>:
True ? Smalltalk cannot even begin to compete with the tools and library support of these two behemoths programming languages.
Just for few cents. If you group this million tools by logical functionality I'm sure it will be much less then smalltalk systems have. Most tools just repeat each other. And you know most smalltalk development tools are absent in other systems. And every year when I read ESUG presentations I see another batch of new tools. I'm not see such progress in another languages.
Man, have had to debug some JavaScript of late, what I nightmarish experience... Phil
Denis wrote:
Kilon wrote: Smalltalk cannot even begin to compete with the tools and library support of these two behemoths programming languages. Â Just for few cents. If you group this million tools by logical functionality I'm sure it will be much less then smalltalk systems have. Most tools just repeat each other. And you >know most smalltalk development tools are absent in other systems. And every year when I read ESUG presentations I see another batch of new tools. I'm not see >such progress in another languages. Â +1
I tried several of the git tools and basically they all do the same, some at a different level or different representations. There are a few differences in features. Smalltalk has a long history in good tools. Also for versioning (ENVY comes to mind). I like that we can use git - but in the end I fear we somehow will come to a point where it does not fit our needs or provide enough flexibility. That does not mean that we should not use it. But we should be prepared with own tools as well. Bye T.
Am 02.12.2014 um 19:51 schrieb Torsten Bergmann <astares@gmx.de>:
Denis wrote:
Kilon wrote: Smalltalk cannot even begin to compete with the tools and library support of these two behemoths programming languages.
Just for few cents. If you group this million tools by logical functionality I'm sure it will be much less then smalltalk systems have. Most tools just repeat each other. And you >know most smalltalk development tools are absent in other systems. And every year when I read ESUG presentations I see another batch of new tools. I'm not see >such progress in another languages.
+1
I tried several of the git tools and basically they all do the same, some at a different level or different representations. There are a few differences in features.
Smalltalk has a long history in good tools. Also for versioning (ENVY comes to mind).
I like that we can use git - but in the end I fear we somehow will come to a point where it does not fit our needs or provide enough flexibility. That does not mean that we should not use it. But we should be prepared with own tools as well.
Bye T.
+1
On Dec 1, 2014, at 8:21 AM, Hilaire <hilaire@drgeo.eu> wrote:
With git, don't you lost the capability to browse the history of changes in your code?
Hilaire
Some IDEs like WebStorm can should you history based on the git repo commit history. But for us is more theoretical than practical so, unfortunately it feels like a no to us.
On 07 Jan 2015, at 13:15, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
On Dec 1, 2014, at 8:21 AM, Hilaire <hilaire@drgeo.eu <mailto:hilaire@drgeo.eu>> wrote:
With git, don't you lost the capability to browse the history of changes in your code?
Hilaire
The history mechanism needs to be changed to query the git repo. Marcus
On 27 Nov 2014, at 11:14, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
SmalltalkHub is slow, so donât click too fast :-(
While Iâm grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We donât have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long...
Itâs better to use some mainstream platform such as github. Weâll we have support for it in Pharo 4?
It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo.
I think it is important to have a serious online system written in Pharo and in daily use (you know, eat your own dog food). There is also a difference between the system itself and the way it is deployed/managed. Please do not underestimate how much work this is for something that is used so heavily, like StHub. But yes, we can/should do better. Sven And like others said, you can start using git(hub) anytime you want, many people do. But be prepared to learn lots of new stuff. And you'll lose some in-image tools (a deal breaker for me).
Am 27.11.2014 um 11:46 schrieb Sven Van Caekenberghe:
On 27 Nov 2014, at 11:14, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
SmalltalkHub is slow, so donât click too fast :-(
While Iâm grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We donât have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long...
Itâs better to use some mainstream platform such as github. Weâll we have support for it in Pharo 4?
It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo. I think it is important to have a serious online system written in Pharo and in daily use (you know, eat your own dog food).
There is also a difference between the system itself and the way it is deployed/managed.
Please do not underestimate how much work this is for something that is used so heavily, like StHub.
Yes, this is important for Pharo in some way. But such a the system have to be maintained and developed further/keept up to date, otherwise it has a bad impact. But i have the feeling in Pharo so many cool things started and then slowly waste away ... Why? The Community is to small, ... the cool guys move further. The PhD is finished ... Gaps hard to close. Would be sad, if this happens to SmalltalkHub. There should be only 2-3 public, open source key systems (or type of systems) where to put the focus on and give them a long term perspective & support from the association / consortium or other donators. And the systems and its building blocks should move with Pharo in the future. And the system should be in some obviously way special & exceptional ... and part of the "Pharo Masterplan". (a) Data Analysis & Visualization System => ?? MOOSE ?? => Key Building Blocks: f.e. Roassal2/3D, ZincHTTP, NeoCSV, NeoJSON, ... (b) Online/Web System => ?? SmalltalkHub ?? => Key Building Blocks: f.e. Amber, Seaside, ZincHTTP, NeoCSV, NeoJSON, ... (c) A Cool Game (would love it) => ??? => Key Building Blocks: ??? (d) ??? I know, it is easy to say. But the best promotion for Pharo are cool systems in Pharo. But maybe Pharo has not more potential than doing one type of systems right and ongoing, f.e. (a). I have no problems with it. I like Pharo for (a) as i like Erlang/OTP for (b) and Lua/Love2D for (c). The coolest would be a perspective for (a), (b), (c) and (d) in Pharo. But i do not see it ... But yes, it is better to do one or two things good, and not a five bad. My 2 cents, Volkert
Can't we have a part of Pharo days devoted to fixing some of this? It would be useful I am sure. STH is putting Amber, Pharo and Mongo together and is a good case for scaling properly. This may feel like a problem but is actually a huge opportunity to get our stack right. Amber is now 0.13 and much nicer inside. Is there a way to get a clone of the current running system for experimenting? I mean with the whole stack as it is? And STH can also be extended to point to Github resources, commits, ... and add a lot of readability to the packages. I do not want STH to die. It is useful. It is a great case. It works and just needs a little love. Who wants to help here? I think that I can, just need some interested people to join. Mail me. Phil Le 29 nov. 2014 01:08, "volkert@nivoba.de" <volkert@nivoba.de> a écrit :
Am 27.11.2014 um 11:46 schrieb Sven Van Caekenberghe:
On 27 Nov 2014, at 11:14, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
SmalltalkHub is slow, so donât click too fast :-(
While Iâm grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We donât have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long...
Itâs better to use some mainstream platform such as github. Weâll we have support for it in Pharo 4?
It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo.
I think it is important to have a serious online system written in Pharo and in daily use (you know, eat your own dog food).
There is also a difference between the system itself and the way it is deployed/managed.
Please do not underestimate how much work this is for something that is used so heavily, like StHub.
Yes, this is important for Pharo in some way. But such a the system have to be maintained and developed further/keept up to date, otherwise it has a bad impact. But i have the feeling in Pharo so many cool things started and then slowly waste away ... Why? The Community is to small, ... the cool guys move further. The PhD is finished ... Gaps hard to close. Would be sad, if this happens to SmalltalkHub.
There should be only 2-3 public, open source key systems (or type of systems) where to put the focus on and give them a long term perspective & support from the association / consortium or other donators. And the systems and its building blocks should move with Pharo in the future. And the system should be in some obviously way special & exceptional ... and part of the "Pharo Masterplan".
(a) Data Analysis & Visualization System => ?? MOOSE ?? => Key Building Blocks: f.e. Roassal2/3D, ZincHTTP, NeoCSV, NeoJSON, ... (b) Online/Web System => ?? SmalltalkHub ?? => Key Building Blocks: f.e. Amber, Seaside, ZincHTTP, NeoCSV, NeoJSON, ... (c) A Cool Game (would love it) => ??? => Key Building Blocks: ??? (d) ???
I know, it is easy to say. But the best promotion for Pharo are cool systems in Pharo. But maybe Pharo has not more potential than doing one type of systems right and ongoing, f.e. (a). I have no problems with it. I like Pharo for (a) as i like Erlang/OTP for (b) and Lua/Love2D for (c). The coolest would be a perspective for (a), (b), (c) and (d) in Pharo. But i do not see it ...
But yes, it is better to do one or two things good, and not a five bad.
My 2 cents, Volkert
Hi,
On 27 Nov 2014, at 11:14, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
SmalltalkHub is slow, so donât click too fast :-(
While Iâm grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We donât have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long...
Itâs better to use some mainstream platform such as github.
I agree.
Weâll we have support for it in Pharo 4?
We already have some support, good enough for a lot of people, but not fopr us :) We will enhance it for pharo4 (the idea is to have monticello git packages using libgit2, something close to Thierryâs work gitfiletree, but using native libs instead osprocess) And weâll continue improving from there. Esteban
It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo.
Noury <Screen Shot 2014-11-27 at 11.04.54.png>
I forgot to add that git comes with excellent gui clients that are far more powerful and elegant that what Pharo offers currently . If you are user of emacs there is magit , really powerful gui client and very popular among emacs users. For gui client I have used quite a lot SmartGit http://www.syntevo.com/smartgit/ and recently a fellow python developer introduced me to Sourcetree http://www.sourcetreeapp.com/ Both are free for non commercial projects. They require a license for commercial use but they are relative cheap. They come with diff tools, easy commit access , branching, merging and tons of stuff to make life easier for complex scenarios and they integrate well with bitbucket and other online repositories besides github. But even from command line there is a lot of room for automation by creating bash scripts to make commits one step process.
At times, mczs still come handy for some merges... And Smalltalkhub is good as a safe heaven for collecting packages that are otherwise scattered all around. Is there a reason why Smalltalkhub would not stay working nicely? Are we talking about using bigger boxes here? Or is it a deeper issue? Phil On Thu, Nov 27, 2014 at 1:52 PM, kilon alios <kilon.alios@gmail.com> wrote:
I forgot to add that git comes with excellent gui clients that are far more powerful and elegant that what Pharo offers currently .
If you are user of emacs there is magit , really powerful gui client and very popular among emacs users.
For gui client I have used quite a lot SmartGit
http://www.syntevo.com/smartgit/
and recently a fellow python developer introduced me to Sourcetree
Both are free for non commercial projects. They require a license for commercial use but they are relative cheap. They come with diff tools, easy commit access , branching, merging and tons of stuff to make life easier for complex scenarios and they integrate well with bitbucket and other online repositories besides github.
But even from command line there is a lot of room for automation by creating bash scripts to make commits one step process.
On 27 Nov 2014, at 14:43, phil@highoctane.be wrote:
At times, mczs still come handy for some merges...
And Smalltalkhub is good as a safe heaven for collecting packages that are otherwise scattered all around.
nothing that a real catalog/centralised package manager alla npm/apt-get/etc cannot do it. using a package manager as a catalog feels to me like hammering a screw.
Is there a reason why Smalltalkhub would not stay working nicely?
because we do not have the strength/willing to maintain it. and each day we are: farther from âstate of the artâ source management, and farther from state of the art javascript, etc. (which is the reason why sthub
Are we talking about using bigger boxes here? Or is it a deeper issue?
keeping up-to-date a system like sthub is a lot of work, and takes a lot of time. personally, I prefer way more to spend my time in things that will have a real impact in the community (like having a modern vm) than lose it trying constantly to catch up with what others (with a lot more resources) already did. each time I start a sub-project, my first question is: âthis stuff will have a multiplier effect in the community?â and second question is âdo we have to doit from scratch, or can we take advantage of other projects?â. As a maintainer, and being conscious of our limitations, this are the driving forces I find positive to work. (and of course, most times I do not start sub-projects at all, I just jump into a burning place and try to do my best to fix it⦠not always very successfully :P) so, coming back to less âphilosophicalâ question: 1) do we need a state-of-the-art source code management? YES. 2) do we want to spend the few manpower we have on running into a worst solution of what is already around? I think no. Esteban
Phil
On Thu, Nov 27, 2014 at 1:52 PM, kilon alios <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> wrote: I forgot to add that git comes with excellent gui clients that are far more powerful and elegant that what Pharo offers currently .
If you are user of emacs there is magit , really powerful gui client and very popular among emacs users.
For gui client I have used quite a lot SmartGit
http://www.syntevo.com/smartgit/ <http://www.syntevo.com/smartgit/>
and recently a fellow python developer introduced me to Sourcetree
http://www.sourcetreeapp.com/ <http://www.sourcetreeapp.com/>
Both are free for non commercial projects. They require a license for commercial use but they are relative cheap. They come with diff tools, easy commit access , branching, merging and tons of stuff to make life easier for complex scenarios and they integrate well with bitbucket and other online repositories besides github.
But even from command line there is a lot of room for automation by creating bash scripts to make commits one step process.
On Thu, Nov 27, 2014 at 3:37 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 27 Nov 2014, at 14:43, phil@highoctane.be wrote:
At times, mczs still come handy for some merges...
And Smalltalkhub is good as a safe heaven for collecting packages that are otherwise scattered all around.
nothing that a real catalog/centralised package manager alla npm/apt-get/etc cannot do it. using a package manager as a catalog feels to me like hammering a screw.
Sure, I am with you on that. I am yum - ing all day long :-) But as you know, the Pharo Catalog descriptions are quite lonely. I'd like to take a moment to tackle that one. In fact, there are several concerns that I find (and other members on the list share the feeling) must be addressed for commercial development. e.g.: Stronger RDBMS support, AAA, Logs, ... But this not really Pharo per se, but a onion ring around it. As you guys are doing 4.0, that onion ring is making 3.0 work for commercial stuff. I think that we'll always be one version behind, which is ok.
Is there a reason why Smalltalkhub would not stay working nicely?
because we do not have the strength/willing to maintain it. and each day we are: farther from âstate of the artâ source management, and farther from state of the art javascript, etc. (which is the reason why sthub
Ok, thx.
Are we talking about using bigger boxes here? Or is it a deeper issue?
keeping up-to-date a system like sthub is a lot of work, and takes a lot of time. personally, I prefer way more to spend my time in things that will have a real impact in the community (like having a modern vm) than lose it trying constantly to catch up with what others (with a lot more resources) already did.
Sure, modern vm anytime! The git worklflow is superpowerful and that's what people use these days. In a MOOC I do, all exercises and slideware are in Github...
each time I start a sub-project, my first question is: âthis stuff will have a multiplier effect in the community?â and second question is âdo we have to doit from scratch, or can we take advantage of other projects?â. As a maintainer, and being conscious of our limitations, this are the driving forces I find positive to work. (and of course, most times I do not start sub-projects at all, I just jump into a burning place and try to do my best to fix it⦠not always very successfully :P)
Nah, you rule. I wish I was as good as you are.
so, coming back to less âphilosophicalâ question:
1) do we need a state-of-the-art source code management? YES. 2) do we want to spend the few manpower we have on running into a worst solution of what is already around? I think no.
libgit2 would provide that without going through Github driver hoops,
which is sweet and more welcoming to newcomers.
Esteban
Phil
On Thu, Nov 27, 2014 at 1:52 PM, kilon alios <kilon.alios@gmail.com> wrote:
I forgot to add that git comes with excellent gui clients that are far more powerful and elegant that what Pharo offers currently .
If you are user of emacs there is magit , really powerful gui client and very popular among emacs users.
For gui client I have used quite a lot SmartGit
http://www.syntevo.com/smartgit/
and recently a fellow python developer introduced me to Sourcetree
Both are free for non commercial projects. They require a license for commercial use but they are relative cheap. They come with diff tools, easy commit access , branching, merging and tons of stuff to make life easier for complex scenarios and they integrate well with bitbucket and other online repositories besides github.
But even from command line there is a lot of room for automation by creating bash scripts to make commits one step process.
On 27 Nov 2014, at 15:53, phil@highoctane.be wrote:
On Thu, Nov 27, 2014 at 3:37 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 27 Nov 2014, at 14:43, phil@highoctane.be <mailto:phil@highoctane.be> wrote:
At times, mczs still come handy for some merges...
And Smalltalkhub is good as a safe heaven for collecting packages that are otherwise scattered all around.
nothing that a real catalog/centralised package manager alla npm/apt-get/etc cannot do it. using a package manager as a catalog feels to me like hammering a screw.
Sure, I am with you on that. I am yum - ing all day long :-)
But as you know, the Pharo Catalog descriptions are quite lonely. I'd like to take a moment to tackle that one.
In fact, there are several concerns that I find (and other members on the list share the feeling) must be addressed for commercial development.
e.g.: Stronger RDBMS support, AAA, Logs, ...
But this not really Pharo per se, but a onion ring around it. As you guys are doing 4.0, that onion ring is making 3.0 work for commercial stuff. I think that we'll always be one version behind, which is ok.
Is there a reason why Smalltalkhub would not stay working nicely?
because we do not have the strength/willing to maintain it. and each day we are: farther from âstate of the artâ source management, and farther from state of the art javascript, etc. (which is the reason why sthub
Ok, thx.
Are we talking about using bigger boxes here? Or is it a deeper issue?
keeping up-to-date a system like sthub is a lot of work, and takes a lot of time. personally, I prefer way more to spend my time in things that will have a real impact in the community (like having a modern vm) than lose it trying constantly to catch up with what others (with a lot more resources) already did.
Sure, modern vm anytime! The git worklflow is superpowerful and that's what people use these days. In a MOOC I do, all exercises and slideware are in Github...
each time I start a sub-project, my first question is: âthis stuff will have a multiplier effect in the community?â and second question is âdo we have to doit from scratch, or can we take advantage of other projects?â. As a maintainer, and being conscious of our limitations, this are the driving forces I find positive to work. (and of course, most times I do not start sub-projects at all, I just jump into a burning place and try to do my best to fix it⦠not always very successfully :P)
Nah, you rule. I wish I was as good as you are.
so, coming back to less âphilosophicalâ question:
1) do we need a state-of-the-art source code management? YES. 2) do we want to spend the few manpower we have on running into a worst solution of what is already around? I think no.
libgit2 would provide that without going through Github driver hoops, which is sweet and more welcoming to newcomers.
and exactly there is where I will put my effort (as soon as I have time) :) In the long way, Iâm quite sure is a lot more important for community than patching sthub. btw⦠historic reference: sthub was never intended to be there for stay. I remember talking about it with Nico and Stef, more than two years ago, before sthub came online, and our conclusion at the time was: âyes, the future it will be git, but until we get there, letâs put sthub online because sqsource cannot handle more projects"
Esteban
Phil
On Thu, Nov 27, 2014 at 1:52 PM, kilon alios <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> wrote: I forgot to add that git comes with excellent gui clients that are far more powerful and elegant that what Pharo offers currently .
If you are user of emacs there is magit , really powerful gui client and very popular among emacs users.
For gui client I have used quite a lot SmartGit
http://www.syntevo.com/smartgit/ <http://www.syntevo.com/smartgit/>
and recently a fellow python developer introduced me to Sourcetree
http://www.sourcetreeapp.com/ <http://www.sourcetreeapp.com/>
Both are free for non commercial projects. They require a license for commercial use but they are relative cheap. They come with diff tools, easy commit access , branching, merging and tons of stuff to make life easier for complex scenarios and they integrate well with bitbucket and other online repositories besides github.
But even from command line there is a lot of room for automation by creating bash scripts to make commits one step process.
2014-11-27 18:01 GMT+03:00 Esteban Lorenzano <estebanlm@gmail.com>:
btw⦠historic reference: sthub was never intended to be there for stay. I remember talking about it with Nico and Stef, more than two years ago, before sthub came online, and our conclusion at the time was: âyes, the future it will be git, but until we get there, letâs put sthub online because sqsource cannot handle more projects"
And why you not choose squeaksource3 which maintained by gemstone team and includes all features from old squeaksource? Why you instead develop sthub if you not believe in it?
On 30 Nov 2014, at 13:41, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2014-11-27 18:01 GMT+03:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>: btw⦠historic reference: sthub was never intended to be there for stay. I remember talking about it with Nico and Stef, more than two years ago, before sthub came online, and our conclusion at the time was: âyes, the future it will be git, but until we get there, letâs put sthub online because sqsource cannot handle more projects"
And why you not choose squeaksource3 which maintained by gemstone team and includes all features from old squeaksource? Why you instead develop sthub if you not believe in it?
Smalltalkhub was already there. Question was if we put it online or not, not if we develop it or not. ss3 was there but Dale always said (at the time) that was a proof of concept and that having time for work on it was complicated (and search was severely broken, and it was slow and we were having *real* problems when doing massive downloads). both situations are probably fixed now, but at the time having a 3rd solution for the community looked like a good idea. and I believe it was. Even if you plan, in the future, to provide something else that you believe is better, when you are developing something like Pharo you have certain responsibilities with your community, you cannot drop something without having already a good replacement. We needed a solution soon, we had sthub, so it was a good match. and look now⦠I still believe the future is using Git as our central source management system, but we are still not there, tools are still not good enough and then, we still need to have tools like sthub. Esteban
+1 It was like that.
On 30 Nov 2014, at 13:41, Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>> wrote:
2014-11-27 18:01 GMT+03:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>:
btw⦠historic reference: sthub was never intended to be there for stay. I remember talking about it with Nico and Stef, more than two years ago, before sthub came online, and our conclusion at the time was: âyes, the future it will be git, but until we get there, letâs put sthub online because sqsource cannot handle more projects"
And why you not choose squeaksource3 which maintained by gemstone team and includes all features from old squeaksource? Why you instead develop sthub if you not believe in it?
Smalltalkhub was already there. Question was if we put it online or not, not if we develop it or not. ss3 was there but Dale always said (at the time) that was a proof of concept and that having time for work on it was complicated (and search was severely broken, and it was slow and we were having *real* problems when doing massive downloads). both situations are probably fixed now, but at the time having a 3rd solution for the community looked like a good idea.
and I believe it was. Even if you plan, in the future, to provide something else that you believe is better, when you are developing something like Pharo you have certain responsibilities with your community, you cannot drop something without having already a good replacement. We needed a solution soon, we had sthub, so it was a good match. and look now⦠I still believe the future is using Git as our central source management system, but we are still not there, tools are still not good enough and then, we still need to have tools like sthub.
Esteban
Actually, SS3 and smalltalkhub appeared about the same time. Tobias Pape had been slowly improving the GemStone version of SqueakSource3 and I got tired of waiting 2-3 days for SqueakSource to come back from a crash, so I pushed SS3 up as an Alpha to get something up that was more stable than SqueakSource. About the same time, SmalltalkHub was made available and I didn't want to compete with SmalltalkHub and at the time it seemed to have potential, so I backed off on my plans to go beyond the Alpha release of SS3. There were several sets of known bugs and performance issues ... but it was and still is Alpha and was never intended to go into production. After several months of development, SmalltalkHub had not quite made it to be production ready and Stef asked me to start backing up SS3 so that it could be used for production apps ... I reluctantly agreed, because at the time SqueakSource was very unstable and something was needed ... Unfortunately the time window for me to have time to devote time to SS3 had passed and Tobias was busy with his work as well. And it took longer than originally anticipated for SmalltalkHub to be ready for prime time. Tobias has continued to work on the SqueakSource3 code base and bring it way beyond the Alpha version that is in production. The folks at Hasso Plattner Institute are using Tobias' SqueakSource3 in production for their Smalltalk repos. But it seemed to not be worth the effort to try to compete with SmalltalkHub ... the original intent of SS3 being brought into production was to be a stopgap measure until SmalltalkHub was ready... Today, I am using GitHub for all of my projects ([1], [2], [3], and [4]) so again I just don't have the time to devote to SS3 to incorporate the improvements that Tobias has had (for years now) .... Neither SqueakSource3 nor SmalltalkHub comes close to the collaborative feature set of GitHub and I personally would rather devote my own time and effort to new Smalltalk projects than trying to duplicate GitHub in Smalltalk. We continue to host SS3, with all of its Alpha warts because is very stable and a number of folks use it on a daily basis... Dale [1] https://github.com/GsDevKit [2] https://github.com/glassdb [3] https://github.com/dalehenrich [4] https://github.com/CampSmalltalk On Sun, Nov 30, 2014 at 4:41 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2014-11-27 18:01 GMT+03:00 Esteban Lorenzano <estebanlm@gmail.com>:
btw⦠historic reference: sthub was never intended to be there for stay. I remember talking about it with Nico and Stef, more than two years ago, before sthub came online, and our conclusion at the time was: âyes, the future it will be git, but until we get there, letâs put sthub online because sqsource cannot handle more projects"
And why you not choose squeaksource3 which maintained by gemstone team and includes all features from old squeaksource? Why you instead develop sthub if you not believe in it?
Tx dale. Yes it was like that :) Le 30/11/14 16:58, Dale Henrichs a écrit :
Actually, SS3 and smalltalkhub appeared about the same time. Tobias Pape had been slowly improving the GemStone version of SqueakSource3 and I got tired of waiting 2-3 days for SqueakSource to come back from a crash, so I pushed SS3 up as an Alpha to get something up that was more stable than SqueakSource. About the same time, SmalltalkHub was made available and I didn't want to compete with SmalltalkHub and at the time it seemed to have potential, so I backed off on my plans to go beyond the Alpha release of SS3. There were several sets of known bugs and performance issues ... but it was and still is Alpha and was never intended to go into production.
After several months of development, SmalltalkHub had not quite made it to be production ready and Stef asked me to start backing up SS3 so that it could be used for production apps ... I reluctantly agreed, because at the time SqueakSource was very unstable and something was needed ...
Unfortunately the time window for me to have time to devote time to SS3 had passed and Tobias was busy with his work as well.
And it took longer than originally anticipated for SmalltalkHub to be ready for prime time.
Tobias has continued to work on the SqueakSource3 code base and bring it way beyond the Alpha version that is in production. The folks at Hasso Plattner Institute are using Tobias' SqueakSource3 in production for their Smalltalk repos.
But it seemed to not be worth the effort to try to compete with SmalltalkHub ... the original intent of SS3 being brought into production was to be a stopgap measure until SmalltalkHub was ready...
Today, I am using GitHub for all of my projects ([1], [2], [3], and [4]) so again I just don't have the time to devote to SS3 to incorporate the improvements that Tobias has had (for years now) ....
Neither SqueakSource3 nor SmalltalkHub comes close to the collaborative feature set of GitHub and I personally would rather devote my own time and effort to new Smalltalk projects than trying to duplicate GitHub in Smalltalk.
We continue to host SS3, with all of its Alpha warts because is very stable and a number of folks use it on a daily basis...
Dale
[1] https://github.com/GsDevKit [2] https://github.com/glassdb [3] https://github.com/dalehenrich [4] https://github.com/CampSmalltalk
On Sun, Nov 30, 2014 at 4:41 AM, Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>> wrote:
2014-11-27 18:01 GMT+03:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>:
btw⦠historic reference: sthub was never intended to be there for stay. I remember talking about it with Nico and Stef, more than two years ago, before sthub came online, and our conclusion at the time was: âyes, the future it will be git, but until we get there, letâs put sthub online because sqsource cannot handle more projects"
And why you not choose squeaksource3 which maintained by gemstone team and includes all features from old squeaksource? Why you instead develop sthub if you not believe in it?
Thank's Dale and Esteban for explanation 2014-11-30 18:58 GMT+03:00 Dale Henrichs <dale.henrichs@gemtalksystems.com>:
Actually, SS3 and smalltalkhub appeared about the same time. Tobias Pape had been slowly improving the GemStone version of SqueakSource3 and I got tired of waiting 2-3 days for SqueakSource to come back from a crash, so I pushed SS3 up as an Alpha to get something up that was more stable than SqueakSource. About the same time, SmalltalkHub was made available and I didn't want to compete with SmalltalkHub and at the time it seemed to have potential, so I backed off on my plans to go beyond the Alpha release of SS3. There were several sets of known bugs and performance issues ... but it was and still is Alpha and was never intended to go into production.
After several months of development, SmalltalkHub had not quite made it to be production ready and Stef asked me to start backing up SS3 so that it could be used for production apps ... I reluctantly agreed, because at the time SqueakSource was very unstable and something was needed ...
Unfortunately the time window for me to have time to devote time to SS3 had passed and Tobias was busy with his work as well.
And it took longer than originally anticipated for SmalltalkHub to be ready for prime time.
Tobias has continued to work on the SqueakSource3 code base and bring it way beyond the Alpha version that is in production. The folks at Hasso Plattner Institute are using Tobias' SqueakSource3 in production for their Smalltalk repos.
But it seemed to not be worth the effort to try to compete with SmalltalkHub ... the original intent of SS3 being brought into production was to be a stopgap measure until SmalltalkHub was ready...
Today, I am using GitHub for all of my projects ([1], [2], [3], and [4]) so again I just don't have the time to devote to SS3 to incorporate the improvements that Tobias has had (for years now) ....
Neither SqueakSource3 nor SmalltalkHub comes close to the collaborative feature set of GitHub and I personally would rather devote my own time and effort to new Smalltalk projects than trying to duplicate GitHub in Smalltalk.
We continue to host SS3, with all of its Alpha warts because is very stable and a number of folks use it on a daily basis...
Dale
[1] https://github.com/GsDevKit [2] https://github.com/glassdb [3] https://github.com/dalehenrich [4] https://github.com/CampSmalltalk
On Sun, Nov 30, 2014 at 4:41 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2014-11-27 18:01 GMT+03:00 Esteban Lorenzano <estebanlm@gmail.com>:
btw⦠historic reference: sthub was never intended to be there for stay. I remember talking about it with Nico and Stef, more than two years ago, before sthub came online, and our conclusion at the time was: âyes, the future it will be git, but until we get there, letâs put sthub online because sqsource cannot handle more projects"
And why you not choose squeaksource3 which maintained by gemstone team and includes all features from old squeaksource? Why you instead develop sthub if you not believe in it?
kilon alios wrote:
I forgot to add that git comes with excellent gui clients that are far more powerful and elegant that what Pharo offers currently .
We started late. We had tools reasonably suited for our needs which we were comfortable with. I think/hope that once libgit is "released" in Pharo and the wider community becomes more familiar with it, it stimulates us to develop tools to rival the others. Tools that non-Smalltalkers also find useful, and when they want to add a feature, they are motivated to learn Pharo. I think this is a small additional benefit of tighter integration of git in Pharo. cheers -ben
"We started late. We had tools reasonably suited for our needs which we were comfortable with. I think/hope that once libgit is "released" in Pharo and the wider community becomes more familiar with it, it stimulates us to develop tools to rival the others. Tools that non-Smalltalkers also find useful, and when they want to add a feature, they are motivated to learn Pharo. I think this is a small additional benefit of tighter integration of git in Pharo. cheers -ben" Even if Smalltalkhub improves and solves these problems, Github will still run circles around it. Sure some pharoers want to stick inside the image because they want to avoid the pain to learn something new or because hey aspire of all inclusive smalltalk enviroment. But I dont want to be like the kid that press his face on the windows of a candy store, salivating for the candy I cannot have. There is a lot of cool technology around us really great and it will be a pity if Pharo does not take advantage of it. Git and Github is only a small part of the story. My belief and this is a belief I put in practice with my project Ephestos is that Pharo can be an excellent candidate as a glue enviroment , an enviroment that can bring all modern very powerful technologies together. I find a pharo enviroment that allows me to control the outside software with ease far more tempting than a Pharo enviroment that allow me to control with ease only itself. For me this is also what made Python so popular as a language. We all have seen the 80s drawing with the baloon leaving the island but even in 2014 even Pharo feels like an island some times. Fortunately this changes and we see more and more a more modern smalltalk and a more modern Pharo. I believe in Pharo and in its success and this is why I love contribute to it.
2014-11-28 14:40 GMT+01:00 Ben Coman <btc@openinworld.com>:
kilon alios wrote:
I forgot to add that git comes with excellent gui clients that are far more powerful and elegant that what Pharo offers currently .
We started late. We had tools reasonably suited for our needs which we were comfortable with. I think/hope that once libgit is "released" in Pharo and the wider community becomes more familiar with it, it stimulates us to develop tools to rival the others. Tools that non-Smalltalkers also find useful, and when they want to add a feature, they are motivated to learn Pharo. I think this is a small additional benefit of tighter integration of git in Pharo.
But underlying this is the hypothesis that you will be able to master the complexity of git from within Pharo, which is ambitious. Given how complex git is and the use cases around it, I personaly do not underestimate that task. I do know that, probably, if git gets totally integrated within Pharo, it will not fit my professional use case and I will have to resort to something else[*]. In the same way that people who knows and use git (and github) everyday do prefer to stay with FileTree and command line git (and external tools) than switch to GitFileTree (which is a plain automation layer above FileTree and git). We are now at four attempts[**] at writing git support for Pharo in no less than three or four years, with two dead, one working for two platforms out of three and one under development for already a while. This shows that we need a bit of humility in promising the perfect git integration and tools. Thierry [*] But it will fit the Pharo team use case perfectly well ;) [**] I'm finding new ones on github while searching: https://github.com/JumpIntoSqueak/metacello-git https://github.com/timfel/gitocello https://github.com/theseion/fs-git https://github.com/theseion/LibGit https://github.com/theseion/LibGit2-bindings
cheers -ben
On Thu, 27 Nov 2014, Noury Bouraqadi wrote:
SmalltalkHub is slow, so donât click too fast :-(
While Iâm grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We donât have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long...
People on this list used to say the same about squeaksource.com. But it has been working flawlessly since it got updated to the latest version (which implies that a few bugs got fixed). What makes you think that tracking down the bugs in SmalltalkHub and fixing them wouldn't be enough? Based on my experience a single image - running well designed software - is able to serve about ten million requests a day. I think that the actual load on smalltalkhub.com is about three magnitudes lower than that. Levente
Itâs better to use some mainstream platform such as github. Weâll we have support for it in Pharo 4?
It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo.
Noury
On 27 Nov 2014, at 16:05, Levente Uzonyi <leves@elte.hu> wrote:
On Thu, 27 Nov 2014, Noury Bouraqadi wrote:
SmalltalkHub is slow, so donât click too fast :-(
While Iâm grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We donât have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long...
People on this list used to say the same about squeaksource.com. But it has been working flawlessly since it got updated to the latest version (which implies that a few bugs got fixed).
What makes you think that tracking down the bugs in SmalltalkHub and fixing them wouldn't be enough?
Based on my experience a single image - running well designed software - is able to serve about ten million requests a day. I think that the actual load on smalltalkhub.com is about three magnitudes lower than that.
because: 1) the reason why squeaksource survived is because there is an smalltalkhub absorbing most of the packages. 2) I never say it was not possible to keep it running. I said it does not worth the effort, which is a complete different thing. Of course, if someone wants to take smalltalkhub (there is even a configuration for it) and fix the problems that emerge, I will be more than happy to update the production image. Esteban
Levente
Itâs better to use some mainstream platform such as github. Weâll we have support for it in Pharo 4?
It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo.
Noury
On Thu, Nov 27, 2014 at 04:19:20PM +0100, Esteban Lorenzano wrote:
On 27 Nov 2014, at 16:05, Levente Uzonyi <leves@elte.hu> wrote:
On Thu, 27 Nov 2014, Noury Bouraqadi wrote:
SmalltalkHub is slow, so don?t click too fast :-(
While I?m grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We don?t have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long...
People on this list used to say the same about squeaksource.com. But it has been working flawlessly since it got updated to the latest version (which implies that a few bugs got fixed).
What makes you think that tracking down the bugs in SmalltalkHub and fixing them wouldn't be enough?
Based on my experience a single image - running well designed software - is able to serve about ten million requests a day. I think that the actual load on smalltalkhub.com is about three magnitudes lower than that.
because: 1) the reason why squeaksource survived is because there is an smalltalkhub absorbing most of the packages.
No. The reason that squeaksource.com survived is that someone decided to put effort into maintaining it. The same will be true for SmalltalkHub. If you decide to make it work, then you will succeed. If you decide that it is not worth the effort, then it will fail. Dave
2) I never say it was not possible to keep it running. I said it does not worth the effort, which is a complete different thing. Of course, if someone wants to take smalltalkhub (there is even a configuration for it) and fix the problems that emerge, I will be more than happy to update the production image.
Esteban
Levente
It?s better to use some mainstream platform such as github. We?ll we have support for it in Pharo 4?
It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo.
Noury
On 27 Nov 2014, at 17:15, David T. Lewis <lewis@mail.msen.com> wrote:
On Thu, Nov 27, 2014 at 04:19:20PM +0100, Esteban Lorenzano wrote:
On 27 Nov 2014, at 16:05, Levente Uzonyi <leves@elte.hu> wrote:
On Thu, 27 Nov 2014, Noury Bouraqadi wrote:
SmalltalkHub is slow, so don?t click too fast :-(
While I?m grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We don?t have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long...
People on this list used to say the same about squeaksource.com. But it has been working flawlessly since it got updated to the latest version (which implies that a few bugs got fixed).
What makes you think that tracking down the bugs in SmalltalkHub and fixing them wouldn't be enough?
Based on my experience a single image - running well designed software - is able to serve about ten million requests a day. I think that the actual load on smalltalkhub.com is about three magnitudes lower than that.
because: 1) the reason why squeaksource survived is because there is an smalltalkhub absorbing most of the packages.
No. The reason that squeaksource.com survived is that someone decided to put effort into maintaining it.
well, thatâs your perception. Mine is that sthub took out from ss 150k packages, and all pharo infrastructure requirements (a lot, believe me⦠we are almost 24h/7 downloading packages and running different processes). stillâ¦if you put enough effort you can keep anything running, of course. But you will always need that extra effort. Thinking in the long term, that does not scales unless you have an organisation that scales. Or unless you have a community that does not change. I prefer to believe that all our predictions will become small in time, and then I prefer to think that in the long term is better to have an up-to-date infrastructure, that is capable to absorb our growing without taking much effort from our part. ah, and btw⦠smalltalkhub works quite fine. It just have problems on safari, because of the version we are using of amber. then, is running in a virtualisation system, so time to time it becomes slow. we can fix the second one paying a better server :) Esteban
The same will be true for SmalltalkHub. If you decide to make it work, then you will succeed. If you decide that it is not worth the effort, then it will fail.
Dave
2) I never say it was not possible to keep it running. I said it does not worth the effort, which is a complete different thing. Of course, if someone wants to take smalltalkhub (there is even a configuration for it) and fix the problems that emerge, I will be more than happy to update the production image.
Esteban
Levente
It?s better to use some mainstream platform such as github. We?ll we have support for it in Pharo 4?
It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo.
Noury
Nice to know that you run successful web apps.
People on this list used to say the same about squeaksource.com. But it has been working flawlessly since it got updated to the latest version (which implies that a few bugs got fixed).
What makes you think that tracking down the bugs in SmalltalkHub and fixing them wouldn't be enough?
Based on my experience a single image - running well designed software - is able to serve about ten million requests a day. I think that the actual load on smalltalkhub.com is about three magnitudes lower than that.
Levente A part of our problem is maintenance and the fact that Smalltalkhub is missing some features and composed of several layers (amber using bower, mongo, pharo...) and that it is using an old version of amber. Now if somebody wants to help it would be great. Probably a seaside version would reduce the stack dependency. We are flooded by work.
Stef
Hello,
From my experience point of view with SmalltlakHub, I found this tool remarkably stable, useful, feature complete and quite well integrated with Monticello. I want to say thank you guys for the energy you spend to keep it running.
Hilaire Le 27/11/2014 11:14, Noury Bouraqadi a écrit :
SmalltalkHub is slow, so donât click too fast :-(
While Iâm grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We donât have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long...
Itâs better to use some mainstream platform such as github. Weâll we have support for it in Pharo 4?
It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo.
Noury
-- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
+1 Doru On Mon, Dec 1, 2014 at 11:19 AM, Hilaire <hilaire@drgeo.eu> wrote:
Hello,
From my experience point of view with SmalltlakHub, I found this tool remarkably stable, useful, feature complete and quite well integrated with Monticello. I want to say thank you guys for the energy you spend to keep it running.
Hilaire
Le 27/11/2014 11:14, Noury Bouraqadi a écrit :
SmalltalkHub is slow, so donât click too fast :-(
While Iâm grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We donât have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long...
Itâs better to use some mainstream platform such as github. Weâll we have support for it in Pharo 4?
It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo.
Noury
-- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
-- www.tudorgirba.com "Every thing has its own flow"
Thanks hilaire. May be we should try to find some time and love to ensure the next 5 years. Le 1/12/14 11:19, Hilaire a écrit :
Hello,
From my experience point of view with SmalltlakHub, I found this tool remarkably stable, useful, feature complete and quite well integrated with Monticello. I want to say thank you guys for the energy you spend to keep it running.
Hilaire
Le 27/11/2014 11:14, Noury Bouraqadi a écrit :
SmalltalkHub is slow, so donât click too fast :-(
While Iâm grateful to developers of SmalltalkHub and previously SqueakSource, I believe as a small community, we cannot afford developing everything by ourselves. We donât have enough man-power. We can see the symptoms since SmalltalkHub is in beta stage since way too long...
Itâs better to use some mainstream platform such as github. Weâll we have support for it in Pharo 4?
It would be interesting also from the communication point of view to make the world a little bit more aware of Pharo.
Noury
participants (23)
-
Andreas Wacknitz -
Andreas Wacknitz
-
Ben Coman -
Dale Henrichs -
David T. Lewis -
Denis Kudriashov -
Esteban A. Maringolo -
Esteban Lorenzano -
Hernán Morales Durand -
Hilaire -
jannik laval -
kilon alios -
Levente Uzonyi -
Marcus Denker -
Noury Bouraqadi -
phil＠highoctane.be -
Sebastian Sastre -
stepharo -
Sven Van Caekenberghe -
Thierry Goubier -
Torsten Bergmann -
Tudor Girba -
volkert＠nivoba.de