MC 1.6 status?

> Hello people,
>
> i'd like to see some answers about the fate of MC 1.6. and its current
> situation.
>
> 1. I think everyone wants to have an atomic loading.
> But according to my knowledge, MC 1.6. has some problems with Traits,
> which prevets us from using it & fully replace the older version.
>
> 2. Besides of that, are there any other reasons to not have it?
>
> So, please, can we disscuss (friendly & constructive), what we might
> need to have it integrated in Squeak and in Pharo, so
> we could benefit from having an atomic loading?
>
>
>

>Hi Igor,
>
>no problem here except from the following issues:
>
>a) I don't even know where/how to load it. There is a bunch of conflicting packages on SqueakSource and zero instructions on what to load from where. Some information would be tremendously helpful.
>
>b) As far as I know nobody is using MC 1.6 at this point (if you do, raise your hand so I can see you). Given the critical nature of Monticello for development I'm not in favor of replacing a working and tested piece of infrastructure without extensive prior testing.
>
>c) It needs to support all the current features of Monticello (i.e., traits) or else it simply isn't fit for the intended purpose.
>
>If we can take care of the above, we can run an experiment like installing MC 1.6 into a 3.10 image and updating all the way through to the current trunk and make sure this works. At that point I would feel a lot more positive about MC 1.6 since what it means is that at least we know we can deal with the stuff that we've already been using.
>
>Cheers,
>  - Andreas
>
>
>Igor Stasenko wrote:
>>Hello people,
>>
>>i'd like to see some answers about the fate of MC 1.6. and its current
>>situation.
>>
>>1. I think everyone wants to have an atomic loading.
>>But according to my knowledge, MC 1.6. has some problems with Traits,
>>which prevets us from using it & fully replace the older version.
>>
>>2. Besides of that, are there any other reasons to not have it?
>>
>>So, please, can we disscuss (friendly & constructive), what we might
>>need to have it integrated in Squeak and in Pharo, so
>>we could benefit from having an atomic loading?

> Mathew Fulmer said yesterday on irc, "mc1.6 worked fine for me. I was using it daily all last year".
> Also regarding loading into trunk:
> "well, hard to say if there have been a bunch of shifts in collections and compiler"
> "may be an issue with traits too"
> "loading kernel won't work with mc1.6, I'm pretty sure. it has traits"
>
> However,  ftp://ftp.squeak.org/3.11/Squeak3.10.2-lpf-atomic/ already has MC 1.6, along with the latest Installer, LPF, and Sake/Packages.
>
> Here's Keith's video from 4 months ago http://www.vimeo.com/groups/squeak/videos/5434330 showing  how to use Sake/Packages to load AND unload Seaside 3.0.
>
> If someone knowledgeable could get the trunk stuff loading into lpf-atomic using Sake/Packages, then we would be positioned to be quantum-leapt into the future.
>
> Ken G. Brown
>
> At 3:05 PM -0700 10/20/09, Andreas Raab apparently wrote:
>> Hi Igor,
>>
>> no problem here except from the following issues:
>>
>> a) I don't even know where/how to load it. There is a bunch of conflicting packages on SqueakSource and zero instructions on what to load from where. Some information would be tremendously helpful.
>>
>> b) As far as I know nobody is using MC 1.6 at this point (if you do, raise your hand so I can see you). Given the critical nature of Monticello for development I'm not in favor of replacing a working and tested piece of infrastructure without extensive prior testing.
>>
>> c) It needs to support all the current features of Monticello (i.e., traits) or else it simply isn't fit for the intended purpose.
>>
>> If we can take care of the above, we can run an experiment like installing MC 1.6 into a 3.10 image and updating all the way through to the current trunk and make sure this works. At that point I would feel a lot more positive about MC 1.6 since what it means is that at least we know we can deal with the stuff that we've already been using.
>>
>> Cheers,
>>  - Andreas
>>
>>
>> Igor Stasenko wrote:
>>> Hello people,
>>>
>>> i'd like to see some answers about the fate of MC 1.6. and its current
>>> situation.
>>>
>>> 1. I think everyone wants to have an atomic loading.
>>> But according to my knowledge, MC 1.6. has some problems with Traits,
>>> which prevets us from using it & fully replace the older version.
>>>
>>> 2. Besides of that, are there any other reasons to not have it?
>>>
>>> So, please, can we disscuss (friendly & constructive), what we might
>>> need to have it integrated in Squeak and in Pharo, so
>>> we could benefit from having an atomic loading?
>
>
>

>Hi Ken -
>
>I gave the image you're pointing to a quick try but there are still some issues with MC 1.6. The biggest one so far is loading ProtoObject subclasses. You can try this if you launch the lpf-atomic image, point it to the trunk and try to merge any of the SUnitGUI versions. It explodes somewhere in SystemEditor.
>
>Outside of that I made quite a bit of progress loading trunk into the lpf-atomic image. Here are the steps if you want to play with it yourself:
>
>* Merge the latest MonticelloConfigurations from the trunk. This will mess up a bit of the structure but since the categories are changed but it'll work okay.
>
>* Hack PackageLoader2>>loadWithNameLike: to avoid nuking Monticello and PackageInfo:
>
>  ((baseName beginsWith: 'Monticello')
>     or:[baseName beginsWith: 'PackageInfo']) ifTrue:[^self].
>
>This makes PackageLoader ignore any MC/PI related packages. If you want to, you can also add SUnitGUI which gets you a little further later on (but not very much).
>
>* Rename MethodContext>>receiverMap to closureOrNil. MC 1.6 does not deal with context reshape (not really a surprise):
>  MethodContext instVarNames at: 2 put: 'closureOrNil'.
>
>* Launch the updater via
>  MCMCMUpdater updateFromRepositories: #('http://source.squeak.org/trunk').
>
>As it is loading, it'll pop up various requests for resolving conflicts; always choose "rest remote" and then "merge". After excluding SUnitGUI I've been able to load it up until the beginning of the closure bootstrap and then it explodes in a Kernel version with the same error that SUnitGUI blows up (in an undebuggable state so your image is toast at that point).
>
>That's how far things are at this point. If you can fix the MC problems we should be getting further.
>
>Cheers,
>  - Andreas
>
>Ken G. Brown wrote:
>>Mathew Fulmer said yesterday on irc, "mc1.6 worked fine for me. I was using it daily all last year".
>>Also regarding loading into trunk:
>>"well, hard to say if there have been a bunch of shifts in collections and compiler"
>>"may be an issue with traits too"
>>"loading kernel won't work with mc1.6, I'm pretty sure. it has traits"
>>
>>However,  ftp://ftp.squeak.org/3.11/Squeak3.10.2-lpf-atomic/ already has MC 1.6, along with the latest Installer, LPF, and Sake/Packages.
>>
>>Here's Keith's video from 4 months ago http://www.vimeo.com/groups/squeak/videos/5434330 showing  how to use Sake/Packages to load AND unload Seaside 3.0.
>>
>>If someone knowledgeable could get the trunk stuff loading into lpf-atomic using Sake/Packages, then we would be positioned to be quantum-leapt into the future.
>>
>>Ken G. Brown
>>
>>At 3:05 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>Hi Igor,
>>>
>>>no problem here except from the following issues:
>>>
>>>a) I don't even know where/how to load it. There is a bunch of conflicting packages on SqueakSource and zero instructions on what to load from where. Some information would be tremendously helpful.
>>>
>>>b) As far as I know nobody is using MC 1.6 at this point (if you do, raise your hand so I can see you). Given the critical nature of Monticello for development I'm not in favor of replacing a working and tested piece of infrastructure without extensive prior testing.
>>>
>>>c) It needs to support all the current features of Monticello (i.e., traits) or else it simply isn't fit for the intended purpose.
>>>
>>>If we can take care of the above, we can run an experiment like installing MC 1.6 into a 3.10 image and updating all the way through to the current trunk and make sure this works. At that point I would feel a lot more positive about MC 1.6 since what it means is that at least we know we can deal with the stuff that we've already been using.
>>>
>>>Cheers,
>>> - Andreas
>>>
>>>
>>>Igor Stasenko wrote:
>>>>Hello people,
>>>>
>>>>i'd like to see some answers about the fate of MC 1.6. and its current
>>>>situation.
>>>>
>>>>1. I think everyone wants to have an atomic loading.
>>>>But according to my knowledge, MC 1.6. has some problems with Traits,
>>>>which prevets us from using it & fully replace the older version.
>>>>
>>>>2. Besides of that, are there any other reasons to not have it?
>>>>
>>>>So, please, can we disscuss (friendly & constructive), what we might
>>>>need to have it integrated in Squeak and in Pharo, so
>>>>we could benefit from having an atomic loading?

> Ken G. Brown
>
> At 7:57 PM -0700 10/20/09, Andreas Raab apparently wrote:
>> Hi Ken -
>>
>> I gave the image you're pointing to a quick try but there are still some issues with MC 1.6. The biggest one so far is loading ProtoObject subclasses. You can try this if you launch the lpf-atomic image, point it to the trunk and try to merge any of the SUnitGUI versions. It explodes somewhere in SystemEditor.
>>
>> Outside of that I made quite a bit of progress loading trunk into the lpf-atomic image. Here are the steps if you want to play with it yourself:
>>
>> * Merge the latest MonticelloConfigurations from the trunk. This will mess up a bit of the structure but since the categories are changed but it'll work okay.
>>
>> * Hack PackageLoader2>>loadWithNameLike: to avoid nuking Monticello and PackageInfo:
>>
>>  ((baseName beginsWith: 'Monticello')
>>     or:[baseName beginsWith: 'PackageInfo']) ifTrue:[^self].
>>
>> This makes PackageLoader ignore any MC/PI related packages. If you want to, you can also add SUnitGUI which gets you a little further later on (but not very much).
>>
>> * Rename MethodContext>>receiverMap to closureOrNil. MC 1.6 does not deal with context reshape (not really a surprise):
>>  MethodContext instVarNames at: 2 put: 'closureOrNil'.
>>
>> * Launch the updater via
>>  MCMCMUpdater updateFromRepositories: #('http://source.squeak.org/trunk').
>>
>> As it is loading, it'll pop up various requests for resolving conflicts; always choose "rest remote" and then "merge". After excluding SUnitGUI I've been able to load it up until the beginning of the closure bootstrap and then it explodes in a Kernel version with the same error that SUnitGUI blows up (in an undebuggable state so your image is toast at that point).
>>
>> That's how far things are at this point. If you can fix the MC problems we should be getting further.
>>
>> Cheers,
>>  - Andreas
>>
>> Ken G. Brown wrote:
>>> Mathew Fulmer said yesterday on irc, "mc1.6 worked fine for me. I was using it daily all last year".
>>> Also regarding loading into trunk:
>>> "well, hard to say if there have been a bunch of shifts in collections and compiler"
>>> "may be an issue with traits too"
>>> "loading kernel won't work with mc1.6, I'm pretty sure. it has traits"
>>>
>>> However,  ftp://ftp.squeak.org/3.11/Squeak3.10.2-lpf-atomic/ already has MC 1.6, along with the latest Installer, LPF, and Sake/Packages.
>>>
>>> Here's Keith's video from 4 months ago http://www.vimeo.com/groups/squeak/videos/5434330 showing  how to use Sake/Packages to load AND unload Seaside 3.0.
>>>
>>> If someone knowledgeable could get the trunk stuff loading into lpf-atomic using Sake/Packages, then we would be positioned to be quantum-leapt into the future.
>>>
>>> Ken G. Brown
>>>
>>> At 3:05 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>> Hi Igor,
>>>>
>>>> no problem here except from the following issues:
>>>>
>>>> a) I don't even know where/how to load it. There is a bunch of conflicting packages on SqueakSource and zero instructions on what to load from where. Some information would be tremendously helpful.
>>>>
>>>> b) As far as I know nobody is using MC 1.6 at this point (if you do, raise your hand so I can see you). Given the critical nature of Monticello for development I'm not in favor of replacing a working and tested piece of infrastructure without extensive prior testing.
>>>>
>>>> c) It needs to support all the current features of Monticello (i.e., traits) or else it simply isn't fit for the intended purpose.
>>>>
>>>> If we can take care of the above, we can run an experiment like installing MC 1.6 into a 3.10 image and updating all the way through to the current trunk and make sure this works. At that point I would feel a lot more positive about MC 1.6 since what it means is that at least we know we can deal with the stuff that we've already been using.
>>>>
>>>> Cheers,
>>>> - Andreas
>>>>
>>>>
>>>> Igor Stasenko wrote:
>>>>> Hello people,
>>>>>
>>>>> i'd like to see some answers about the fate of MC 1.6. and its current
>>>>> situation.
>>>>>
>>>>> 1. I think everyone wants to have an atomic loading.
>>>>> But according to my knowledge, MC 1.6. has some problems with Traits,
>>>>> which prevets us from using it & fully replace the older version.
>>>>>
>>>>> 2. Besides of that, are there any other reasons to not have it?
>>>>>
>>>>> So, please, can we disscuss (friendly & constructive), what we might
>>>>> need to have it integrated in Squeak and in Pharo, so
>>>>> we could benefit from having an atomic loading?
>
>
>

>Ken G. Brown wrote:
>>While following your instructions, when executing MCMcmUpdater updateFromRepositories: #('http://source.squeak.org/trunk').
>>(with lowercase 'cm' typo fixed), I get an error could not find Installer-Core-edc.83. Perhaps Installer stuff should be bypassed too in PackageLoader2?
>
>Try adding the either the 3.10 or the 3.9 repository to all packages with ancestor versions that cannot be found (you need to both add the repository and attach the repository to the package version). That should do the trick.
>
>(I got lucky because the version was in my local package cache)
>
>Cheers,
>  - Andreas
>
>>Ken G. Brown
>>
>>At 7:57 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>Hi Ken -
>>>
>>>I gave the image you're pointing to a quick try but there are still some issues with MC 1.6. The biggest one so far is loading ProtoObject subclasses. You can try this if you launch the lpf-atomic image, point it to the trunk and try to merge any of the SUnitGUI versions. It explodes somewhere in SystemEditor.
>>>
>>>Outside of that I made quite a bit of progress loading trunk into the lpf-atomic image. Here are the steps if you want to play with it yourself:
>>>
>>>* Merge the latest MonticelloConfigurations from the trunk. This will mess up a bit of the structure but since the categories are changed but it'll work okay.
>>>
>>>* Hack PackageLoader2>>loadWithNameLike: to avoid nuking Monticello and PackageInfo:
>>>
>>> ((baseName beginsWith: 'Monticello')
>>>    or:[baseName beginsWith: 'PackageInfo']) ifTrue:[^self].
>>>
>>>This makes PackageLoader ignore any MC/PI related packages. If you want to, you can also add SUnitGUI which gets you a little further later on (but not very much).
>>>
>>>* Rename MethodContext>>receiverMap to closureOrNil. MC 1.6 does not deal with context reshape (not really a surprise):
>>> MethodContext instVarNames at: 2 put: 'closureOrNil'.
>>>
>>>* Launch the updater via
>>> MCMCMUpdater updateFromRepositories: #('http://source.squeak.org/trunk').
>>>
>>>As it is loading, it'll pop up various requests for resolving conflicts; always choose "rest remote" and then "merge". After excluding SUnitGUI I've been able to load it up until the beginning of the closure bootstrap and then it explodes in a Kernel version with the same error that SUnitGUI blows up (in an undebuggable state so your image is toast at that point).
>>>
>>>That's how far things are at this point. If you can fix the MC problems we should be getting further.
>>>
>>>Cheers,
>>> - Andreas
>>>
>>>Ken G. Brown wrote:
>>>>Mathew Fulmer said yesterday on irc, "mc1.6 worked fine for me. I was using it daily all last year".
>>>>Also regarding loading into trunk:
>>>>"well, hard to say if there have been a bunch of shifts in collections and compiler"
>>>>"may be an issue with traits too"
>>>>"loading kernel won't work with mc1.6, I'm pretty sure. it has traits"
>>>>
>>>>However,  ftp://ftp.squeak.org/3.11/Squeak3.10.2-lpf-atomic/ already has MC 1.6, along with the latest Installer, LPF, and Sake/Packages.
>>>>
>>>>Here's Keith's video from 4 months ago http://www.vimeo.com/groups/squeak/videos/5434330 showing  how to use Sake/Packages to load AND unload Seaside 3.0.
>>>>
>>>>If someone knowledgeable could get the trunk stuff loading into lpf-atomic using Sake/Packages, then we would be positioned to be quantum-leapt into the future.
>>>>
>>>>Ken G. Brown
>>>>
>>>>At 3:05 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>>>Hi Igor,
>>>>>
>>>>>no problem here except from the following issues:
>>>>>
>>>>>a) I don't even know where/how to load it. There is a bunch of conflicting packages on SqueakSource and zero instructions on what to load from where. Some information would be tremendously helpful.
>>>>>
>>>>>b) As far as I know nobody is using MC 1.6 at this point (if you do, raise your hand so I can see you). Given the critical nature of Monticello for development I'm not in favor of replacing a working and tested piece of infrastructure without extensive prior testing.
>>>>>
>>>>>c) It needs to support all the current features of Monticello (i.e., traits) or else it simply isn't fit for the intended purpose.
>>>>>
>>>>>If we can take care of the above, we can run an experiment like installing MC 1.6 into a 3.10 image and updating all the way through to the current trunk and make sure this works. At that point I would feel a lot more positive about MC 1.6 since what it means is that at least we know we can deal with the stuff that we've already been using.
>>>>>
>>>>>Cheers,
>>>>>- Andreas
>>>>>
>>>>>
>>>>>Igor Stasenko wrote:
>>>>>>Hello people,
>>>>>>
>>>>>>i'd like to see some answers about the fate of MC 1.6. and its current
>>>>>>situation.
>>>>>>
>>>>>>1. I think everyone wants to have an atomic loading.
>>>>>>But according to my knowledge, MC 1.6. has some problems with Traits,
>>>>>>which prevets us from using it & fully replace the older version.
>>>>>>
>>>>>>2. Besides of that, are there any other reasons to not have it?
>>>>>>
>>>>>>So, please, can we disscuss (friendly & constructive), what we might
>>>>>>need to have it integrated in Squeak and in Pharo, so
>>>>>>we could benefit from having an atomic loading?

>
> Ken G. Brown
>
> At 8:53 PM -0700 10/20/09, Andreas Raab apparently wrote:
>> Ken G. Brown wrote:
>>> While following your instructions, when executing MCMcmUpdater updateFromRepositories: #('http://source.squeak.org/trunk').
>>> (with lowercase 'cm' typo fixed), I get an error could not find Installer-Core-edc.83. Perhaps Installer stuff should be bypassed too in PackageLoader2?
>> Try adding the either the 3.10 or the 3.9 repository to all packages with ancestor versions that cannot be found (you need to both add the repository and attach the repository to the package version). That should do the trick.
>>
>> (I got lucky because the version was in my local package cache)
>>
>> Cheers,
>>  - Andreas
>>
>>> Ken G. Brown
>>>
>>> At 7:57 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>> Hi Ken -
>>>>
>>>> I gave the image you're pointing to a quick try but there are still some issues with MC 1.6. The biggest one so far is loading ProtoObject subclasses. You can try this if you launch the lpf-atomic image, point it to the trunk and try to merge any of the SUnitGUI versions. It explodes somewhere in SystemEditor.
>>>>
>>>> Outside of that I made quite a bit of progress loading trunk into the lpf-atomic image. Here are the steps if you want to play with it yourself:
>>>>
>>>> * Merge the latest MonticelloConfigurations from the trunk. This will mess up a bit of the structure but since the categories are changed but it'll work okay.
>>>>
>>>> * Hack PackageLoader2>>loadWithNameLike: to avoid nuking Monticello and PackageInfo:
>>>>
>>>> ((baseName beginsWith: 'Monticello')
>>>>    or:[baseName beginsWith: 'PackageInfo']) ifTrue:[^self].
>>>>
>>>> This makes PackageLoader ignore any MC/PI related packages. If you want to, you can also add SUnitGUI which gets you a little further later on (but not very much).
>>>>
>>>> * Rename MethodContext>>receiverMap to closureOrNil. MC 1.6 does not deal with context reshape (not really a surprise):
>>>> MethodContext instVarNames at: 2 put: 'closureOrNil'.
>>>>
>>>> * Launch the updater via
>>>> MCMCMUpdater updateFromRepositories: #('http://source.squeak.org/trunk').
>>>>
>>>> As it is loading, it'll pop up various requests for resolving conflicts; always choose "rest remote" and then "merge". After excluding SUnitGUI I've been able to load it up until the beginning of the closure bootstrap and then it explodes in a Kernel version with the same error that SUnitGUI blows up (in an undebuggable state so your image is toast at that point).
>>>>
>>>> That's how far things are at this point. If you can fix the MC problems we should be getting further.
>>>>
>>>> Cheers,
>>>> - Andreas
>>>>
>>>> Ken G. Brown wrote:
>>>>> Mathew Fulmer said yesterday on irc, "mc1.6 worked fine for me. I was using it daily all last year".
>>>>> Also regarding loading into trunk:
>>>>> "well, hard to say if there have been a bunch of shifts in collections and compiler"
>>>>> "may be an issue with traits too"
>>>>> "loading kernel won't work with mc1.6, I'm pretty sure. it has traits"
>>>>>
>>>>> However,  ftp://ftp.squeak.org/3.11/Squeak3.10.2-lpf-atomic/ already has MC 1.6, along with the latest Installer, LPF, and Sake/Packages.
>>>>>
>>>>> Here's Keith's video from 4 months ago http://www.vimeo.com/groups/squeak/videos/5434330 showing  how to use Sake/Packages to load AND unload Seaside 3.0.
>>>>>
>>>>> If someone knowledgeable could get the trunk stuff loading into lpf-atomic using Sake/Packages, then we would be positioned to be quantum-leapt into the future.
>>>>>
>>>>> Ken G. Brown
>>>>>
>>>>> At 3:05 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>>>> Hi Igor,
>>>>>>
>>>>>> no problem here except from the following issues:
>>>>>>
>>>>>> a) I don't even know where/how to load it. There is a bunch of conflicting packages on SqueakSource and zero instructions on what to load from where. Some information would be tremendously helpful.
>>>>>>
>>>>>> b) As far as I know nobody is using MC 1.6 at this point (if you do, raise your hand so I can see you). Given the critical nature of Monticello for development I'm not in favor of replacing a working and tested piece of infrastructure without extensive prior testing.
>>>>>>
>>>>>> c) It needs to support all the current features of Monticello (i.e., traits) or else it simply isn't fit for the intended purpose.
>>>>>>
>>>>>> If we can take care of the above, we can run an experiment like installing MC 1.6 into a 3.10 image and updating all the way through to the current trunk and make sure this works. At that point I would feel a lot more positive about MC 1.6 since what it means is that at least we know we can deal with the stuff that we've already been using.
>>>>>>
>>>>>> Cheers,
>>>>>> - Andreas
>>>>>>
>>>>>>
>>>>>> Igor Stasenko wrote:
>>>>>>> Hello people,
>>>>>>>
>>>>>>> i'd like to see some answers about the fate of MC 1.6. and its current
>>>>>>> situation.
>>>>>>>
>>>>>>> 1. I think everyone wants to have an atomic loading.
>>>>>>> But according to my knowledge, MC 1.6. has some problems with Traits,
>>>>>>> which prevets us from using it & fully replace the older version.
>>>>>>>
>>>>>>> 2. Besides of that, are there any other reasons to not have it?
>>>>>>>
>>>>>>> So, please, can we disscuss (friendly & constructive), what we might
>>>>>>> need to have it integrated in Squeak and in Pharo, so
>>>>>>> we could benefit from having an atomic loading?
>
>
>

>Ken G. Brown wrote:
>>Seems like it would be good to bypass Installer stuff since the latest Installer is already in the lpf-atomic image, how would you do that?
>>It does not work to hack PackageLoader2>>loadWithNameLike: to avoid Installer-Core'.
>
>There is no need to. The updater uses merges which means that any newer versions you have won't be nuked, any local modifications that you have will be preserved. For Installer-Core (which you can merge manually if you want to see the differences) there are only two methods that are different and the differences are pretty much irrelevant. That's what is powerful about updating from the trunk - you *can* maintain your own versions of packages and merge in only the new stuff from the trunk repository.
>
>>It's good to see you having a look at using MC 1.6. Might not take much for someone to fix the outstanding issues if they know what they are doing.
>
>To be very clear, that someone won't be me. I was only interested to find out if MC 1.6 looks ready for prime time or not. Trying to load the trunk is a good reality check because it does various "interesting" changes.
>
>Cheers,
>  - Andreas
>
>>
>>Ken G. Brown
>>
>>At 8:53 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>Ken G. Brown wrote:
>>>>While following your instructions, when executing MCMcmUpdater updateFromRepositories: #('http://source.squeak.org/trunk').
>>>>(with lowercase 'cm' typo fixed), I get an error could not find Installer-Core-edc.83. Perhaps Installer stuff should be bypassed too in PackageLoader2?
>>>Try adding the either the 3.10 or the 3.9 repository to all packages with ancestor versions that cannot be found (you need to both add the repository and attach the repository to the package version). That should do the trick.
>>>
>>>(I got lucky because the version was in my local package cache)
>>>
>>>Cheers,
>>> - Andreas
>>>
>>>>Ken G. Brown
>>>>
>>>>At 7:57 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>>>Hi Ken -
>>>>>
>>>>>I gave the image you're pointing to a quick try but there are still some issues with MC 1.6. The biggest one so far is loading ProtoObject subclasses. You can try this if you launch the lpf-atomic image, point it to the trunk and try to merge any of the SUnitGUI versions. It explodes somewhere in SystemEditor.
>>>>>
>>>>>Outside of that I made quite a bit of progress loading trunk into the lpf-atomic image. Here are the steps if you want to play with it yourself:
>>>>>
>>>>>* Merge the latest MonticelloConfigurations from the trunk. This will mess up a bit of the structure but since the categories are changed but it'll work okay.
>>>>>
>>>>>* Hack PackageLoader2>>loadWithNameLike: to avoid nuking Monticello and PackageInfo:
>>>>>
>>>>>((baseName beginsWith: 'Monticello')
>>>>>   or:[baseName beginsWith: 'PackageInfo']) ifTrue:[^self].
>>>>>
>>>>>This makes PackageLoader ignore any MC/PI related packages. If you want to, you can also add SUnitGUI which gets you a little further later on (but not very much).
>>>>>
>>>>>* Rename MethodContext>>receiverMap to closureOrNil. MC 1.6 does not deal with context reshape (not really a surprise):
>>>>>MethodContext instVarNames at: 2 put: 'closureOrNil'.
>>>>>
>>>>>* Launch the updater via
>>>>>MCMCMUpdater updateFromRepositories: #('http://source.squeak.org/trunk').
>>>>>
>>>>>As it is loading, it'll pop up various requests for resolving conflicts; always choose "rest remote" and then "merge". After excluding SUnitGUI I've been able to load it up until the beginning of the closure bootstrap and then it explodes in a Kernel version with the same error that SUnitGUI blows up (in an undebuggable state so your image is toast at that point).
>>>>>
>>>>>That's how far things are at this point. If you can fix the MC problems we should be getting further.
>>>>>
>>>>>Cheers,
>>>>>- Andreas
>>>>>
>>>>>Ken G. Brown wrote:
>>>>>>Mathew Fulmer said yesterday on irc, "mc1.6 worked fine for me. I was using it daily all last year".
>>>>>>Also regarding loading into trunk:
>>>>>>"well, hard to say if there have been a bunch of shifts in collections and compiler"
>>>>>>"may be an issue with traits too"
>>>>>>"loading kernel won't work with mc1.6, I'm pretty sure. it has traits"
>>>>>>
>>>>>>However,  ftp://ftp.squeak.org/3.11/Squeak3.10.2-lpf-atomic/ already has MC 1.6, along with the latest Installer, LPF, and Sake/Packages.
>>>>>>
>>>>>>Here's Keith's video from 4 months ago http://www.vimeo.com/groups/squeak/videos/5434330 showing  how to use Sake/Packages to load AND unload Seaside 3.0.
>>>>>>
>>>>>>If someone knowledgeable could get the trunk stuff loading into lpf-atomic using Sake/Packages, then we would be positioned to be quantum-leapt into the future.
>>>>>>
>>>>>>Ken G. Brown
>>>>>>
>>>>>>At 3:05 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>>>>>Hi Igor,
>>>>>>>
>>>>>>>no problem here except from the following issues:
>>>>>>>
>>>>>>>a) I don't even know where/how to load it. There is a bunch of conflicting packages on SqueakSource and zero instructions on what to load from where. Some information would be tremendously helpful.
>>>>>>>
>>>>>>>b) As far as I know nobody is using MC 1.6 at this point (if you do, raise your hand so I can see you). Given the critical nature of Monticello for development I'm not in favor of replacing a working and tested piece of infrastructure without extensive prior testing.
>>>>>>>
>>>>>>>c) It needs to support all the current features of Monticello (i.e., traits) or else it simply isn't fit for the intended purpose.
>>>>>>>
>>>>>>>If we can take care of the above, we can run an experiment like installing MC 1.6 into a 3.10 image and updating all the way through to the current trunk and make sure this works. At that point I would feel a lot more positive about MC 1.6 since what it means is that at least we know we can deal with the stuff that we've already been using.
>>>>>>>
>>>>>>>Cheers,
>>>>>>>- Andreas
>>>>>>>
>>>>>>>
>>>>>>>Igor Stasenko wrote:
>>>>>>>>Hello people,
>>>>>>>>
>>>>>>>>i'd like to see some answers about the fate of MC 1.6. and its current
>>>>>>>>situation.
>>>>>>>>
>>>>>>>>1. I think everyone wants to have an atomic loading.
>>>>>>>>But according to my knowledge, MC 1.6. has some problems with Traits,
>>>>>>>>which prevets us from using it & fully replace the older version.
>>>>>>>>
>>>>>>>>2. Besides of that, are there any other reasons to not have it?
>>>>>>>>
>>>>>>>>So, please, can we disscuss (friendly & constructive), what we might
>>>>>>>>need to have it integrated in Squeak and in Pharo, so
>>>>>>>>we could benefit from having an atomic loading?

> Ken G. Brown
>
> At 9:15 PM -0700 10/20/09, Andreas Raab apparently wrote:
>> Ken G. Brown wrote:
>>> Seems like it would be good to bypass Installer stuff since the latest Installer is already in the lpf-atomic image, how would you do that?
>>> It does not work to hack PackageLoader2>>loadWithNameLike: to avoid Installer-Core'.
>> There is no need to. The updater uses merges which means that any newer versions you have won't be nuked, any local modifications that you have will be preserved. For Installer-Core (which you can merge manually if you want to see the differences) there are only two methods that are different and the differences are pretty much irrelevant. That's what is powerful about updating from the trunk - you *can* maintain your own versions of packages and merge in only the new stuff from the trunk repository.
>>
>>> It's good to see you having a look at using MC 1.6. Might not take much for someone to fix the outstanding issues if they know what they are doing.
>> To be very clear, that someone won't be me. I was only interested to find out if MC 1.6 looks ready for prime time or not. Trying to load the trunk is a good reality check because it does various "interesting" changes.
>>
>> Cheers,
>>  - Andreas
>>
>>> Ken G. Brown
>>>
>>> At 8:53 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>> Ken G. Brown wrote:
>>>>> While following your instructions, when executing MCMcmUpdater updateFromRepositories: #('http://source.squeak.org/trunk').
>>>>> (with lowercase 'cm' typo fixed), I get an error could not find Installer-Core-edc.83. Perhaps Installer stuff should be bypassed too in PackageLoader2?
>>>> Try adding the either the 3.10 or the 3.9 repository to all packages with ancestor versions that cannot be found (you need to both add the repository and attach the repository to the package version). That should do the trick.
>>>>
>>>> (I got lucky because the version was in my local package cache)
>>>>
>>>> Cheers,
>>>> - Andreas
>>>>
>>>>> Ken G. Brown
>>>>>
>>>>> At 7:57 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>>>> Hi Ken -
>>>>>>
>>>>>> I gave the image you're pointing to a quick try but there are still some issues with MC 1.6. The biggest one so far is loading ProtoObject subclasses. You can try this if you launch the lpf-atomic image, point it to the trunk and try to merge any of the SUnitGUI versions. It explodes somewhere in SystemEditor.
>>>>>>
>>>>>> Outside of that I made quite a bit of progress loading trunk into the lpf-atomic image. Here are the steps if you want to play with it yourself:
>>>>>>
>>>>>> * Merge the latest MonticelloConfigurations from the trunk. This will mess up a bit of the structure but since the categories are changed but it'll work okay.
>>>>>>
>>>>>> * Hack PackageLoader2>>loadWithNameLike: to avoid nuking Monticello and PackageInfo:
>>>>>>
>>>>>> ((baseName beginsWith: 'Monticello')
>>>>>>   or:[baseName beginsWith: 'PackageInfo']) ifTrue:[^self].
>>>>>>
>>>>>> This makes PackageLoader ignore any MC/PI related packages. If you want to, you can also add SUnitGUI which gets you a little further later on (but not very much).
>>>>>>
>>>>>> * Rename MethodContext>>receiverMap to closureOrNil. MC 1.6 does not deal with context reshape (not really a surprise):
>>>>>> MethodContext instVarNames at: 2 put: 'closureOrNil'.
>>>>>>
>>>>>> * Launch the updater via
>>>>>> MCMCMUpdater updateFromRepositories: #('http://source.squeak.org/trunk').
>>>>>>
>>>>>> As it is loading, it'll pop up various requests for resolving conflicts; always choose "rest remote" and then "merge". After excluding SUnitGUI I've been able to load it up until the beginning of the closure bootstrap and then it explodes in a Kernel version with the same error that SUnitGUI blows up (in an undebuggable state so your image is toast at that point).
>>>>>>
>>>>>> That's how far things are at this point. If you can fix the MC problems we should be getting further.
>>>>>>
>>>>>> Cheers,
>>>>>> - Andreas
>>>>>>
>>>>>> Ken G. Brown wrote:
>>>>>>> Mathew Fulmer said yesterday on irc, "mc1.6 worked fine for me. I was using it daily all last year".
>>>>>>> Also regarding loading into trunk:
>>>>>>> "well, hard to say if there have been a bunch of shifts in collections and compiler"
>>>>>>> "may be an issue with traits too"
>>>>>>> "loading kernel won't work with mc1.6, I'm pretty sure. it has traits"
>>>>>>>
>>>>>>> However,  ftp://ftp.squeak.org/3.11/Squeak3.10.2-lpf-atomic/ already has MC 1.6, along with the latest Installer, LPF, and Sake/Packages.
>>>>>>>
>>>>>>> Here's Keith's video from 4 months ago http://www.vimeo.com/groups/squeak/videos/5434330 showing  how to use Sake/Packages to load AND unload Seaside 3.0.
>>>>>>>
>>>>>>> If someone knowledgeable could get the trunk stuff loading into lpf-atomic using Sake/Packages, then we would be positioned to be quantum-leapt into the future.
>>>>>>>
>>>>>>> Ken G. Brown
>>>>>>>
>>>>>>> At 3:05 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>>>>>> Hi Igor,
>>>>>>>>
>>>>>>>> no problem here except from the following issues:
>>>>>>>>
>>>>>>>> a) I don't even know where/how to load it. There is a bunch of conflicting packages on SqueakSource and zero instructions on what to load from where. Some information would be tremendously helpful.
>>>>>>>>
>>>>>>>> b) As far as I know nobody is using MC 1.6 at this point (if you do, raise your hand so I can see you). Given the critical nature of Monticello for development I'm not in favor of replacing a working and tested piece of infrastructure without extensive prior testing.
>>>>>>>>
>>>>>>>> c) It needs to support all the current features of Monticello (i.e., traits) or else it simply isn't fit for the intended purpose.
>>>>>>>>
>>>>>>>> If we can take care of the above, we can run an experiment like installing MC 1.6 into a 3.10 image and updating all the way through to the current trunk and make sure this works. At that point I would feel a lot more positive about MC 1.6 since what it means is that at least we know we can deal with the stuff that we've already been using.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> - Andreas
>>>>>>>>
>>>>>>>>
>>>>>>>> Igor Stasenko wrote:
>>>>>>>>> Hello people,
>>>>>>>>>
>>>>>>>>> i'd like to see some answers about the fate of MC 1.6. and its current
>>>>>>>>> situation.
>>>>>>>>>
>>>>>>>>> 1. I think everyone wants to have an atomic loading.
>>>>>>>>> But according to my knowledge, MC 1.6. has some problems with Traits,
>>>>>>>>> which prevets us from using it & fully replace the older version.
>>>>>>>>>
>>>>>>>>> 2. Besides of that, are there any other reasons to not have it?
>>>>>>>>>
>>>>>>>>> So, please, can we disscuss (friendly & constructive), what we might
>>>>>>>>> need to have it integrated in Squeak and in Pharo, so
>>>>>>>>> we could benefit from having an atomic loading?
>
>
>

>Ken G. Brown wrote:
>>Seems like it would be good to bypass Installer stuff since the latest Installer is already in the lpf-atomic image, how would you do that?
>>It does not work to hack PackageLoader2>>loadWithNameLike: to avoid Installer-Core'.
>
>There is no need to. The updater uses merges which means that any newer versions you have won't be nuked, any local modifications that you have will be preserved. For Installer-Core (which you can merge manually if you want to see the differences) there are only two methods that are different and the differences are pretty much irrelevant. That's what is powerful about updating from the trunk - you *can* maintain your own versions of packages and merge in only the new stuff from the trunk repository.
>
>>It's good to see you having a look at using MC 1.6. Might not take much for someone to fix the outstanding issues if they know what they are doing.
>
>To be very clear, that someone won't be me. I was only interested to find out if MC 1.6 looks ready for prime time or not. Trying to load the trunk is a good reality check because it does various "interesting" changes.
>
>Cheers,
>  - Andreas
>
>>
>>Ken G. Brown
>>
>>At 8:53 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>Ken G. Brown wrote:
>>>>While following your instructions, when executing MCMcmUpdater updateFromRepositories: #('http://source.squeak.org/trunk').
>>>>(with lowercase 'cm' typo fixed), I get an error could not find Installer-Core-edc.83. Perhaps Installer stuff should be bypassed too in PackageLoader2?
>>>Try adding the either the 3.10 or the 3.9 repository to all packages with ancestor versions that cannot be found (you need to both add the repository and attach the repository to the package version). That should do the trick.
>>>
>>>(I got lucky because the version was in my local package cache)
>>>
>>>Cheers,
>>> - Andreas
>>>
>>>>Ken G. Brown
>>>>
>>>>At 7:57 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>>>Hi Ken -
>>>>>
>>>>>I gave the image you're pointing to a quick try but there are still some issues with MC 1.6. The biggest one so far is loading ProtoObject subclasses. You can try this if you launch the lpf-atomic image, point it to the trunk and try to merge any of the SUnitGUI versions. It explodes somewhere in SystemEditor.
>>>>>
>>>>>Outside of that I made quite a bit of progress loading trunk into the lpf-atomic image. Here are the steps if you want to play with it yourself:
>>>>>
>>>>>* Merge the latest MonticelloConfigurations from the trunk. This will mess up a bit of the structure but since the categories are changed but it'll work okay.
>>>>>
>>>>>* Hack PackageLoader2>>loadWithNameLike: to avoid nuking Monticello and PackageInfo:
>>>>>
>>>>>((baseName beginsWith: 'Monticello')
>>>>>   or:[baseName beginsWith: 'PackageInfo']) ifTrue:[^self].
>>>>>
>>>>>This makes PackageLoader ignore any MC/PI related packages. If you want to, you can also add SUnitGUI which gets you a little further later on (but not very much).
>>>>>
>>>>>* Rename MethodContext>>receiverMap to closureOrNil. MC 1.6 does not deal with context reshape (not really a surprise):
>>>>>MethodContext instVarNames at: 2 put: 'closureOrNil'.
>>>>>
>>>>>* Launch the updater via
>>>>>MCMCMUpdater updateFromRepositories: #('http://source.squeak.org/trunk').
>>>>>
>>>>>As it is loading, it'll pop up various requests for resolving conflicts; always choose "rest remote" and then "merge". After excluding SUnitGUI I've been able to load it up until the beginning of the closure bootstrap and then it explodes in a Kernel version with the same error that SUnitGUI blows up (in an undebuggable state so your image is toast at that point).
>>>>>
>>>>>That's how far things are at this point. If you can fix the MC problems we should be getting further.
>>>>>
>>>>>Cheers,
>>>>>- Andreas
>>>>>
>>>>>Ken G. Brown wrote:
>>>>>>Mathew Fulmer said yesterday on irc, "mc1.6 worked fine for me. I was using it daily all last year".
>>>>>>Also regarding loading into trunk:
>>>>>>"well, hard to say if there have been a bunch of shifts in collections and compiler"
>>>>>>"may be an issue with traits too"
>>>>>>"loading kernel won't work with mc1.6, I'm pretty sure. it has traits"
>>>>>>
>>>>>>However,  ftp://ftp.squeak.org/3.11/Squeak3.10.2-lpf-atomic/ already has MC 1.6, along with the latest Installer, LPF, and Sake/Packages.
>>>>>>
>>>>>>Here's Keith's video from 4 months ago http://www.vimeo.com/groups/squeak/videos/5434330 showing  how to use Sake/Packages to load AND unload Seaside 3.0.
>>>>>>
>>>>>>If someone knowledgeable could get the trunk stuff loading into lpf-atomic using Sake/Packages, then we would be positioned to be quantum-leapt into the future.
>>>>>>
>>>>>>Ken G. Brown
>>>>>>
>>>>>>At 3:05 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>>>>>Hi Igor,
>>>>>>>
>>>>>>>no problem here except from the following issues:
>>>>>>>
>>>>>>>a) I don't even know where/how to load it. There is a bunch of conflicting packages on SqueakSource and zero instructions on what to load from where. Some information would be tremendously helpful.
>>>>>>>
>>>>>>>b) As far as I know nobody is using MC 1.6 at this point (if you do, raise your hand so I can see you). Given the critical nature of Monticello for development I'm not in favor of replacing a working and tested piece of infrastructure without extensive prior testing.
>>>>>>>
>>>>>>>c) It needs to support all the current features of Monticello (i.e., traits) or else it simply isn't fit for the intended purpose.
>>>>>>>
>>>>>>>If we can take care of the above, we can run an experiment like installing MC 1.6 into a 3.10 image and updating all the way through to the current trunk and make sure this works. At that point I would feel a lot more positive about MC 1.6 since what it means is that at least we know we can deal with the stuff that we've already been using.
>>>>>>>
>>>>>>>Cheers,
>>>>>>>- Andreas
>>>>>>>
>>>>>>>
>>>>>>>Igor Stasenko wrote:
>>>>>>>>Hello people,
>>>>>>>>
>>>>>>>>i'd like to see some answers about the fate of MC 1.6. and its current
>>>>>>>>situation.
>>>>>>>>
>>>>>>>>1. I think everyone wants to have an atomic loading.
>>>>>>>>But according to my knowledge, MC 1.6. has some problems with Traits,
>>>>>>>>which prevets us from using it & fully replace the older version.
>>>>>>>>
>>>>>>>>2. Besides of that, are there any other reasons to not have it?
>>>>>>>>
>>>>>>>>So, please, can we disscuss (friendly & constructive), what we might
>>>>>>>>need to have it integrated in Squeak and in Pharo, so
>>>>>>>>we could benefit from having an atomic loading?

>Ken G. Brown wrote:
>>Here are a couple previous emails about MC 1.5/1.6 that Matthew Fulmer mentioned on #squeak:
>>
>><http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-July/137124.html>
>>
>><http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-July/137135.html>
>
>Great reminders, thanks. Has any progress been made on the issues raised in these posts?
>
>Cheers,
>  - Andreas
>
>>Ken G. Brown
>>
>>At 9:15 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>Ken G. Brown wrote:
>>>>Seems like it would be good to bypass Installer stuff since the latest Installer is already in the lpf-atomic image, how would you do that?
>>>>It does not work to hack PackageLoader2>>loadWithNameLike: to avoid Installer-Core'.
>>>There is no need to. The updater uses merges which means that any newer versions you have won't be nuked, any local modifications that you have will be preserved. For Installer-Core (which you can merge manually if you want to see the differences) there are only two methods that are different and the differences are pretty much irrelevant. That's what is powerful about updating from the trunk - you *can* maintain your own versions of packages and merge in only the new stuff from the trunk repository.
>>>
>>>>It's good to see you having a look at using MC 1.6. Might not take much for someone to fix the outstanding issues if they know what they are doing.
>>>To be very clear, that someone won't be me. I was only interested to find out if MC 1.6 looks ready for prime time or not. Trying to load the trunk is a good reality check because it does various "interesting" changes.
>>>
>>>Cheers,
>>> - Andreas
>>>
>>>>Ken G. Brown
>>>>
>>>>At 8:53 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>>>Ken G. Brown wrote:
>>>>>>While following your instructions, when executing MCMcmUpdater updateFromRepositories: #('http://source.squeak.org/trunk').
>>>>>>(with lowercase 'cm' typo fixed), I get an error could not find Installer-Core-edc.83. Perhaps Installer stuff should be bypassed too in PackageLoader2?
>>>>>Try adding the either the 3.10 or the 3.9 repository to all packages with ancestor versions that cannot be found (you need to both add the repository and attach the repository to the package version). That should do the trick.
>>>>>
>>>>>(I got lucky because the version was in my local package cache)
>>>>>
>>>>>Cheers,
>>>>>- Andreas
>>>>>
>>>>>>Ken G. Brown
>>>>>>
>>>>>>At 7:57 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>>>>>Hi Ken -
>>>>>>>
>>>>>>>I gave the image you're pointing to a quick try but there are still some issues with MC 1.6. The biggest one so far is loading ProtoObject subclasses. You can try this if you launch the lpf-atomic image, point it to the trunk and try to merge any of the SUnitGUI versions. It explodes somewhere in SystemEditor.
>>>>>>>
>>>>>>>Outside of that I made quite a bit of progress loading trunk into the lpf-atomic image. Here are the steps if you want to play with it yourself:
>>>>>>>
>>>>>>>* Merge the latest MonticelloConfigurations from the trunk. This will mess up a bit of the structure but since the categories are changed but it'll work okay.
>>>>>>>
>>>>>>>* Hack PackageLoader2>>loadWithNameLike: to avoid nuking Monticello and PackageInfo:
>>>>>>>
>>>>>>>((baseName beginsWith: 'Monticello')
>>>>>>>  or:[baseName beginsWith: 'PackageInfo']) ifTrue:[^self].
>>>>>>>
>>>>>>>This makes PackageLoader ignore any MC/PI related packages. If you want to, you can also add SUnitGUI which gets you a little further later on (but not very much).
>>>>>>>
>>>>>>>* Rename MethodContext>>receiverMap to closureOrNil. MC 1.6 does not deal with context reshape (not really a surprise):
>>>>>>>MethodContext instVarNames at: 2 put: 'closureOrNil'.
>>>>>>>
>>>>>>>* Launch the updater via
>>>>>>>MCMCMUpdater updateFromRepositories: #('http://source.squeak.org/trunk').
>>>>>>>
>>>>>>>As it is loading, it'll pop up various requests for resolving conflicts; always choose "rest remote" and then "merge". After excluding SUnitGUI I've been able to load it up until the beginning of the closure bootstrap and then it explodes in a Kernel version with the same error that SUnitGUI blows up (in an undebuggable state so your image is toast at that point).
>>>>>>>
>>>>>>>That's how far things are at this point. If you can fix the MC problems we should be getting further.
>>>>>>>
>>>>>>>Cheers,
>>>>>>>- Andreas
>>>>>>>
>>>>>>>Ken G. Brown wrote:
>>>>>>>>Mathew Fulmer said yesterday on irc, "mc1.6 worked fine for me. I was using it daily all last year".
>>>>>>>>Also regarding loading into trunk:
>>>>>>>>"well, hard to say if there have been a bunch of shifts in collections and compiler"
>>>>>>>>"may be an issue with traits too"
>>>>>>>>"loading kernel won't work with mc1.6, I'm pretty sure. it has traits"
>>>>>>>>
>>>>>>>>However,  ftp://ftp.squeak.org/3.11/Squeak3.10.2-lpf-atomic/ already has MC 1.6, along with the latest Installer, LPF, and Sake/Packages.
>>>>>>>>
>>>>>>>>Here's Keith's video from 4 months ago http://www.vimeo.com/groups/squeak/videos/5434330 showing  how to use Sake/Packages to load AND unload Seaside 3.0.
>>>>>>>>
>>>>>>>>If someone knowledgeable could get the trunk stuff loading into lpf-atomic using Sake/Packages, then we would be positioned to be quantum-leapt into the future.
>>>>>>>>
>>>>>>>>Ken G. Brown
>>>>>>>>
>>>>>>>>At 3:05 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>>>>>>>Hi Igor,
>>>>>>>>>
>>>>>>>>>no problem here except from the following issues:
>>>>>>>>>
>>>>>>>>>a) I don't even know where/how to load it. There is a bunch of conflicting packages on SqueakSource and zero instructions on what to load from where. Some information would be tremendously helpful.
>>>>>>>>>
>>>>>>>>>b) As far as I know nobody is using MC 1.6 at this point (if you do, raise your hand so I can see you). Given the critical nature of Monticello for development I'm not in favor of replacing a working and tested piece of infrastructure without extensive prior testing.
>>>>>>>>>
>>>>>>>>>c) It needs to support all the current features of Monticello (i.e., traits) or else it simply isn't fit for the intended purpose.
>>>>>>>>>
>>>>>>>>>If we can take care of the above, we can run an experiment like installing MC 1.6 into a 3.10 image and updating all the way through to the current trunk and make sure this works. At that point I would feel a lot more positive about MC 1.6 since what it means is that at least we know we can deal with the stuff that we've already been using.
>>>>>>>>>
>>>>>>>>>Cheers,
>>>>>>>>>- Andreas
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Igor Stasenko wrote:
>>>>>>>>>>Hello people,
>>>>>>>>>>
>>>>>>>>>>i'd like to see some answers about the fate of MC 1.6. and its current
>>>>>>>>>>situation.
>>>>>>>>>>
>>>>>>>>>>1. I think everyone wants to have an atomic loading.
>>>>>>>>>>But according to my knowledge, MC 1.6. has some problems with Traits,
>>>>>>>>>>which prevets us from using it & fully replace the older version.
>>>>>>>>>>
>>>>>>>>>>2. Besides of that, are there any other reasons to not have it?
>>>>>>>>>>
>>>>>>>>>>So, please, can we disscuss (friendly & constructive), what we might
>>>>>>>>>>need to have it integrated in Squeak and in Pharo, so
>>>>>>>>>>we could benefit from having an atomic loading?

> Ken G. Brown
>
> At 9:15 PM -0700 10/20/09, Andreas Raab apparently wrote:
>> Ken G. Brown wrote:
>>> Seems like it would be good to bypass Installer stuff since the latest Installer is already in the lpf-atomic image, how would you do that?
>>> It does not work to hack PackageLoader2>>loadWithNameLike: to avoid Installer-Core'.
>> There is no need to. The updater uses merges which means that any newer versions you have won't be nuked, any local modifications that you have will be preserved. For Installer-Core (which you can merge manually if you want to see the differences) there are only two methods that are different and the differences are pretty much irrelevant. That's what is powerful about updating from the trunk - you *can* maintain your own versions of packages and merge in only the new stuff from the trunk repository.
>>
>>> It's good to see you having a look at using MC 1.6. Might not take much for someone to fix the outstanding issues if they know what they are doing.
>> To be very clear, that someone won't be me. I was only interested to find out if MC 1.6 looks ready for prime time or not. Trying to load the trunk is a good reality check because it does various "interesting" changes.
>>
>> Cheers,
>>  - Andreas
>>
>>> Ken G. Brown
>>>
>>> At 8:53 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>> Ken G. Brown wrote:
>>>>> While following your instructions, when executing MCMcmUpdater updateFromRepositories: #('http://source.squeak.org/trunk').
>>>>> (with lowercase 'cm' typo fixed), I get an error could not find Installer-Core-edc.83. Perhaps Installer stuff should be bypassed too in PackageLoader2?
>>>> Try adding the either the 3.10 or the 3.9 repository to all packages with ancestor versions that cannot be found (you need to both add the repository and attach the repository to the package version). That should do the trick.
>>>>
>>>> (I got lucky because the version was in my local package cache)
>>>>
>>>> Cheers,
>>>> - Andreas
>>>>
>>>>> Ken G. Brown
>>>>>
>>>>> At 7:57 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>>>> Hi Ken -
>>>>>>
>>>>>> I gave the image you're pointing to a quick try but there are still some issues with MC 1.6. The biggest one so far is loading ProtoObject subclasses. You can try this if you launch the lpf-atomic image, point it to the trunk and try to merge any of the SUnitGUI versions. It explodes somewhere in SystemEditor.
>>>>>>
>>>>>> Outside of that I made quite a bit of progress loading trunk into the lpf-atomic image. Here are the steps if you want to play with it yourself:
>>>>>>
>>>>>> * Merge the latest MonticelloConfigurations from the trunk. This will mess up a bit of the structure but since the categories are changed but it'll work okay.
>>>>>>
>>>>>> * Hack PackageLoader2>>loadWithNameLike: to avoid nuking Monticello and PackageInfo:
>>>>>>
>>>>>> ((baseName beginsWith: 'Monticello')
>>>>>>   or:[baseName beginsWith: 'PackageInfo']) ifTrue:[^self].
>>>>>>
>>>>>> This makes PackageLoader ignore any MC/PI related packages. If you want to, you can also add SUnitGUI which gets you a little further later on (but not very much).
>>>>>>
>>>>>> * Rename MethodContext>>receiverMap to closureOrNil. MC 1.6 does not deal with context reshape (not really a surprise):
>>>>>> MethodContext instVarNames at: 2 put: 'closureOrNil'.
>>>>>>
>>>>>> * Launch the updater via
>>>>>> MCMCMUpdater updateFromRepositories: #('http://source.squeak.org/trunk').
>>>>>>
>>>>>> As it is loading, it'll pop up various requests for resolving conflicts; always choose "rest remote" and then "merge". After excluding SUnitGUI I've been able to load it up until the beginning of the closure bootstrap and then it explodes in a Kernel version with the same error that SUnitGUI blows up (in an undebuggable state so your image is toast at that point).
>>>>>>
>>>>>> That's how far things are at this point. If you can fix the MC problems we should be getting further.
>>>>>>
>>>>>> Cheers,
>>>>>> - Andreas
>>>>>>
>>>>>> Ken G. Brown wrote:
>>>>>>> Mathew Fulmer said yesterday on irc, "mc1.6 worked fine for me. I was using it daily all last year".
>>>>>>> Also regarding loading into trunk:
>>>>>>> "well, hard to say if there have been a bunch of shifts in collections and compiler"
>>>>>>> "may be an issue with traits too"
>>>>>>> "loading kernel won't work with mc1.6, I'm pretty sure. it has traits"
>>>>>>>
>>>>>>> However,  ftp://ftp.squeak.org/3.11/Squeak3.10.2-lpf-atomic/ already has MC 1.6, along with the latest Installer, LPF, and Sake/Packages.
>>>>>>>
>>>>>>> Here's Keith's video from 4 months ago http://www.vimeo.com/groups/squeak/videos/5434330 showing  how to use Sake/Packages to load AND unload Seaside 3.0.
>>>>>>>
>>>>>>> If someone knowledgeable could get the trunk stuff loading into lpf-atomic using Sake/Packages, then we would be positioned to be quantum-leapt into the future.
>>>>>>>
>>>>>>> Ken G. Brown
>>>>>>>
>>>>>>> At 3:05 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>>>>>> Hi Igor,
>>>>>>>>
>>>>>>>> no problem here except from the following issues:
>>>>>>>>
>>>>>>>> a) I don't even know where/how to load it. There is a bunch of conflicting packages on SqueakSource and zero instructions on what to load from where. Some information would be tremendously helpful.
>>>>>>>>
>>>>>>>> b) As far as I know nobody is using MC 1.6 at this point (if you do, raise your hand so I can see you). Given the critical nature of Monticello for development I'm not in favor of replacing a working and tested piece of infrastructure without extensive prior testing.
>>>>>>>>
>>>>>>>> c) It needs to support all the current features of Monticello (i.e., traits) or else it simply isn't fit for the intended purpose.
>>>>>>>>
>>>>>>>> If we can take care of the above, we can run an experiment like installing MC 1.6 into a 3.10 image and updating all the way through to the current trunk and make sure this works. At that point I would feel a lot more positive about MC 1.6 since what it means is that at least we know we can deal with the stuff that we've already been using.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> - Andreas
>>>>>>>>
>>>>>>>>
>>>>>>>> Igor Stasenko wrote:
>>>>>>>>> Hello people,
>>>>>>>>>
>>>>>>>>> i'd like to see some answers about the fate of MC 1.6. and its current
>>>>>>>>> situation.
>>>>>>>>>
>>>>>>>>> 1. I think everyone wants to have an atomic loading.
>>>>>>>>> But according to my knowledge, MC 1.6. has some problems with Traits,
>>>>>>>>> which prevets us from using it & fully replace the older version.
>>>>>>>>>
>>>>>>>>> 2. Besides of that, are there any other reasons to not have it?
>>>>>>>>>
>>>>>>>>> So, please, can we disscuss (friendly & constructive), what we might
>>>>>>>>> need to have it integrated in Squeak and in Pharo, so
>>>>>>>>> we could benefit from having an atomic loading?
>
>
>

>Ken G. Brown wrote:
>>When attempting
>>  MCMcmUpdater updateFromRepositories: #('http://source.squeak.org/310' 'http://source.squeak.org/trunk' ). I cannot get past the error saying it cannot find 'Installer-Core-edc.83', and it appears to be there in http://source.squeak.org/310
>
>It works fine when you add the repo to the package. You need to:
>a) Add the repository, i.e., click on +repository and paste
>MCHttpRepository
>    location: 'http://source.squeak.org/310'
>    user: ''
>    password: ''
>
>b) Select the newly added repository, and from the context menu choose "add to package..." and select the package "Installer-Core" (NOT "Installer"). Once you've done this you should be able to either merge any of the versions from the trunk directly, or via updating. I did both just now (deleting my local package-cached version) and both ways work fine.
>
>Cheers,
>  - Andreas
>
>>Ken G. Brown
>>
>>At 9:15 PM -0700 10/20/09, Andreas Raab apparently wrote:
>>>Ken G. Brown wrote:
>>>>Seems like it would be good to bypass Installer stuff since the latest Installer is already in the lpf-atomic image, how would you do that?
>>>>It does not work to hack PackageLoader2>>loadWithNameLike: to avoid Installer-Core'.
>>>There is no need to. The updater uses merges which means that any newer versions you have won't be nuked, any local modifications that you have will be preserved. For Installer-Core (which you can merge manually if you want to see the differences) there are only two methods that are different and the differences are pretty much irrelevant. That's what is powerful about updating from the trunk - you *can* maintain your own versions of packages and merge in only the new stuff from the trunk repository.
>>>
>>>>It's good to see you having a look at using MC 1.6. Might not take much for someone to fix the outstanding issues if they know what they are doing.
>>>To be very clear, that someone won't be me. I was only interested to find out if MC 1.6 looks ready for prime time or not. Trying to load the trunk is a good reality check because it does various "interesting" changes.
>>>
>>>Cheers,
>>> - Andreas
>>>
>>>>>>>>>><snip>

> Hello people,
>
> i'd like to see some answers about the fate of MC 1.6. and its current
> situation.
>
> 1. I think everyone wants to have an atomic loading.
> But according to my knowledge, MC 1.6. has some problems with Traits,
> which prevets us from using it & fully replace the older version.
>
> 2. Besides of that, are there any other reasons to not have it?
>
> So, please, can we disscuss (friendly & constructive), what we might
> need to have it integrated in Squeak and in Pharo, so
> we could benefit from having an atomic loading?
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> I would love to have that.
> I started to migrate some 1.5 code (fast loading) from MC15 to pharo
> MC15 but nobody have a look
> at the slice I published
>
>
> Stef
>
>> Hello people,
>>
>> i'd like to see some answers about the fate of MC 1.6. and its current
>> situation.
>>
>> 1. I think everyone wants to have an atomic loading.
>> But according to my knowledge, MC 1.6. has some problems with Traits,
>> which prevets us from using it & fully replace the older version.
>>
>> 2. Besides of that, are there any other reasons to not have it?
>>
>> So, please, can we disscuss (friendly & constructive), what we might
>> need to have it integrated in Squeak and in Pharo, so
>> we could benefit from having an atomic loading?
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> 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 had chat with Matthew today, and he said that he could turn his head
> back on MC 1.6 for a bit.
> But he doesn't guarantees that he can spend much time on it, so i
> asked him first, to
> write the small report - an overview, which lists the problems its
> having and in what way they can be solved.
>
> Then, i hope, someone could pick up the task and make it available.
>
> Next thing is a clarification about LPF from its respectible developer(s):
> LPF is an 'MC 1.6' , in terms that its a main tool which provides
> means to load & install MC 1.6 in *your image*.
>
> By *your image* i meant that LPF is not targeted for a particular
> squeak version or its fork - it attempts to target as many of them as
> possible.
> And this means, that LPF (along with MC 1.6) could serve as a common
> ground for many existing squeak versions and its forks.
>
> And this means, in own turn, that it is in our best interests to make
> it adopted. :)
>
> In a future, i suggest to use a better naming for a projects, like
> LPF, or make name to be more elaborate (like LPF - the MC 1.6
> bootstrapper) because its confusing the people up to the point that
> they don't understand why it is so good to have it.
>
>
> 2009/10/21 Stéphane Ducasse <[hidden email]>:
>> I would love to have that.
>> I started to migrate some 1.5 code (fast loading) from MC15 to pharo
>> MC15 but nobody have a look
>> at the slice I published
>>
>>
>> Stef
>>
>>> Hello people,
>>>
>>> i'd like to see some answers about the fate of MC 1.6. and its current
>>> situation.
>>>
>>> 1. I think everyone wants to have an atomic loading.
>>> But according to my knowledge, MC 1.6. has some problems with Traits,
>>> which prevets us from using it & fully replace the older version.
>>>
>>> 2. Besides of that, are there any other reasons to not have it?
>>>
>>> So, please, can we disscuss (friendly & constructive), what we might
>>> need to have it integrated in Squeak and in Pharo, so
>>> we could benefit from having an atomic loading?
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>