MC Filetree -- missing FiletreeURL ?
I'm trying to setup a git-based build script from the command line and I end up unable to load a configuration from a filetree repository on the pharo command line. Has someone encountered that? It seems Gopher is missing a FiletreeURL for this to work. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On 22 May 2013 12:05, Goubier Thierry <thierry.goubier@cea.fr> wrote:
I'm trying to setup a git-based build script from the command line and I end up unable to load a configuration from a filetree repository on the pharo command line.
Has someone encountered that? It seems Gopher is missing a FiletreeURL for this to work.
What does your script currently look like? frank
Le 22/05/2013 13:05, Frank Shearar a écrit :
On 22 May 2013 12:05, Goubier Thierry <thierry.goubier@cea.fr> wrote:
I'm trying to setup a git-based build script from the command line and I end up unable to load a configuration from a filetree repository on the pharo command line.
Has someone encountered that? It seems Gopher is missing a FiletreeURL for this to work.
What does your script currently look like?
frank
./pharo Pharo.image config filetree://`pwd`/../src/ Fails on trying to execute #mcRepositoryAsUser:withPassword: on a GenericUrl instance inside Gofer. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On 22 May 2013 12:13, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 22/05/2013 13:05, Frank Shearar a écrit :
On 22 May 2013 12:05, Goubier Thierry <thierry.goubier@cea.fr> wrote:
I'm trying to setup a git-based build script from the command line and I end up unable to load a configuration from a filetree repository on the pharo command line.
Has someone encountered that? It seems Gopher is missing a FiletreeURL for this to work.
What does your script currently look like?
frank
./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? frank
./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.
frank
On 22 May 2013 12:49, stephane ducasse <stephane.ducasse@free.fr> 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?" Because the latter option makes it more difficult/less useful for me to think about submitting changes to Gofer. I've no interest in arguing about the merits of either position: I'm quite clear on how _I_ feel about things (namely, push changes upstream), but I do not want to fight over _your_ feelings on the matter. I just want to know where Pharo stands on the issue of changes to codebases that might be shared between Pharo and Squeak. (Gofer, Metacello, FileTree for starters.) frank
frank
Le 22/05/2013 14:02, Frank Shearar a écrit :
On 22 May 2013 12:49, stephane ducasse <stephane.ducasse@free.fr> 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?"
Now, I'd have a question related to that. Where should I push my changes ? Or give up on updating Gofer and use eval instead of config for my package loading.
Because the latter option makes it more difficult/less useful for me to think about submitting changes to Gofer. I've no interest in arguing about the merits of either position: I'm quite clear on how _I_ feel about things (namely, push changes upstream), but I do not want to fight over _your_ feelings on the matter. I just want to know where Pharo stands on the issue of changes to codebases that might be shared between Pharo and Squeak. (Gofer, Metacello, FileTree for starters.)
I'll start then to worry about the fact I'm relying on FileTree in the first place, then, since this is not a part of the Pharo infrastructure. But I couldn't find a way to get my git integration to work otherwise. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On 22 May 2013 13:13, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 22/05/2013 14:02, Frank Shearar a écrit :
On 22 May 2013 12:49, stephane ducasse <stephane.ducasse@free.fr> 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?"
Now, I'd have a question related to that. Where should I push my changes ?
Or give up on updating Gofer and use eval instead of config for my package loading.
Because the latter option makes it more difficult/less useful for me to think about submitting changes to Gofer. I've no interest in arguing about the merits of either position: I'm quite clear on how _I_ feel about things (namely, push changes upstream), but I do not want to fight over _your_ feelings on the matter. I just want to know where Pharo stands on the issue of changes to codebases that might be shared between Pharo and Squeak. (Gofer, Metacello, FileTree for starters.)
I'll start then to worry about the fact I'm relying on FileTree in the first place, then, since this is not a part of the Pharo infrastructure.
But I couldn't find a way to get my git integration to work otherwise.
Exactly. I'm halfway through supporting FileTree directly in Squeak's Installer (currently stalled as I figure out why SSL broke), and I'd intended to make Gofer support FileTree directly once that was done. But where to push the changes? frank
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?"
Now, I'd have a question related to that. Where should I push my changes ?
Or give up on updating Gofer and use eval instead of config for my package loading.
We are welcoming enhancements to Gofer.
Because the latter option makes it more difficult/less useful for me to think about submitting changes to Gofer. I've no interest in arguing about the merits of either position: I'm quite clear on how _I_ feel about things (namely, push changes upstream), but I do not want to fight over _your_ feelings on the matter. I just want to know where Pharo stands on the issue of changes to codebases that might be shared between Pharo and Squeak. (Gofer, Metacello, FileTree for starters.)
I'll start then to worry about the fact I'm relying on FileTree in the first place, then, since this is not a part of the Pharo infrastructure.
But I couldn't find a way to get my git integration to work otherwise.
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Le 22/05/2013 16:16, stephane ducasse a écrit :
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?"
Now, I'd have a question related to that. Where should I push my changes ?
Or give up on updating Gofer and use eval instead of config for my package loading.
We are welcoming enhancements to Gofer.
Ok. I have something ready, but it's an update to FileTree itself and it creates a dependency from FileTree to Gofer. Camillo has added an issue to Monticello, so I can upload i there. I'm not keen on adding a dependency between Gofer and FileTree, Gofer being a part of the Pharo core, and FileTree outside of it. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On 2013-05-22, at 14:02, Frank Shearar <frank.shearar@gmail.com> wrote:
On 22 May 2013 12:49, stephane ducasse <stephane.ducasse@free.fr> 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.
On 22 May 2013 13:20, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-05-22, at 14:02, Frank Shearar <frank.shearar@gmail.com> wrote:
On 22 May 2013 12:49, stephane ducasse <stephane.ducasse@free.fr> 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? 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? frank
On 2013-05-22, at 14:36, Frank Shearar <frank.shearar@gmail.com> wrote:
On 22 May 2013 13:20, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-05-22, at 14:02, Frank Shearar <frank.shearar@gmail.com> wrote:
On 22 May 2013 12:49, stephane ducasse <stephane.ducasse@free.fr> 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.
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. There IS a reason pharo forked from squeak...
On 22 May 2013 13:44, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-05-22, at 14:36, Frank Shearar <frank.shearar@gmail.com> wrote:
On 22 May 2013 13:20, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-05-22, at 14:02, Frank Shearar <frank.shearar@gmail.com> wrote:
On 22 May 2013 12:49, stephane ducasse <stephane.ducasse@free.fr> 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. frank
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.
Reducing Pharo to a personal decision is ridiculous but you can believe it if you want. Then I do not know what is politic. Pharo exists to create a sustainable eco system where companies can make money and wealth/knowledge/innovation can expand. We started Pharo because we could not do it with Squeak. No more no less. If you ask me, we should have started to do Pharo way before because we all lost energy for nothing. If I should redo it I would. Stef
On 22 May 2013 15:25, stephane ducasse <stephane.ducasse@free.fr> wrote:
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.
Reducing Pharo to a personal decision is ridiculous but you can believe it if you want. Then I do not know what is politic. Pharo exists to create a sustainable eco system where companies can make money and wealth/knowledge/innovation can expand. We started Pharo because we could not do it with Squeak. No more no less.
I believe the things I do regarding the fork because of personal conversations with people close to the decision.
If you ask me, we should have started to do Pharo way before because we all lost energy for nothing. If I should redo it I would.
That may be so. Squeak in 2013 is not the same community as Squeak in 2007/2008 (and not just because most of the community moved to Pharo). frank
I believe the things I do regarding the fork because of personal conversations with people close to the decision.
Fun because we are the people who took the decisions and we never got a real discussions so far. So this means that so far you got discussions with people that believe that they know why we forked but may be these people have only a partial view on it. ;D And since we created Pharo with Marcus and a couple of others I can tell that this is not a ego nor a personal point that drove us. I was thinking to go to ruby, python or lua at that time. This is a life vision. People should simply look at what our acts! We are not doing Pharo for us but because we believe in a smalltalk way of programming. But we want more much more than an old ST-80 system.
If you ask me, we should have started to do Pharo way before because we all lost energy for nothing. If I should redo it I would.
That may be so. Squeak in 2013 is not the same community as Squeak in 2007/2008 (and not just because most of the community moved to Pharo).
Sure! Now when you wake up the morning you have to decide what you want to do and we decided to build Pharo to create a sustainable eco system where companies can make money and wealth/knowledge/innovation can expand. I have no idea what is the goal of squeak but our goal is clear (and may be it is not reasonable) is to make a true alternative to dynamic languages out there and the best Smalltalk implementation we can. We wrote a 40 pages document and one day I will revise it. So people sharing this vision can join or not. Pharo is not a closed project we welcome newcomers. We even hired them when they share our vision and we have money (with I fight for). for example the first time I met esteban he was not really happy about Pharo, then he **understood** after discussing for real with us our vision. Stef
On 22 May 2013 16:42, stephane ducasse <stephane.ducasse@free.fr> wrote:
I believe the things I do regarding the fork because of personal conversations with people close to the decision.
Fun because we are the people who took the decisions and we never got a real discussions so far. So this means that so far you got discussions with people that believe that they know why we forked but may be these people have only a partial view on it. ;D
I'm going back on my word by engaging with this. I do not think either you or Marcus are egotists. I do think it is a crying shame that the split occurred. I don't understand the reasons, and by now they really don't matter. I've heard things from someone here about stuff that happened, but I can only take him at his word, because whatever happened happened off-list.
People should simply look at what our acts! We are not doing Pharo for us but because we believe in a smalltalk way of programming. But we want more much more than an old ST-80 system.
As do I. My issue with the way I've seen Pharo operate is this: Pharo uses some project. The original maintainer or maintainers don't respond quickly enough for Pharo's liking, so Pharo forks the repo and abandons upstream. That means that while Pharo's needs might be met, everyone else is worse off. The upstream maintainers become disillusioned with trying to keep up with the the churn in the base image, and give up. This has happened time and again. Now I completely understand the need to get stuff done NOW. What I'd like to see is some effort made to play nicely with the other communities. (And I think that keeping Camillo and Max and friends gainfully employed on improving git integration is an excellent way to do this - hosting on github makes pushing changes upstream so easy that we can hopefully avoid this pattern of fork-and-abandon.) frank
Frank, On 22 May 2013, at 14:55, Frank Shearar <frank.shearar@gmail.com> wrote:
On 22 May 2013 13:44, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-05-22, at 14:36, Frank Shearar <frank.shearar@gmail.com> wrote:
On 22 May 2013 13:20, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-05-22, at 14:02, Frank Shearar <frank.shearar@gmail.com> wrote:
On 22 May 2013 12:49, stephane ducasse <stephane.ducasse@free.fr> 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). 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). 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. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
+1
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).
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.
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On 22 May 2013 18:29, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Frank,
On 22 May 2013, at 14:55, Frank Shearar <frank.shearar@gmail.com> wrote:
On 22 May 2013 13:44, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-05-22, at 14:36, Frank Shearar <frank.shearar@gmail.com> wrote:
On 22 May 2013 13:20, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-05-22, at 14:02, Frank Shearar <frank.shearar@gmail.com> wrote:
On 22 May 2013 12:49, stephane ducasse <stephane.ducasse@free.fr> 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.
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
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.
that's simply not true, as you can see by all the success stories: http://files.pharo.org/SuccessStories/
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.
that is sad :(, I really think your contribution would be better off over here. I speak for many at our lab I think, that there is no motivation to prepare stuff for squeak: burnt once, fooled twice :/
On 22 May 2013 20:37, Camillo Bruni <camillobruni@gmail.com> wrote:
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.
that's simply not true, as you can see by all the success stories: http://files.pharo.org/SuccessStories/
Sorry, I didn't mean in general. I meant at my work.
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.
that is sad :(, I really think your contribution would be better off over here. I speak for many at our lab I think, that there is no motivation to prepare stuff for squeak: burnt once, fooled twice :/
I don't understand that, I really don't. Burnt by what? By whom? frank
On 22 May 2013 21:12, Frank Shearar <frank.shearar@gmail.com> wrote:
On 22 May 2013 18:29, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Frank,
On 22 May 2013, at 14:55, Frank Shearar <frank.shearar@gmail.com> wrote:
On 22 May 2013 13:44, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-05-22, at 14:36, Frank Shearar <frank.shearar@gmail.com> wrote:
On 22 May 2013 13:20, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-05-22, at 14:02, Frank Shearar <frank.shearar@gmail.com> wrote:
On 22 May 2013 12:49, stephane ducasse <stephane.ducasse@free.fr> 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.
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.
it will happen. I'm sure :)
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.
Just so that I understand. What are you trying to achieve? Most of the pharo people are not payed for doing pharo. What we are building (and fighting for) is an ecosystem in which smart guys can also find a job and it is becoming to happen. Mariano is full of work and many others. Sean told me that he got several job offers. Pharo is not the end, it is the start. It is not like we would like it to be but everyday it gets closer to it. Stef
On 23 May 2013 07:01, stephane ducasse <stephane.ducasse@free.fr> wrote:
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.
it will happen. I'm sure :)
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.
Just so that I understand. What are you trying to achieve?
I want a minimal Smalltalk with decent modularity semantics. I want decent integration with the standard tools of the trade. I _don't_ want to require special unique snowflake tools to work with my code. Right now I'm breaking up the Squeak Trunk into pieces, unloading things as I go. I hope, at some stage, to end up with some fairly minimal thing that will still allow one to load the main things that Squeak's used for. Colin Putney's Environments work is the main thrust for 4.5, together with the usual cruft removal work. But I see your point about lack of vision, whether perceived or actual. That's something Squeak will have to work on.
Most of the pharo people are not payed for doing pharo. What we are building (and fighting for) is an ecosystem in which smart guys can also find a job and it is becoming to happen. Mariano is full of work and many others. Sean told me that he got several job offers.
Pharo is not the end, it is the start. It is not like we would like it to be but everyday it gets closer to it.
That's good to hear. I feel the same way about Squeak, although it's clearly a lot, er, *mossier* than Pharo. frank
I want a minimal Smalltalk with decent modularity semantics.
We have been working on that since Pharo day one and we will continue.
I want decent integration with the standard tools of the trade. I _don't_ want to require special unique snowflake tools to work with my code.
Ok
Right now I'm breaking up the Squeak Trunk into pieces, unloading things as I go. I hope, at some stage, to end up with some fairly minimal thing that will still allow one to load the main things that Squeak's used for.
To me minimality can be a trap. We want to empower users. if you goal is to make smalltalk used with normal tool, I do not really understand why you do not focus on making Pharo fully working with Git.
Colin Putney's Environments work is the main thrust for 4.5, together with the usual cruft removal work.
We are doing that since years but if you want to spend your energy on that this is your decision.
But I see your point about lack of vision, whether perceived or actual. That's something Squeak will have to work on.
I even wrote 40 pages to describe that we will get a minimal image with no compiler, we have tanker and candle light that are starting to work and we dreamed about it with pavel back in 2005. But this is your time and energy. :) Just be ready for competition because we are going there for real. There are so many exciting paths (type inferences, real modules, git back end) that I do not understand why you just redo what we did. May be this is something that you want to prove to yourself and this is ok too.
Most of the pharo people are not payed for doing pharo. What we are building (and fighting for) is an ecosystem in which smart guys can also find a job and it is becoming to happen. Mariano is full of work and many others. Sean told me that he got several job offers.
Pharo is not the end, it is the start. It is not like we would like it to be but everyday it gets closer to it.
That's good to hear. I feel the same way about Squeak, although it's clearly a lot, er, *mossier* than Pharo.
frank
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?
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?
Frank this is a question of energy and money. If you have the energy to push changes towards us we will accept them if they do not break Pharo nor hamper us to move on. We are not against collaboration. Now we are focused on our goal. We are fighting to get time to push Pharo, we are fighting to get resources so we pay attention to where we spent them. Stef
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?"
what means pushing changes upstream? to the original gofer repo?
Because the latter option makes it more difficult/less useful for me to think about submitting changes to Gofer. I've no interest in arguing about the merits of either position: I'm quite clear on how _I_ feel about things (namely, push changes upstream), but I do not want to fight over _your_ feelings on the matter. I just want to know where Pharo stands on the issue of changes to codebases that might be shared between Pharo and Squeak. (Gofer, Metacello, FileTree for starters.)
Do we have the energy for that? Should we spent manpower? Who pay it and what else could they do instead? These are the questions I asked myself. I ***fight*** every day to push business around Pharo and to get credibility around our research and Pharo. This is a ***constant*** fight. Now I have no clue what is the vision behind squeak if any and why people doing business would use it instead of Pharo. But at the end of the day I cannot do anything about it soâ¦. Now I'm concerned that it can have an impact and slow us. Just having large configurationOf that starts to get complex to read/change and tests makes me nervous. Stef PS: we are ants running around while elephants (python, ruby, Javascripts) are passing close by. Not making serious progress is death.
On 22 May 2013 15:14, stephane ducasse <stephane.ducasse@free.fr> wrote:
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?"
what means pushing changes upstream? to the original gofer repo?
Yes.
Because the latter option makes it more difficult/less useful for me to think about submitting changes to Gofer. I've no interest in arguing about the merits of either position: I'm quite clear on how _I_ feel about things (namely, push changes upstream), but I do not want to fight over _your_ feelings on the matter. I just want to know where Pharo stands on the issue of changes to codebases that might be shared between Pharo and Squeak. (Gofer, Metacello, FileTree for starters.)
Do we have the energy for that? Should we spent manpower? Who pay it and what else could they do instead? These are the questions I asked myself.
These are exactly the questions I ask myself too. Now if Lukas has abandoned Gofer, that's a different story: if the upstream maintainer has disappeared then forking Gofer is an act of survival. But that's not the answer that anyone's given me. "Look at what we've done" is all I've had so far. To be fair, sometimes the people who can answer (like yourself!) are busy doing other utterly necessary things. So: if Lukas' Gofer is effectively abandoned, then so be it: Pharo's fork is the new canonical repo (de facto: it's the one that's maintained), and Pharo's repo is where Gofer enhancements should go. I'm happy with that.
I ***fight*** every day to push business around Pharo and to get credibility around our research and Pharo. This is a ***constant*** fight. Now I have no clue what is the vision behind squeak if any and why people doing business would use it instead of Pharo. But at the end of the day I cannot do anything about it soâ¦. Now I'm concerned that it can have an impact and slow us. Just having large configurationOf that starts to get complex to read/change and tests makes me nervous.
Stef
PS: we are ants running around while elephants (python, ruby, Javascripts) are passing close by. Not making serious progress is death.
And that's why I don't push Smalltalk as an option at work. It's too different, it has too many special requirements. That's exactly why I push the things I do. frank
On May 22, 2013, at 4:26 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
PS: we are ants running around while elephants (python, ruby, Javascripts) are passing close by. Not making serious progress is death.
And that's why I don't push Smalltalk as an option at work. It's too different, it has too many special requirements.
May be but with this state of mind then we should all better to something else. And we are all working on Pharo just to make it shiny and a tool of choice to build complex system. And we are getting really there. We do not have the luxury to think that Pharo is only for research. Else life would be easier but probably less challenging too.
That's exactly why I push the things I do.
Dne 22. 05. 2013 16:14, piše stephane ducasse:
PS: we are ants running around while elephants (python, ruby, Javascripts) are passing close by. Not making serious progress is death.
We will be even smaller ants if we won't cooperate and listen to each other, and this thread is exact example, how listening don't go very well. Also, sending messages like Pharo as Smalltalk-inspired instead of naming it proudly as Pharo Smalltalk is also a short-sighted, again making divisions instead of cooperation. Not to mention that outside world is confused, questioning if Pharo is or will stay Smalltalk at all. And ants we are smaller and smaller... Janko -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
On 2013-05-22, at 17:43, Janko Mivšek <janko.mivsek@eranova.si> wrote:
Dne 22. 05. 2013 16:14, piše stephane ducasse:
PS: we are ants running around while elephants (python, ruby, Javascripts) are passing close by. Not making serious progress is death.
We will be even smaller ants if we won't cooperate and listen to each other, and this thread is exact example, how listening don't go very well.
Also, sending messages like Pharo as Smalltalk-inspired instead of naming it proudly as Pharo Smalltalk is also a short-sighted, again making divisions instead of cooperation. Not to mention that outside world is confused, questioning if Pharo is or will stay Smalltalk at all.
Now I wonder how this will play along when we will add Slots :P: -not used in any other language - not in the ST80 specs!
PS: we are ants running around while elephants (python, ruby, Javascripts) are passing close by. Not making serious progress is death.
We will be even smaller ants if we won't cooperate and listen to each other, and this thread is exact example, how listening don't go very well.
Also, sending messages like Pharo as Smalltalk-inspired instead of naming it proudly as Pharo Smalltalk is also a short-sighted, again making divisions instead of cooperation. Not to mention that outside world is confused, questioning if Pharo is or will stay Smalltalk at all.
Now I wonder how this will play along when we will add Slots :P: -not used in any other language - not in the ST80 specs!
but so fucking powerful and conceptual elegant! Of course dan and alan totally missed them but we will get them for real. Stef
PS: we are ants running around while elephants (python, ruby, Javascripts) are passing close by. Not making serious progress is death.
We will be even smaller ants if we won't cooperate and listen to each other, and this thread is exact example, how listening don't go very well.
No it is not. frank asked our position on upstream and we said it.
Also, sending messages like Pharo as Smalltalk-inspired instead of naming it proudly as Pharo Smalltalk is also a short-sighted, again making divisions instead of cooperation.
Because you think that showing a technology that is from 1980 when Javascript is out is a way to get slightly credible. Janko you should give more lecture to students to see their eyesâ¦. I did that during years trying to push Smalltalk with grey visualworks and pinky squeak and I can tell you that it was a failure. Now let us talk about car, I want a brand new one and hyper cool not one (even cool) from the 1980. I want the one of 2010. Now may be you do not understand what we are doing and you think that we are idiot. But get burnt as many times as us and come back to talk with us: - because we are systematically perceived as strange/idiots when using smalltalk - we got the blackout based on java, now there is scala and javascript.
Not to mention that outside world is confused, questioning if Pharo is or will stay Smalltalk at all.
The outside world (where is that)? who is that? if you believe that the world did not change since 1980 this is good for you :). But the world changed. Now we want a super Smalltalk not just a Smalltalk from the 80. Not one where each I want to do something I have to jump above barrier and garbage. I want a system that enable me to work, be productive and have fun with objects. Stef
Janko, On 22 May 2013, at 17:43, Janko Mivšek <janko.mivsek@eranova.si> wrote:
Dne 22. 05. 2013 16:14, piše stephane ducasse:
PS: we are ants running around while elephants (python, ruby, Javascripts) are passing close by. Not making serious progress is death.
We will be even smaller ants if we won't cooperate and listen to each other, and this thread is exact example, how listening don't go very well.
Also, sending messages like Pharo as Smalltalk-inspired instead of naming it proudly as Pharo Smalltalk is also a short-sighted, again making divisions instead of cooperation. Not to mention that outside world is confused, questioning if Pharo is or will stay Smalltalk at all.
And ants we are smaller and smallerâ¦
It is actually the complete opposite: the Pharo project is responsible for a lot of, if not most, renewed interest in Smalltalk. The last couple of years, activity in the Pharo community has been increasing steadily. The sheer amount of people and projects is proof of that. It is precisely due to the direction and actual steps taken by Pharo that so many organisations and business are using it. And although the Pharo vision is much more than that, the approach to moving forward, sometimes taking ownership and responsibility and occasionally breaking backwards compatibility, is what makes the current velocity of change possible. And there are so many more cool things in the pipeline. Sven
Janko
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
Well, yet another ant doing business w/ Pharo over here. I signed for the consortium and not for staying stuck in the eighties for sure. Phil On Wed, May 22, 2013 at 7:18 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Janko,
On 22 May 2013, at 17:43, Janko Mivšek <janko.mivsek@eranova.si> wrote:
Dne 22. 05. 2013 16:14, piše stephane ducasse:
PS: we are ants running around while elephants (python, ruby, Javascripts) are passing close by. Not making serious progress is death.
We will be even smaller ants if we won't cooperate and listen to each other, and this thread is exact example, how listening don't go very well.
Also, sending messages like Pharo as Smalltalk-inspired instead of naming it proudly as Pharo Smalltalk is also a short-sighted, again making divisions instead of cooperation. Not to mention that outside world is confused, questioning if Pharo is or will stay Smalltalk at all.
And ants we are smaller and smaller...
It is actually the complete opposite: the Pharo project is responsible for a lot of, if not most, renewed interest in Smalltalk. The last couple of years, activity in the Pharo community has been increasing steadily. The sheer amount of people and projects is proof of that.
It is precisely due to the direction and actual steps taken by Pharo that so many organisations and business are using it. And although the Pharo vision is much more than that, the approach to moving forward, sometimes taking ownership and responsibility and occasionally breaking backwards compatibility, is what makes the current velocity of change possible.
And there are so many more cool things in the pipeline.
Sven
Janko
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
My own understanding where Pharo is heading in couple worlds can be described as follows: - make better smalltalk And making better sometimes means breaking eggs, and fixing something which is not broken. Sure thing, Pharo is not immune from wrong decisions and bad ideas (as any other project). But as long as visions stays same, bad things can be fixed and made better. -- Best regards, Igor Stasenko.
Le 22/05/2013 13:28, Frank Shearar a écrit :
On 22 May 2013 12:13, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 22/05/2013 13:05, Frank Shearar a écrit :
On 22 May 2013 12:05, Goubier Thierry <thierry.goubier@cea.fr> wrote:
I'm trying to setup a git-based build script from the command line and I end up unable to load a configuration from a filetree repository on the pharo command line.
Has someone encountered that? It seems Gopher is missing a FiletreeURL for this to work.
What does your script currently look like?
frank
./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?
Not sure I can answer that; in the meantime, I just added a FileTreeUrl as a subclass of FileUrl, and Gofer seems happy with that. Thierry
frank
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On 22 May 2013 12:56, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 22/05/2013 13:28, Frank Shearar a écrit :
On 22 May 2013 12:13, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 22/05/2013 13:05, Frank Shearar a écrit :
On 22 May 2013 12:05, Goubier Thierry <thierry.goubier@cea.fr> wrote:
I'm trying to setup a git-based build script from the command line and I end up unable to load a configuration from a filetree repository on the pharo command line.
Has someone encountered that? It seems Gopher is missing a FiletreeURL for this to work.
What does your script currently look like?
frank
./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?
Not sure I can answer that; in the meantime, I just added a FileTreeUrl as a subclass of FileUrl, and Gofer seems happy with that.
Neat. frank
Thierry
frank
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Le 22/05/2013 13:57, Frank Shearar a écrit :
On 22 May 2013 12:56, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 22/05/2013 13:28, Frank Shearar a écrit :
On 22 May 2013 12:13, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 22/05/2013 13:05, Frank Shearar a écrit :
On 22 May 2013 12:05, Goubier Thierry <thierry.goubier@cea.fr> wrote:
I'm trying to setup a git-based build script from the command line and I end up unable to load a configuration from a filetree repository on the pharo command line.
Has someone encountered that? It seems Gopher is missing a FiletreeURL for this to work.
What does your script currently look like?
frank
./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?
Not sure I can answer that; in the meantime, I just added a FileTreeUrl as a subclass of FileUrl, and Gofer seems happy with that.
Neat.
Now, I can do: ./pharo Pharo.image eval --save Gofer new url: \'filetree://`pwd`/../../src\'\; package: \'TauC-Parser\'\; load And a long time after (package loading is slowwww), it's done. However, the --install in the config handler doesn't work; had to use --install=stable instead. Thierry
frank
Thierry
frank
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Not sure I can answer that; in the meantime, I just added a FileTreeUrl as a subclass of FileUrl, and Gofer seems happy with that.
Neat.
Now, I can do:
./pharo Pharo.image eval --save Gofer new url: \'filetree://`pwd`/../../src\'\; package: \'TauC-Parser\'\; load
cool!
And a long time after (package loading is slowwww), it's done.
However, the --install in the config handler doesn't work; had to use --install=stable instead.
that's in 2.0 I guess, since I changed it to use #stable by default in 2.0. So we should push the FileTreeUrl into the 2.0 repository for FileTree..
On 2013-05-22, at 15:05, Camillo Bruni <camillobruni@gmail.com> wrote:
Not sure I can answer that; in the meantime, I just added a FileTreeUrl as a subclass of FileUrl, and Gofer seems happy with that.
Neat.
Now, I can do:
./pharo Pharo.image eval --save Gofer new url: \'filetree://`pwd`/../../src\'\; package: \'TauC-Parser\'\; load
cool!
And a long time after (package loading is slowwww), it's done.
However, the --install in the config handler doesn't work; had to use --install=stable instead.
that's in 2.0 I guess, since I changed it to use #stable by default in 2.0. So we should push the FileTreeUrl into the 2.0 repository for FileTree..
or simpler, change the command line handler to use GenericURL
Le 22/05/2013 15:12, Camillo Bruni a écrit :
On 2013-05-22, at 15:05, Camillo Bruni <camillobruni@gmail.com> wrote:
Not sure I can answer that; in the meantime, I just added a FileTreeUrl as a subclass of FileUrl, and Gofer seems happy with that.
Neat.
Now, I can do:
./pharo Pharo.image eval --save Gofer new url: \'filetree://`pwd`/../../src\'\; package: \'TauC-Parser\'\; load
cool!
And a long time after (package loading is slowwww), it's done.
However, the --install in the config handler doesn't work; had to use --install=stable instead.
that's in 2.0 I guess, since I changed it to use #stable by default in 2.0. So we should push the FileTreeUrl into the 2.0 repository for FileTree..
or simpler, change the command line handler to use GenericURL
Well, with FileTreeUrl, if you have a config in your filetree repo, you can use config filetree:///whatever ConfigurationOf; no need to change the ConfigurationCommandLineHandler for that. I haven't done a ConfigurationOf for that project, so I wanted to load packages by packages (hence the eval) but you'll notice this is almost the same code as ConfigurationCommandLineHandler. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On 2013-05-22, at 15:22, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 22/05/2013 15:12, Camillo Bruni a écrit :
On 2013-05-22, at 15:05, Camillo Bruni <camillobruni@gmail.com> wrote:
Not sure I can answer that; in the meantime, I just added a FileTreeUrl as a subclass of FileUrl, and Gofer seems happy with that.
Neat.
Now, I can do:
./pharo Pharo.image eval --save Gofer new url: \'filetree://`pwd`/../../src\'\; package: \'TauC-Parser\'\; load
cool!
And a long time after (package loading is slowwww), it's done.
However, the --install in the config handler doesn't work; had to use --install=stable instead.
that's in 2.0 I guess, since I changed it to use #stable by default in 2.0. So we should push the FileTreeUrl into the 2.0 repository for FileTree..
or simpler, change the command line handler to use GenericURL
Well, with FileTreeUrl, if you have a config in your filetree repo, you can use config filetree:///whatever ConfigurationOf; no need to change the ConfigurationCommandLineHandler for that.
I haven't done a ConfigurationOf for that project, so I wanted to load packages by packages (hence the eval) but you'll notice this is almost the same code as ConfigurationCommandLineHandler.
yes, I came to the same conclusion: https://github.com/dalehenrich/filetree/issues/74 :)
Le 22/05/2013 15:26, Camillo Bruni a écrit :
On 2013-05-22, at 15:22, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 22/05/2013 15:12, Camillo Bruni a écrit :
On 2013-05-22, at 15:05, Camillo Bruni <camillobruni@gmail.com> wrote:
Not sure I can answer that; in the meantime, I just added a FileTreeUrl as a subclass of FileUrl, and Gofer seems happy with that.
Neat.
Now, I can do:
./pharo Pharo.image eval --save Gofer new url: \'filetree://`pwd`/../../src\'\; package: \'TauC-Parser\'\; load
cool!
And a long time after (package loading is slowwww), it's done.
However, the --install in the config handler doesn't work; had to use --install=stable instead.
that's in 2.0 I guess, since I changed it to use #stable by default in 2.0. So we should push the FileTreeUrl into the 2.0 repository for FileTree..
or simpler, change the command line handler to use GenericURL
Well, with FileTreeUrl, if you have a config in your filetree repo, you can use config filetree:///whatever ConfigurationOf; no need to change the ConfigurationCommandLineHandler for that.
I haven't done a ConfigurationOf for that project, so I wanted to load packages by packages (hence the eval) but you'll notice this is almost the same code as ConfigurationCommandLineHandler.
yes, I came to the same conclusion: https://github.com/dalehenrich/filetree/issues/74 :)
I've uploaded a MonticelloFileTree-Core package with a FileTreeUrl in it in the ss3 FileTree repository. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Thierry, I'm on vacation this week, but I will be integrating your change into Metacello ... thanks man! Dale ----- Original Message ----- | From: "Goubier Thierry" <thierry.goubier@cea.fr> | To: "Discusses Development of Pharo" <pharo-dev@lists.pharo.org> | Sent: Wednesday, May 22, 2013 7:48:49 AM | Subject: Re: [Pharo-dev] MC Filetree -- missing FiletreeURL ? | | Le 22/05/2013 15:26, Camillo Bruni a écrit : | > | > On 2013-05-22, at 15:22, Goubier Thierry <thierry.goubier@cea.fr> | > wrote: | > | >> Le 22/05/2013 15:12, Camillo Bruni a écrit : | >>> | >>> On 2013-05-22, at 15:05, Camillo Bruni <camillobruni@gmail.com> | >>> wrote: | >>> | >>>>>>> Not sure I can answer that; in the meantime, I just added a | >>>>>>> FileTreeUrl as a | >>>>>>> subclass of FileUrl, and Gofer seems happy with that. | >>>>>> | >>>>>> Neat. | >>>>> | >>>>> Now, I can do: | >>>>> | >>>>> ./pharo Pharo.image eval --save Gofer new url: | >>>>> \'filetree://`pwd`/../../src\'\; package: \'TauC-Parser\'\; | >>>>> load | >>>> | >>>> cool! | >>>> | >>>>> And a long time after (package loading is slowwww), it's done. | >>>>> | >>>>> However, the --install in the config handler doesn't work; had | >>>>> to use --install=stable instead. | >>>> | >>>> that's in 2.0 I guess, since I changed it to use #stable by | >>>> default in 2.0. | >>>> So we should push the FileTreeUrl into the 2.0 repository for | >>>> FileTree.. | >>> | >>> or simpler, change the command line handler to use GenericURL | >> | >> Well, with FileTreeUrl, if you have a config in your filetree | >> repo, you can use config filetree:///whatever ConfigurationOf; no | >> need to change the ConfigurationCommandLineHandler for that. | >> | >> I haven't done a ConfigurationOf for that project, so I wanted to | >> load packages by packages (hence the eval) but you'll notice this | >> is almost the same code as ConfigurationCommandLineHandler. | > | > yes, I came to the same conclusion: | > https://github.com/dalehenrich/filetree/issues/74 :) | | I've uploaded a MonticelloFileTree-Core package with a FileTreeUrl in | it | in the ss3 FileTree repository. | | Thierry | -- | Thierry Goubier | CEA list | Laboratoire des Fondations des Systèmes Temps Réel Embarqués | 91191 Gif sur Yvette Cedex | France | Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 |
Le 22/05/2013 15:05, Camillo Bruni a écrit :
Not sure I can answer that; in the meantime, I just added a FileTreeUrl as a subclass of FileUrl, and Gofer seems happy with that.
Neat.
Now, I can do:
./pharo Pharo.image eval --save Gofer new url: \'filetree://`pwd`/../../src\'\; package: \'TauC-Parser\'\; load
cool!
And a long time after (package loading is slowwww), it's done.
However, the --install in the config handler doesn't work; had to use --install=stable instead.
that's in 2.0 I guess, since I changed it to use #stable by default in 2.0. So we should push the FileTreeUrl into the 2.0 repository for FileTree..
I think it's not the stable by default which creates the error, but the fact the --install command line option looked for has no provision for no argument :) I'll push my version of FileTree into the 2.0 repo (it creates a dependency on Gofer). Is there a SmalltalkHub link for that? Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On 2013-05-22, at 13:05, Goubier Thierry <thierry.goubier@cea.fr> wrote:
I'm trying to setup a git-based build script from the command line and I end up unable to load a configuration from a filetree repository on the pharo command line.
Has someone encountered that? It seems Gopher is missing a FiletreeURL for this to work.
Did you install Filetree using the instructions given here https://github.com/dalehenrich/filetree? Gofer new url: 'http://ss3.gemstone.com/ss/FileTree'; package: 'ConfigurationOfFileTree'; load. ((Smalltalk at: #ConfigurationOfFileTree) project version: #'stable') load. then I am also not sure how much the internals of the config command line handler rely on the URL code.
Le 22/05/2013 13:58, Camillo Bruni a écrit :
On 2013-05-22, at 13:05, Goubier Thierry <thierry.goubier@cea.fr> wrote:
I'm trying to setup a git-based build script from the command line and I end up unable to load a configuration from a filetree repository on the pharo command line.
Has someone encountered that? It seems Gopher is missing a FiletreeURL for this to work.
Did you install Filetree using the instructions given here https://github.com/dalehenrich/filetree?
Gofer new url: 'http://ss3.gemstone.com/ss/FileTree'; package: 'ConfigurationOfFileTree'; load.
((Smalltalk at: #ConfigurationOfFileTree) project version: #'stable') load.
then I am also not sure how much the internals of the config command line handler rely on the URL code.
I specifically loaded version 1.0.2 of FileTree because this is the only one which has a pharo2.x tag in the configuration (and I knew that the version I used in 1.4 wasn't working in 2.0). 1.0.2 works fine in 2.0, if you want to know :) The config handler calls Gofer with an url, as far as I have looked. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
participants (9)
-
Camillo Bruni -
Dale K. Henrichs -
Frank Shearar -
Goubier Thierry -
Igor Stasenko -
Janko Mivšek -
phil＠highoctane.be -
stephane ducasse -
Sven Van Caekenberghe