Smalltalk › Squeak › Squeak - Dev

[squeak-dev] Re: Newbie Questions

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

keith1y

[squeak-dev] Re: Newbie Questions

Cross posted because I think others may find this discussion useful:

Chris Muller wrote:

> Hi Keith, I think the work you did on Level-Playing Field and MC 1.5
> has always sounded fantastic.
>
>> implemented it. Magma users use a variety of images and Magma needs you
>> to have MCConfigurations working. Thats what LevelPlayingField in LPF
>> gives you.
>>
>
> So if it makes MC Configurations "work" why do *I* need to use it and
> not just those wanting to load Magma via MC Configurations?
>
>

You dont, but I kind of assume that you are a user too.

>> Also the issue of extensions to classes that don't exist in older images
>> is solved via the orphanage. MC1.5 doesnt complain like MC1 does.
>>
>
> This is again something that happens for those *loading* Magma, so is
> there a reason it is needed by the person doing the deployment? And,
> if so, and I do, will others who want to load it require MC 1.5 and/or
> LPF?
>
> The reason I have not moved on it after all this time, and I'm almost
> ashamed to say it, it has never bubbled up into the realm of
> critical-need that exceeded other priorities. Is LPF and MC 1.5 "drop
> in and go?", completely compatible with existing mc packages?
>
> Thanks..
> Chris
>

It should be more so.

The original MC1 made no effort to make anything compatible with
anything else. It uses a simple binary storeOn: so save its binary data.
This means that if you add an instance variable to any class in MC1's
model, your packages are incompatible with past MC1's This is what
happened, the MC in 3.9 added support for traits, and so packages saved,
with that MC are incompatible with previous MC's.

MC1.5 knows about this, and if a model class is realised with have extra
data items, that it does not have inst vars for, it pops them into a
properties dictionary. Also, MC1.5 makes an effort to only save the
minimum amounts of instVars, so if your class does not have any Traits
it saves, only the non-trait oriented inst-vars, and in doing so in
theory the packages it generates should be compatible with even the
older non 3.9 MC's.

The original MC1 was very naive about handling errors. It would simply
retry anything that raised an error. There were a number of situations
that it did not handle well, such as renaming or re-ordering of inst vars.

MC1.5 takes a much more considered approach. It attempts to actually
make the class definition compatible with both the before and after
situations, when loading methods. Obviously this is not always possible.

In theory MC1.5 should handle more of the difficult cases, than MC1.0
did. However that doesn't stop people blaming MC1.5 if a package doesnt
load, and they may find that the old MC1.0 can handle it using its old
brute force approach.

Finally MC1.6 with atomic loading is really cool, its over 3 times
faster, which for something the size of Magma is a big deal. (However
last time I tried it there was a minor bug)

thanks for asking the relevant questions.

Keith

Bert Freudenberg

[squeak-dev] Monticello compatibility (was Re: Newbie Questions)

On 25.03.2009, at 12:05, Keith Hodges wrote:
> The original MC1 made no effort to make anything compatible with
> anything else. It uses a simple binary storeOn: so save its binary
> data.
> This means that if you add an instance variable to any class in MC1's
> model, your packages are incompatible with past MC1's This is what
> happened, the MC in 3.9 added support for traits, and so packages
> saved,
> with that MC are incompatible with previous MC's.

Well, actually, in MC1 the binary snapshot was nothing than a speed
optimization. It stored the source code as text, too. If the binary
snapshot loading failed, it fell back to parsing the source. Has this
changed?

> MC1.5 knows about this, and if a model class is realised with have
> extra
> data items, that it does not have inst vars for, it pops them into a
> properties dictionary. Also, MC1.5 makes an effort to only save the
> minimum amounts of instVars, so if your class does not have any Traits
> it saves, only the non-trait oriented inst-vars, and in doing so in
> theory the packages it generates should be compatible with even the
> older non 3.9 MC's.
>
> The original MC1 was very naive about handling errors. It would simply
> retry anything that raised an error. There were a number of situations
> that it did not handle well, such as renaming or re-ordering of inst
> vars.

Indeed. Or annoying issues like not sorting class vars leading to
spurious conflicts.

> MC1.5 takes a much more considered approach. It attempts to actually
> make the class definition compatible with both the before and after
> situations, when loading methods. Obviously this is not always
> possible.
>
> In theory MC1.5 should handle more of the difficult cases, than MC1.0
> did. However that doesn't stop people blaming MC1.5 if a package
> doesnt
> load, and they may find that the old MC1.0 can handle it using its old
> brute force approach.
>
> Finally MC1.6 with atomic loading is really cool, its over 3 times
> faster, which for something the size of Magma is a big deal. (However
> last time I tried it there was a minor bug)

Sounds rather nice. Wish I could spend more time playing with it. I
have a question though:

How does the Installer-based 3.11 development style go together with
Monticello packages? Wouldn't every bug fix installed per changeset
from Mantis make the packages dirty?

- Bert -