Hello, I have a question regarding the way the Pharo image is technically and socially built. One of the Pharo aim is to be a small and clean environment one can use to develop and build dedicated application. Dedicated tools as Metacello and Gofer are developed for this purpose. Many architecture and dev tools are developed and replacing the old ones: spec, nautillus, etc. Now from the my peripheral point of view, it looks like these tools are carved in the image, breaking the idea of a small and clean core image; making difficult to build dedicated application image. My question: why those tools were not developed to be loadable in a Pharo? Thanks Hilaire -- Dr. Geo http://drgeo.eu
On 05 Apr 2014, at 13:08, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Hello,
I have a question regarding the way the Pharo image is technically and socially built. One of the Pharo aim is to be a small and clean environment one can use to develop and build dedicated application. Dedicated tools as Metacello and Gofer are developed for this purpose. Many architecture and dev tools are developed and replacing the old ones: spec, nautillus, etc. Now from the my peripheral point of view, it looks like these tools are carved in the image, breaking the idea of a small and clean core image; making difficult to build dedicated application image. My question: why those tools were not developed to be loadable in a Pharo?
Time. The secret is that in the end only those things are done that are done. Marcus
à temps, suspends ton vol! I will add this quote: It is costless to get things done right than undone. Hilaire Le 05/04/2014 13:16, Marcus Denker a écrit :
Time. The secret is that in the end only those things are done that are done.
-- Dr. Geo http://drgeo.eu
On 05 Apr 2014, at 13:50, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
à temps, suspends ton vol!
I will add this quote: It is costless to get things done right than undone.
Yes, we need to look into a more modular build in Pharo4⦠to not just load updates on the server but instead build from a small core (and possibly even from a bootstrap). Marcus
Still, I do not get why the newer packages are not loadable with configurations instead of been carved in the image. Why can't packages developers provide such configurations? Why don't we have an image without those packages? Then public images built with. Is it not what Jenkins is supposed to do? I am afraid the situation looks like Etoys carved in Squeak. Hilaire Le 05/04/2014 18:32, Marcus Denker a écrit :
Yes, we need to look into a more modular build in Pharo4⦠to not just load updates on the server but instead build from a small core (and possibly even from a bootstrap).
-- Dr. Geo http://drgeo.eu
On 05 Apr 2014, at 21:48, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Still, I do not get why the newer packages are not loadable with configurations instead of been carved in the image. Why can't packages developers provide such configurations?
sure give us a list? - RB - Nautilus - spec - Keychain - key mapping - smart suggestions - â¦.. - and many more do you want an image by default without any tools? I do but we need time. So what we want to do is - to have a core mage that the one people use is based on the core + the loading of the components and now we are arriving to this situation because before we did not have command-line jenkins - for Pharo 4.0 we will get there. Now since it is not easy to unload tools, and Iâm busy with other aspects of work we could not do it the way you describe it but this is what we want. => why did we fail ok you have a core and some nice configurations then a guy report a bug and a fixe from this core and configuration we should create a new core AND correctly loading configurations and this is not fully automated yet. have a look at Pharo/SystemConfigurations You take unReloader you run the scripts and you load the configurations. when they fail you fix them and restart. I have been doing that a lot and we will continue but this is booooooring. So we should build tools and so far I do not see many people **Helping** beside pavel on this task so you are right we are concious about it but no resources.
Why don't we have an image without those packages? Then public images built with. Is it not what Jenkins is supposed to do? I am afraid the situation looks like Etoys carved in Squeak.
We are fighting against it.
Hilaire
Le 05/04/2014 18:32, Marcus Denker a écrit :
Yes, we need to look into a more modular build in Pharo4⦠to not just load updates on the server but instead build from a small core (and possibly even from a bootstrap).
-- Dr. Geo http://drgeo.eu
For me this should the responsibilities of the component developers. It is more efficient as s/he knows the component and what may break at installation time. Le 06/04/2014 10:44, Pharo4Stef a écrit :
You take unReloader you run the scripts and you load the configurations. when they fail you fix them and restart. I have been doing that a lot and we will continue but this is booooooring.
-- Dr. Geo http://drgeo.eu
On 06 Apr 2014, at 11:43, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
For me this should the responsibilities of the component developers. It is more efficient as s/he knows the component and what may break at installation time.
Except that it requires a better infrastructure and who is in charge about - RB - RBenvironment - Smart Suggestions - â¦. Stef
Le 06/04/2014 10:44, Pharo4Stef a écrit :
You take unReloader you run the scripts and you load the configurations. when they fail you fix them and restart. I have been doing that a lot and we will continue but this is booooooring.
-- Dr. Geo http://drgeo.eu
Le 06/04/2014 10:44, Pharo4Stef a écrit :
On 05 Apr 2014, at 21:48, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Still, I do not get why the newer packages are not loadable with configurations instead of been carved in the image. Why can't packages developers provide such configurations?
sure give us a list? - RB - Nautilus - spec - Keychain - key mapping - smart suggestions - â¦.. - and many more
I can give you all the Monticello package list, but is it relevant? I hardly know 10% of them. Some should probably belong to core other not.
do you want an image by default without any tools? I do but we need time.
I don't understand: with times new important tools were developed, like Nautilus and other I don't know I guess. Was it decided these tools should be carved in the image or be loaded? Was not removing old tools and using new loadable ones the way to build step by step this core image? I confess I very likely don't see the subtle details.
so you are right we are concious about it but no resources.
Is it really a resource problem? With my scarce resources and knowledge I can build automatically drgeo with a bash script and a .st file since 1.x for several platform. I agree it is more complex with Pharo but... Hilaire -- Dr. Geo http://drgeo.eu
I can give you all the Monticello package list, but is it relevant? I hardly know 10% of them. Some should probably belong to core other not.
do you want an image by default without any tools? I do but we need time.
I don't understand: with times new important tools were developed, like Nautilus and other I don't know I guess. Was it decided these tools should be carved in the image or be loaded?
No they should be loaded. Now we should not deliver an image that is not the one we use so we will put in place a building process from the smaller images, loading the tools we need. Now we rewrote slowly the tools and we are removing the ones that have been fully rewritten. But there is no magic: time and resources. So give me 1 engineer full time to have the process I dream and it will be there. Now igor is focusing on texteditor (beside fonts and NB) and esteban the rest :)
Was not removing old tools and using new loadable ones the way to build step by step this core image?
This is what we did: new finder, new message, new changesorter, new browserâ¦.
I confess I very likely don't see the subtle details.
so you are right we are concious about it but no resources.
Is it really a resource problem?
Yes.
With my scarce resources and knowledge I can build automatically drgeo with a bash script and a .st file since 1.x for several platform. I agree it is more complex with Pharo butâ¦
It is. And Drgeo is just managed by you and not by the community/independant projects. I asked already one year ago an engineer to build this but he was refused. We resubmitted the project and we are waiting.
Hilaire
-- Dr. Geo http://drgeo.eu
participants (3)
-
Hilaire Fernandes -
Marcus Denker -
Pharo4Stef