I just noticed that OSProcess misses from Pharo 6 image, it was supposed to be replaced by OSSubProcess but this not in the image either ? What we suppose to use to execute bash from inside pharo ?
Am 28.10.2016 um 13:17 schrieb Dimitris Chloupis <kilon.alios@gmail.com>:
I just noticed that OSProcess misses from Pharo 6 image, it was supposed to be replaced by OSSubProcess but this not in the image either ? What we suppose to use to execute bash from inside pharo ?
It was never in the image. You need to install it in order to use it. Norbert
I have a love and hate relationship with Pharo this one I will put in the hate category You expect people to use pharo when you do not offer functionality they come to expect from the language they already use and not even offer an altervative, say a library with similar command line functionality (See Scale). On Fri, Oct 28, 2016 at 2:59 PM Norbert Hartl <norbert@hartl.name> wrote:
Am 28.10.2016 um 13:17 schrieb Dimitris Chloupis <kilon.alios@gmail.com :
I just noticed that OSProcess misses from Pharo 6 image, it was supposed to be replaced by OSSubProcess but this not in the image either ? What we suppose to use to execute bash from inside pharo ?
It was never in the image. You need to install it in order to use it.
Norbert
But the functionality is there, it's just that it is not loaded by default. Loading it by default implies wedding Pharo's life cycle with OS(Sub)Process' one, and having to maintain the possibility of dependencies to OS(Sub)Process spreading in the entire environment. What is wrong in executing a simple Metacello command to load it? -------- Original Message --------
I have a love and hate relationship with Pharo this one I will put in the hate category
You expect people to use pharo when you do not offer functionality they come to expect from the language they already use and not even offer an altervative, say a library with similar command line functionality (See Scale).
On Fri, Oct 28, 2016 at 2:59 PM Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>> wrote:
> Am 28.10.2016 um 13:17 schrieb Dimitris Chloupis <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>>: > > I just noticed that OSProcess misses from Pharo 6 image, it was supposed to be replaced by OSSubProcess but this not in the image either ? What we suppose to use to execute bash from inside pharo ?
It was never in the image. You need to install it in order to use it.
Norbert
2016-10-28 14:12 GMT+02:00 Guille Polito <guillermopolito@gmail.com>:
But the functionality is there, it's just that it is not loaded by default.
Loading it by default implies wedding Pharo's life cycle with OS(Sub)Process' one, and having to maintain the possibility of dependencies to OS(Sub)Process spreading in the entire environment.
Like many of the other projects loaded by default in a Pharo image. What is wrong with OSSubprocess or OSProcess so that they can't be treated the same?
What is wrong in executing a simple Metacello command to load it?
The fact the image doesn't come as a one download / ready to use for an average user? Thierry
-------- Original Message --------
I have a love and hate relationship with Pharo this one I will put in the hate category
You expect people to use pharo when you do not offer functionality they come to expect from the language they already use and not even offer an altervative, say a library with similar command line functionality (See Scale).
On Fri, Oct 28, 2016 at 2:59 PM Norbert Hartl <norbert@hartl.name> wrote:
Am 28.10.2016 um 13:17 schrieb Dimitris Chloupis <kilon.alios@gmail.com :
I just noticed that OSProcess misses from Pharo 6 image, it was supposed to be replaced by OSSubProcess but this not in the image either ? What we suppose to use to execute bash from inside pharo ?
It was never in the image. You need to install it in order to use it.
Norbert
-------- Original Message --------
2016-10-28 14:12 GMT+02:00 Guille Polito <guillermopolito@gmail.com <mailto:guillermopolito@gmail.com>>:
But the functionality is there, it's just that it is not loaded by default.
Loading it by default implies wedding Pharo's life cycle with OS(Sub)Process' one, and having to maintain the possibility of dependencies to OS(Sub)Process spreading in the entire environment.
Like many of the other projects loaded by default in a Pharo image. What is wrong with OSSubprocess or OSProcess so that they can't be treated the same?
The fact that it is done for some projects it does not mean it is good. Moreover, it does not mean either that we can manage it well :). - Just ask Stef the headaches he has every time he has to do a change that crosses many packages and some of them are developed outside the image (do we commit everything to the inbox, or do we commit outside, wait for integration, integrate a configuration, wait until everything is right, not break cyclic dependencies? and so on...). - Or just see what happened with the metacello configurations of the refactoring browser, opal, and so on. Also, we are starting to see how to move Pharo sources to git, and this means we are looking at how we should design Pharo's repository so we can smoothly collaborate and synchronize repositories using pull requests. For example, these two last week I took some hours to evaluate and exercise myself with git subtrees and submodules. The notes I made from this are here: https://github.com/guillep/PharoIntegrationProcess/wiki/Analysis-of-sub-proj... What I mean, adding a package inside the image can bring also a lot of problems to package maintainers, so doing it just because "others do it" is not a good argument.
What is wrong in executing a simple Metacello command to load it?
The fact the image doesn't come as a one download / ready to use for an average user?
What is an average user? If you mean beginners, I can think of myself using a new language: when I do not know how to do something in some new language, I google for documentation or already done solutions (stack overflow :P). Then I follow instructions if they are not too complicated. And installing a library is inside my box for "not too complicated". I do and did it all the time with maven, sbt, apt-get, npm, and it is for sure not simpler than metacello most of the cases... If you mean pharo users like you and me, I think then that using Metacello should be a standard practice to manage projects and dependencies. Now, a nice step in the middle of both worlds would be making sure that OS(Sub)process is in the catalog.
Thierry
-------- Original Message --------
I have a love and hate relationship with Pharo this one I will put in the hate category
You expect people to use pharo when you do not offer functionality they come to expect from the language they already use and not even offer an altervative, say a library with similar command line functionality (See Scale).
On Fri, Oct 28, 2016 at 2:59 PM Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>> wrote:
> Am 28.10.2016 um 13:17 schrieb Dimitris Chloupis <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>>:
>
> I just noticed that OSProcess misses from Pharo 6 image, it was supposed to be replaced by OSSubProcess but this not in the image either ? What we suppose to use to execute bash from inside pharo ?
It was never in the image. You need to install it in order to use it.
Norbert
On 10/28/16 6:05 AM, Guille Polito wrote:
Also, we are starting to see how to move Pharo sources to git, and this means we are looking at how we should design Pharo's repository so we can smoothly collaborate and synchronize repositories using pull requests. For example, these two last week I took some hours to evaluate and exercise myself with git subtrees and submodules. The notes I made from this are here:
https://github.com/guillep/PharoIntegrationProcess/wiki/Analysis-of-sub-proj...
What I mean, adding a package inside the image can bring also a lot of problems to package maintainers, so doing it just because "others do it" is not a good argument.
Guille, I looked at trying to use submodules with a project or two back when I first started working with git and github[1] -- 5 years ago now. It seems that using submodules introduces a very tight coupling between the individual projects and it was more of a pain than it was worth ... Using Metacello locks and independent clones has worked very well, but some structure is needed ... I spent several years "splashing around" trying to figure out a structure for GsDevKit/GLASS and finally settled on the structure in GsDevKit_home[2] (about 2 years ago) and the structure there is working quite well ... I am giving a talk at the upcoming Smalltalks where I will be describing my thoughts on this structure/organization in detail. I am certainly willing to share my experience with you guys and maybe save you a couple of years of "splashing around" --- if you are interested. Dale [1] https://github.com/dalehenrich/amber-skeleton [2] https://github.com/GsDevKit/GsDevKit_home
I'm not going to smalltalks, but maybe we can do an skype (or a public discord) any time soon? -------- Original Message --------
On 10/28/16 6:05 AM, Guille Polito wrote:
Also, we are starting to see how to move Pharo sources to git, and this means we are looking at how we should design Pharo's repository so we can smoothly collaborate and synchronize repositories using pull requests. For example, these two last week I took some hours to evaluate and exercise myself with git subtrees and submodules. The notes I made from this are here:
https://github.com/guillep/PharoIntegrationProcess/wiki/Analysis-of-sub-proj...
What I mean, adding a package inside the image can bring also a lot of problems to package maintainers, so doing it just because "others do it" is not a good argument.
Guille,
I looked at trying to use submodules with a project or two back when I first started working with git and github[1] -- 5 years ago now.
It seems that using submodules introduces a very tight coupling between the individual projects and it was more of a pain than it was worth ...
Using Metacello locks and independent clones has worked very well, but some structure is needed ...
I spent several years "splashing around" trying to figure out a structure for GsDevKit/GLASS and finally settled on the structure in GsDevKit_home[2] (about 2 years ago) and the structure there is working quite well ...
I am giving a talk at the upcoming Smalltalks where I will be describing my thoughts on this structure/organization in detail.
I am certainly willing to share my experience with you guys and maybe save you a couple of years of "splashing around" --- if you are interested.
Dale
[1] https://github.com/dalehenrich/amber-skeleton [2] https://github.com/GsDevKit/GsDevKit_home
Guille that would be great ... I am in the process of writing the presentation but would make time to talk with you ... lets arrange to skype or discord sometime next week ... Dale On 10/28/16 7:53 AM, Guille Polito wrote:
I'm not going to smalltalks, but maybe we can do an skype (or a public discord) any time soon?
-------- Original Message --------
On 10/28/16 6:05 AM, Guille Polito wrote:
Also, we are starting to see how to move Pharo sources to git, and this means we are looking at how we should design Pharo's repository so we can smoothly collaborate and synchronize repositories using pull requests. For example, these two last week I took some hours to evaluate and exercise myself with git subtrees and submodules. The notes I made from this are here:
https://github.com/guillep/PharoIntegrationProcess/wiki/Analysis-of-sub-proj...
What I mean, adding a package inside the image can bring also a lot of problems to package maintainers, so doing it just because "others do it" is not a good argument.
Guille,
I looked at trying to use submodules with a project or two back when I first started working with git and github[1] -- 5 years ago now.
It seems that using submodules introduces a very tight coupling between the individual projects and it was more of a pain than it was worth ...
Using Metacello locks and independent clones has worked very well, but some structure is needed ...
I spent several years "splashing around" trying to figure out a structure for GsDevKit/GLASS and finally settled on the structure in GsDevKit_home[2] (about 2 years ago) and the structure there is working quite well ...
I am giving a talk at the upcoming Smalltalks where I will be describing my thoughts on this structure/organization in detail.
I am certainly willing to share my experience with you guys and maybe save you a couple of years of "splashing around" --- if you are interested.
Dale
[1] https://github.com/dalehenrich/amber-skeleton [2] https://github.com/GsDevKit/GsDevKit_home
Dimitris, As Guile explained it, it is a matter of responsibility to include a package in the Pharo image. The more packages in the base Pharo image the more complicated is the release process for the Pharo team, and more stress, etc. Nevertheless, a complement Pharo release with additional packages is possible and can be automated with Jenkins. But another team need to take this specific responsibility. The Smalltalk community has been discussing this matter for decades. Hope it clarify Hilaire Le 28/10/2016 à 15:05, Guille Polito a écrit :
What I mean, adding a package inside the image can bring also a lot of problems to package maintainers, so doing it just because "others do it" is not a good argument.
-- Dr. Geo http://drgeo.eu
For those not experienced with other language let me offer here an explanation why having something like OSProcess is vastly important. Coding even before the time of Smalltalk has been tied to the command line, even in this day all languages come with the ability of the command line to use them and them to use the command line. Since increasing the size of our community is paramount to the acceleration of the growth and evolution of pharo , it is also paramount to smooth out the learning curve of Smalltalk. In order to do that we must offer a familiar environment to these coders , especially in the case where Pharo offers no real alternative. Arguing that just because Smalltalk offers a different way of doing things ok to ignore what others are been doing, is an excuse destined to collapse on itself when Smalltalk for decades and still even Pharo fails to offer , not only good alternatives but even bad ones , in case of command line. Which means that currently Pharo offers no real alternative for functionality that is offered via the command line, that means: 1) No library to deal with Git directly , Gitfiletree does this through the command line 2) No command line alternative for interaction with a vast array of software like VLC, ImageMagick, video converters, audio converters , programming languages etc etc 3) Even when we take a look at pharo ecosystem the command like reigns supreme, for example a trip to the pharo website success stories make its clear that by far the most popular platform for commercial pharo apps is the web . Guess what tool the web developers use the most ? Yeap the command line. We make the life of those people that want to use pharo professionally really really hard. Programming and coding is about covering a vast array of scenarios and maybe in a small community of a few hundred like pharo maybe its ok to ignore the command line but I can assure you in a community like Python that is more than 2 million , it is not. We already got command line integration for pharo outside the image , lets make the logical next step and offer also command line support from inside the image as well. Let's not justify the stereotype that "Smalltalk is a distant lone island, just because" or that is outdated. On Fri, Oct 28, 2016 at 3:25 PM Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-10-28 14:12 GMT+02:00 Guille Polito <guillermopolito@gmail.com>:
But the functionality is there, it's just that it is not loaded by default.
Loading it by default implies wedding Pharo's life cycle with OS(Sub)Process' one, and having to maintain the possibility of dependencies to OS(Sub)Process spreading in the entire environment.
Like many of the other projects loaded by default in a Pharo image. What is wrong with OSSubprocess or OSProcess so that they can't be treated the same?
What is wrong in executing a simple Metacello command to load it?
The fact the image doesn't come as a one download / ready to use for an average user?
Thierry
-------- Original Message --------
I have a love and hate relationship with Pharo this one I will put in the hate category
You expect people to use pharo when you do not offer functionality they come to expect from the language they already use and not even offer an altervative, say a library with similar command line functionality (See Scale).
On Fri, Oct 28, 2016 at 2:59 PM Norbert Hartl <norbert@hartl.name> wrote:
Am 28.10.2016 um 13:17 schrieb Dimitris Chloupis <kilon.alios@gmail.com :
I just noticed that OSProcess misses from Pharo 6 image, it was supposed to be replaced by OSSubProcess but this not in the image either ? What we suppose to use to execute bash from inside pharo ?
It was never in the image. You need to install it in order to use it.
Norbert
For what it is worth, I am with Dimitris on this: sub shell execution is so fundamental that it should be a standard part of the image. I always thought that that was the goal of the new OSSubProcess.
On 28 Oct 2016, at 15:25, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
For those not experienced with other language let me offer here an explanation why having something like OSProcess is vastly important.
Coding even before the time of Smalltalk has been tied to the command line, even in this day all languages come with the ability of the command line to use them and them to use the command line.
Since increasing the size of our community is paramount to the acceleration of the growth and evolution of pharo , it is also paramount to smooth out the learning curve of Smalltalk. In order to do that we must offer a familiar environment to these coders , especially in the case where Pharo offers no real alternative.
Arguing that just because Smalltalk offers a different way of doing things ok to ignore what others are been doing, is an excuse destined to collapse on itself when Smalltalk for decades and still even Pharo fails to offer , not only good alternatives but even bad ones , in case of command line.
Which means that currently Pharo offers no real alternative for functionality that is offered via the command line, that means: 1) No library to deal with Git directly , Gitfiletree does this through the command line 2) No command line alternative for interaction with a vast array of software like VLC, ImageMagick, video converters, audio converters , programming languages etc etc 3) Even when we take a look at pharo ecosystem the command like reigns supreme, for example a trip to the pharo website success stories make its clear that by far the most popular platform for commercial pharo apps is the web . Guess what tool the web developers use the most ? Yeap the command line. We make the life of those people that want to use pharo professionally really really hard.
Programming and coding is about covering a vast array of scenarios and maybe in a small community of a few hundred like pharo maybe its ok to ignore the command line but I can assure you in a community like Python that is more than 2 million , it is not.
We already got command line integration for pharo outside the image , lets make the logical next step and offer also command line support from inside the image as well. Let's not justify the stereotype that "Smalltalk is a distant lone island, just because" or that is outdated.
On Fri, Oct 28, 2016 at 3:25 PM Thierry Goubier <thierry.goubier@gmail.com> wrote: 2016-10-28 14:12 GMT+02:00 Guille Polito <guillermopolito@gmail.com>: But the functionality is there, it's just that it is not loaded by default.
Loading it by default implies wedding Pharo's life cycle with OS(Sub)Process' one, and having to maintain the possibility of dependencies to OS(Sub)Process spreading in the entire environment.
Like many of the other projects loaded by default in a Pharo image. What is wrong with OSSubprocess or OSProcess so that they can't be treated the same?
What is wrong in executing a simple Metacello command to load it?
The fact the image doesn't come as a one download / ready to use for an average user?
Thierry
-------- Original Message --------
I have a love and hate relationship with Pharo this one I will put in the hate category
You expect people to use pharo when you do not offer functionality they come to expect from the language they already use and not even offer an altervative, say a library with similar command line functionality (See Scale).
On Fri, Oct 28, 2016 at 2:59 PM Norbert Hartl <norbert@hartl.name> wrote:
Am 28.10.2016 um 13:17 schrieb Dimitris Chloupis <kilon.alios@gmail.com>:
I just noticed that OSProcess misses from Pharo 6 image, it was supposed to be replaced by OSSubProcess but this not in the image either ? What we suppose to use to execute bash from inside pharo ?
It was never in the image. You need to install it in order to use it.
Norbert
Yes, me too. OSProcess/SubProcess should be included in the default image. 2016-10-28 10:29 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
For what it is worth, I am with Dimitris on this: sub shell execution is so fundamental that it should be a standard part of the image. I always thought that that was the goal of the new OSSubProcess.
On 28 Oct 2016, at 15:25, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
For those not experienced with other language let me offer here an explanation why having something like OSProcess is vastly important.
Coding even before the time of Smalltalk has been tied to the command line, even in this day all languages come with the ability of the command line to use them and them to use the command line.
Since increasing the size of our community is paramount to the acceleration of the growth and evolution of pharo , it is also paramount to smooth out the learning curve of Smalltalk. In order to do that we must offer a familiar environment to these coders , especially in the case where Pharo offers no real alternative.
Arguing that just because Smalltalk offers a different way of doing things ok to ignore what others are been doing, is an excuse destined to collapse on itself when Smalltalk for decades and still even Pharo fails to offer , not only good alternatives but even bad ones , in case of command line.
Which means that currently Pharo offers no real alternative for functionality that is offered via the command line, that means: 1) No library to deal with Git directly , Gitfiletree does this through the command line 2) No command line alternative for interaction with a vast array of software like VLC, ImageMagick, video converters, audio converters , programming languages etc etc 3) Even when we take a look at pharo ecosystem the command like reigns supreme, for example a trip to the pharo website success stories make its clear that by far the most popular platform for commercial pharo apps is the web . Guess what tool the web developers use the most ? Yeap the command line. We make the life of those people that want to use pharo professionally really really hard.
Programming and coding is about covering a vast array of scenarios and maybe in a small community of a few hundred like pharo maybe its ok to ignore the command line but I can assure you in a community like Python that is more than 2 million , it is not.
We already got command line integration for pharo outside the image , lets make the logical next step and offer also command line support from inside the image as well. Let's not justify the stereotype that "Smalltalk is a distant lone island, just because" or that is outdated.
On Fri, Oct 28, 2016 at 3:25 PM Thierry Goubier < thierry.goubier@gmail.com> wrote: 2016-10-28 14:12 GMT+02:00 Guille Polito <guillermopolito@gmail.com>: But the functionality is there, it's just that it is not loaded by default.
Loading it by default implies wedding Pharo's life cycle with OS(Sub)Process' one, and having to maintain the possibility of dependencies to OS(Sub)Process spreading in the entire environment.
Like many of the other projects loaded by default in a Pharo image. What is wrong with OSSubprocess or OSProcess so that they can't be treated the same?
What is wrong in executing a simple Metacello command to load it?
The fact the image doesn't come as a one download / ready to use for an average user?
Thierry
-------- Original Message --------
I have a love and hate relationship with Pharo this one I will put in the hate category
You expect people to use pharo when you do not offer functionality they come to expect from the language they already use and not even offer an altervative, say a library with similar command line functionality (See Scale).
On Fri, Oct 28, 2016 at 2:59 PM Norbert Hartl <norbert@hartl.name> wrote:
Am 28.10.2016 um 13:17 schrieb Dimitris Chloupis < kilon.alios@gmail.com>:
I just noticed that OSProcess misses from Pharo 6 image, it was supposed to be replaced by OSSubProcess but this not in the image either ? What we suppose to use to execute bash from inside pharo ?
It was never in the image. You need to install it in order to use it.
Norbert
This is also part of the vision document. Now first SubOSProcess should work on windows. Then Guillermo is RIGHT. We will continue to work on - creating a pharo minimal image - producing configurations - creating one image with default loaded configurations. You see the two objectives are not antagonists. Now you should all stop to think about Pharo a being one image. Pharo should be - a minimal core - a nicely tested distribution - potentially one validated configuration we all like. But it cannot be a monolithic system where people create dependency hell without even noticing it. Stef Le 28/10/16 à 15:29, Sven Van Caekenberghe a écrit :
For what it is worth, I am with Dimitris on this: sub shell execution is so fundamental that it should be a standard part of the image. I always thought that that was the goal of the new OSSubProcess.
On 28 Oct 2016, at 15:25, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
For those not experienced with other language let me offer here an explanation why having something like OSProcess is vastly important.
Coding even before the time of Smalltalk has been tied to the command line, even in this day all languages come with the ability of the command line to use them and them to use the command line.
Since increasing the size of our community is paramount to the acceleration of the growth and evolution of pharo , it is also paramount to smooth out the learning curve of Smalltalk. In order to do that we must offer a familiar environment to these coders , especially in the case where Pharo offers no real alternative.
Arguing that just because Smalltalk offers a different way of doing things ok to ignore what others are been doing, is an excuse destined to collapse on itself when Smalltalk for decades and still even Pharo fails to offer , not only good alternatives but even bad ones , in case of command line.
Which means that currently Pharo offers no real alternative for functionality that is offered via the command line, that means: 1) No library to deal with Git directly , Gitfiletree does this through the command line 2) No command line alternative for interaction with a vast array of software like VLC, ImageMagick, video converters, audio converters , programming languages etc etc 3) Even when we take a look at pharo ecosystem the command like reigns supreme, for example a trip to the pharo website success stories make its clear that by far the most popular platform for commercial pharo apps is the web . Guess what tool the web developers use the most ? Yeap the command line. We make the life of those people that want to use pharo professionally really really hard.
Programming and coding is about covering a vast array of scenarios and maybe in a small community of a few hundred like pharo maybe its ok to ignore the command line but I can assure you in a community like Python that is more than 2 million , it is not.
We already got command line integration for pharo outside the image , lets make the logical next step and offer also command line support from inside the image as well. Let's not justify the stereotype that "Smalltalk is a distant lone island, just because" or that is outdated.
On Fri, Oct 28, 2016 at 3:25 PM Thierry Goubier <thierry.goubier@gmail.com> wrote: 2016-10-28 14:12 GMT+02:00 Guille Polito <guillermopolito@gmail.com>: But the functionality is there, it's just that it is not loaded by default.
Loading it by default implies wedding Pharo's life cycle with OS(Sub)Process' one, and having to maintain the possibility of dependencies to OS(Sub)Process spreading in the entire environment.
Like many of the other projects loaded by default in a Pharo image. What is wrong with OSSubprocess or OSProcess so that they can't be treated the same?
What is wrong in executing a simple Metacello command to load it?
The fact the image doesn't come as a one download / ready to use for an average user?
Thierry
-------- Original Message --------
I have a love and hate relationship with Pharo this one I will put in the hate category
You expect people to use pharo when you do not offer functionality they come to expect from the language they already use and not even offer an altervative, say a library with similar command line functionality (See Scale).
On Fri, Oct 28, 2016 at 2:59 PM Norbert Hartl <norbert@hartl.name> wrote:
Am 28.10.2016 um 13:17 schrieb Dimitris Chloupis <kilon.alios@gmail.com>:
I just noticed that OSProcess misses from Pharo 6 image, it was supposed to be replaced by OSSubProcess but this not in the image either ? What we suppose to use to execute bash from inside pharo ? It was never in the image. You need to install it in order to use it.
Norbert
+1 One step at a time. When we are close to this we can extensively argue what should be the distribution that ships. Complaining is always easy. If we make the image containing a lot of stuff and maintaining that will postpone releases it will be different complaints Norbert
Am 28.10.2016 um 18:11 schrieb stepharo <stepharo@free.fr>:
This is also part of the vision document. Now first SubOSProcess should work on windows.
Then Guillermo is RIGHT.
We will continue to work on
- creating a pharo minimal image
- producing configurations
- creating one image with default loaded configurations.
You see the two objectives are not antagonists.
Now you should all stop to think about Pharo a being one image. Pharo should be
- a minimal core
- a nicely tested distribution
- potentially one validated configuration we all like.
But it cannot be a monolithic system where people create dependency hell without even noticing it.
Stef
Le 28/10/16 à 15:29, Sven Van Caekenberghe a écrit : For what it is worth, I am with Dimitris on this: sub shell execution is so fundamental that it should be a standard part of the image. I always thought that that was the goal of the new OSSubProcess.
On 28 Oct 2016, at 15:25, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
For those not experienced with other language let me offer here an explanation why having something like OSProcess is vastly important.
Coding even before the time of Smalltalk has been tied to the command line, even in this day all languages come with the ability of the command line to use them and them to use the command line.
Since increasing the size of our community is paramount to the acceleration of the growth and evolution of pharo , it is also paramount to smooth out the learning curve of Smalltalk. In order to do that we must offer a familiar environment to these coders , especially in the case where Pharo offers no real alternative.
Arguing that just because Smalltalk offers a different way of doing things ok to ignore what others are been doing, is an excuse destined to collapse on itself when Smalltalk for decades and still even Pharo fails to offer , not only good alternatives but even bad ones , in case of command line.
Which means that currently Pharo offers no real alternative for functionality that is offered via the command line, that means: 1) No library to deal with Git directly , Gitfiletree does this through the command line 2) No command line alternative for interaction with a vast array of software like VLC, ImageMagick, video converters, audio converters , programming languages etc etc 3) Even when we take a look at pharo ecosystem the command like reigns supreme, for example a trip to the pharo website success stories make its clear that by far the most popular platform for commercial pharo apps is the web . Guess what tool the web developers use the most ? Yeap the command line. We make the life of those people that want to use pharo professionally really really hard.
Programming and coding is about covering a vast array of scenarios and maybe in a small community of a few hundred like pharo maybe its ok to ignore the command line but I can assure you in a community like Python that is more than 2 million , it is not.
We already got command line integration for pharo outside the image , lets make the logical next step and offer also command line support from inside the image as well. Let's not justify the stereotype that "Smalltalk is a distant lone island, just because" or that is outdated.
On Fri, Oct 28, 2016 at 3:25 PM Thierry Goubier <thierry.goubier@gmail.com> wrote: 2016-10-28 14:12 GMT+02:00 Guille Polito <guillermopolito@gmail.com>: But the functionality is there, it's just that it is not loaded by default.
Loading it by default implies wedding Pharo's life cycle with OS(Sub)Process' one, and having to maintain the possibility of dependencies to OS(Sub)Process spreading in the entire environment.
Like many of the other projects loaded by default in a Pharo image. What is wrong with OSSubprocess or OSProcess so that they can't be treated the same?
What is wrong in executing a simple Metacello command to load it?
The fact the image doesn't come as a one download / ready to use for an average user?
Thierry
-------- Original Message --------
I have a love and hate relationship with Pharo this one I will put in the hate category
You expect people to use pharo when you do not offer functionality they come to expect from the language they already use and not even offer an altervative, say a library with similar command line functionality (See Scale).
On Fri, Oct 28, 2016 at 2:59 PM Norbert Hartl <norbert@hartl.name> wrote:
Am 28.10.2016 um 13:17 schrieb Dimitris Chloupis <kilon.alios@gmail.com>:
I just noticed that OSProcess misses from Pharo 6 image, it was supposed to be replaced by OSSubProcess but this not in the image either ? What we suppose to use to execute bash from inside pharo ? It was never in the image. You need to install it in order to use it.
Norbert
If you talking about me, no it does not work like that. Complaining is easy indeed but what is easier for me is just using Python libraries from Pharo , this way I don't wait for you to implements features I need and you don't have to endure my complaining. Win - win situation. Soon I will also be able to use C++ libraries from Pharo and I will be virtually unstoppable. From Pharo I will be able to use any programming language , any library and any application. So no, I have no need to argue, I prefer implementing my own solutions. The days of being an inexperienced Pharo developer are long gone, sure I am still no Pharo expert but I can easily overcome Pharo limitations. Took me 5 years but better late than never .
This 5 years time span looks like accurate in what it takes to become somewhat proficient with Pharo. I am curious to know how long one required to grok it. Because there is a world between the "syntax on a postcard" narrative and the "dig in the bowels of the beast" narrative. Anyone? Phil On Fri, Oct 28, 2016 at 11:07 PM, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
If you talking about me, no it does not work like that.
Complaining is easy indeed but what is easier for me is just using Python libraries from Pharo , this way I don't wait for you to implements features I need and you don't have to endure my complaining. Win - win situation.
Soon I will also be able to use C++ libraries from Pharo and I will be virtually unstoppable. From Pharo I will be able to use any programming language , any library and any application.
So no, I have no need to argue, I prefer implementing my own solutions.
The days of being an inexperienced Pharo developer are long gone, sure I am still no Pharo expert but I can easily overcome Pharo limitations. Took me 5 years but better late than never .
Depends how many hours per week you spend and how deep you want to go in it. I spent around 3 hours per week , thats 150 hours per year , 750 in 5 years. For someone working 40 hours a week on pharo it would have taken him only 5 months to reach my level. Also in my case there were not that many libraries to help me out for the things I like to do , 3d graphics, custom GUIs and sound music. It was basically Morphic, Athens and Pharo Sound. Hence why I need to rely on external libraries. Web developing on the other hand would have required to learn Seaside and many other libraries that would have risen the learning curve quite substantially. On Sat, Oct 29, 2016 at 9:44 AM phil@highoctane.be <phil@highoctane.be> wrote:
This 5 years time span looks like accurate in what it takes to become somewhat proficient with Pharo.
I am curious to know how long one required to grok it. Because there is a world between the "syntax on a postcard" narrative and the "dig in the bowels of the beast" narrative.
Anyone?
Phil
On Fri, Oct 28, 2016 at 11:07 PM, Dimitris Chloupis <kilon.alios@gmail.com
wrote:
If you talking about me, no it does not work like that.
Complaining is easy indeed but what is easier for me is just using Python libraries from Pharo , this way I don't wait for you to implements features I need and you don't have to endure my complaining. Win - win situation.
Soon I will also be able to use C++ libraries from Pharo and I will be virtually unstoppable. From Pharo I will be able to use any programming language , any library and any application.
So no, I have no need to argue, I prefer implementing my own solutions.
The days of being an inexperienced Pharo developer are long gone, sure I am still no Pharo expert but I can easily overcome Pharo limitations. Took me 5 years but better late than never .
From my perspective it depends on your previous programming experiences. After programming C++ for a few years, I immediately saw the huge potential of Smalltalk (Squeak at this time) with image, live programming, etc even if at that same time I did not understand at all any details. Free software mates not dedicated to programming but to mere scripting did not see that benefit, but more a nuisance in this image based system. But then after you have the main stream people prefer to follow.
Hilaire Le 29/10/2016 à 08:43, phil@highoctane.be a écrit :
This 5 years time span looks like accurate in what it takes to become somewhat proficient with Pharo.
I am curious to know how long one required to grok it. Because there is a world between the "syntax on a postcard" narrative and the "dig in the bowels of the beast" narrative.
Anyone?
-- Dr. Geo http://drgeo.eu
On Fri, Oct 28, 2016 at 01:25:25PM +0000, Dimitris Chloupis wrote:
For those not experienced with other language
I'm probably not contributing anything of value to this conversation... :-) IMHO, most people who settle on Smalltalk aren't "not experienced with other language". Pierce
"I'm probably not contributing anything of value to this conversation... :-) IMHO, most people who settle on Smalltalk aren't "not experienced with other language". Pierce" No idea where you have drawn that conclusion maybe it was true in the past or outside Pharo but Pharo is mostly used for web apps and that means you have to know both HTML5/CSS and Javascript and SQL for databases. Sticking to a single language is rarely a good idea mainly because even though languages are meant to be used for everything they have to a degree specific areas that they excel which makes them ideal choices for those situations. "As Guile explained it, it is a matter of responsibility to include a package in the Pharo image. The more packages in the base Pharo image the more complicated is the release process for the Pharo team, and more stress, etc." I think that's an overgeneralisation and a really lousy excuses. If conflicts occur between versions then its not the library that needs to be blamed but Pharo itself. Backward compatibility is a necessary evil in the end. When Pharo started indeed it went through a period of flux with many deep redesigns etc of course those things are a headache for those that maintain packages inside or outside the Pharo official distribution. Those braking enhancements were necessary to establish a healthy and stable code base and very much welcomed. However the honeymoon period has ended and Pharo cannot afford to brake compatibility anymore since more and more people are using it and none of us will be happy if we have to rewrite our software from scratch to accommodate new redesigns of Pharo code base in each version. An example is Python, Python 3 did brake backward compatibility with Python 2, because its creator Guido felt it was time for a deep redesign and most people agreed with him. But even though users approved the new improvements the cost for Python was massive . Python 3 was released in 2008 , 8 years later and still Python 2 is by far the most popular choice for python coders. It even been a reason not to use Python at all because of the brake between version 2 and 3. https://blogs.msdn.microsoft.com/pythonengineering/2016/03/08/python-3-is-wi... So after 8 years , at last , Python 3 has catch up with Python 2 , mainly because all new projects chose python 3 and all old ones stick with Python 2. 8 years is how many years Pharo has been around. This has led the creator of Python to even claim that he regrets making Python 3 non backward compatible with Python and please note Python 3 comes with a special tool that can convert Python 2 code to Python 3 automagically. Still because the tool was far from perfect people chose to stick with Python 2. So for a stable environment that retains backward compatibility the cost of maintenance of individual packages should be zero to close to zero. Saying that my experience with my own code base shown me that in real life scenarios the maintenance is very little since after version 4 , Pharo has not done any radical change. In any case if Pharo is a pain to maintain , even only under the condition that a ton of packages added to it, we must wonder as a community whether this is the direction we want to go. Pharo will inevitably grow in popularity which will make its usage in big software more likely if maintenance cost is high it defeats the purpose of using Smalltalk in the first place.
On 28 October 2016 at 14:12, Guille Polito <guillermopolito@gmail.com> wrote:
What is wrong in executing a simple Metacello command to load it?
What's wrong is, it's not convenient / easy / publicized enough. There isn't a nice user story about dependency management and package loading, even though technically everything is (nearly) there. That's why the bootstrap, cargo, etc are important.
participants (12)
-
Dale Henrichs -
Damien Pollet -
Dimitris Chloupis -
Guille Polito -
Hernán Morales Durand -
Hilaire -
Norbert Hartl -
phil＠highoctane.be -
Pierce Ng -
stepharo -
Sven Van Caekenberghe -
Thierry Goubier