[Pharo-project] ConfigurationOfGrease stable does not load in Pharo 1.3
Hi, Try this in the latest Pharo 1.3 13315: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfGrease'; load. (ConfigurationOfGrease project version: #stable) load It won't work because ParseTreeEnvironment got renamed into RBParseTreeEnvironment. Any takes for updating the configuration? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"
I can have a look later. Stef
Hi,
Try this in the latest Pharo 1.3 13315:
Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfGrease'; load. (ConfigurationOfGrease project version: #stable) load
It won't work because ParseTreeEnvironment got renamed into RBParseTreeEnvironment.
Any takes for updating the configuration?
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
I updated the configurationOfGrease
(ConfigurationOfGrease project version: #development) load loads well in 1.3.
I do not understand why lukas and philippe do not give a shit about metacello but this is sad because idiots like me have to go and understand the dependencies after the fact. May be metacello is plain bad and ugly. I do not know what I know is that it is really important for our community. Now I do not know if I should promote it as stable. I could also do soemthing like stable: spec <symbolicVersion: #stable> spec for: #'pharo1.3.x' version: '1.6.0.2'. instead of stable: spec <symbolicVersion: #'stable'> spec for: #'common' version: '1.0.6'. On Oct 17, 2011, at 10:43 AM, Tudor Girba wrote:
Hi,
Try this in the latest Pharo 1.3 13315:
Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfGrease'; load. (ConfigurationOfGrease project version: #stable) load
It won't work because ParseTreeEnvironment got renamed into RBParseTreeEnvironment.
Any takes for updating the configuration?
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
On Tue, Oct 18, 2011 at 2:15 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
I updated the configurationOfGrease
(ConfigurationOfGrease project version: #development) load loads well in 1.3.
I do not understand why lukas and philippe do not give a shit about metacello but this is sad because idiots like me have to go and understand the dependencies after the fact.
May be metacello is plain bad and ugly. I do not know what I know is that it is really important for our community.
Now I do not know if I should promote it as stable.
I could also do soemthing like stable: spec <symbolicVersion: #stable>
spec for: #'pharo1.3.x' version: '1.6.0.2'.
instead of
stable: spec <symbolicVersion: #'stable'>
spec for: #'common' version: '1.0.6'.
Yes, I think you should do that because some users use stable. For example ConfigurationOfGlamour does: spec project: 'Grease' with: [ spec className: 'ConfigurationOfGrease'; file: 'ConfigurationOfGrease'; version: #stable; repository: ' http://www.squeaksource.com/MetacelloRepository' ].
On Oct 17, 2011, at 10:43 AM, Tudor Girba wrote:
Hi,
Try this in the latest Pharo 1.3 13315:
Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfGrease'; load. (ConfigurationOfGrease project version: #stable) load
It won't work because ParseTreeEnvironment got renamed into RBParseTreeEnvironment.
Any takes for updating the configuration?
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
-- Mariano http://marianopeck.wordpress.com
Ok I will I hope that it will not break users. Stef
On Tue, Oct 18, 2011 at 2:15 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: I updated the configurationOfGrease
(ConfigurationOfGrease project version: #development) load loads well in 1.3.
I do not understand why lukas and philippe do not give a shit about metacello but this is sad because idiots like me have to go and understand the dependencies after the fact.
May be metacello is plain bad and ugly. I do not know what I know is that it is really important for our community.
Now I do not know if I should promote it as stable.
I could also do soemthing like stable: spec <symbolicVersion: #stable>
spec for: #'pharo1.3.x' version: '1.6.0.2'.
instead of
stable: spec <symbolicVersion: #'stable'>
spec for: #'common' version: '1.0.6'.
Yes, I think you should do that because some users use stable. For example ConfigurationOfGlamour does:
spec project: 'Grease' with: [ spec className: 'ConfigurationOfGrease'; file: 'ConfigurationOfGrease'; version: #stable; repository: 'http://www.squeaksource.com/MetacelloRepository' ].
On Oct 17, 2011, at 10:43 AM, Tudor Girba wrote:
Hi,
Try this in the latest Pharo 1.3 13315:
Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfGrease'; load. (ConfigurationOfGrease project version: #stable) load
It won't work because ParseTreeEnvironment got renamed into RBParseTreeEnvironment.
Any takes for updating the configuration?
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
-- Mariano http://marianopeck.wordpress.com
On 18 October 2011 14:15, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I updated the configurationOfGrease
(ConfigurationOfGrease project version: #development) load loads well in 1.3.
I do not understand why lukas and philippe do not give a shit about metacello but this is sad because idiots like me have to go and understand the dependencies after the fact.
Sorry, but I am too stupid for it. It is too complex for me. You can take my scripts and get a working and minimal image. For many years I've been building images without problems. Now you can say that this is not your use-case, but Metacello configurations are not my use-case either. Lukas -- Lukas Renggli www.lukas-renggli.ch
Sorry, but I am too stupid for it. It is too complex for me.
You can take my scripts and get a working and minimal image. For many years I've been building images without problems.
sure Do not change. You are right. I'm wrong. Let us know try to improve metacello and bash it.
Now you can say that this is not your use-case, but Metacello configurations are not my use-case either.
I say nothing. I just totally convinced that if we do not want to stay an obscure little toy we have to capture dependencies and scripts do not capture that. For me metacello is not the panacea but it exists and if we would spend a little time then the system would benefit from it. Now there are problems because I have to fix configurations for systems I have no clue how they are built. So what your attitude just create is more burden on my shoulder. Sadly I would love that we do not have to use your projects but we cannot so I should do the fucking stupid job of extracting the dependencies in your project. It would cost you 3 min and it costs me hours but apparently your are right and I'm wrong and this is my stone. So I will continue. I do it because I want pharo to be a success. We will have a new engineer and we will ask him to improve metacello. because there is no other ways. I do not want to maintain Pharo without spec of dependencies and support for development because metacello supports that. Stef
Now you can say that this is not your use-case, but Metacello configurations are not my use-case either.
I say nothing. I just totally convinced that if we do not want to stay an obscure little toy we have to capture dependencies and scripts do not capture that.
I totally agree.
For me metacello is not the panacea but it exists and if we would spend a little time then the system would benefit from it. Now there are problems because I have to fix configurations for systems I have no clue how they are built.
This makes me wonder why you feel obliged to fix these problems?
So what your attitude just create is more burden on my shoulder. Sadly I would love that we do not have to use your projects  but we cannot so I should do the fucking stupid job of extracting the dependencies in your project.
Grease, Seaside, Magritte, Pier, ... have very well statically defined dependencies declared in each package (extension methods in GRPackage). There are numerous tests that ensure consistency (they are verified with each build). Dale has written tests that verify that the Grease declarations and Metacello definitions are in sync (don't know if they pass, they are not run if Metacello is not in the image). Furthermore, I have repeatedly posted dependencies graphs of various parts of the system. Also Jannik has repeatedly produced matrices with dependency information (I could never understand them). Either way, I thought we were are all fluent in one or the other tool to tell us outright about broken dependencies?
It would cost you 3 min and it costs me hours but apparently your are right and I'm wrong and this is my stone. So I will continue.
How? I do not even know what is wrong. Lukas -- Lukas Renggli www.lukas-renggli.ch
On Oct 18, 2011, at 3:33 PM, Lukas Renggli wrote:
Now you can say that this is not your use-case, but Metacello configurations are not my use-case either.
I say nothing. I just totally convinced that if we do not want to stay an obscure little toy we have to capture dependencies and scripts do not capture that.
I totally agree.
For me metacello is not the panacea but it exists and if we would spend a little time then the system would benefit from it. Now there are problems because I have to fix configurations for systems I have no clue how they are built.
This makes me wonder why you feel obliged to fix these problems?
because they break and people say that pharo does not work. This is why I want to have a build server that validates automatically all these configuration and tools to help people building/ublishing and testing them.
So what your attitude just create is more burden on my shoulder. Sadly I would love that we do not have to use your projects but we cannot so I should do the fucking stupid job of extracting the dependencies in your project.
Grease, Seaside, Magritte, Pier, ... have very well statically defined dependencies declared in each package (extension methods in GRPackage). There are numerous tests that ensure consistency (they are verified with each build). Dale has written tests that verify that the Grease declarations and Metacello definitions are in sync (don't know if they pass, they are not run if Metacello is not in the image).
Ok I was not aware of that.
Furthermore, I have repeatedly posted dependencies graphs of various parts of the system. Also Jannik has repeatedly produced matrices with dependency information (I could never understand them). Either way, I thought we were are all fluent in one or the other tool to tell us outright about broken dependencies?
It would cost you 3 min and it costs me hours but apparently your are right and I'm wrong and this is my stone. So I will continue.
How? I do not even know what is wrong.
When you change Grease update the configuration. We will build tools that support all the process. Just need time but we will get there. Stef
Lukas
-- Lukas Renggli www.lukas-renggli.ch
Lukas, Looking at the aftermath of this ConfigurationOfGrease issue, it appears that you and Philippe published a several new packages for Grease and those new packages were not included in the ConfigurationOfGrease that everyone else uses. If you had sent mail to me telling me that you have some updates you'd like included in Metacello, I would have made the edits to the configuration and there would have been no problem. I am very busy, but a request to edit 6 lines in a configuration is not too much work for me to handle ... Let's be honest Lukas, stupidity is not your problem ... Frankly, I am a bit mystified and dismayed, but if you claim stupidity then I guess you are stupid. With that said, you only need to send me mail when you want to release a new Seaside/Grease configuration and I will continue to do the genius work of maintaining the configurations. Dale ----- Original Message ----- | From: "Lukas Renggli" <renggli@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Tuesday, October 18, 2011 5:26:59 AM | Subject: Re: [Pharo-project] ConfigurationOfGrease stable does not load in Pharo 1.3 | | On 18 October 2011 14:15, Stéphane Ducasse | <stephane.ducasse@inria.fr> wrote: | > I updated the configurationOfGrease | > | >> (ConfigurationOfGrease project version: #development) load | > loads well in 1.3. | > | > I do not understand why lukas and philippe do not give a shit about | > metacello but this is sad | > because idiots like me have to go and understand the dependencies | > after the fact. | | Sorry, but I am too stupid for it. It is too complex for me. | | You can take my scripts and get a working and minimal image. For many | years I've been building images without problems. | | Now you can say that this is not your use-case, but Metacello | configurations are not my use-case either. | | Lukas | | -- | Lukas Renggli | www.lukas-renggli.ch | |
Looking at the aftermath of this ConfigurationOfGrease issue, it appears that you and Philippe published a several new packages for Grease and those new packages were not included in the ConfigurationOfGrease that everyone else uses.
Thank you for the offer to update the configurations, I really appreciate that. Though, I am not aware of any changes in the past weeks and our builds work just fine. Lukas -- Lukas Renggli www.lukas-renggli.ch
Lukas, The "fixed" configuration has new versions of nearly all of the grease packages committed by both you and Philippe. I haven't looked to see when the packages were committed, but they presumably were updated since the last release of Seaside/Grease which was a month ago. It would be useful if you used the ConfigurationOfSeaside30 and ConfigurationOfGrease in your continuous integration server for seaside. There have been a number of issues that would have been uncovered much earlier if you included the configurations in your tests ... In the past testing the configurations would have uncovered dependency issues that were masked by the fact that you don't test Grease independently of Seaside (or at least didn't at the time). This time around, the platform moved out from under the configuration... You'd only need to build one or two additional images using the configurations to completely test the Seaside eco-system ... as it stands now configuration problems are left for the end users to find and that's not correct. Dale ----- Original Message ----- | From: "Lukas Renggli" <renggli@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Tuesday, October 18, 2011 1:41:22 PM | Subject: Re: [Pharo-project] ConfigurationOfGrease stable does not load in Pharo 1.3 | | > Looking at the aftermath of this ConfigurationOfGrease issue, it | > appears that you and Philippe published a several new packages for | > Grease and those new packages were not included in the | > ConfigurationOfGrease that everyone else uses. | | Thank you for the offer to update the configurations, I really | appreciate that. | | Though, I am not aware of any changes in the past weeks and our | builds | work just fine. | | Lukas | | -- | Lukas Renggli | www.lukas-renggli.ch | |
It would be useful if you used the ConfigurationOfSeaside30 and ConfigurationOfGrease in your continuous integration server for seaside. There have been a number of issues that would have been uncovered much earlier if you included the configurations in your tests ...
I can do that. Which one? Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSeaside30'; load. (Smalltalk at: #ConfigurationOfSeaside30) load. Lukas -- Lukas Renggli www.lukas-renggli.ch
Done. http://jenkins.lukas-renggli.ch/job/Seaside%203.0%20(Metacello)/ On 18 October 2011 23:44, Lukas Renggli <renggli@gmail.com> wrote:
It would be useful if you used the ConfigurationOfSeaside30 and ConfigurationOfGrease in your continuous integration server for seaside. There have been a number of issues that would have been uncovered much earlier if you included the configurations in your tests ...
I can do that. Which one?
Gofer new   squeaksource: 'MetacelloRepository';   package: 'ConfigurationOfSeaside30';   load. (Smalltalk at: #ConfigurationOfSeaside30) load.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
Great! Yes...that's the one ...I've subscribe to the rss feed for the Metacello build (Looks like you kicked one off already) so I'll be able to respond to those issues... Presumably you'll trigger builds not only when the config changes, but when underlying platform changes as well? Or is it better to schedule it to build once a day (or when config changes)? Dale ----- Original Message ----- | From: "Lukas Renggli" <renggli@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Tuesday, October 18, 2011 2:44:58 PM | Subject: Re: [Pharo-project] ConfigurationOfGrease stable does not load in Pharo 1.3 | | > It would be useful if you used the ConfigurationOfSeaside30 and | > ConfigurationOfGrease in your continuous integration server for | > seaside. There have been a number of issues that would have been | > uncovered much earlier if you included the configurations in your | > tests ... | | I can do that. Which one? | | Gofer new | squeaksource: 'MetacelloRepository'; | package: 'ConfigurationOfSeaside30'; | load. | (Smalltalk at: #ConfigurationOfSeaside30) load. | | Lukas | | -- | Lukas Renggli | www.lukas-renggli.ch | |
Ok, it is broken indeed: http://jenkins.lukas-renggli.ch/job/Seaside%203.0%20(Metacello)/3/console At starting point I use a normal Pharo 1.3, but with e tests unloaded. On Wednesday, 19 October 2011, Dale Henrichs <dhenrich@vmware.com> wrote:
Great!
Yes...that's the one ...I've subscribe to the rss feed for the Metacello build (Looks like you kicked one off already) so I'll be able to respond to those issues...
Presumably you'll trigger builds not only when the config changes, but when underlying platform changes as well? Or is it better to schedule it to build once a day (or when config changes)?
I can observe a single directory per project. Should I trigger the build with changes to the Metacello repository? My machine cannot handle too many builds. It is old and very slow. Lukas
Dale ----- Original Message ----- | From: "Lukas Renggli" <renggli@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Tuesday, October 18, 2011 2:44:58 PM | Subject: Re: [Pharo-project] ConfigurationOfGrease stable does not load
in Pharo 1.3
| | > It would be useful if you used the ConfigurationOfSeaside30 and | > ConfigurationOfGrease in your continuous integration server for | > seaside. There have been a number of issues that would have been | > uncovered much earlier if you included the configurations in your | > tests ... | | I can do that. Which one? | | Gofer new | squeaksource: 'MetacelloRepository'; | package: 'ConfigurationOfSeaside30'; | load. | (Smalltalk at: #ConfigurationOfSeaside30) load. | | Lukas | | -- | Lukas Renggli | www.lukas-renggli.ch | |
-- Lukas Renggli www.lukas-renggli.ch
On Wednesday, 19 October 2011, Lukas Renggli <renggli@gmail.com> wrote:
Ok, it is broken indeed:
http://jenkins.lukas-renggli.ch/job/Seaside%203.0%20(Metacello)/3/console
At starting point I use a normal Pharo 1.3, but with e tests unloaded.
And it is because a too old version or a forked version of RB is loaded. Lukas
On Wednesday, 19 October 2011, Dale Henrichs <dhenrich@vmware.com> wrote:
Great!
Yes...that's the one ...I've subscribe to the rss feed for the Metacello
build (Looks like you kicked one off already) so I'll be able to respond to those issues...
Presumably you'll trigger builds not only when the config changes, but
when underlying platform changes as well? Or is it better to schedule it to build once a day (or when config changes)?
I can observe a single directory per project. Should I trigger the build with changes to the Metacello repository? My machine cannot handle too many builds. It is old and very slow.
Lukas
Dale ----- Original Message ----- | From: "Lukas Renggli" <renggli@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Tuesday, October 18, 2011 2:44:58 PM | Subject: Re: [Pharo-project] ConfigurationOfGrease stable does not load
in Pharo 1.3
| | > It would be useful if you used the ConfigurationOfSeaside30 and | > ConfigurationOfGrease in your continuous integration server for | > seaside. There have been a number of issues that would have been | > uncovered much earlier if you included the configurations in your | > tests ... | | I can do that. Which one? | | Gofer new | squeaksource: 'MetacelloRepository'; | package: 'ConfigurationOfSeaside30'; | load. | (Smalltalk at: #ConfigurationOfSeaside30) load. | | Lukas | | -- | Lukas Renggli | www.lukas-renggli.ch | |
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
On Oct 19, 2011, at 12:19 AM, Lukas Renggli wrote:
On Wednesday, 19 October 2011, Lukas Renggli <renggli@gmail.com> wrote:
Ok, it is broken indeed:
http://jenkins.lukas-renggli.ch/job/Seaside%203.0%20(Metacello)/3/console
At starting point I use a normal Pharo 1.3, but with e tests unloaded.
And it is because a too old version or a forked version of RB is loaded.
I merged all your changes (rename of classes) during the last sprint and updated it the configuration the last sprint. We still want to use RBEngine to perform refactoring on remote images so we will start modify the version that we have in Pharo to handle that and we will maintain this version and merge your changes in. Stef
Thanks lukas Here is the latest version where we explain metacello. I changed a lot and I should continue I'm half way there. The idea is that the last two pages should contain a summary of everything. So that we can write a config in a glance. Stef On Oct 19, 2011, at 12:03 AM, Dale Henrichs wrote:
Great!
Yes...that's the one ...I've subscribe to the rss feed for the Metacello build (Looks like you kicked one off already) so I'll be able to respond to those issues...
Presumably you'll trigger builds not only when the config changes, but when underlying platform changes as well? Or is it better to schedule it to build once a day (or when config changes)?
Dale ----- Original Message ----- | From: "Lukas Renggli" <renggli@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Tuesday, October 18, 2011 2:44:58 PM | Subject: Re: [Pharo-project] ConfigurationOfGrease stable does not load in Pharo 1.3 | | > It would be useful if you used the ConfigurationOfSeaside30 and | > ConfigurationOfGrease in your continuous integration server for | > seaside. There have been a number of issues that would have been | > uncovered much earlier if you included the configurations in your | > tests ... | | I can do that. Which one? | | Gofer new | squeaksource: 'MetacelloRepository'; | package: 'ConfigurationOfSeaside30'; | load. | (Smalltalk at: #ConfigurationOfSeaside30) load. | | Lukas | | -- | Lukas Renggli | www.lukas-renggli.ch | |
Hi doru I saw that we were working on parallel. Even better two idiots on the same configuration... I saw that you merged. I just published the new version with stable: spec <symbolicVersion: #'stable'> spec for: #'common' version: '1.0.6.2'. spec for: #'pharo1.3.x' version: '1.6.0.2'. So that we have a milestones for 1.3 and 1.4 will be working. Stef On Oct 17, 2011, at 10:43 AM, Tudor Girba wrote:
Hi,
Try this in the latest Pharo 1.3 13315:
Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfGrease'; load. (ConfigurationOfGrease project version: #stable) load
It won't work because ParseTreeEnvironment got renamed into RBParseTreeEnvironment.
Any takes for updating the configuration?
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
participants (5)
-
Dale Henrichs -
Lukas Renggli -
Mariano Martinez Peck -
Stéphane Ducasse -
Tudor Girba