thanks mariano and kirtai. On Jul 16, 2009, at 10:39 PM, Mariano Martinez Peck wrote:

Stef....Kirtai was looking you in IRC

[16:39] <Kirtai> is stephanes problem with loading mc due to non- atomicloading changing a method then using it before another method it depends on is compiled? [17:06] <marianopeck> Kirtai: stef isn't in IRC most of the time [17:07] <marianopeck> it would be better to send him an email [17:07] <Kirtai> I'm just lookin at the problem [17:07] <Kirtai> seems that MCMethodDefinition>>actualClass is calling MCMethodDefinition>>actualClassIn: after actualClass is recompiled but before actualClassIn: is installed

argh!

Mariano

On Thu, Jul 16, 2009 at 7:33 PM, Stéphane Ducasse <stephane.ducasse@inria.fr

...

wrote: apparently the UI gets stuck during the cleaning phase when I try to load moose :(

On Jul 16, 2009, at 8:49 PM, Stéphane Ducasse wrote:

...

Hi guys

thanks to matthew I finally understood his optimization. The entry point is MCPackage>>snapshot

I published a slice in the inbox. If you can try it, look at the changes and let me know.

I did some experiences and could load moose which start to be complex but I may have done some mistakes.

Stef

PS: having real package will really make all that much faster. I will regularly to the TaskForces the code for a new package class.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Douglas Brebner wrote:

Stephane, if you set the following preferences raiseDepreciatedWarnings=disabled (causes problems due to the Author initials depreciation) allowBlockArgumentAssignment=enabled (Breaks a method called #unloadTraits. A convenience method that isn't used and isn't in the image after the install is finished)

then you can load MC 1.5 (with updated Installer) by using Keiths LPF script.

After setting the prefs, do the following:

HTTPSocket httpFileIn: 'ftp.squeak.org/3.11/scripts/LPF.st'.

and it should just work.

I know it's bad form to reply to my own mail but there's minor breakage in that ProjectLauncher>>#startUpAfterLogin throws a DNU by sending #setupFlaps when you first click on the world after restarting the image.

Keith Hodges wrote:

Stef if you want to load the source code direct from an mcz, Installer can do it as in the following example.

scriptUpgradeMonticelloBootstrap

(Installer url: 'http://www.squeaksource.com/mc/PackageInfo-Base') fileInSource. (Installer url: 'http://www.squeaksource.com/mc/System-PasswordManager') fileInSource. (Installer url: 'http://www.squeaksource.com/mc/', self class configMCVersion,'.mcz') fileInSource.

This is available in Installer install: 'UpgradeMonticelloBootstrap'.

Damien loads MC1.5 via...

Installer install: 'LevelPlayingField'

this doesnt include Installer-Launcher which causes the above problem.

I was able to load it in a 10379 image after upgrading Installer. Preferences enable: #allowBlockArgumentAssignment. Preferences disable: #raiseDepreciatedWarnings. Installer upgrade upgrade. Installer install: 'UpgradeMonticelloBootstrap'. Thanks to Keith :)

Stéphane Ducasse wrote:

Ok it works

...

Preferences enable: #allowBlockArgumentAssignment. Preferences disable: #raiseDepreciatedWarnings.

Installer upgrade upgrade. Installer install: 'UpgradeMonticelloBootstrap'.

Now which version is loaded....?

This should install the latest version of Installer, PackageInfo and Monticello 1.5 You should get:

From http://www.squeaksource.com/Installer Installer-Core-kph.321.mcz Installer-Scripts-kph.16.mcz Installer-Formats-kph.4.mcz

From http://www.squeaksource.com/mc/ PackageInfo-Base-mtf.70.mcz System-PasswordManager-kph.2.mcz (a dependency) Monticello.impl-kph.643.mcz

I tried this on the 10373 download and the latest 10379 images and it just works.

...

Stef if you want to load the source code direct from an mcz, Installer can do it as in the following example.

I loaded HTTPSocket httpFileIn: 'ftp.squeak.org/3.11/scripts/LPF.st'. but I could not find that method scriptUpgradeMonticelloBootstrap then I tried

(Installer url: 'http://www.squeaksource.com/mc/PackageInfo-Base') fileInSource.

broke on url: :( Then I did ScriptLoader new installingInstaller

(Installer url: 'http://www.squeaksource.com/mc/PackageInfo-Base') fileInSource.

broke MCZInstaller class Then I tried Installer install: 'LevelPlayingField' and it broke on me InstallerScripts..... So sorry but I do not suceed to load MC1.5 just to check why what I did does not work. I'm too stupid. SO I trashed my image and the time I lost too.

scriptUpgradeMonticelloBootstrap

(Installer url: 'http://www.squeaksource.com/mc/PackageInfo-Base') fileInSource. (Installer url: 'http://www.squeaksource.com/mc/System-PasswordManager') fileInSource. (Installer url: 'http://www.squeaksource.com/mc/', self class configMCVersion,'.mcz') fileInSource.

This is available in Installer install: 'UpgradeMonticelloBootstrap'.

Damien loads MC1.5 via...

Installer install: 'LevelPlayingField'

this doesnt include Installer-Launcher which causes the above problem.

Keith

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

raiseDepreciatedWarnings=disabled (causes problems due to the Author initials depreciation) allowBlockArgumentAssignment=enabled (Breaks a method called #unloadTraits. A convenience method that isn't used and isn't in the image after the install is finished)

then you can load MC 1.5 (with updated Installer) by using Keiths LPF script.

After setting the prefs, do the following:

HTTPSocket httpFileIn: 'ftp.squeak.org/3.11/scripts/LPF.st'.

I did that but it does not load MC1.5 I getting confused

I checked a bit but actualClassIn: in MC1.6 depends on MCMethodDefinition having theClass as instanceVariable. The results of this experience is clearly showing me that merging between fork is nearly impossible. I already lost some days on that issues and I think that we will stay with a slow MC for now. Stef On Jul 16, 2009, at 10:39 PM, Mariano Martinez Peck wrote:

Stef....Kirtai was looking you in IRC

[16:39] <Kirtai> is stephanes problem with loading mc due to non- atomicloading changing a method then using it before another method it depends on is compiled? [17:06] <marianopeck> Kirtai: stef isn't in IRC most of the time [17:07] <marianopeck> it would be better to send him an email [17:07] <Kirtai> I'm just lookin at the problem [17:07] <Kirtai> seems that MCMethodDefinition>>actualClass is calling MCMethodDefinition>>actualClassIn: after actualClass is recompiled but before actualClassIn: is installed

Mariano

On Thu, Jul 16, 2009 at 7:33 PM, Stéphane Ducasse <stephane.ducasse@inria.fr

...

wrote: apparently the UI gets stuck during the cleaning phase when I try to load moose :(

On Jul 16, 2009, at 8:49 PM, Stéphane Ducasse wrote:

...

Hi guys

thanks to matthew I finally understood his optimization. The entry point is MCPackage>>snapshot

I published a slice in the inbox. If you can try it, look at the changes and let me know.

I did some experiences and could load moose which start to be complex but I may have done some mistakes.

Stef

PS: having real package will really make all that much faster. I will regularly to the TaskForces the code for a new package class.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

The problem doug is that it is unclear if all the features are needed and what is the status of the implementation. I do not know what are orphanage, scripts, upgrade upgrade, file....... We just did not update to MC1.5 because we are idiot or blind. First we were focusing on something else and also when something is working for you then it is difficult to try something new and risky since it can stall the complete process. I do not even know what LFP is doing in our back. Now the key point is that if somebody in the pharo community stand up and take the **huge** and painful job to have a **real** look at MC1.5/1.6 and to be here as a fireman then there is a chance that we use it. Not just saying yes it works (which is already a challenge as I noticed it these days). Stef

Stéphane Ducasse wrote:

...

I checked a bit but actualClassIn: in MC1.6 depends on MCMethodDefinition having theClass as instanceVariable.

The results of this experience is clearly showing me that merging between fork is nearly impossible. I already lost some days on that issues and I think that we will stay with a slow MC for now.

Isn't the version loaded by the following code from my other mail the already merged version of 1.5/1.6? (I believe that 1.6 is just 1.5 with atomic loading enabled)

Preferences enable: #allowBlockArgumentAssignment. Preferences disable: #raiseDepreciatedWarnings. Installer upgrade upgrade. Installer install: 'UpgradeMonticelloBootstrap'.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Jul 17, 2009, at 6:23 PM, Douglas Brebner wrote:

Stéphane Ducasse wrote:

...

The problem doug is that it is unclear if all the features are needed and what is the status of the implementation. I do not know what are orphanage, scripts, upgrade upgrade, file.......

Well, it was my understanding that this version of MC, PackageInfo and Installer were the ones which were intended to become the portable versions that all Squeak forks would use.

Well yes this is the intention of keith. It was a bold challenge. Now if you look at Installer you get a lot of things you do not need.

...

We just did not update to MC1.5 because we are idiot or blind.

I never claimed you were :(

I did not mean you did :) this was a subliminal message to others :)

...

First we were focusing on something else and also when something is working for you then it is difficult to try something new and risky since it can stall the complete process. I do not even know what LFP is doing in our back.

As I understand it, this approach only upgrades Installer, PackaageInfo and Monticello, it doesn't include the rest of LPF.

...

Now the key point is that if somebody in the pharo community stand up and take the **huge** and painful job to have a **real** look at MC1.5/1.6 and to be here as a fireman then there is a chance that we use it. Not just saying yes it works (which is already a challenge as I noticed it these days).

Yes, but my response was only to do with solving the the loading problem you had. Not that every MC problem had been solved :)

;) Anyway this is a long way to go but we should go there step by step. Welcome to pharo.

...

Stef

...

Stéphane Ducasse wrote:

...

I checked a bit but actualClassIn: in MC1.6 depends on MCMethodDefinition having theClass as instanceVariable.

The results of this experience is clearly showing me that merging between fork is nearly impossible. I already lost some days on that issues and I think that we will stay with a slow MC for now.

Isn't the version loaded by the following code from my other mail the already merged version of 1.5/1.6? (I believe that 1.6 is just 1.5 with atomic loading enabled)

Preferences enable: #allowBlockArgumentAssignment. Preferences disable: #raiseDepreciatedWarnings. Installer upgrade upgrade. Installer install: 'UpgradeMonticelloBootstrap'.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

...

...

Well yes this is the intention of keith. It was a bold challenge. Now if you look at Installer you get a lot of things you do not need.

True, but this was just an attempt to get MC loaded. I'd expect quite a lot could be trimmed.

I know and this was nice from you. Now you may also have a look at a nice project named gofer on squeaksource :) soon available ScriptLoader gofer :)

...

...

...

Now the key point is that if somebody in the pharo community stand up and take the **huge** and painful job to have a **real** look at MC1.5/1.6 and to be here as a fireman then there is a chance that we use it. Not just saying yes it works (which is already a challenge as I noticed it these days). Yes, but my response was only to do with solving the the loading problem you had. Not that every MC problem had been solved :)

;) Anyway this is a long way to go but we should go there step by step. Welcome to pharo.

Thank you :) I've been away from Squeak for a while due to the problems it's had but one of the reasons I came back was seeing what was happening with Pharo :)

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/7/17 Stéphane Ducasse <stephane.ducasse@inria.fr>:

On Jul 17, 2009, at 6:23 PM, Douglas Brebner wrote:

...

Stéphane Ducasse wrote:

...

The problem doug is that it is unclear if all the features are needed and what is the status of the implementation. I do not know what are orphanage, scripts, upgrade upgrade, file.......

Well, it was my understanding that this version of MC, PackageInfo and Installer were the ones which were intended to become the portable versions that all Squeak forks would use.

Well yes this is the intention of keith. It was a bold challenge. Now if you look at Installer you get a lot of things you do not need.

installer is mainly a DSL for installing a stuff. It doesn't implementing a facilities which actually doing the work, just provides you a convenient abstractions for using them. It is generic, and covers multiple ways of installing code into system. Sure, you are free to use just those which is good for you. As to me it is compact enough, to not think about carving out unused things :)

...

...

We just did not update to MC1.5 because we are idiot or blind.

I never claimed you were :(

I did not mean you did :) this was a subliminal message to others :)

...

...

First we were focusing on something else and also when something is working for you then it is difficult to try something new and risky since it can stall the complete process. I do not even know what LFP is doing in our back.

As I understand it, this approach only upgrades Installer, PackaageInfo and Monticello, it doesn't include the rest of LPF.

...

Now the key point is that if somebody in the pharo community stand up and take the **huge** and painful job to have a **real** look at MC1.5/1.6 and to be here as a fireman then there is a chance that we use it. Not just saying yes it works (which is already a challenge as I noticed it these days).

Yes, but my response was only to do with solving the the loading problem you had. Not that every MC problem had been solved :)

;) Anyway this is a long way to go but we should go there step by step. Welcome to pharo.

...

...

Stef

...

Stéphane Ducasse wrote:

...

I checked a bit but actualClassIn: in MC1.6 depends on MCMethodDefinition having theClass as instanceVariable.

The results of this experience is clearly showing me that merging between fork is nearly impossible. I already lost some days on that issues and I think that we will stay with a slow MC for now.

Isn't the version loaded by the following code from my other mail the already merged version of 1.5/1.6? (I believe that 1.6 is just 1.5 with atomic loading enabled)

Preferences enable: #allowBlockArgumentAssignment. Preferences disable: #raiseDepreciatedWarnings. Installer upgrade upgrade. Installer install: 'UpgradeMonticelloBootstrap'.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.

...

installer is mainly a DSL for installing a stuff. It doesn't implementing a facilities which actually doing the work, just provides you a convenient abstractions for using them. It is generic, and covers multiple ways of installing code into system. Sure, you are free to use just those which is good for you. As to me it is compact enough, to not think about carving out unused things :)

I know igor, I probably was aware about it before lot of people. I would not call it compact. Stef

ok

...

That's why the only effective way is to use as is, and contribute to the package in an external repository. If you don't then everyone is stuck with a version that cannot move forward. That's where we were three years ago.

The version in squeaksource.com/mc has moved forward, in the same way as Pharo has unashamedly moved forward. Feel free to adopt squeaksource.com/mc as your own if you want to, I wont be contributing to it for a long long while if ever.

May I invite someone to feel free to maintain the InstallerScripts for loadinging mc1.5 into Pharo, it used to work

Keith

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project