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?

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?