Hi Dale: On 20 Feb 2013, at 16:15, Dale Henrichs wrote:

I have to admit that I haven't kept up with Pharo2.0 since last summer when I couldn't use Pharo2.0 for development because of OsProcess issues. I know that recently those issues have been cleared up, but I haven't had the time to return to Pharo2.0 and check things out (I'm facing more issues with getting PHaro2.0 to work with travis-ci, etc. so it will be a big undertaking for me to fully support Pharo2.0).

I have a working build with Travis. Well, working in the sense that it executes my unit tests. The tests actually fail for other reasons. See https://travis-ci.org/smarr/LibGit I use basically the CI infrastructure provided by Pharo 2.0. Guess that's Camillo's work. https://github.com/smarr/LibGit/blob/master/.travis.yml I happen to use a makefile: libgit.image: latest.image $(NBCOG) -headless $< config http://smalltalkhub.com/mc/StefanMarr/LibGit/main ConfigurationOfLibGit --install=bleedingEdge mv latest.image libgit.image mv latest.changes libgit.changes LibGit-Core-Tests-Test.xml: libgit.image $(NBCOG) -headless $< test --junit-xml-output LibGit-Core-Tests The only problem for the build status is to report the correct error code to travis, I think. As I understand it, Travis doesn't actually care about parsing or understanding test results, which is a pity. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

This is pretty cool. Doru On Wed, Feb 20, 2013 at 5:28 PM, Stefan Marr <smalltalk@stefan-marr.de>wrote:

Hi Dale:

On 20 Feb 2013, at 16:15, Dale Henrichs wrote:

...

I have to admit that I haven't kept up with Pharo2.0 since last summer when I couldn't use Pharo2.0 for development because of OsProcess issues. I know that recently those issues have been cleared up, but I haven't had the time to return to Pharo2.0 and check things out (I'm facing more issues with getting PHaro2.0 to work with travis-ci, etc. so it will be a big undertaking for me to fully support Pharo2.0).

I have a working build with Travis. Well, working in the sense that it executes my unit tests. The tests actually fail for other reasons. See https://travis-ci.org/smarr/LibGit

I use basically the CI infrastructure provided by Pharo 2.0. Guess that's Camillo's work. https://github.com/smarr/LibGit/blob/master/.travis.yml

I happen to use a makefile:

libgit.image: latest.image $(NBCOG) -headless $< config http://smalltalkhub.com/mc/StefanMarr/LibGit/main ConfigurationOfLibGit --install=bleedingEdge mv latest.image libgit.image mv latest.changes libgit.changes

LibGit-Core-Tests-Test.xml: libgit.image $(NBCOG) -headless $< test --junit-xml-output LibGit-Core-Tests

The only problem for the build status is to report the correct error code to travis, I think.

As I understand it, Travis doesn't actually care about parsing or understanding test results, which is a pity.

Best regards Stefan

-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

-- www.tudorgirba.com "Every thing has its own flow"

Stef, I definitely intend to keep supporting Metacello on ALL platforms ... I have not made any public changes to Metacello since the summer (roughly) so in one sense I've been ignoring all platforms equally for a while now ... I am looking forward to porting the Metacello Scripting API work to Pharo2.0, but I have a number of balls in the air at them moment ...

From reading subsequent emails, it sounds as though the bar is a lot lower than it was before ... it sounds like it won't be as big a job to get things running on Pharo2.0 as I anticipated, but I still need to find some time just to get my development environment (FileTree, git/github, travisCI) operational on Pharo2.0 ...

Dale ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: Pharo-project@lists.gforge.inria.fr | Cc: metacello@googlegroups.com | Sent: Wednesday, February 20, 2013 10:14:33 AM | Subject: Re: [Pharo-project] Metacello issues on Pharo 2.0 | | Dale | | We are investing massively on metacello so now this is important for us to | know if you will continue | to maintain it or not. | Because if this is not the case then we will have to rethink our strategy. | | Stef | | | | > Christophe, | > | > I'm not exactly sure what your problem is ... | > | > I have to admit that I haven't kept up with Pharo2.0 since last summer when | > I couldn't use Pharo2.0 for development because of OsProcess issues. I | > know that recently those issues have been cleared up, but I haven't had | > the time to return to Pharo2.0 and check things out (I'm facing more | > issues with getting PHaro2.0 to work with travis-ci, etc. so it will be a | > big undertaking for me to fully support Pharo2.0). | > | > I've got a fairly recent Pharo2.0 image and it looks like there are | > pharo-specific versions for each of the packages loaded into Pharo2.0. I | > assume that the tests are all passing with those versions, although I | > can't say whether or not the tests had to be modified to pass in Pharo2.0 | > as well ... which is likely to be a source of one of the problems you are | > looking at ... | > | > I don't know where the configuration exists that is being used to manage | > the changes for Pharo2.0 and the tests, but that is probably a good | > starting point ... if you are not using the proper Pharo2.0 configuration, | > you won't be getting the proper packages loaded ... | > | > Dale | > ----- Original Message ----- | > | From: "Christophe Demarey" <Christophe.Demarey@inria.fr> | > | To: metacello@googlegroups.com | > | Cc: Pharo-project@lists.gforge.inria.fr | > | Sent: Friday, February 15, 2013 6:09:27 AM | > | Subject: [Pharo-project] Metacello issues on Pharo 2.0 | > | | > | Hi all, | > | | > | I have issues with Metacello on Pharo 2.0 | > | | > | If I load and run tests for the version used in Pharo1.4, it gives: | > | (ConfigurationOfMetacello project version: '1.0-beta.31.1.4') load: | > | 'Tests' | > | | > | | > | | > | Metacello packages shipped with Pharo 2.0 are all packages derived from | > | the | > | latest stable Metacello baseline (1.0-beta.31.1.5) except the | > | MetacelloToolBox. | > | If I load and run tests packages with version described in the latest | > | stable | > | Metacello baseline (1.0-beta.31.1.5), i.e. : | > | Metacello-TestsCore-DaleHenrichs.14 and | > | Metacello-TestsMC-dkh.351, | > | it gives (Pharo 2.0 #20547): | > | | > | | > | So, it seems there are some problems. Do we use the rigth versions of | > | Metacello packages? | > | | > | Regards, | > | Christophe. | > | | > | | > | | > Chr | > |

I could not load in Pharo 2.0 latest (ConfigurationOfMetacello project version: '1.0-beta.32') load: 'Tests' Stef

On 20 February 2013 18:17, stephane ducasse <stephane.ducasse@free.fr> wrote:

Hi christophe

We should clear up this issue. Did you make progress on that front? The answer of dale are not really giving my hope. I do not want to base all our infrastructure

on a tool that we do not know if it will be maintained.

Metacello is perfectly well maintained, and runs on a number of Smalltalks. It broke on Pharo 2.0 because things changed too quickly, too quickly for Dale to keep up. What would be vastly more constructive than implying that Dale has abandoned Metacello would be applying some Pharo effort towards making it work again on 2.0. frank

Stef

On Feb 15, 2013, at 3:09 PM, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:

Hi all,

I have issues with Metacello on Pharo 2.0

If I load and run tests for the version used in Pharo1.4, it gives: (ConfigurationOfMetacello project version: '1.0-beta.31.1.4') load: 'Tests'

<Capture d’écran 2013-02-15 à 14.45.15.png>

Metacello packages shipped with Pharo 2.0 are all packages derived from the latest stable Metacello baseline (1.0-beta.31.1.5) except the MetacelloToolBox. If I load and run tests packages with version described in the latest stable Metacello baseline (1.0-beta.31.1.5), i.e. :

Metacello-TestsCore-DaleHenrichs.14 and Metacello-TestsMC-dkh.351,

it gives (Pharo 2.0 #20547): <Capture d’écran 2013-02-15 à 14.55.36.png>

So, it seems there are some problems. Do we use the rigth versions of Metacello packages?

Regards, Christophe.

On 20 February 2013 19:53, stephane ducasse <stephane.ducasse@free.fr> wrote:

...

Metacello is perfectly well maintained, and runs on a number of Smalltalks.

I do not know. If Dale did not had a look since this summer this is 8 months ago. I have no problem that this would happen. I just want to know because we want to build all the validation of packages on top of metacello.

...

It broke on Pharo 2.0 because things changed too quickly, too quickly for Dale to keep up.

Probably. But I do not think so.

Well, Dale certainly thought so, because he said so - it was when you replaced FileDirectory with FileSystem.

...

What would be vastly more constructive than implying that Dale has abandoned Metacello would be applying some Pharo effort towards making it work again on 2.0.

Frank I spent a lot of time pushing Metacello, christophe is working on a tool so that everybody can produce more easily configuration.

I know, and I appreciate that.

Now my question is still valid. I just want to know because my time is counted and christophe is trying to understand metacello since some time and we should move forward.

Sure, and Metacello's quite a complicated beast. I'm trying to gently suggest out that since it was Pharo's changes that broke Metacello, and Pharo desperately needs to keep it working, that maybe Pharo should apply some of its funded muscle and help Dale. frank

Stef

...

frank

...

Stef

On Feb 15, 2013, at 3:09 PM, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:

Hi all,

I have issues with Metacello on Pharo 2.0

If I load and run tests for the version used in Pharo1.4, it gives: (ConfigurationOfMetacello project version: '1.0-beta.31.1.4') load: 'Tests'

<Capture d’écran 2013-02-15 à 14.45.15.png>

Metacello packages shipped with Pharo 2.0 are all packages derived from the latest stable Metacello baseline (1.0-beta.31.1.5) except the MetacelloToolBox. If I load and run tests packages with version described in the latest stable Metacello baseline (1.0-beta.31.1.5), i.e. :

Metacello-TestsCore-DaleHenrichs.14 and Metacello-TestsMC-dkh.351,

it gives (Pharo 2.0 #20547): <Capture d’écran 2013-02-15 à 14.55.36.png>

So, it seems there are some problems. Do we use the rigth versions of Metacello packages?

Regards, Christophe.

Hi Dale Sure no problem was tired and nervous because Metacello is key for us. I'm sitting with christophe to check. Information that can interest you - on the repository of Pharo the Metacello-Core was fixed to handle FileReference Now I do not know how you want to manage it for your bootstrap. let us know how you want that we proceed. - for the tests (not version 10.32 that I cannot load - I will have a look at profStef to make it 2.0 aware I guess that this is that the problem) runCase refers to SystemNotifier we have to check how we control silently the announcement of the new announcer. Probably SystemAnnouncer uniqueInstance suspendAllWhile: For the Toolbox problem Christophe checked the version of '1.0-beta.31.1.5' since this is the latest stable version spec package: 'Metacello-Base' with: 'Metacello-Base-DaleHenrichs.19'; -> Metacello-Base-MarcusDenker.20 (no difference) package: 'Metacello-Core' with: 'Metacello-Core-dkh.492'; -> Metacello-Core-MarcusDenker.494 (handle FileSystem package: 'Metacello-MC' with: 'Metacello-MC-dkh.664'; -> Metacello-MC-StephaneDucasse.666 (apparently we remove the versions accesssor => look really suspicious) package: 'Metacello-Reference' with: 'Metacello-Reference-DaleHenrichs.31'; package: 'Metacello-Tutorial' with: 'Metacello-Tutorial-dkh.25'; package: 'OB-Metacello' with: 'OB-Metacello-dkh.82'; package: 'Metacello-TestsReference' with: 'Metacello-TestsReference-DaleHenrichs.17'; package: 'Metacello-TestsCore' with: 'Metacello-TestsCore-DaleHenrichs.14'; package: 'Metacello-TestsMC' with: 'Metacello-TestsMC-dkh.351'; package: 'Metacello-TestsTutorial' with: 'Metacello-TestsTutorial-dkh.33'; package: 'Metacello-ToolBox' with: 'Metacello-ToolBox-dkh.130' -> Metacello-ToolBox-MarcusDenker.135 here this is strange because the version of the toolbox in Pharo is based on 135 134 133 132 131 127 126 .... so should we take another version of the toolbox? May be there was a mistake from our side to take a wrong branch. In particular neither version of configurationClasses work in pharo configurationClasses "Return a set of the Metacello configuration classes that have been loaded into the image." <apiDocumentation> ^ MetacelloProjectRegistration configurationClasses configurationClasses "Return a set of the Metacello configuration classes that have been loaded into the image." <apiDocumentation> self flag: 'more work needed about MetacelloProjectRegistration'. ^ Array streamContents: [ :s| SystemNavigation default allClassesDo: [ :cls| (cls name beginsWith: 'ConfigurationOf') ifTrue: [ s nextPut: cls ]]] So this means that we do not know what to do but Christophe cannot work on 2.0 for versioner. Stef & Christophe

Stef,

AFAIK, this is the first report of any bugs with Metacello since September... just saying....

Dale

----- Original Message ----- | From: "stephane ducasse" <stephane.ducasse@free.fr> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, February 20, 2013 11:53:28 AM | Subject: Re: [Pharo-project] Metacello issues on Pharo 2.0 | | | > Metacello is perfectly well maintained, and runs on a number of | > Smalltalks. | | I do not know. If Dale did not had a look since this summer this is 8 months | ago. | I have no problem that this would happen. I just want to know because | we want to build all the validation of packages on top of metacello. | | > It broke on Pharo 2.0 because things changed too quickly, | > too quickly for Dale to keep up. | | Probably. But I do not think so. | | > What would be vastly more | > constructive than implying that Dale has abandoned Metacello would be | > applying some Pharo effort towards making it work again on 2.0. | | Frank I spent a lot of time pushing Metacello, christophe is working on a | tool | so that everybody can produce more easily configuration. | | Now my question is still valid. I just want to know because my time is | counted | and christophe is trying to understand metacello since some time and we | should | move forward. | | Stef | | > | > frank | > | >> Stef | >> | >> | >> | >> | >> On Feb 15, 2013, at 3:09 PM, Christophe Demarey | >> <Christophe.Demarey@inria.fr> wrote: | >> | >> Hi all, | >> | >> I have issues with Metacello on Pharo 2.0 | >> | >> If I load and run tests for the version used in Pharo1.4, it gives: | >> (ConfigurationOfMetacello project version: '1.0-beta.31.1.4') load: | >> 'Tests' | >> | >> <Capture d’écran 2013-02-15 à 14.45.15.png> | >> | >> Metacello packages shipped with Pharo 2.0 are all packages derived from | >> the | >> latest stable Metacello baseline (1.0-beta.31.1.5) except the | >> MetacelloToolBox. | >> If I load and run tests packages with version described in the latest | >> stable | >> Metacello baseline (1.0-beta.31.1.5), i.e. : | >> | >> Metacello-TestsCore-DaleHenrichs.14 and | >> Metacello-TestsMC-dkh.351, | >> | >> it gives (Pharo 2.0 #20547): | >> <Capture d’écran 2013-02-15 à 14.55.36.png> | >> | >> So, it seems there are some problems. Do we use the rigth versions of | >> Metacello packages? | >> | >> Regards, | >> Christophe. | >> | >> | >> | > |

| | let us know how you want that we proceed.

I will have to look at the changes themselves to determine which direction to go ... if the changes are isolated enough I'd be inclined to hide them in MetacelloPlatform ... that's where the platform uglies go ... If the changes are extensive, then I'd consider extracting out a filedirectory[1]/filesystem[2] utilities package (as was done for zinc and filetree).

I have the impression when I checked all the changes that they are minor but impacting (FS for example)

[1] https://github.com/dalehenrich/filetree/tree/pharo2.0/repository/MonticelloF... [2] https://github.com/dalehenrich/filetree/tree/pharo2.0/repository/MonticelloF... | | - for the tests (not version 10.32 that I cannot load - I will have a look

Metacello 1.0-beta.32 is the Metacello Preview version (not yet released anywhere) and porting that version stopped me cold last summer ... OSProcess was the final straw:)

Ok I could not load it because ProfStef was not found but I can retry.

| at profStef to make it 2.0 aware I guess that this is that the problem) | runCase refers to SystemNotifier | | versions accesssor => look really suspicious)

Yeah, that looks very suspicious and tests won't pass without that puppy:)

yes to me it looks really strange.

| 'Metacello-TestsTutorial-dkh.33'; | package: 'Metacello-ToolBox' with: | 'Metacello-ToolBox-dkh.130' | -> Metacello-ToolBox-MarcusDenker.135 | | here this is strange because the version of the toolbox in Pharo is | based on 135 134 133 132 131 127 126 .... so should we take another | version of the toolbox? | May be there was a mistake from our side to take a wrong branch.

You are on the right branch, Metacello-ToolBox-dkh.130 is okay (it's part of Metacello 1.0-beta.31.1.5) but Metacello-ToolBox-dkh.131 is part of the Preview release.

We do not use 130 but 135 so we are using the wrong branch. So do you have idea of experience we should run. I think that we should try to load metacello-Toolbox.130 and check the tests.

I think that the suspendAllWhile: call is important because a) some Metacello tests are sensitive to packages getting marked dirty or other events getting triggered ... ----- Original Message ----- | From: "Christophe Demarey" <Christophe.Demarey@inria.fr> | To: Pharo-project@lists.gforge.inria.fr | Sent: Thursday, February 21, 2013 1:26:31 AM | Subject: Re: [Pharo-project] Metacello issues on Pharo 2.0 | | Dale | | we run the tests simply rewriting runCase as | | runCase | | original | | (self doSilently) ifFalse: [ ^super runCase ]. | original := MetacelloPlatform current bypassGoferLoadUpdateCategories. | [ | MetacelloPlatform current bypassGoferLoadUpdateCategories: true. | ^ SystemAnnouncer uniqueInstance suspendAllWhile: [ super runCase ] | ensure: [ MetacelloPlatform current bypassGoferLoadUpdateCategories: | original ] | | but it seems that we do not have the same behavior between the two | | runCase | | original | | (self doSilently) ifFalse: [ ^super runCase ]. | original := MetacelloPlatform current bypassGoferLoadUpdateCategories. | [ | MetacelloPlatform current bypassGoferLoadUpdateCategories: true. | ^ super runCase ] | ensure: [ MetacelloPlatform current bypassGoferLoadUpdateCategories: | original ] | | So we will run all the tests | | Stef