> Our goal is to make progress. Squeak is dying don't see it? > The reason it is dying is because once anyone starts a significant project they are stuck with the same image that they started with. Thus everyone gets left along the path of progress. They keep up or get left behind to fork their own little world. Pharo perpetuates and exacerbates this problem through its philosophy.
You could have picked a slice of squeak, instituted a project to improve it, and then contributed that improved slice back to everyone, and so on. The kernel image itself is not that important to getting actual work done, once you eliminate certain headaches like FileDirectory (Rio was my choice of the section of the kernel to improve). Sure, if you are doing academic little projects, you might be constantly irked by the lack of change in the kernel. If you are working on a big project with clients breathing down your neck, you just get on with it. The <i>cause</i> (since captials are deemed to be rude, sorry Paul) of squeak dying is that those who move it forward are too busy making progress and they <i>dont</i> think about the users of older images. How many of our potential millions of future xo users will be taking their future xo software apart to find Pharo inside? >> And you are ignoring those tools, because you dont see them as >> important. >> > I would love to have a buildServer and also run automatically > SmallLint rules on the code > now either pharo does not exist because we build those tools or pharo > exist. So please .... explain this to me.... why cant. Project A working on the kernel and not the tools, fit together with project B, working on the tools and not the kernel? Looks simple on paper doesn't it. Think it over, A+B = AB, and B + A = BA, hmm it works, infact its kind of obvious. Now why is it that this doesn't work I wonder? Please explain this to me? Correct me if I am wrong, but I think it is because Project A is working on the kernel, and is for some reason forking the loadable tools (which should be outside of their remit) thus absorbing all of the expertise, making things more difficult for everyone. Project B then gives up and goes off to do something else, because they realise that 3 years of efforts trying to open up repositories and to encourage people to contribute collaboratively to tools as shared resources over the whole community of projects, is a total and utter waste of time. All the repo's on Project B are public, and anyone can contribute, however the majority of Project A contributors don't join in. > buildserver and this is why > I have been working on the Build server since Feb 2007. That was where the idea for Rio originally came from. The ruby version of Bob did work but it was tricky to set up. The smalltalk one only needs one day of work to complete, and I said that 3 months ago. However since no-one from your team seems willing to <i>join</i> on fixing up MC1.5 etc I was left to spend yesterday fixing an MC1.5 bug. Perhaps there is no point in doing that one day of work on Bob because no-one will bother looking at it anyway. > we started to write on Installer (and you know that this is not only > for pharo so you should be happy). > You did? > Now you should ask yourself the question why people are not all using > your tool extensions. > Actually they are. If they were not I wouldn't be here now. > Conservatism? stupidity? lack of time? lack of trust? Dont'care? > None of the above. Many people load LPF and get on with the job they have to do. Keith _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
