Sorry Keith, but I must say this:
The obvious reason Pharoers reject your contributions are not contributions as such but your attitude as the contributor. And I'd do the same, reject them, because they are dangerous. Because they bring you and your attitude with them.
Please think that way a bit. For the sake of Squeak community and our progress. And for the sake of your work at the end. Changing your attitude will change the acceptance of your work too, be sure!
Best regards Janko
Keith Hodges pravi:
If find it weird that 2 Smalltalk implementations/communities, so close to each other like Squeak and Pharo, go to great lengths at flaming each other...
No they don't, it's just me.
Please don't tar the mostly polite squeak-dev with my brush.
I spent a lot of time working on stuff that pharo could use, particularly because a lot of it was Stephane's idea in the first place, going back to August 2006.
My two main points of contention are Monticello and SUnit but as you can see there are others.
Monticello: I put a LOT, read LOTS of effort into joining the 3+ Monticello forks into one, and assuring that it loads in to all forks of squeak, as a strategic approach for the whole community to have common tools everywhere. Pharo has made that effort a waste of time, simply because they wont use or contribute to the merged uber-Monticello.
SUnit: I put a second lot of effort into improving SUnit so that it could support multiple forks of squeak simultaneously. I also wrote a non Gui test runner for automated testing. SUnit is a public resource and is maintained in a public repository. Pharo have needlessly forked SUnit.
Several things that wind me up, one is wasted effort, and another is duplicated effort, and the third is making plans to duplicate effort on purpose.
that will only leave us isolated, both in our own camps ? I'm puzzled! What do I do if I like both? Choose my camp or abandon them both ?
If you like both, then please encourage them to make parts that could be common common. For example I maintain ProcessSpecific for Logging, Pharo has integrated ProcessSpecific but has made no attempt to pick or offer feedback to version that was maintained. This is one of numerous example of subsystems that could easily be mutually maintained.
There are many initiatives in the pharo camp, that could be developed and deployed into both camps. I spent all that time on Monticello in order to ensure that this could happen, but pharo only develops initiatives for itself, therefore Pharo is effectively planning for duplicated effort.
One more example, Pharo could come up with an initiative to fix the sources/changes file mess. This would be very benefitcial to me. However its no good if I cant load it into squeak where a lot of my code runs. So at some point someone would have to duplicate the effort for Squeak. All it would take is a little thought and planning.
When I took the initiative to write Rio as a replacement for FileDirectory, I did it in such a way as anyone could benefit. When I took the initiative to write Logging as a potential core feature for Kernel/Server images I did it so that anyone could benefit. When I wrote the TestReporter as a text based tool for testing I did it so that anyone could benefit. When I wrote Bob for automated image building and testing I have done it so that it can build any image. When I wrote Sake for rake like functionality it loads into any image. When I wrote Sake/Packges for managing packges dependencies I did it so that any image can benefit.
I dont know what initiatives pharo has completed, but, and please do correct me if I am wrong. I havent seen a single initiative from pharo that has been developed and deployed so that everyone could benefit.
best regards
Keith