+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 <steph...@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.al...@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.goub...@gmail.com> >>> wrote: >>> 2016-10-28 14:12 GMT+02:00 Guille Polito <guillermopol...@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 <norb...@hartl.name> 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 >>>> >>>> >> >> > >
