I recently spent some time to revise how to write Metacello Configurations. Observation: ============ - many configurations are quite a mess - many configurations duplicate code internally - many configurations have archived development versions For Pharo 3.0 I made a new Configuration template which improves and documents these observed points in quite some detail. Simply load a new 3.0 image and create a new configuration from the monticello working copy browser. Solution: ========= - specify external projects in separate, reusable methods - only have ONE development version you regularly update - do not use version numbers for the development version - only make a version number when you release something stable AKA not #development - name the baseline after the first version that introduces it What do you think?
On 22 May 2013 17:53, Camillo Bruni <camillobruni@gmail.com> wrote:
I recently spent some time to revise how to write Metacello Configurations.
Observation: ============ - many configurations are quite a mess - many configurations duplicate code internally - many configurations have archived development versions
For Pharo 3.0 I made a new Configuration template which improves and documents these observed points in quite some detail. Simply load a new 3.0 image and create a new configuration from the monticello working copy browser.
Solution: ========= - specify external projects in separate, reusable methods - only have ONE development version you regularly update - do not use version numbers for the development version - only make a version number when you release something stable AKA not #development - name the baseline after the first version that introduces it
+1 especially i never understood why development version should have a number. it makes sense , like "a future release number".. but it feels like you should plan what/when you will release before even starting development, which is not always an option.
What do you think?
-- Best regards, Igor Stasenko.
+100! On 22.05.2013, at 17:53, Camillo Bruni <camillobruni@gmail.com> wrote:
I recently spent some time to revise how to write Metacello Configurations.
Observation: ============ - many configurations are quite a mess - many configurations duplicate code internally - many configurations have archived development versions
For Pharo 3.0 I made a new Configuration template which improves and documents these observed points in quite some detail. Simply load a new 3.0 image and create a new configuration from the monticello working copy browser.
Solution: ========= - specify external projects in separate, reusable methods - only have ONE development version you regularly update - do not use version numbers for the development version - only make a version number when you release something stable AKA not #development - name the baseline after the first version that introduces it
What do you think?
On May 22, 2013, at 5:53 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
I recently spent some time to revise how to write Metacello Configurations.
Observation: ============ - many configurations are quite a mess - many configurations duplicate code internally - many configurations have archived development versions
I would love to go over the one I maintain and fix them. So give me hints and I will do it. I want patterns! Patterns are a proof of maturity and optimise the space.
For Pharo 3.0 I made a new Configuration template which improves and documents these observed points in quite some detail. Simply load a new 3.0 image and create a new configuration from the monticello working copy browser.
Solution: ========= - specify external projects in separate, reusable methods - only have ONE development version you regularly update - do not use version numbers for the development version - only make a version number when you release something stable AKA not #development - name the baseline after the first version that introduces it
What do you think?
show me one example because there are too many concepts and I'm confused about words when talking metacellonese. But yes I do not want all the possible possibilities just the cool and efficient patterns (that a tool should codify for me). In my dream (and this is why I'm frustrated that we are burning the time of christophe on travis) I would love to have a tools to generate and validate configurations for me. Stef
On 2013-05-22, at 19:00, stephane ducasse <stephane.ducasse@free.fr> wrote:
On May 22, 2013, at 5:53 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
I recently spent some time to revise how to write Metacello Configurations.
Observation: ============ - many configurations are quite a mess - many configurations duplicate code internally - many configurations have archived development versions
I would love to go over the one I maintain and fix them. So give me hints and I will do it. I want patterns! Patterns are a proof of maturity and optimise the space.
For Pharo 3.0 I made a new Configuration template which improves and documents these observed points in quite some detail. Simply load a new 3.0 image and create a new configuration from the monticello working copy browser.
Solution: ========= - specify external projects in separate, reusable methods - only have ONE development version you regularly update - do not use version numbers for the development version - only make a version number when you release something stable AKA not #development - name the baseline after the first version that introduces it
What do you think?
show me one example because there are too many concepts and I'm confused about words when talking metacellonese. But yes I do not want all the possible possibilities just the cool and efficient patterns (that a tool should codify for me).
you can check the ConfigurationOfCI and ConfigurationOfAsmJit in http://smalltalkhub.com/mc/Pharo/ci/main or http://smalltalkhub.com/mc/Pharo/AsmJit/main or you come to my office and we look at it together ;)
In my dream (and this is why I'm frustrated that we are burning the time of christophe on travis) I would love to have a tools to generate and validate configurations for me.
yes definitely!
What do you think?
I think we should have a stable and strong Versionner. As soon as making a software release is more than clicking one button, we will end up with messy configurations. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On May 23, 2013, at 4:22 AM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
What do you think?
I think we should have a stable and strong Versionner. As soon as making a software release is more than clicking one button, we will end up with messy configurations.
Yes christophe worked on porting travis to pharo because dale used it for his tests so that we can get the latest version of metacello in pharo. We do not do it for fun believe me. Stef
On 2013-05-23, at 07:52, stephane ducasse <stephane.ducasse@free.fr> wrote:
On May 23, 2013, at 4:22 AM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
What do you think?
I think we should have a stable and strong Versionner. As soon as making a software release is more than clicking one button, we will end up with messy configurations.
Yes christophe worked on porting travis to pharo because dale used it for his tests so that we can get the latest version of metacello in pharo. We do not do it for fun believe me.
unless it runs in the current development version of Pharo I fear that it will ever be used. currently it only runs under 1.4 which is deprecated. If the current development aims at 2.0 we will have the same situation.
Cami, Metacello has never been properly ported to Pharo2.0 and we don't need to rehash those issues again ... I am working with Christophe to properly port Metacello to Pharo2.0 (we are down to about 8 failing tests so we are very close) ... Once this job is done, both Pharo2.0 and Pharo3.0 will be added to my travis ci lineup (I currently run ci builds for Metacello against 6 different versions of GemStone, 3 versions of Squeak and 4 versions of Pharo) ... Once Pharo2.0 and Pharo3.0 becomes part of the standard Metacello build lineup, I should be able to keep pace with you guys as you continue to push the boundaries of Smalltalk. Dale ----- Original Message ----- | From: "Camillo Bruni" <camillobruni@gmail.com> | To: "Discusses Development of Pharo" <pharo-dev@lists.pharo.org> | Sent: Thursday, May 23, 2013 12:58:38 AM | Subject: Re: [Pharo-dev] Messy Configurations | | | On 2013-05-23, at 07:52, stephane ducasse <stephane.ducasse@free.fr> | wrote: | > On May 23, 2013, at 4:22 AM, Alexandre Bergel | > <alexandre.bergel@me.com> wrote: | >>> What do you think? | >> | >> I think we should have a stable and strong Versionner. As soon as | >> making a software release is more than clicking one button, we | >> will end up with messy configurations. | > | > Yes christophe worked on porting travis to pharo because dale used | > it for his tests so that we can get the latest version of | > metacello | > in pharo. We do not do it for fun believe me. | | unless it runs in the current development version of Pharo I fear | that it will ever be used. | currently it only runs under 1.4 which is deprecated. If the current | development aims at 2.0 we will have the same situation.
Dale K. Henrichs wrote
Once Pharo2.0 and Pharo3.0 becomes part of the standard Metacello build lineup, I should be able to keep pace with you guys as you continue to push the boundaries of Smalltalk.
Three cheers for Dale!! Thank you :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-Messy-Configurations-tp4689182p4689482.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
+100 ----- Original Message ----- | From: "Alexandre Bergel" <alexandre.bergel@me.com> | To: "Discusses Development of Pharo" <pharo-dev@lists.pharo.org> | Sent: Wednesday, May 22, 2013 7:22:54 PM | Subject: Re: [Pharo-dev] Messy Configurations | | | > What do you think? | | I think we should have a stable and strong Versionner. As soon as | making a software release is more than clicking one button, we will | end up with messy configurations. | | Alexandre | | -- | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | Alexandre Bergel http://www.bergel.eu | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:; |
+1000 Camillo!! I'd really appreciate a "better" MC configuration mechanism! R On May 22, 2013, at 5:53 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
I recently spent some time to revise how to write Metacello Configurations.
Observation: ============ - many configurations are quite a mess - many configurations duplicate code internally - many configurations have archived development versions
For Pharo 3.0 I made a new Configuration template which improves and documents these observed points in quite some detail. Simply load a new 3.0 image and create a new configuration from the monticello working copy browser.
Solution: ========= - specify external projects in separate, reusable methods - only have ONE development version you regularly update - do not use version numbers for the development version - only make a version number when you release something stable AKA not #development - name the baseline after the first version that introduces it
What do you think?
On May 23, 2013, at 10:17 AM, roberto.minelli@usi.ch wrote:
+1000 Camillo!! I'd really appreciate a "better" MC configuration mechanism!
us too. Now we have to deal with the fact that latest version of metacello could not work in Pharo anymore Stef
On May 22, 2013, at 5:53 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
I recently spent some time to revise how to write Metacello Configurations.
Observation: ============ - many configurations are quite a mess - many configurations duplicate code internally - many configurations have archived development versions
For Pharo 3.0 I made a new Configuration template which improves and documents these observed points in quite some detail. Simply load a new 3.0 image and create a new configuration from the monticello working copy browser.
Solution: ========= - specify external projects in separate, reusable methods - only have ONE development version you regularly update - do not use version numbers for the development version - only make a version number when you release something stable AKA not #development - name the baseline after the first version that introduces it
What do you think?
On 2013-05-23, at 11:27, stephane ducasse <stephane.ducasse@free.fr> wrote:
On May 23, 2013, at 10:17 AM, roberto.minelli@usi.ch wrote:
+1000 Camillo!! I'd really appreciate a "better" MC configuration mechanism!
well this is only a convention, without proper tools everything will become messy anyway :P Here is used example of the new configuration: Gofer new smalltalkhubUser: 'Pharo' project: 'ci'; configurationOf: 'CI'; load. #ConfigurationOfCI asClass browse
well this is only a convention, without proper tools everything will become messy anyway :P
agreed
Here is used example of the new configuration:
Gofer new smalltalkhubUser: 'Pharo' project: 'ci'; configurationOf: 'CI'; load.
#ConfigurationOfCI asClass browse
Yes this is good!.
----- Original Message ----- | From: "Camillo Bruni" <camillobruni@gmail.com> | To: pharo-dev@lists.pharo.org | Sent: Wednesday, May 22, 2013 8:53:31 AM | Subject: [Pharo-dev] Messy Configurations | | I recently spent some time to revise how to write Metacello | Configurations. | | Observation: | ============ | - many configurations are quite a mess | - many configurations duplicate code internally | - many configurations have archived development versions | | | For Pharo 3.0 I made a new Configuration template which improves and | documents | these observed points in quite some detail. Simply load a new 3.0 | image and | create a new configuration from the monticello working copy browser. | | Solution: | ========= | - specify external projects in separate, reusable methods | - only have ONE development version you regularly update | - do not use version numbers for the development version | - only make a version number when you release something stable AKA | not #development | - name the baseline after the first version that introduces it | | | | What do you think? Cami, I don't want to discount your frustration with the complexity of Metacello configurations and looking at your sample configurations you have definitely come up with a cleaner structure for the code ... But, (there always is a _but_) ... Metacello configurations are not really code ... they are specifications ... Metacello configurations are closer to XML files than they are to Smalltalk classes ... XML files are "read" by tools and "written" by tools ... You can hand edit an XML file to produce a pleasing structure for human readability, but when a tool gets ahold of the file and rewrites the XML file, all of the fancy hand editing disappears ... The same thing will happen with configurations ... you can restructure the code in your configuration using nicely structured methods, etc, however, if you use a tool to add/manipulate your configuration, all of the fancy "formatting" will be lost and the tool will write out a monolithic single method representation of your specification (leaving the rest of the configuration methods untouched) ... With that said, it is conceivable that a crop of tools can be written to produce "better structured configurations" ... meaningful pragmas could be invented so that tools and humans could both be aware of the "project methods" and other components that you've added ... but that is up to the tool builders ... Dale
participants (8)
-
Alexandre Bergel -
Camillo Bruni -
Dale K. Henrichs -
Igor Stasenko -
Max Leske -
roberto.minelli＠usi.ch -
Sean P. DeNigris -
stephane ducasse