[Pharo-users] OSProcess missing from Pharo 6 image

[Dimitris Chloupis]

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 ?

Re: [Pharo-users] OSProcess missing from Pharo 6 image

[Norbert Hartl]

> Am 28.10.2016 um 13:17 schrieb Dimitris Chloupis :
> 
> 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

Re: [Pharo-users] OSProcess missing from Pharo 6 image

[Dimitris Chloupis]

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  wrote:

>
> > Am 28.10.2016 um 13:17 schrieb Dimitris Chloupis  >:
> >
> > 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
>
>
>

Re: [Pharo-users] OSProcess missing from Pharo 6 image

[Guille Polito]

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 > wrote:



> Am 28.10.2016 um 13:17 schrieb Dimitris Chloupis
mailto:kilon.al...@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

Re: [Pharo-users] OSProcess missing from Pharo 6 image

[Thierry Goubier]

2016-10-28 14:12 GMT+02:00 Guille Polito :

> 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  wrote:
>
>>
>> > Am 28.10.2016 um 13:17 schrieb Dimitris Chloupis > >:
>> >
>> > 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
>>
>>
>>
>

Re: [Pharo-users] OSProcess missing from Pharo 6 image

[Guille Polito]

 Original Message 



2016-10-28 14:12 GMT+02:00 Guille Polito >:







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-project-storage-alternatives

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
mailto:norb...@hartl.name>>
wrote:




> Am 28.10.2016 um 13:17 schrieb Dimitris Chloupis
mailto:kilon.al...@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

Re: [Pharo-users] OSProcess missing from Pharo 6 image

[Dimitris Chloupis]

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 
wrote:

> 2016-10-28 14:12 GMT+02:00 Guille Polito :
>
> 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  wrote:
>
>
> > Am 28.10.2016 um 13:17 schrieb Dimitris Chloupis  >:
> >
> > 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
>
>
>
>

Re: [Pharo-users] OSProcess missing from Pharo 6 image

[Sven Van Caekenberghe]

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  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  
> wrote:
> 2016-10-28 14:12 GMT+02:00 Guille Polito :
> 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  wrote:
>> 
>> > Am 28.10.2016 um 13:17 schrieb Dimitris Chloupis :
>> >
>> > 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
>> 
>> 
> 

Re: [Pharo-users] OSProcess missing from Pharo 6 image

[Hernán Morales Durand]

Yes, me too. OSProcess/SubProcess should be included in the default image.



2016-10-28 10:29 GMT-03:00 Sven Van Caekenberghe :

> 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 
> 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.goub...@gmail.com> wrote:
> > 2016-10-28 14:12 GMT+02:00 Guille Polito :
> > 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 
> wrote:
> >>
> >> > Am 28.10.2016 um 13:17 schrieb Dimitris Chloupis <
> kilon.al...@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
> >>
> >>
> >
>
>
>

Re: [Pharo-users] OSProcess missing from Pharo 6 image

[stepharo]

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  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  
wrote:
2016-10-28 14:12 GMT+02:00 Guille Polito :
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  wrote:


Am 28.10.2016 um 13:17 schrieb Dimitris Chloupis :

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

Re: [Pharo-users] OSProcess missing from Pharo 6 image

[Norbert Hartl]

+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 :
> 
> 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  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  
>>> wrote:
>>> 2016-10-28 14:12 GMT+02:00 Guille Polito :
>>> 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, Oc

Re: [Pharo-users] OSProcess missing from Pharo 6 image

[Dimitris Chloupis]

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 .

Re: [Pharo-users] OSProcess missing from Pharo 6 image

[Damien Pollet]

On 28 October 2016 at 14:12, Guille Polito 
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.

Re: [Pharo-users] OSProcess missing from Pharo 6 image

[p...@highoctane.be]

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 
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 .
>

Re: [Pharo-users] OSProcess missing from Pharo 6 image

[Dimitris Chloupis]

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 p...@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  > 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 .
>
>
>

Re: [Pharo-users] OSProcess missing from Pharo 6 image

[Hilaire]

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

Re: [Pharo-users] OSProcess missing from Pharo 6 image

[Hilaire]

>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, p...@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

Re: [Pharo-users] OSProcess missing from Pharo 6 image

[Pierce Ng]

On Fri, Oct 28, 2016 at 01:25:25PM +, 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

Re: [Pharo-users] OSProcess missing from Pharo 6 image

[Dimitris Chloupis]

"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-winning/

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.