Pharo dev image rc2 thoughts

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Pharo dev image rc2 thoughts

Miguel Cobá
First that anything, thanks to Mariano for all the effort put in order
to release a 1.0 version of Pharo. And to all the contributors also.

As part of incorporating Metacello to my projects, I have gain a little
more insight in the working of it. For that I have been studying the
existing configurations. I even contributed a pair to the repository.
Tonight I was building a Pharo image using the ConfigurationOfPharo.

The announce said nothing but the inner workings of the dev image
creations changed, although the result is exactly (with a lot of fixes
included) the same that the rc1 image created with Metacello. The
changes are this:

- in rc1, it was only necessary ConfigurationOfPharo to build a complete
Pharo dev image. That is ConfigurationOfPharo included
ImageForDevelopers.

- in rc2, ConfigurationOfPharo isn't enough to build a dev image (I
noticed this tonight because I used ConfigurationOfPharo alone to build
an image but in the end I didn't get autocompetition), it is also
necessary to run a second script to load ImageForDevelopers and install
it. This is all done in the installScript.st script included in the
pharo rc2 dev image.

As I said before, the results are the same, but before all was done in
the ConfigurationOfPharo and now requires two steps.

Now to the point. I understand that the separation of concerns is good,
because ImageForDevelopers is already a separated and tested package
that shouldn't be inside ConfigurationOfPharo.

- Shouldn't be necessary to create a ConfigurationOfImageForDevelopers
and in this configuration reference ConfigurationOfPharo and then the
installScript for the dev image use *only*
ConfigurationOfImageForDevelopers?

- It appears that Dale will announce project preload/postload doIts next
monday. If that happens, shouldn't be better to incorporate the code
from DEVImageCreator as preload/postload do its to the
ConfigurationOfPharo?

It appears to me that DEVImageCreator is a mixture of different things,
both preference tuning (setDefaultPreferences, setFonts) image fixing
(addPreferenceCategories, cleanOpenMenu) and image building stuff
(writeListOfPackages, showWelcomeWorkspaces).

Maybe the image fixing stuff should be a change incorporated to the
PharoCore image, and the preference tuning should be a postload do it
for the ConfigurationOfImageForDevelopers, and the image building stuff
should be in the install script.

This way, if someone wants to build a image for developers (but without
the list of packages, or welcome workspaces) it only has to use
ConfigurationOfImageForDevelopers.

Also, maybe after all this refactoring, the
ConfigurationOfImageForDevelopers isn't necessary because all can be
incorporated to the ConfigurationOfPharo as preload/postload do its.
That is fine.

Also, the image for developers has stuff for squeak. This refactoring
would permit to separate them in preload/postload for each platform, in
a cleaner way.

As I said at beginning, this is only thoughts, and the current result
image is the same as the one produced by the previous configuration, but
maybe, with more time and less pressure, this refactoring and cleaning
could be made.

Of course, I will try to do this and contribute the code as my time
permits, but if someone can do it sooner, the better for all of us.

Thanks again for the hard work
--
Miguel Cobá
http://miguel.leugim.com.mx


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Pharo dev image rc2 thoughts

Stéphane Ducasse

On Jan 24, 2010, at 8:53 AM, Miguel Enrique Cobá Martinez wrote:

> First that anything, thanks to Mariano for all the effort put in order
> to release a 1.0 version of Pharo. And to all the contributors also.

+ 200 :)

>
> As part of incorporating Metacello to my projects, I have gain a little
> more insight in the working of it. For that I have been studying the
> existing configurations. I even contributed a pair to the repository.
> Tonight I was building a Pharo image using the ConfigurationOfPharo.
>
> The announce said nothing but the inner workings of the dev image
> creations changed, although the result is exactly (with a lot of fixes
> included) the same that the rc1 image created with Metacello. The
> changes are this:
>
> - in rc1, it was only necessary ConfigurationOfPharo to build a complete
> Pharo dev image. That is ConfigurationOfPharo included
> ImageForDevelopers.
>
> - in rc2, ConfigurationOfPharo isn't enough to build a dev image (I
> noticed this tonight because I used ConfigurationOfPharo alone to build
> an image but in the end I didn't get autocompetition), it is also
> necessary to run a second script to load ImageForDevelopers and install
> it. This is all done in the installScript.st script included in the
> pharo rc2 dev image.
>
> As I said before, the results are the same, but before all was done in
> the ConfigurationOfPharo and now requires two steps.
>
> Now to the point. I understand that the separation of concerns is good,
> because ImageForDevelopers is already a separated and tested package
> that shouldn't be inside ConfigurationOfPharo.
>
> - Shouldn't be necessary to create a ConfigurationOfImageForDevelopers
> and in this configuration reference ConfigurationOfPharo and then the
> installScript for the dev image use *only*
> ConfigurationOfImageForDevelopers?
>
> - It appears that Dale will announce project preload/postload doIts next
> monday. If that happens, shouldn't be better to incorporate the code
> from DEVImageCreator as preload/postload do its to the
> ConfigurationOfPharo?

probably even if I do not have enough experience with metacello

>
> It appears to me that DEVImageCreator is a mixture of different things,
> both preference tuning (setDefaultPreferences, setFonts) image fixing
> (addPreferenceCategories, cleanOpenMenu) and image building stuff
> (writeListOfPackages, showWelcomeWorkspaces).
>
> Maybe the image fixing stuff should be a change incorporated to the
> PharoCore image, and the preference tuning should be a postload do it
> for the ConfigurationOfImageForDevelopers, and the image building stuff
> should be in the install script.
>
> This way, if someone wants to build a image for developers (but without
> the list of packages, or welcome workspaces) it only has to use
> ConfigurationOfImageForDevelopers.

probably

>
> Also, maybe after all this refactoring, the
> ConfigurationOfImageForDevelopers isn't necessary because all can be
> incorporated to the ConfigurationOfPharo as preload/postload do its.
> That is fine.
>
> Also, the image for developers has stuff for squeak. This refactoring
> would permit to separate them in preload/postload for each platform, in
> a cleaner way.
>
> As I said at beginning, this is only thoughts, and the current result
> image is the same as the one produced by the previous configuration, but
> maybe, with more time and less pressure, this refactoring and cleaning
> could be made.
>
> Of course, I will try to do this and contribute the code as my time
> permits, but if someone can do it sooner, the better for all of us.
>
> Thanks again for the hard work
> --
> Miguel Cobá
> http://miguel.leugim.com.mx
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Pharo dev image rc2 thoughts

Mariano Martinez Peck
In reply to this post by Miguel Cobá


2010/1/24 Miguel Enrique Cobá Martinez <[hidden email]>
First that anything, thanks to Mariano for all the effort put in order
to release a 1.0 version of Pharo. And to all the contributors also.

You are welcome :)
Thanks for taking the time to look at the confs and to write this mail.
 

As part of incorporating Metacello to my projects, I have gain a little
more insight in the working of it. For that I have been studying the
existing configurations. I even contributed a pair to the repository.
Tonight I was building a Pharo image using the ConfigurationOfPharo.


yes, I noticed that :)
 
The announce said nothing but the inner workings of the dev image
creations changed, although the result is exactly (with a lot of fixes
included) the same that the rc1 image created with Metacello. The
changes are this:

- in rc1, it was only necessary ConfigurationOfPharo to build a complete
Pharo dev image. That is ConfigurationOfPharo included
ImageForDevelopers.


yes
 
- in rc2, ConfigurationOfPharo isn't enough to build a dev image (I
noticed this tonight because I used ConfigurationOfPharo alone to build
an image but in the end I didn't get autocompetition), it is also
necessary to run a second script to load ImageForDevelopers and install
it. This is all done in the installScript.st script included in the
pharo rc2 dev image.

As I said before, the results are the same, but before all was done in
the ConfigurationOfPharo and now requires two steps.

exactly
 

Now to the point. I understand that the separation of concerns is good,
because ImageForDevelopers is already a separated and tested package
that shouldn't be inside ConfigurationOfPharo.

I will tell you a bit the background: First, when I took the installScript from Damien, there where some stuff done in the script (like settings the preferences and the fonts) done in the installScript. It didn't have sense for me (of course I asked Damien) and I put that in ImageForDevelopers (and this is cool because it is versiones with monticello). Actually in DEVImageCreator >> install.  I need also to clean that class as it has a lot of old stuff. But not time for the moment.

When I create rc1, ImageForDevelopers was a dependency of ConfigurationOfPharo as you said. There was a problem installing it with the progress bar and Metacello. The image just frezze because of a sempahore and a delay....see issue: http://code.google.com/p/metacello/issues/detail?id=39
But I can even reproduce the problem....So, that quick solution (as I needed to relase the Pharo image) was to put in the installScript.

And after a while I discovered that I even like more that approach. Someone may want just the packages of a dev image, but not to set preferences, fonts, cleanups, etc. And I don't have the Metacello bug.
The problem I found also putting it as a dependency is that it has to be the LATEST (I think that you cannot even said that XX package has to be the last one to be loaded) package to be loaded. I can put it as postDoIt for the project, but this cannot be done because it is ONLY required for certain groups


- Shouldn't be necessary to create a ConfigurationOfImageForDevelopers
and in this configuration reference ConfigurationOfPharo and then the
installScript for the dev image use *only*
ConfigurationOfImageForDevelopers?


It can work, but actually for me we are having a problem (maybe we need the support the post/pre doit for groupos...but dale said it was complicated). I would like to just do (ConfigurationOfPharo project version: 'XXX') load:'ImageForDeveloper'


- It appears that Dale will announce project preload/postload doIts next

This was already done if I remember.....
 
monday. If that happens, shouldn't be better to incorporate the code
from DEVImageCreator as preload/postload do its to the
ConfigurationOfPharo?


no, because of the problem I told you that NOT all the groups want that.
 
It appears to me that DEVImageCreator is a mixture of different things,
both preference tuning (setDefaultPreferences, setFonts) image fixing
(addPreferenceCategories, cleanOpenMenu) and image building stuff
(writeListOfPackages, showWelcomeWorkspaces).


yes...and some obsolete code.
 
Maybe the image fixing stuff should be a change incorporated to the
PharoCore image, and the preference tuning should be a postload do it
for the ConfigurationOfImageForDevelopers, and the image building stuff
should be in the install script.

This way, if someone wants to build a image for developers (but without
the list of packages, or welcome workspaces) it only has to use
ConfigurationOfImageForDevelopers.


Yes, I like the idea. But I am not sure if for 1.0. I would do that for 1.1 images.
At the end of this converstation, we should open a ticket.
 
Also, maybe after all this refactoring, the
ConfigurationOfImageForDevelopers isn't necessary because all can be
incorporated to the ConfigurationOfPharo as preload/postload do its.
That is fine.


Yes!!!  I don't want a ConfigurationOfImageForDevelop. That means we are lacking something.
 
Also, the image for developers has stuff for squeak. This refactoring
would permit to separate them in preload/postload for each platform, in
a cleaner way.

As I said at beginning, this is only thoughts, and the current result
image is the same as the one produced by the previous configuration, but
maybe, with more time and less pressure, this refactoring and cleaning
could be made.

Of course, I will try to do this and contribute the code as my time
permits, but if someone can do it sooner, the better for all of us.

Thanks again for the hard work


Thanks for the notes...cheers

Mariano
 
--
Miguel Cobá
http://miguel.leugim.com.mx


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Pharo dev image rc2 thoughts

Mariano Martinez Peck
In reply to this post by Miguel Cobá

Also, the image for developers has stuff for squeak. This refactoring
would permit to separate them in preload/postload for each platform, in
a cleaner way.


Perdón....pero me importa muy poco lo que pase con Squeak. Ya limpié todo lo relacionado con Squeak de los shell scripts para crear las imágenes y pienso hacer lo mismo con ImageForDevelopers...todo lo que sea de Squeak, directamente lo borro. Quiero que esté todo limpio.

 
As I said at beginning, this is only thoughts, and the current result
image is the same as the one produced by the previous configuration, but
maybe, with more time and less pressure, this refactoring and cleaning
could be made.

Of course, I will try to do this and contribute the code as my time
permits, but if someone can do it sooner, the better for all of us.

Thanks again for the hard work
--
Miguel Cobá
http://miguel.leugim.com.mx


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Pharo dev image rc2 thoughts

Mariano Martinez Peck
ok...in English: the package ImageForDevelopers is not a normal package of software. It is just to build a particular image. At the beginning Damien use this for both, Squeak and Pharo. Each project is ever time far away from the other, and thus, having the same package for that, doesn't make sense. I do care that SqueakDBX for example works in Pharo and Squeak, but for this particular package I want to clean all what it Squeak related. Squeak people would probably do the same. Even more, I don't know when was the last time Squeak has a development image using this package....and I don't even know if they will use it again.

Cheers

Mariano

On Sun, Jan 24, 2010 at 12:20 PM, Mariano Martinez Peck <[hidden email]> wrote:

Also, the image for developers has stuff for squeak. This refactoring
would permit to separate them in preload/postload for each platform, in
a cleaner way.


Perdón....pero me importa muy poco lo que pase con Squeak. Ya limpié todo lo relacionado con Squeak de los shell scripts para crear las imágenes y pienso hacer lo mismo con ImageForDevelopers...todo lo que sea de Squeak, directamente lo borro. Quiero que esté todo limpio.

 
As I said at beginning, this is only thoughts, and the current result
image is the same as the one produced by the previous configuration, but
maybe, with more time and less pressure, this refactoring and cleaning
could be made.

Of course, I will try to do this and contribute the code as my time
permits, but if someone can do it sooner, the better for all of us.

Thanks again for the hard work
--
Miguel Cobá
http://miguel.leugim.com.mx


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Pharo dev image rc2 thoughts

Dale
In reply to this post by Miguel Cobá
Mariano,

The progress-bar problem is solvable.

The progress bar problem appears because the dev image doits reinitalize the progress bar class. The first question is: "Must the progress bar code be initialized?" if no, then remove the initialization code and the problem should be solved:) If yes, then I will dig into the problem and see what I can come up with ... there are a couple of routes I can take, but I'd like to know that we can't bypass the initialization before getting my hands that dirty:)

Dale

----- "Mariano Martinez Peck" <[hidden email]> wrote:

| 2010/1/24 Miguel Enrique Cobá Martinez <[hidden email]>
|
| >
| > Now to the point. I understand that the separation of concerns is
| good,
| > because ImageForDevelopers is already a separated and tested
| package
| > that shouldn't be inside ConfigurationOfPharo.
| >
|
| I will tell you a bit the background: First, when I took the
| installScript
| from Damien, there where some stuff done in the script (like settings
| the
| preferences and the fonts) done in the installScript. It didn't have
| sense
| for me (of course I asked Damien) and I put that in ImageForDevelopers
| (and
| this is cool because it is versiones with monticello). Actually in
| DEVImageCreator >> install.  I need also to clean that class as it has
| a lot
| of old stuff. But not time for the moment.
|
| When I create rc1, ImageForDevelopers was a dependency of
| ConfigurationOfPharo as you said. There was a problem installing it
| with the
| progress bar and Metacello. The image just frezze because of a
| sempahore and
| a delay....see issue:
| http://code.google.com/p/metacello/issues/detail?id=39
| But I can even reproduce the problem....So, that quick solution (as I
| needed
| to relase the Pharo image) was to put in the installScript.
|
| And after a while I discovered that I even like more that approach.
| Someone
| may want just the packages of a dev image, but not to set
| preferences,
| fonts, cleanups, etc. And I don't have the Metacello bug.
| The problem I found also putting it as a dependency is that it has to
| be the
| LATEST (I think that you cannot even said that XX package has to be
| the last
| one to be loaded) package to be loaded. I can put it as postDoIt for
| the
| project, but this cannot be done because it is ONLY required for
| certain
| groups
|
|
| > - Shouldn't be necessary to create a
| ConfigurationOfImageForDevelopers
| > and in this configuration reference ConfigurationOfPharo and then
| the
| > installScript for the dev image use *only*
| > ConfigurationOfImageForDevelopers?
| >
| >
| It can work, but actually for me we are having a problem (maybe we
| need the
| support the post/pre doit for groupos...but dale said it was
| complicated). I
| would like to just do (ConfigurationOfPharo project version: 'XXX')
| load:'ImageForDeveloper'
|


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Pharo dev image rc2 thoughts

Mariano Martinez Peck


On Sun, Jan 24, 2010 at 10:24 PM, Dale Henrichs <[hidden email]> wrote:
Mariano,

The progress-bar problem is solvable.

The progress bar problem appears because the dev image doits reinitalize the progress bar class. The first question is: "Must the progress bar code be initialized?" if no, then remove the initialization code and the problem should be solved:) If yes, then I will dig into the problem and see what I can come up with ... there are a couple of routes I can take, but I'd like to know that we can't bypass the initialization before getting my hands that dirty:)


Cool you are reading this thread Dale. Maybe this is another typical case where I may need post/pre doit for groups :) hahahahah   Of course, I need what you said it was most difficult...That's Morphy law :)   But doesn't matter. We can bypass this problem. Maybe we can think about it with time, in Metacello 1.1 or something like that.

I am completely ignorant about the progress. Could you detect where is exactly that the progress bar is initialized in that package ?
 
Dale

----- "Mariano Martinez Peck" <[hidden email]> wrote:

| 2010/1/24 Miguel Enrique Cobá Martinez <[hidden email]>
|
| >
| > Now to the point. I understand that the separation of concerns is
| good,
| > because ImageForDevelopers is already a separated and tested
| package
| > that shouldn't be inside ConfigurationOfPharo.
| >
|
| I will tell you a bit the background: First, when I took the
| installScript
| from Damien, there where some stuff done in the script (like settings
| the
| preferences and the fonts) done in the installScript. It didn't have
| sense
| for me (of course I asked Damien) and I put that in ImageForDevelopers
| (and
| this is cool because it is versiones with monticello). Actually in
| DEVImageCreator >> install.  I need also to clean that class as it has
| a lot
| of old stuff. But not time for the moment.
|
| When I create rc1, ImageForDevelopers was a dependency of
| ConfigurationOfPharo as you said. There was a problem installing it
| with the
| progress bar and Metacello. The image just frezze because of a
| sempahore and
| a delay....see issue:
| http://code.google.com/p/metacello/issues/detail?id=39
| But I can even reproduce the problem....So, that quick solution (as I
| needed
| to relase the Pharo image) was to put in the installScript.
|
| And after a while I discovered that I even like more that approach.
| Someone
| may want just the packages of a dev image, but not to set
| preferences,
| fonts, cleanups, etc. And I don't have the Metacello bug.
| The problem I found also putting it as a dependency is that it has to
| be the
| LATEST (I think that you cannot even said that XX package has to be
| the last
| one to be loaded) package to be loaded. I can put it as postDoIt for
| the
| project, but this cannot be done because it is ONLY required for
| certain
| groups
|
|
| > - Shouldn't be necessary to create a
| ConfigurationOfImageForDevelopers
| > and in this configuration reference ConfigurationOfPharo and then
| the
| > installScript for the dev image use *only*
| > ConfigurationOfImageForDevelopers?
| >
| >
| It can work, but actually for me we are having a problem (maybe we
| need the
| support the post/pre doit for groupos...but dale said it was
| complicated). I
| would like to just do (ConfigurationOfPharo project version: 'XXX')
| load:'ImageForDeveloper'
|


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Pharo dev image rc2 thoughts

Miguel Cobá
El dom, 24-01-2010 a las 22:33 +0100, Mariano Martinez Peck escribió:

>
>
> I am completely ignorant about the progress. Could you detect where is
> exactly that the progress bar is initialized in that package ?

Thanks Dale and Mariano.
I found the place where the reset is made.

The postDoit for ImageForDevelopers calls

  DEVImageCreator default install

that calls

self setTheme

that calls:

  UIThemeStandardSqueak beCurrent.
  UIThemeWatery2 beCurrent.

that is defined in:

  UITheme class.

There calls

  self current: self newDefault

where current is:

        "Set the current ui theme."

        Current := aUITheme.
        UITheme allThemeClasses do: [:c | c changed: #isCurrent].
        SystemProgressMorph reset. "reset to use new fill styles"
        ScrollBar initializeImagesCache. "reset to use new arrows"
        aUITheme updateWorldDockingBars.
        World themeChanged

and here is the problem! (finally :))

The SystemProgressMorph reset

is the culprit of the initialization of the progress bar.

and is called not one but two times, because the setThemes method first
install the old squeak theme (I suppose that Watery theme doesn't cover
all the UI elements) and then install the watery theme.

So here we have a problem. I think that it is correct to reset the
progress bar when you install the theme.
But I also think that *is not* the responsibility of Metacello to track
this specific scenario (unless that is really simple and non-invasive to
do, in that case, well, Dale is your time and we'll for sure welcome and
thank that fix)

Also, this problem can be solved by extracting the theme change to the
installScript.st

that is,

DEVImageCreator>>install

should remove the setTheme call and the installScript.st should do,
after creating the image:

DEVImageCreator default setTheme.

BTW, as we are here, install also should remove:

self writeListOfPackages.
self openWelcomeWorkspaces.

also to the installScript.st as

DEVImageCreator default
        setTheme;
        writeListOfPackages;
        openWelcomeWorkspaces.


But I digress. Returning to the problem of the reset of the progress
bar, maybe the best solution is to simply remove the setTheme call
because: Pharo already uses the watery theme, this was used, I think, in
the dev images based on squeak. But, as you are using the
ImageForDevelopers-pharo, just delete it.
Dale has nothing to do after that.

(but if you can change the writeListOfPackages and openWelcomeWorkspaces
to the installScript that would be cool ;)).


Cheers to all.




        SystemProgressMorph reset. "reset to use new fill styles"

--
Miguel Cobá
http://miguel.leugim.com.mx


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project