Call for testers of a faster MC

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

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

>
>>
>> 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
> [hidden email]
> 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.

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

>
>>>> 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
> [hidden email]
> 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
>> [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
>

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