Moose 4.1 bootstrapping (Pharo 1.1) - Moose-dev

Tudor Girba

4 Jun 4 Jun

7:04 p.m.

Great job, Simon! I will take a look tomorrow during the sprint. Cheers, Doru On 4 Jun 2010, at 18:38, Simon Denier wrote:

...

So I know that some of you already started to use Moose under Pharo 1.1, and now it is time to assess the situation. I took the latest Pharo Core on the web 11383. I loaded the latest Pharo Conf 1.1-beta1.10517 Then I loaded default of ConfigurationOfMoose. After loading, the first issue I knew beforehand is that there was a conflicting dependency between the version of MorphTreeWidget loaded by Moose default and the one which now comes by default with Pharo 1.1 I built two new default versions for Glamour and Moose with Pharo1.1 by removing this dependency: (ConfigurationOfMoose project version: 'default11') load should load a working Moose (not tested) Tests got something like 200 errors, however most of them seem to have common roots (meaning fix one problem and you fix dozens of tests). There seem to be nothing really serious, just fixing changes in API and also compiler semantics, with strange things around. 1) For example, the following snippet of code is valid (I didn't even know that!) but the semantic has changed: [ :i ] value: 1 -> returns 1 under Pharo 1.0, and nil under Pharo 1.1 2) Also it seems that the compiler now considers _ as a message send. Just try MSEUtilities signatureFromSmalltalkSelector: #_ and you get a nice primitive failed. Of course the importer did not like it :) I just replaced _ with := 3) fix deprecation asSortedArray -> asArray sort in Hashtable 4) One fix NOT commited in Glamour: Message send autoDeselect: produces DNU, rewritten as autoDeselection: in GLMMorphicRenderer>>treeMorphFor:and: I started to do that, I'm now at 20 failures and 42 errors. The fun thing is that the changes are not necessarily complicated, but the effects on tests can be weird (like above). So it's difficult sometimes to tell what is the problem. Now failing tests are mostly in GroupTest (some difference in importing the model, perhaps simply due to changes in the system classes imported) and MooseAlgos, a couple of other packages... If someone knows how to replace the following snipper, it will solve a lot of error tests in MooseAlgos actually. Stream endOfStreamSignal signal -- Simon _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

Reply

Tudor Girba

5 Jun 5 Jun

12:55 a.m.

Hi, I did a quick tour over the issues: - I renamed versions default11 to default, because default should always point to the latest development configuration, and from now on we move development to Pharo 1.1 - I fixed the Glamour problem, and now all tests are green (with the expected failures) - I also fixed a couple of GroupTests However, I noticed that the GroupTests break because the imported model now contains 42 classes instead of 48. I have no idea why. Cheers, Doru On 4 Jun 2010, at 22:04, Alexandre Bergel wrote:

...

Good job!! Alexandre On 4 Jun 2010, at 12:38, Simon Denier wrote:

So I know that some of you already started to use Moose under Pharo 1.1, and now it is time to assess the situation. I took the latest Pharo Core on the web 11383. I loaded the latest Pharo Conf 1.1-beta1.10517 Then I loaded default of ConfigurationOfMoose. After loading, the first issue I knew beforehand is that there was a conflicting dependency between the version of MorphTreeWidget loaded by Moose default and the one which now comes by default with Pharo 1.1 I built two new default versions for Glamour and Moose with Pharo1.1 by removing this dependency: (ConfigurationOfMoose project version: 'default11') load should load a working Moose (not tested) Tests got something like 200 errors, however most of them seem to have common roots (meaning fix one problem and you fix dozens of tests). There seem to be nothing really serious, just fixing changes in API and also compiler semantics, with strange things around. 1) For example, the following snippet of code is valid (I didn't even know that!) but the semantic has changed: [ :i ] value: 1 -> returns 1 under Pharo 1.0, and nil under Pharo 1.1 2) Also it seems that the compiler now considers _ as a message send. Just try MSEUtilities signatureFromSmalltalkSelector: #_ and you get a nice primitive failed. Of course the importer did not like it :) I just replaced _ with := 3) fix deprecation asSortedArray -> asArray sort in Hashtable 4) One fix NOT commited in Glamour: Message send autoDeselect: produces DNU, rewritten as autoDeselection: in GLMMorphicRenderer>>treeMorphFor:and: I started to do that, I'm now at 20 failures and 42 errors. The fun thing is that the changes are not necessarily complicated, but the effects on tests can be weird (like above). So it's difficult sometimes to tell what is the problem. Now failing tests are mostly in GroupTest (some difference in importing the model, perhaps simply due to changes in the system classes imported) and MooseAlgos, a couple of other packages... If someone knows how to replace the following snipper, it will solve a lot of error tests in MooseAlgos actually. Stream endOfStreamSignal signal -- Simon _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

Reply

Tudor Girba

6 Jun 6 Jun

11:27 a.m.

Hi, Yesterday, Fabrizio did a great job at solving a number of tests, including the MooseAlgos ones (He ported the EndOfStream class from 1.0 to the MooseAlgos-InformationRetrieval package). I also fixed the configuration of glamour and now it properly loads all needed magritte code. I also update the Hudson server to build on Pharo 1.1. There are only 7 failing tests: http://hudson.moosetechnology.org/job/moose-latest-dev/177/testReport/ All in all, pretty smooth transition :). Actually, I would propose to release a 4.1 soon, because there already is a significant difference in speed. Cheers, Doru On 5 Jun 2010, at 00:55, Tudor Girba wrote:

...

Hi, I did a quick tour over the issues: - I renamed versions default11 to default, because default should always point to the latest development configuration, and from now on we move development to Pharo 1.1 - I fixed the Glamour problem, and now all tests are green (with the expected failures) - I also fixed a couple of GroupTests However, I noticed that the GroupTests break because the imported model now contains 42 classes instead of 48. I have no idea why. Cheers, Doru On 4 Jun 2010, at 22:04, Alexandre Bergel wrote:

Good job!! Alexandre On 4 Jun 2010, at 12:38, Simon Denier wrote:

So I know that some of you already started to use Moose under Pharo 1.1, and now it is time to assess the situation. I took the latest Pharo Core on the web 11383. I loaded the latest Pharo Conf 1.1-beta1.10517 Then I loaded default of ConfigurationOfMoose. After loading, the first issue I knew beforehand is that there was a conflicting dependency between the version of MorphTreeWidget loaded by Moose default and the one which now comes by default with Pharo 1.1 I built two new default versions for Glamour and Moose with Pharo1.1 by removing this dependency: (ConfigurationOfMoose project version: 'default11') load should load a working Moose (not tested) Tests got something like 200 errors, however most of them seem to have common roots (meaning fix one problem and you fix dozens of tests). There seem to be nothing really serious, just fixing changes in API and also compiler semantics, with strange things around. 1) For example, the following snippet of code is valid (I didn't even know that!) but the semantic has changed: [ :i ] value: 1 -> returns 1 under Pharo 1.0, and nil under Pharo 1.1 2) Also it seems that the compiler now considers _ as a message send. Just try MSEUtilities signatureFromSmalltalkSelector: #_ and you get a nice primitive failed. Of course the importer did not like it :) I just replaced _ with := 3) fix deprecation asSortedArray -> asArray sort in Hashtable 4) One fix NOT commited in Glamour: Message send autoDeselect: produces DNU, rewritten as autoDeselection: in GLMMorphicRenderer>>treeMorphFor:and: I started to do that, I'm now at 20 failures and 42 errors. The fun thing is that the changes are not necessarily complicated, but the effects on tests can be weird (like above). So it's difficult sometimes to tell what is the problem. Now failing tests are mostly in GroupTest (some difference in importing the model, perhaps simply due to changes in the system classes imported) and MooseAlgos, a couple of other packages... If someone knows how to replace the following snipper, it will solve a lot of error tests in MooseAlgos actually. Stream endOfStreamSignal signal -- Simon _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

-- www.tudorgirba.com "One cannot do more than one can do."

Reply

Simon Denier

7 Jun 7 Jun

11:28 a.m.

On 6 juin 2010, at 11:27, Tudor Girba wrote:

...

Hi, Yesterday, Fabrizio did a great job at solving a number of tests, including the MooseAlgos ones (He ported the EndOfStream class from 1.0 to the MooseAlgos-InformationRetrieval package).

Thanks I notice that two versions of the Glamour config have been saved in the Moose repository. Is this wanted?

...

I also fixed the configuration of glamour and now it properly loads all needed magritte code. I also update the Hudson server to build on Pharo 1.1. There are only 7 failing tests: http://hudson.moosetechnology.org/job/moose-latest-dev/177/testReport/ All in all, pretty smooth transition :). Actually, I would propose to release a 4.1 soon, because there already is a significant difference in speed. Cheers, Doru On 5 Jun 2010, at 00:55, Tudor Girba wrote:

Hi, I did a quick tour over the issues: - I renamed versions default11 to default, because default should always point to the latest development configuration, and from now on we move development to Pharo 1.1 - I fixed the Glamour problem, and now all tests are green (with the expected failures) - I also fixed a couple of GroupTests However, I noticed that the GroupTests break because the imported model now contains 42 classes instead of 48. I have no idea why. Cheers, Doru On 4 Jun 2010, at 22:04, Alexandre Bergel wrote:

Good job!! Alexandre On 4 Jun 2010, at 12:38, Simon Denier wrote:

So I know that some of you already started to use Moose under Pharo 1.1, and now it is time to assess the situation. I took the latest Pharo Core on the web 11383. I loaded the latest Pharo Conf 1.1-beta1.10517 Then I loaded default of ConfigurationOfMoose. After loading, the first issue I knew beforehand is that there was a conflicting dependency between the version of MorphTreeWidget loaded by Moose default and the one which now comes by default with Pharo 1.1 I built two new default versions for Glamour and Moose with Pharo1.1 by removing this dependency: (ConfigurationOfMoose project version: 'default11') load should load a working Moose (not tested) Tests got something like 200 errors, however most of them seem to have common roots (meaning fix one problem and you fix dozens of tests). There seem to be nothing really serious, just fixing changes in API and also compiler semantics, with strange things around. 1) For example, the following snippet of code is valid (I didn't even know that!) but the semantic has changed: [ :i ] value: 1 -> returns 1 under Pharo 1.0, and nil under Pharo 1.1 2) Also it seems that the compiler now considers _ as a message send. Just try MSEUtilities signatureFromSmalltalkSelector: #_ and you get a nice primitive failed. Of course the importer did not like it :) I just replaced _ with := 3) fix deprecation asSortedArray -> asArray sort in Hashtable 4) One fix NOT commited in Glamour: Message send autoDeselect: produces DNU, rewritten as autoDeselection: in GLMMorphicRenderer>>treeMorphFor:and: I started to do that, I'm now at 20 failures and 42 errors. The fun thing is that the changes are not necessarily complicated, but the effects on tests can be weird (like above). So it's difficult sometimes to tell what is the problem. Now failing tests are mostly in GroupTest (some difference in importing the model, perhaps simply due to changes in the system classes imported) and MooseAlgos, a couple of other packages... If someone knows how to replace the following snipper, it will solve a lot of error tests in MooseAlgos actually. Stream endOfStreamSignal signal -- Simon _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

-- www.tudorgirba.com "One cannot do more than one can do." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- Simon

Reply