At 11:16 PM -0800 1/27/10, Andreas Raab apparently wrote:
>keith wrote:
>>It sounds like you loaded the right thing. You just need to turn the "useAtomicLoading" preference off, this uses MCPackageLoader1b, the non atomic loading code.
>
>So I tried this too and it doesn't get very far either (same process described earlier). It fails very early on when it's trying to load a variant of ProgressInitiationException>>defaultMorphicAction. The failure originates from MCMethodDefinition>>preloadOver: which actually *removes* the selector that is being changed.
>
>This is a fatal flaw since removing a method that's about to be modified can't possibly work when it comes to any system critical methods (compiler etc. comes to mind but even the progress display is enought to blow up). This version won't be able to deal with many, many changes that went into the trunk.
>
>Cheers,
>  - Andreas

Andreas,
I am finding it somewhat odd that you seem to be willing to hack your ancient trunk fork of MC any which way, but with the big potential wins of the MC1.5/1.6 versions, I'm thinking someone like yourself with the necessary detailed system knowledge, might be able to apply some appropriate fixes to bring MC into a better working state. Even if it might be an interim solution, it seems to me there could be some real gains.
How far away from stable working versions can MC1.5/1.6 be? Both Matthew and Keith have used MC 1.5 and 1.6 fairly extensively, but perhaps not exactly for the types of things you have been doing. Maybe I don't fully appreciate the efforts required, but to my mind if the ancient version is able to do what you need, the newer versions must be close too.
As Keith recently mentioned:

>>At 10:00 PM +0000 1/26/10, keith apparently wrote:
>>>
>>>All efforts to change this, to move obvious loadable libraries like SUnit, and MC out to be externally managed, have up to now failed. The weakness of my attempts so far has been in the testing side of things. (Matthew Fulmer is worth is weight in gold on that one)
>>>
>>>
>>>However Monticello is a complicated beast, I may have made 400 more commits, merging 3 forks, but one or two bugs is all it takes to reject the entire refactoring of the repositories code, the improved more uniform ui implementation, the password manager, the dual change sorter, the orphanage for out of order loading, public package info properties for package managers, scripting of commits, memory analysis per package, the atomic loader, cleanUp code, improved version numbering, integrated Configurations, separated tests, default packageinfo package types etc etc etc.
>>>
>>
>>Those are package specific problems. I suggest getting in touch with Monticello developers to merge your changes.
>>
>
>Matthew and I were the monticello maintainers for 3 years, after there had been none for at least a year. That was the whole point of setting up a shared repository squeaksource.com/mc so that Monticello could be maintained and worked on by anyone that knew how.
>
>Most of us work with the latest of established packages on a day to day basis. Yet for some reason, both Pharo and "trunk" adopted the ancient version. There are no more bugs in the new version, the exisiting bugs are just in slightly different places. The new version passes lukas' "difficult test case", whereas the old one doesn't.
>
>Keith

Ken G. Brown