Image Distributions [was:Re: Mocks are missing in Pharo (from thread OSProcess is missing)}
Having them in image can indeed be useful. I am testing against REST backends, and well, this is a destructive test to say the least. Not easy to replay as much as I want. I hope that with the Bootstrap we'll be able to have a set of "Batteries Included" distributions. Kind of like we have Moose today, which I like very much as I do not have to load parts from all over the place. On http://tcl.tk there are also a number of such distributions: * the "Batteries Included" ActiveTcl (http://www.activestate.com/activetcl) with its various support levels [which would be good to emulate for the Pharo Pro business proposition] * TclKit / StarKits concept (http://wiki.tcl.tk/52). TclKit is a BaseKit. See http://wiki.tcl.tk/15985 for a table of kits and their supported features. * Build your own from sources. TclKit allows one to build special kit, using a command line tool, similar to what we discuss for loading packages easily. http://wiki.tcl.tk/10558 We do have an image and the TclKit has a VFS (Virtual File System) bundling everything in a single file. So, basically, one runs things with tclkit hello.kit. Quite reminiscent of pharo Pharo.image I'd say. Question 1: Which top 5 packages/configurations would you find useful to have available in a distribution? 1- 2- 3- 4- 5- Question 2: What do you consider to be the top 3 use cases of a Pharo Distribution for your own use? 1- 2- 3- Best, Phil ` On Fri, Oct 28, 2016 at 8:36 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-10-28 18:58 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com>:
No, please, kernel test should have the fewer dependencies as possible!
I would say this dependency is needed.
And again i'll hold my position: whoever wants to load it can do it. There is no need to put it there by default.
Do you know how much easier it would be to design and test FileSystem with mocks. Code and tests will be much better and simpler from the beginning. And I could said it about any package which provide abstractions.
Now no project which is part of Pharo can use mocks for tests. So it is not question of loading it for own project. Pharo contributors can't use mocks.
And there is another story. Imaging Ruby guys join Pharo development (not real story :)). Many years In Ruby people use mocks and "human should" assertions. Most TDD evolution was from Ruby. I imaging their impression about Pharo "the best for TDD".
And generally I would said we have quite bad tests in system. They are slow, they corrupt image. Mocks will help to improve this situation.
Le 29/10/16 à 08:39, phil@highoctane.be a écrit :
> Having them in image can indeed be useful.
>
> I am testing against REST backends, and well, this is a destructive
> test to say the least. Not easy to replay as much as I want.
>
> I hope that with the Bootstrap we'll be able to have a set of
> "Batteries Included" distributions. Kind of like we have Moose today,
> which I like very much as I do not have to load parts from all over
> the place.
Yes we will now people will be able to also define their own image.
At the end
bootstrap
+ configura
+ jenkins
= an image
>
> On http://tcl.tk there are also a number of such distributions:
>
> * the "Batteries Included" ActiveTcl
> (http://www.activestate.com/activetcl) with its various support levels
> [which would be good to emulate for the Pharo Pro business proposition]
>
> * TclKit / StarKits concept (http://wiki.tcl.tk/52). TclKit is a
> BaseKit. See http://wiki.tcl.tk/15985 for a table of kits and their
> supported features.
>
> * Build your own from sources.
>
> TclKit allows one to build special kit, using a command line tool,
> similar to what we discuss for loading packages easily.
> http://wiki.tcl.tk/10558
>
> We do have an image and the TclKit has a VFS (Virtual File System)
> bundling everything in a single file.
>
> So, basically, one runs things with tclkit hello.kit. Quite
> reminiscent of pharo Pharo.image I'd say.
>
> Question 1:
>
> Which top 5 packages/configurations would you find useful to have
> available in a distribution?
>
> 1-
> 2-
> 3-
> 4-
> 5-
>
> Question 2:
>
> What do you consider to be the top 3 use cases of a Pharo Distribution
> for your own use?
>
> 1-
> 2-
> 3-
>
> Best,
> Phil
>
>
>
> `
>
>
>
>
>
>
>
> On Fri, Oct 28, 2016 at 8:36 PM, Denis Kudriashov
> <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>> wrote:
>
>
> 2016-10-28 18:58 GMT+02:00 Guillermo Polito
> <guillermopolito@gmail.com <mailto:guillermopolito@gmail.com>>:
>
> No, please, kernel test should have the fewer dependencies as
> possible!
>
> I would say this dependency is needed.
>
> And again i'll hold my position: whoever wants to load it can
> do it. There is no need to put it there by default.
>
> Do you know how much easier it would be to design and test
> FileSystem with mocks. Code and tests will be much better and
> simpler from the beginning.
> And I could said it about any package which provide abstractions.
>
> Now no project which is part of Pharo can use mocks for tests. So
> it is not question of loading it for own project. Pharo
> contributors can't use mocks.
>
> And there is another story. Imaging Ruby guys join Pharo
> development (not real story :)). Many years In Ruby people use
> mocks and "human should" assertions. Most TDD evolution was from
> Ruby. I imaging their impression about Pharo "the best for TDD".
>
> And generally I would said we have quite bad tests in system. They
> are slow, they corrupt image. Mocks will help to improve this
> situation.
>
>
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.
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 <kilon.alios@gmail.com> 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.
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 phil@highoctane.be <phil@highoctane.be> 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 <kilon.alios@gmail.com> 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.
On 1 Nov 2016, at 21:21, Dimitris Chloupis <kilon.alios@gmail.com> 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.
Why not go the Spec way ? window := TextModel new text: 'Smalltalk version.'; title: 'My Workspace'; openWithSpec. window model text: 'Smalltalk garbageCollect.' I do agree that it is not obvious in GT. Sven
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/1180... 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 <kilon.alios@gmail.com> 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 phil@highoctane.be <phil@highoctane.be> 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 <kilon.alios@gmail.com> 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.
Impressive , Cuis has 13 times less classes than Pharo. Maybe I should give it a closer look afterall. Pity that does not translate well in hard disk space. Pharo 6 is 100mbs Cuis is just 70mbs. The VM alone is 50 mbs. On Wed, Nov 2, 2016 at 1:38 AM phil@highoctane.be <phil@highoctane.be> wrote:
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/1180...
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 <kilon.alios@gmail.com> 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 phil@highoctane.be <phil@highoctane.be> 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 <kilon.alios@gmail.com> 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.
On 2 Nov 2016, at 07:37, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Impressive , Cuis has 13 times less classes than Pharo. Maybe I should give it a closer look afterall.
Cuis is quite nice, impressive even. Ideal for learning and then some. But don't be fooled: it lacks lots and lots of things that you take for granted in Pharo.
Pity that does not translate well in hard disk space. Pharo 6 is 100mbs Cuis is just 70mbs. The VM alone is 50 mbs.
On Wed, Nov 2, 2016 at 1:38 AM phil@highoctane.be <phil@highoctane.be> wrote: 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/1180...
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 <kilon.alios@gmail.com> 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 phil@highoctane.be <phil@highoctane.be> 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 <kilon.alios@gmail.com> 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.
participants (4)
-
Dimitris Chloupis -
phil＠highoctane.be -
stepharo -
Sven Van Caekenberghe