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