On 22 May 2013 21:12, Frank Shearar <[email protected]> wrote: > On 22 May 2013 18:29, Sven Van Caekenberghe <[email protected]> wrote: >> Frank, >> >> On 22 May 2013, at 14:55, Frank Shearar <[email protected]> wrote: >> >>> On 22 May 2013 13:44, Camillo Bruni <[email protected]> wrote: >>>> >>>> On 2013-05-22, at 14:36, Frank Shearar <[email protected]> wrote: >>>> >>>>> On 22 May 2013 13:20, Camillo Bruni <[email protected]> wrote: >>>>>> >>>>>> On 2013-05-22, at 14:02, Frank Shearar <[email protected]> wrote: >>>>>> >>>>>>> On 22 May 2013 12:49, stephane ducasse <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>> ./pharo Pharo.image config filetree://`pwd`/../src/ >>>>>>>>>> >>>>>>>>>> Fails on trying to execute #mcRepositoryAsUser:withPassword: on a >>>>>>>>>> GenericUrl >>>>>>>>>> instance inside Gofer. >>>>>>>>> >>>>>>>>> Yep, I'd agree with your assessment. Has Pharo forked Gofer, or does >>>>>>>>> it still use Lukas Renggli's repository? >>>>>>>> >>>>>>>> We forked it. We cannot built a part of our infrastructure on a >>>>>>>> project that can vanished in nature. >>>>>>> >>>>>>> Well. What I should have asked was "have you cloned the repository >>>>>>> with the intention of pushing improvements upstream, or have you >>>>>>> forked the project with no intention of pushing changes upstream?" >>>>>> >>>>>> well, check on how much we changed in detail and them come back. >>>>> >>>>> Sorry, was that supposed to be an answer? I must go find out how much >>>>> work you've done before guessing whether you've forked and abandoned >>>>> upstream? >>>> >>>> abandon or progress that's the question here. >>> >>> That's a false dichotomy. There's a middle path, where you do the MC >>> equivalent of a pull request. Now there's something useful to aim for: >>> GitHub works so very, very well because it's utterly trivial to make >>> upstream repositories know you have improvements lying around. Because >>> fragmentation of your committer base _does not help you_ in the long >>> run. >>> >>> Now if the upstream maintainer _dies_, sure, that's a different story. >>> >>>>> Like I said: What I want to know is this: if I want to make a change >>>>> to infrastructure common to multiple Smalltalks, does Pharo expect me >>>>> to submit special unique snowflake additions to Pharo AND to upstream? >>>> >>>> well if you expect us to push anything upstream then have a look at the >>>> massive amount of changes that happened since pharo 1.0. >>> >>> I don't care about Pharo 1.0 in the context of this discussion. I care >>> about one particular package, one that should have no UI elements in >>> it or similar nasty sources of entanglement. (I have attempted to port >>> quite a few Pharo packages to Squeak. Lack of separation between UI >>> and core functionality has been the only reason I've had to abandon a >>> port, thus far.) And certainly Gofer as it's pulled in via Metacello >>> (er, which one? The upstream one, not Pharo's fork of same) works fine >>> in Pharo, Squeak and Gemstone, and wherever else Metacello and Gofer >>> run. I should _not_ have to submit to more than one repository to add >>> functionality to Gofer. >>> >>>> There IS a reason pharo forked from squeak... >>> >>> I'm not pursuing this thread: it's my understanding that the fork was >>> largely political, and personal, and that's as far as I'm going to >>> talk about it. >> >> Well, you are wrong about the reasons for the fork, IMO. But it is a done >> deal. (See my answer to Janko). > > Am I? I spent a good hour crawling through squeak-dev for the time > period 2007-2008. The Board was around at the time, and I saw nothing > in their communications to indicate anything about a fork. So whatever > happened, happened in secrecy, in private mails, in person. Ways that > left no public trace. And, in my opinion, if people did unethical > things to certain members of the community, then I think they should > be named and shamed. > > The split was _bad_ for the community. I understand that Stef and > Marcus did what they felt they had to do, and I think it's a crying > shame that they were forced into such drastic action. It's now 5 or 6 > years later and it's still an open wound. >
I felt the same around 2009.. but today not.. maybe because i am too involved with Pharo now, and i cannot tell a difference. But i agree with Stef, that main issue with Squeak, there is no clear what direction(s) it going. Fixes and small improvements? Okay.. but can you call it evolution? Clearly not. (well, except from plans to make next Squeak release to be based on Craig's Spoon work.. which was plans when i was board member in 2008 (i think), and it is still not there).. The only big thing which happened around, when i was active member of Squeak, was fixing license issues and making Squeak code covered by MIT. Yes, this is important move (but Pharo came through this pain too, as you know, and it took much less time for them to do that, and take into account that at that time there was much more squeakers than pharoers). But again this "progress" belongs rather to political plane, not technical one, and personally, i do not really care :). The technical progress is Opal compiler. Nautilus browser, and RPackage (and this list not ends..). Yes they are not ideal and need further work.. but what i like that we, in pharo do not wait till something will become ideal and only then we include it into our project: it should be just fairly acceptable. And that we're not fear to step on someone's toys. And believe me, Pharo is still quite far (to my taste) from being ideal platform for my daily needs. But that's why i here, and many others, who sharing same vision: make smalltalk appeal to professional developers. Because if you can attract professionals, then they can do rest: better tools, better UI's.. everything. And then eventually you will have plenty of manpower to make things done, as well as feel safe from bus-factor, when one guru leaves project making its future very dim & uncertain. So, this are the values, why i would bet on Pharo instead of Squeak for any future project i may want to develop: not technical superiority(or opposite), not the size of community, but clear vision and direction where it heading. >> Now, for library/framework developers/maintainers it is hard to be >> compatible with different Smalltalk implementations. It is not impossible, >> but requires manpower, interest and will. Recently, only Fuel managed to do >> that (of the bigger projects). > > Yes, it _is_ hard, and I _greatly_ appreciate the efforts not just of > Max, Martin and Mariano but also the Metacello community (especially > Dale, who has suffered for his project) on making things work across > platforms. I try do what little I can to help to support them. Again > thanks to Dale, I can have my various libraries running against Pharo > (although I see I need to add Pharo 2.0 to my Control library's > matrix). So I try make sure that my Squeak work's available for Pharo > users. > >> Sven >> >> PS: I occasionally read the Squeak mailing and I see the work that you are >> doing and it is impressive. Your attitude, approach and drive remind me of >> the many Pharo developers. I would not dream of convincing you, but IMHO you >> would fit perfectly in the Pharo community, where you would find more >> interaction and feedback - maybe you would even reconsider using Smalltalk >> in business. > > Thanks, Sven. I'm really not trying to pick fights over here. And > perhaps today was a bad day to open my mouth at all, given my > crankiness level. > > I would _love_ to be able to use Smalltalk at work. Until it can work > properly with git, and people can use their own text editors (vim, > emacs, sublime), and quite a few other bits and pieces, it's just a > non-starter. > > I _like_ Pharo, and I _like_ how it has energy and momentum, and a > much nicer UI than the old Pharo 1.0 UI. I'm honestly quite jealous of > the resources the community wields, not just because of INRIA's and > the Consortium's money, but because there are loads of people actually > around, who are prepared to knuckle down and do the gruntwork needed. > Squeak is now a very small community. I'm rather proud of what we get > done with what little we have. > > frank > -- Best regards, Igor Stasenko.
