Proposal for the coming versions

Adrian Lienhard adi at netstyle.ch
Tue Mar 14 09:16:56 UTC 2006


Hi

It would be valuable to precisely identify the problems of MC because  
in my experience it works very well for 80% of the cases (which we  
can't say for change sets -- at least what I use MC for). So, the  
goal for 3.10 (or for a dedicated "task force") would be to improve  
those shortcomings.

I see three main areas of problems:

a) performance (although not necessarily a show stopper the slow  
speed makes working with MC for non-trivial projects quite annoying)

b) load order problems (I guess, an atomic load would solve all those  
problems):
(i) i.e., moving a class from package A to B, or circular  
dependencies between packages
(ii) modifying code that is used while loading itself

c) "live updates": upgrading state to the new version of the system,  
a task that change sets and the update stream was really good at but  
that MC does not support explicitly. Here we could argue that this is  
not MC's business, in which case we should find another solution that  
is less ad-hoc than the ScriptLoader as used in 3.9a now.

- other stuff: method overrides don't work correctly and extending  
class definition would be nice too (e.g., in package A add an  
instance variable to a class that is defined in package B).

Although MC2 is supposed to solve many of those problems, I don't  
think it is a good strategy to wait and leave those issues unfixed.   
Since MC is in the critical path of the development of Squeak, I  
think we should rather start today to fix what stands in our way.

Cheers,
Adrian

PS: for b) there seems to be a solution already but I wonder why this  
has never found any big attention, nor has been incorporated into MC  
in 3.9? Citing Colin: "SystemEditor is a small package that provides  
way to execute a series of change to the system atomically. It's  
going to be a critical part of Monticello2, and in the meantime, I  
think it would be valuable to update Monticello1 to use it as well."


On Mar 13, 2006, at 22:27 , Daniel Vainsencher wrote:

> Hi everyone.
>
> I think improving the process for those doing the development is  
> important, but agree with Andreas that the current proposal sounds  
> like we're giving up on users ability to update their images. If  
> that's what we want, we should just say so.
>
> If we're going to go for a better system that has the benefits of  
> MC and supports image updates, we need to actually catalog,  
> discuss, and solve those nitty gritty problems that bug both sides  
> of the development process at the moment. And this will be a lot of  
> work, and we can't expect the MC guys to just solve it all for us,  
> even if MC2 solves the code issues, including performance and class- 
> renames.
>
> Before continuing with the bad news, just wanted to remind  
> ourselves that systematic treatment of live system updates is  
> possible at least in the sense that GemStone does it.
>
> Here is a partial list of problems I met while working on the  
> updates for Traits:
> - Having made some changes, I should know whether these are  
> loadable into a published image. This currently requires manually  
> posting, opening new image, loading. Some test server seems useful  
> in this context.
> - Doing live updates correctly requires capturing a sequence of  
> steps which know enough each about the previous state to keep  
> things running correctly. MC by itself does not model this at all.  
> An external tool (ScriptLoader, IIRC, in the current process) can  
> capture this. But in addition to capturing update sequences, we  
> need to be able to merge them. For example, suppose we and  
> Squeakland create two unrelated update sequences for overlapping  
> sets of packages, starting from common state A, going to B and C  
> respectively, through B1, B2... and C1, C2... The "did-both- 
> updates" state D needs to be created (probably via MC merge), but  
> what are the stage D1,D2...? It might well be that the merge  
> problem needs to be solved manually, rather than automatically, but  
> we definitely need a better way to detect it, to capture the  
> sequences, and to change from one sequence to the other when we  
> find problems (currently doable only by updating the updates-list  
> file, AFAIK).
> - Recompiling the whole image is very slow. Therefore changing the  
> shape of many classes (in that example, all metaclasses) makes  
> updates take a very long time.
> - It is hard to make some system level changes because none of the  
> existing tools in the image document all the VM assumptions.  
> Therefore, that bug from changing the shape of Behaviors that  
> prevents some primitives from running.
>
> Daniel Vainsencher
>
> Andreas Raab wrote:
>
>> Cees de Groot wrote:
>>
>>> Personally, I would point my finger at the use of MC instead of MC
>>> itself (MC seems to be not fit for a particular purpose its creators
>>> probably never reckoned with).
>>
>>
>> According to Colin "Monticello was designed with maintaining live  
>> system in mind" (see http://lists.squeakfoundation.org/pipermail/ 
>> squeak-dev/2006-February/101067.html)
>>
>>> Anyway, I wasn't assigning "blame", I
>>> was just remarking that there was a conflict here.
>>
>>
>> Me neither. As I've said in the past, MC is good for what MC is  
>> good for (namely managing source code in a "build" environment)  
>> but it strikes me that you're proposing to apply it in just the  
>> way where it doesn't work very well. But of course, that's just my  
>> experience. YMMV.
>>
>>> Nope. My idea is that during "fast development", the team leader  
>>> just
>>> publishes images. And probably an MCC map or something similar  
>>> showing
>>> how the image is put together. So the user would effectively have to
>>> download the image to hop across major upgrades. Minor upgrades  
>>> would
>>> likely be doable by just udating using the MCC map. For some  
>>> value of
>>> "major" and "minor", of course :)
>>
>>
>> Um ... I might be slow or something but can you explain to me  
>> again how this makes things simpler/easier/whatever? Where is (in  
>> terms of pain associated with it) the difference between having  
>> that MCC map and posting it to an update stream? (unless you don't  
>> do it at all ;-)
>>
>> And using images this way ... uh, oh. I have a *really* bad  
>> feeling about this one. You're right, it's often easier to do  
>> things in your image and distribute that image. It's also a sure  
>> way of making it impossible for anyone to track ongoing  
>> development, the release progress, and the history of how things  
>> evolved in the image. All of which are (in my understanding) very  
>> desirable properties. I fear that this will lead to a process  
>> where you hand off "the image vX.Y" to a small group of people  
>> (possibly one) and get back "the image vX.Y+1" and hardly anyone  
>> will have looked at anything at all, noticed the oddities, which  
>> clean ups are required along the way etc. Not saying that many  
>> people today track the changes very closely but I even that seems  
>> preferrable to a process where you don't get to see anything and  
>> have no documentation of the changes the "official" image went  
>> through.
>>
>>> Yes, that's bad (for people with low bandwidth, for starters).
>>> However, it buys time to fix the issues with Monticello, so that
>>> hopefully later on a "upgrade v.X to v.Y" button can be reinstated.
>>
>>
>> Nice try. You know just as well as I do that this ain't gonna  
>> happen ;-) If only because when you give people the ability to  
>> modify an image "at home" they'll use it for *precisely* those  
>> changes that are hard to deal with in Monticello. Otherwise, why  
>> not use Monticello to begin with?
>>
>> Cheers,
>>   - Andreas
>>
>
>




More information about the Squeak-dev mailing list