Image Distributions [was:Re: Mocks are missing in Pharo (from thread OSProcess is missing)}

Bootstrapping is needed to escape the big ball of mud that the current image is.

It is already much much much better than Pharo 1x.

Having a smaller core can iron out a lot of issues and make it super stable.

And decouple the various parts. That is no small feat indeed.

And frankly it is super hard to understand how the whole thing actually works internally with all the stuff we have inside.

I see bootstrapping as being able to extract the nuclear core from the current vehicle and be able to inject it into new forms.

Phil

On Tuesday, 1 November 2016, Dimitris Chloupis <[hidden email]> wrote:

We already have a ton of ready made image in CI that pharolauncher has access to and it is very easy to build your own. I build my own images regularly with a makefile and startup script. You can do a lot of neat tricks with those two combinations. 

Because my image grows quite large lately I was thinking maybe make an image builder with pharo. Nothing fancy just a basic GUI that will ask me questions what I want to build and I can tick which image I want inside and let it run in the background. Essentially replacing both my makefile and my startup script. So far though I cannot say I really need it

Why a test would corrupt the image, that makes no sense. I am using Pharo 5 years now and I did not have a single corrupted image, ever. 

Also about the claim that Pharo is "the best TDD" first time I heard that. What makes a system best for TDD ? its not as if TDD is anything sophisticated or even something new. The only difference is that lately it went from being a library to being a religion. 

You may compare Ruby all you want with Pharo but then that gives me motivation to compare Ruby with Python . Ruby basically has Ruby on Rails and then.... nothing.  Great language , lousy library system. 

Bootstrapping is more than welcomed but I am sorry to say that , its not that important. 

You wanna proof , take a look at Python, huge library and coders love it. Actually the huge size of its library was always its best selling point. Python is pretty much everywhere nowdays and there is nothing stopping it. Not that is a surprise Python always prioritised minimalism and ease of use over amount of features , something desperately needed in todays incredible complex software demands. 

Setting the Playground contents, yeah, I see what you mean. The old Workspace worked better there.

I disagree with your view on the modularity.

And Cuis is nice indeed (and the UI is fast) - https://github.com/Cuis-Smalltalk-Learning/Learning-Cuis shows the number of classes. Definitely less than Pharo. 

But it is not boostrap anything, sorry. It is the same code that has dependencies all over. Ok it is kind of a minimal image but not something one can call bootstrap.

Check the original intent: http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-January/118051.html

So, starting from an empty object memory. That is important to have. So that we can rebuild in other ways.

Phil

On Tue, Nov 1, 2016 at 9:21 PM, Dimitris Chloupis <[hidden email]> wrote:

I was trying just yesterday to do something super simple, change the contents of Playground via code. I used the inspector to navigate , I ended up running around and accomplish zero. 

Bootstraping will never make Pharo easy. Bootstraping is for making it smaller and more modular.  Completely different thing. 

Pharo is super hard to hack because many of its APIs even for new tools like GTPlayground are huge pile of mess. The spaggetification of the Pharo image is beyond repair and needs a complete rewrite. But that is not going to happen any time this decade or the next. So for now we will have to compromise with the idea that Pharo code is hard and it will keep getting harder the more features are added even if the packages are reduced.  

On the other hand I am ok with hard code, as long as it gets the job done. 

Plus there was always a bootstraped "Pharo", Cuis, Wanna see how minimal and clean code looks like , take a deep look in Cuis, its a beauty. But Cuis is nowhere near as popular as Pharo. People prefer features over simplicity and , unfortunately , you cannot have both. I am willing to bet that we will still choose big Pharos image even when bootstrap becomes a reality. Its as if there is a lot of room to move here, most of the libraries inside Pharo are crucial to the system, others are very useful for user interaction. 

Unless of course we follow the example of Cuis and decided to reduce the features of Pharo, but I suspect that wont have many supporters. 

So yes its nice to have this extra options, no it wont make Pharo code much simpler. 

On Tue, Nov 1, 2016 at 9:39 PM [hidden email] <[hidden email]> wrote:

Bootstrapping is needed to escape the big ball of mud that the current image is.

It is already much much much better than Pharo 1x.

Having a smaller core can iron out a lot of issues and make it super stable.

And decouple the various parts. That is no small feat indeed.

And frankly it is super hard to understand how the whole thing actually works internally with all the stuff we have inside.

I see bootstrapping as being able to extract the nuclear core from the current vehicle and be able to inject it into new forms.

Phil

On Tuesday, 1 November 2016, Dimitris Chloupis <[hidden email]> wrote:

We already have a ton of ready made image in CI that pharolauncher has access to and it is very easy to build your own. I build my own images regularly with a makefile and startup script. You can do a lot of neat tricks with those two combinations. 

Because my image grows quite large lately I was thinking maybe make an image builder with pharo. Nothing fancy just a basic GUI that will ask me questions what I want to build and I can tick which image I want inside and let it run in the background. Essentially replacing both my makefile and my startup script. So far though I cannot say I really need it

Why a test would corrupt the image, that makes no sense. I am using Pharo 5 years now and I did not have a single corrupted image, ever. 

Also about the claim that Pharo is "the best TDD" first time I heard that. What makes a system best for TDD ? its not as if TDD is anything sophisticated or even something new. The only difference is that lately it went from being a library to being a religion. 

You may compare Ruby all you want with Pharo but then that gives me motivation to compare Ruby with Python . Ruby basically has Ruby on Rails and then.... nothing.  Great language , lousy library system. 

Bootstrapping is more than welcomed but I am sorry to say that , its not that important. 

You wanna proof , take a look at Python, huge library and coders love it. Actually the huge size of its library was always its best selling point. Python is pretty much everywhere nowdays and there is nothing stopping it. Not that is a surprise Python always prioritised minimalism and ease of use over amount of features , something desperately needed in todays incredible complex software demands.