Call for testers of a faster MC

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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 <[hidden email]
> > 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
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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!
>  

> 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.
>  

> 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.
>
>  

> 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!
>  

> 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.
>
>
>  

> Stéphane Ducasse wrote:
>> 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!
>>
> 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.
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> 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'.

>
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Ok it works
>
>  
>> Preferences enable: #allowBlockArgumentAssignment.
>> Preferences disable: #raiseDepreciatedWarnings.
>>
>> Installer upgrade upgrade.
>> Installer install: 'UpgradeMonticelloBootstrap'.
>>    
>
> Now which version is loaded....?
>
>
>  

> 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.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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 <[hidden email]
> > 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
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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.
>
>
>  

> 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
>  

>> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project