Why aren't they "real" images? And, following on the discussion on packaging, MC, update stream yes/no - what is the current strategy of the 39a team to get updates in the 39a canonical image? Is there any way I can help? I submitted half a day's worth of work last monday but didn't hear anything back. No I might be a patient guy <cough> but in order to motivate people to help in this process we need a roundtrip that's considerably shorter (ideally in the order of 24-48 hours during alpha stage).

On 10/22/05, Marcus Denker denker@iam.unibe.ch wrote:

On 22.10.2005, at 09:34, Juan Vuletich wrote:

...

The image is at http://ftp.squeak.org/3.9/ . Where are the scripts?

BTW, what are http://ftp.squeak.org/3.9/Squeak3.9a-6693md4.zip and http://ftp.squeak.org/3.9/Squeak3.9a-6693md5.zip ?

As we can't do "real" images, I did an image containing the latest content of the repository. I guess they are just confusing, so I will delete them.

  Marcus

On 10/22/05, Marcus Denker denker@iam.unibe.ch wrote:

Because we have a problem with making real ones...

Still - it begs the question: what is a 'real' image?

I mean, up to some days ago, nobody cared *at all* about moving things forward and now suddenly we want 24 hour reaction time? Why not trying something in between those extremes first?

I'm saying that I think it's a goal we should strive for. Note that I'm not saying this for the first time. And we've got some build-up of enthousiasm and the teams, I would hate to lose that because their work doesn't make a round trip quick enough to keep them enthousiastic..

Another problem: I directly sent you a mail that it will take a while to integrate your changes.

That's another issue the 39a team needs to work on, yes. Stef asked specifically to integrate this work. I spend half a day to do it, and then receive back from you a mail that it will take a while to integrate the work.

Note, again, that it'll be hard to put me off :), but I'm concerned mostly about us whipping up package teams at one end and having no place to go for their work at the other end...

Andrian and Daniel spend *weeks* on that stuff, with "first come first serverd" changes like these will never make it.

Sure they will. At least, that's how I always did this sort of stuff (and I worked in some *very* complex environments, think supporting a matrix of 15 operating systems, 10 databases, and at least three branches of development): you branch for a big integration, and constantly feed back smaller patches from the trunk. In that way, you never wander off too far, nor lock the trunk because everyone has to wait for a big change (which seems to be the case now?).

We tried the 'lock the trunk for a big change' approach a while, but it pissed off the developers. Now, in this corporate setting we could hold out for a while by just telling them to stop whining and go back to work, but somehow I think that in a volunteer setting this approach would be even less succesful :)

it's not my day-job, so there is no way that I can provide a 24h service.

Fine with me. And I'm not saying we must provide 24h response overnight, just that I think for psychological reasons that 24-48h is something to strive for.

And, I repeat - with your being busy, is there anything I can do? The last time I asked, I got the ToolBuilder/PlusTools stuff thrown at me, but that clearly wasn't the right thing to spend my (very precious) spare time on...

On 10/22/05, Marcus Denker denker@iam.unibe.ch wrote:

An image build in a way that we don't need to replace in in the future, and build by taking the last one "load updates" and be done.

Ok, so the update stream lives on.

One of the problems right now is that the image is around 20MB large after loading the latest from the repostory...

That issue was fixed - dunnow whether it's in some version of the code. but even I remembered that mail passing by:

McHttpRepository>>flushCache super flushCache. readerCache := nil

brings my post-PlusTools back to <<20Mb

I am not up to speed with harvesting, so I everything need to be taken a bit with a "I need to check that". But the problem with Traits is that it changes the system in a way that can't be merged with Monticello.

So let them publish an image and work from there?

I'm fine either way, but then at the very least I want a big red trafficlight on the frontpage on whatever website that signals "please do not do ANY work on 3.9a until Traits is in, because it'll be worthless".

Not money, but unclear communication is the root of all evil :)

Ok. Back when harvesting was done with changesets and nobody cared too much, we had a good reaction time in some cases... but mostly, reaction time was *months* even for stuff like typos in class comments.

Yup. And we complained about that, and we set about making it better - and I'm quite confident that we're on the correct path. If there are hurdles on the road, fine. But I think that the 3.9a team must then immediately pull the brakes (on squeak-dev, at least), tell everyone to stop what they're doing, and wait for event X to happen.

...

That issue was fixed - dunnow whether it's in some version of the code. but even I remembered that mail passing by:

McHttpRepository>>flushCache super flushCache. readerCache := nil

brings my post-PlusTools back to <<20Mb

I tried when avi sent it did not work with my machine. But now everything I do is strange.

...

I am not up to speed with harvesting, so I everything need to be taken a bit with a "I need to check that". But the problem with Traits is that it changes the system in a way that can't be merged with Monticello.

So let them publish an image and work from there?

Yes but this is not that simple. Because we do not want that people just complain because z or x

I'm fine either way, but then at the very least I want a big red trafficlight on the frontpage on whatever website that signals "please do not do ANY work on 3.9a until Traits is in, because it'll be worthless".

Not money, but unclear communication is the root of all evil :)

...

Ok. Back when harvesting was done with changesets and nobody cared too much, we had a good reaction time in some cases... but mostly, reaction time was *months* even for stuff like typos in class comments.

Yup. And we complained about that, and we set about making it better - and I'm quite confident that we're on the correct path. If there are hurdles on the road, fine. But I think that the 3.9a team must then immediately pull the brakes (on squeak-dev, at least), tell everyone to stop what they're doing, and wait for event X to happen.

Not really Traits is not impacting everything. Just Kernel and some browsers.

On 23 oct. 05, at 12:58, Cees De Groot wrote:

On 10/23/05, stéphane ducasse ducasse@iam.unibe.ch wrote:

...

I tried when avi sent it did not work with my machine. But now everything I do is strange.

Ok that one crossed with my slightly irritated answer, so you saw it. Ignore the irritated tone of that mail, in that case :)

But, please - for the interest of good communication - if you have a known condition where your image behaves differently from everyone's image, will you please be precise in your communications and say "there is a bloated image bug with *my image*"? So we can count heads, so to say, instead of assume that there is a general problem?

Sure but I could imagine that I would get a different behavior taking the same image as everybody. If you read the package mailing-list you will notice that avi did not understand why I got conflicts while he did so at that time I simply thought I was stupid.

Now I really want to find why I get this irritating behavior. May be I do something different.

Not only will it help communicating what the problem is, but als, I fear, you'll otherwise risk going the same way as the boy who cried wolf...

About Traits: when Traits is in, I'll do an MC merge of the ToolBuilder/PlusTools packages and re-stuff the inbox. (until that time, I'll keep my hands off 3.9a ;-)) So consider that bit of work still to be on my plate.

Ok

On 22.10.2005, at 20:32, Andreas Raab wrote:

Marcus Denker wrote:

...

Yes, I understand that. The problem is that there is suddenly comming everything at once: The problems with actually putting out a new image, having the traits guys looking at hundrets of methods one-by-one by hand, and the tools Tools-Plus changes... (I gave up on integrating the changes for method annotation and the new compiler for now till the dust settles)

Correct me if I'm wrong but how would changes for traits significantly interact with the PlusTools patches?

If you look at http://bugs.impara.de/view.php?id=1915 you'll find that most of the changes are pure additions or reclassifications (known not to have any impact whatsoever); the second largest group are trivial changes just to keep the system work when the tools are unloaded (e.g., making sure some services are not classified as Tools) and only a few change sets have the potential to have any significant overlap with traits. In fact, I can only imagine two change sets to have any overlap with traits whatsoever, which would be those changing references from concrete tools to ToolSet (ToolRefs.cs and ToolSetRefs.cs).

Based on this and based on my inability to have a look at a recent traits version, I would guess that if you leave out those two everything should be just fine.

Ok, yes, that sounds reasonable. And it's exaclty the kind of information that I meant with "need to be checked". So now I only need to find time...

I should maybe have phrase the answer to why toolsplus has not been looked at last week just with the answer: "I had no time to look at it at all".

...

I am not up to speed with harvesting, so I everything need to be taken a bit with a "I need to check that". But the problem with Traits is that it changes the system in a way that can't be merged with Monticello.

Uh. You mean traits cannot be loaded and unloaded at will? Uh. I have a baaaaad feeling, Luke.

I am no expert on the traits implementation... Adrian?

Marcus

So what are the conflicts? Recalling in the past we had a class reshape error in the changes stream because of how the background downloading of the change sets interacted with how the class reshape logic was reshaping instances. This was only evident under certain conditions related to how fast/ slow your connectivity was.

On 26-Oct-05, at 11:06 AM, stéphane ducasse wrote:

on my other mac I took the latest vm of john - 3.8.9beta7 - the latest image 6693 and update and I get conflicts and I do not understand........why.

Stef

-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

Marcus Denker wrote:

Another problem: I directly sent you a mail that it will take a while to integrate your changes. One of the reasons is that we can't right now update the image, another is that, as I said, we need to carefully look into how these change interact with traits.

Out of curiosity: What is the status of traits? What conflicts exist and need to be addressed? Where can I have a look at the current version to see what potential conflicts there are and how to work them out?

For the records, I have of course tried to load the 3.7 traits version from SqueakMap but to no avail - it takes about an hour before it dies with an "error during install: PureBehavior class>>compiledMethodAt:ifAbsent:". And when I try to open a debugger I get repeated errors of the same sort so it's no good even to try to understand what is going on here.

Why do we now need to rush everything? We managed to do nothing for 8 Months while waiting for 3.8, so why now suddenly the rush?

How about "because we would all like to avoid such delays in the future"? Is that good enough of a why? ;-)

Cheers, - Andreas

On 10/23/05, stéphane ducasse ducasse@iam.unibe.ch wrote:

But again we cannot expect people to react in 24-48 hours.

A person, no. A team, yes. That's why I am trying to find out what the bottlenecks in this process are and how we can spread them among many shoulders.

(gee... maybe I have some manager blood in me after all.. scary ;-))

On 10/23/05, stéphane ducasse ducasse@iam.unibe.ch wrote:

If you want to join the 3.9 release team, just ask.

Increasing the number of people you throw at a problem when you don't have the means to let them work in parallel usually is a recipe for disaster :)

That's why I'm trying to find out how work is done now, how to optimize it - for example by pushing responsibilities out to the various package Teams, etcetera.

On 10/23/05, stéphane ducasse ducasse@iam.unibe.ch wrote:

Sure this is why we have the wiki page for the pending actions that we want to handle.

http://minnow.cc.gatech.edu/squeak/5645 I assume? Is it up-to-date?

If help is needed, I'll gladly join the team as a junior member ;)

But isn't it wiser to stall the process for Traits if integration is waiting for that? Is there a possibility to help with getting Traits packageable?

On 23-Oct-05, at 3:48 AM, Cees De Groot wrote:

On 10/23/05, stéphane ducasse ducasse@iam.unibe.ch wrote:

...

But again we cannot expect people to react in 24-48 hours.

A person, no. A team, yes.

Only if they are fulltime engaged in supporting you. Which almost certainly means paid. Are they?

tim

On 23 oct. 05, at 19:09, Cees De Groot wrote:

On 10/23/05, tim Rowledge tim@rowledge.org wrote:

...

Only if they are fulltime engaged in supporting you. Which almost certainly means paid. Are they?

Nope. Nor do I think that's a necessary requirement. The crucial factor is to make it possible that any member of the team can respond (integrate a submission) and that this takes little work (both to get 'into' the job and to execute the job).

the problem is that until recently this was not a little work since we had to make sure that we could built an image.

Also note that I'm not talking SLA's here. Just something to strive for to keep the stewarding teams, harversters and individual patch submitters happy. If you handle the majority of cases quickly, no-one will object (or run to a lawyer, or want to get her money back) if some cases take longer. But you will have the advantages of simple Pavlovian psychology working for you...

Exact. If you remember when ned was harvesting, I was trying to do that with his fixes so that he continues to clean....

Stef

Hi Adrian -

Thanks for the update. I will admit that based on what you write I'm not entirely sure what a realistic deadline for traits integration may be (do you have one?). It looks like you're probably several weeks away from a version that could be tested and that testing will (given the complexity of the changes) likely take another couple of months. Since I'm not sure it's worthwhile or necessary to "hold still" for such a long time, so let me ask a question:

Have you guys ever considered that, instead of doing open heart surgery on a conscious patient, e.g., reformulating core-classes while the system is running, you might as well evolve it sideways?

I got this idea a while ago when I got so pissed about some of the changes that have been done in 3.7 that I started looking for maintaining "my own metaclass hierarchy" in a way that would isolate me from being dependent on those changes and it turns out that this is surprisingly simple. All you need is a basic metaclass hierarchy, a classbuilder that allows you to insert new metaclasses (nothing you want to do casually, but in these cases it's really useful) a single recompilation after loading, and voila! There is your parallel class hierarchy functioning just as well as any other.

Why is this advantageous? Two reasons mostly: For one thing, it allows people to load traits side-by-side with the existing class kernel (and be able to unload it which I think would be a VERY useful property) without the fear of breaking their formerly stable system. I would also think that this approach would allow you guys to push the core parts a lot earlier than otherwise possible - it may not be enabled by default, but it allows people to play around, fix any issues (like Monticello, browsers etc). And when the time comes, all you do is to pull the big switch and turn everything over to a traits metaclass hierarchy.

If you're interested in this, I've put you an example of such a bootstrap up at Squeakmap:

http://map1.squeakfoundation.org/sm/packagebyname/MetaclassBootstrap/

which should load into any 3.8/3.9 image and will create the basic kernel required to boostrap the new metaclass hierarchy. When it's loaded, inspect any MyObject subclass and notice the variables foo, bar, and baz in its class and Metaclass which were added by MyBehavior (that's just to show that indeed, MyObject is defined by the MyBehavior hierarchy). All subclasses of MyObject are created as MyMetaclass instances and you can actually create new instances with a specific metaclass by extending Class to take the metaclass in question and pass it to MyClassBuilder[*]. You can see an example of that in MyMetaclass class>>initialize which does the initial bootstrap of changing MyObject from its regular metaclass to MyMetaclass.

So what this gives you is the ability to bootstrap a perfectly self-contained class kernel which you can then hack to the best of your abilities :-) Even better, you can convert that kernel between the different metaclasses which can be quite advantageous when things get too nasty.

What do you think?

Cheers, - Andreas

[*] For those interested, there is an interesting anomaly when you add new metaclasses: It is necessary to change the meta class inheritance, e.g., although "MyObject superclass == Object" it is the case that "MyObject class superclass ~~ Object class" but rather MyClass. Why is that? Because having a superclass implies identical shape for the subclass and since our new metaclasses can be completely different from the old ones (in the example, I added foo, bar and baz) we cannot inherit from any but the same kind of metaclass. This also implies that any non-inherited class methods cannot be called; e.g., "MyObject windowColorSpecification" will raise a DNU despite the fact that windowColorSpecification is implemented in Object class (which MyObject class no longer inherits from). Which really all just goes to say that if you do a bootstrap you should probably do it completely, e.g., with a nil subclass to avoid nasty surprises. But for experiments like we're talking about here this is still very cool and useful :-)

Adrian Lienhard wrote:

1. The current work needed to bring traits to 3.9 is integrating the

relevant changes that were done in 3.8 and until now in 3.9. The initial implementation was done in 3.7, thus, what we now have to do (and Daniel and I partly already did that) is integrating changes. This is not that trivial because for example methods were moved into traits in the new kernel to avoid code duplication. However, to be able to use MC's diffing, we did some tricks (flattening classes) that help us in the process. What then remains is the methods that should actually be removed (e.g., because they were deprecated), added (e.g., new behavior of the new kernel) and conflicting changes. This is the next task that has to be done based on a fixed Kernel version of 3.9a (this has to be fixed because else we just end up redoing it again). This should also answer the question about waiting for traits with further harvesting: it should be enough for us to have the Kernel package frozen until our stuff gets in because this is where most of the changes are. So, harvesting in other packages is ok.

2. The next part of the story is doing the bootstrapping, that is,

having a set of versions that can be loaded in a specific order into a current 3.9a image.

3. When having finished with these two steps we should finally be able

to load the new traits-aware kernel, and start doing remaining cleanups (e.g., moving class extensions into correct packages), adjustments (making the code browser and other UI stuff work with traits) and testing/bugfixing.

4. The other parts are the UI (Daniel worked on a new OB browser),

traits-aware MC and fileIn/Out (already exists but a review would be good) etc.

I'm not sure if it really makes sense for step 1) and 2) to have help because the coordination overhead is quite big. Currently Daniel does not have time to help here, so I will do it in the next weeks.

But for 3) and 4), when we actually have something that can be loaded in 3.9, help would very much be appreciated.

Daniel, anything to add what I forgot?

Adrian

On Oct 23, 2005, at 1:00 AM, Andreas Raab wrote:

...

Marcus Denker wrote:

...

Another problem: I directly sent you a mail that it will take a while

to integrate your changes. One of the reasons is that we can't right now update the image, another is that, as I said, we need to carefully look into how these change interact with traits.

Out of curiosity: What is the status of traits? What conflicts exist and need to be addressed? Where can I have a look at the current version to see what potential conflicts there are and how to work them out?

For the records, I have of course tried to load the 3.7 traits version from SqueakMap but to no avail - it takes about an hour before it dies with an "error during install: PureBehavior class>>compiledMethodAt:ifAbsent:". And when I try to open a debugger I get repeated errors of the same sort so it's no good even to try to understand what is going on here.

...

Why do we now need to rush everything? We managed to do nothing for 8 Months while waiting for 3.8, so why now suddenly the rush?

How about "because we would all like to avoid such delays in the future"? Is that good enough of a why? ;-)

Cheers,

• Andreas

I'd love to see a Traits implementation that I can load, play with and unload even if it's not quite ready for use in production.

I plan to make a Traits module for Spoon like that; it should be easier since I already have a remote system browser which can deal with arbitrary remote system dictionaries. (The tools live in one object memory and Traits lives in another one.)

-C

On Oct 25, 2005, at 6:32 AM, Tony Garnock-Jones wrote:

Colin Putney wrote:

...

I second this idea. I did the same sort of thing when fooling around with different ways of representing code using packages. It's surprisingly easy, and a great way to experiment with stuff that would be really difficult to do to the core system without breaking it, at least temporarily.

Wow! I'd love to hear more detail about how this kind of thing is done. Where are the main gotchas? Where does one *start*?

Well, getting started is easy. Just develop your new classes as ususal. The tricky bits only come when you want to create instances of them. In my case, I used a class name prefix of CM to distinguish my sandbox from the core system. I just implemented CMBehavior, CMClass, CMMetaclass and so on. Then I wrote a little importer that would first create the core sandbox - nil, ProtoObject, Object and their metaclasses - and then import a set of packages into the sandbox.

Gotchas to look out for:

- behaviors must have the following as the first three instance variables: "superclass methodDictionary format".

- every object must be able to respond to at least one method, #doesNotUnderstand: if you try to send a message to an object with no methods at all, the VM will shut down in disgust.

- there's an anomaly where the metaclass hierarchy "wraps around" and becomes normal classes. For example, have a look at the difference between "ProtoObject superclass" and "ProtoObject class superclass".

And that's it. Have fun!

Colin

Hi Andreas

On Oct 24, 2005, at 1:41 AM, Andreas Raab wrote:

Hi Adrian -

Thanks for the update. I will admit that based on what you write I'm not entirely sure what a realistic deadline for traits integration may be (do you have one?). It looks like you're probably several weeks away from a version that could be tested and that testing will (given the complexity of the changes) likely take another couple of months. Since I'm not sure it's worthwhile or necessary to "hold still" for such a long time, so let me ask a question:

Its not that the amount of remaining work is in the range of weeks or month, rather days - but as you might imagine, the problem is as usual the limited time I can spend on this project. What I planned to do is working two days within the next two weeks and I think I should have a first working version that can be loaded in current 3.9a. Also worth mentioning is that "standing still" would be necessary for the kernel package only (or even only Kernel-Classes).

[...]

Why is this advantageous? Two reasons mostly: For one thing, it allows people to load traits side-by-side with the existing class kernel (and be able to unload it which I think would be a VERY useful property) without the fear of breaking their formerly stable system. I would also think that this approach would allow you guys to push the core parts a lot earlier than otherwise possible - it may not be enabled by default, but it allows people to play around, fix any issues (like Monticello, browsers etc). And when the time comes, all you do is to pull the big switch and turn everything over to a traits metaclass hierarchy.

Interesting - thanks for sharing this.

I see, this would make it trivial to (i) not force people to use the new code and (ii) unload/get rid of traits (for whatever reason). And therefore, would put less pressure on the "traits-team".

On the other hand, I see some quite important drawbacks, that have to be considered:

- the new kernel would not be used/tested as much as if it was the primary 3.9a kernel - duplication: all upcoming changes to the traditional kernel have to be done in parallel in the new kernel to keep it up to date - the alternative metaclass hierarchy helps running with two class kernels at the same time, but it does not help with other changes that are needed to make the system smoothly work with traits, such as adaptation of the code browser, fileOut/in, debugger and such. These are not that big changes but I don't see how we would make that work for the new and for the old code at the same time.

So, I definitely see your arguments but I fear, that this will make it rather harder to get traits in, in the end. The new code will break here and there, but that's basically the idea of running in alpha mode, isn't it? Somebody who needs to depend on a stable system, shouldn't use the alpha images either way.

In the worst case, if we should come to the conclusion that it just does not work or we have a better solution than traits or whatever, we can still go back to earlier MC versions of the modified packages and backport later introduced changes. That's not a one-click action and thus not an option for people that want to remove the stuff we added again. But I don't see why unloading is that important(?). If you don't want to use traits or even don't know about it, there's not much, if any at all, difference you would see compared with previous versions of Squeak.

So, what I suggest is, give me three weeks to produce a loadable version of traits in a current 3.9a image and then see how this works and what problems we run into. At this time we can decide whether we continue 3.9a with these changes or go for a split solution.

Cheers, Adrian

BTW: you mentioned in another mail problems with loading traits as it is published on SM? Did you load in a 3.7 image? That has been working for quite a couple of people... if you want to look at the implementation, then I suggest to use Daniel's image he posted a link to some weeks ago. What Daniel and I have been doing since then was only bringing it up to date with 3.9a, and working on the bootstrapping.

If you're interested in this, I've put you an example of such a bootstrap up at Squeakmap:

http://map1.squeakfoundation.org/sm/packagebyname/MetaclassBootstrap/

which should load into any 3.8/3.9 image and will create the basic kernel required to boostrap the new metaclass hierarchy. When it's loaded, inspect any MyObject subclass and notice the variables foo, bar, and baz in its class and Metaclass which were added by MyBehavior (that's just to show that indeed, MyObject is defined by the MyBehavior hierarchy). All subclasses of MyObject are created as MyMetaclass instances and you can actually create new instances with a specific metaclass by extending Class to take the metaclass in question and pass it to MyClassBuilder[*]. You can see an example of that in MyMetaclass class>>initialize which does the initial bootstrap of changing MyObject from its regular metaclass to MyMetaclass.

So what this gives you is the ability to bootstrap a perfectly self- contained class kernel which you can then hack to the best of your abilities :-) Even better, you can convert that kernel between the different metaclasses which can be quite advantageous when things get too nasty.

What do you think?

Cheers,

• Andreas

[*] For those interested, there is an interesting anomaly when you add new metaclasses: It is necessary to change the meta class inheritance, e.g., although "MyObject superclass == Object" it is the case that "MyObject class superclass ~~ Object class" but rather MyClass. Why is that? Because having a superclass implies identical shape for the subclass and since our new metaclasses can be completely different from the old ones (in the example, I added foo, bar and baz) we cannot inherit from any but the same kind of metaclass. This also implies that any non-inherited class methods cannot be called; e.g., "MyObject windowColorSpecification" will raise a DNU despite the fact that windowColorSpecification is implemented in Object class (which MyObject class no longer inherits from). Which really all just goes to say that if you do a bootstrap you should probably do it completely, e.g., with a nil subclass to avoid nasty surprises. But for experiments like we're talking about here this is still very cool and useful :-)

Adrian Lienhard wrote:

...

1. The current work needed to bring traits to 3.9 is integrating

the relevant changes that were done in 3.8 and until now in 3.9. The initial implementation was done in 3.7, thus, what we now have to do (and Daniel and I partly already did that) is integrating changes. This is not that trivial because for example methods were moved into traits in the new kernel to avoid code duplication. However, to be able to use MC's diffing, we did some tricks (flattening classes) that help us in the process. What then remains is the methods that should actually be removed (e.g., because they were deprecated), added (e.g., new behavior of the new kernel) and conflicting changes. This is the next task that has to be done based on a fixed Kernel version of 3.9a (this has to be fixed because else we just end up redoing it again). This should also answer the question about waiting for traits with further harvesting: it should be enough for us to have the Kernel package frozen until our stuff gets in because this is where most of the changes are. So, harvesting in other packages is ok. 2) The next part of the story is doing the bootstrapping, that is, having a set of versions that can be loaded in a specific order into a current 3.9a image. 3) When having finished with these two steps we should finally be able to load the new traits-aware kernel, and start doing remaining cleanups (e.g., moving class extensions into correct packages), adjustments (making the code browser and other UI stuff work with traits) and testing/bugfixing. 4) The other parts are the UI (Daniel worked on a new OB browser), traits-aware MC and fileIn/Out (already exists but a review would be good) etc. I'm not sure if it really makes sense for step 1) and 2) to have help because the coordination overhead is quite big. Currently Daniel does not have time to help here, so I will do it in the next weeks. But for 3) and 4), when we actually have something that can be loaded in 3.9, help would very much be appreciated. Daniel, anything to add what I forgot? Adrian On Oct 23, 2005, at 1:00 AM, Andreas Raab wrote:

...

Marcus Denker wrote:

...

Another problem: I directly sent you a mail that it will take a while

to integrate your changes. One of the reasons is that we can't

right

...

now update the image, another is that, as I said, we need to carefully look into how these change interact with traits.

Out of curiosity: What is the status of traits? What conflicts exist and need to be addressed? Where can I have a look at the current version to see what potential conflicts there are and how to work them out?

For the records, I have of course tried to load the 3.7 traits version from SqueakMap but to no avail - it takes about an hour before it dies with an "error during install: PureBehavior class>>compiledMethodAt:ifAbsent:". And when I try to open a debugger I get repeated errors of the same sort so it's no good even to try to understand what is going on here.

...

Why do we now need to rush everything? We managed to do nothing for 8 Months while waiting for 3.8, so why now suddenly the rush?

How about "because we would all like to avoid such delays in the future"? Is that good enough of a why? ;-)

Cheers,

• Andreas

Andreas Raab wrote:

...

So, what I suggest is, give me three weeks to produce a loadable version of traits in a current 3.9a image and then see how this works and what problems we run into. At this time we can decide whether we continue 3.9a with these changes or go for a split solution.

That sounds good to me and is definitely necessary. We should have something to talk about before we make any decisions.

Forgot to mention something: Personally, I don't really care how long it takes you (e.g., three weeks or three months) just as long as we agree that we'll find time for and actually have that discussion.

Cheers, - Andreas

To help adrian, we need feedback on the

- Kernel-dvf.35 - Kernel-dvf.36

in squeakFoundation/inbox

Here is a summary of the emails sent around:

Am I correct that you change is only in the method name: className inEnvironment: env subclassOf: newSuper type: type instanceVariableNames: instVarString classVariableNames: classVarString poolDictionaries: poolString category: category unsafe: unsafe?

I run the tests and you change breaks

ClassBuilderFormatTests>>testByteVariableSubclass ClassBuilderFormatTests>>testWordVariableSubclass

ClassBuilderChangeClassTypeTest>>testClassCreationAndChange was failing in 3.7, 3.8, 6693 and it is still broken.

Stef

I just run into MetaClassBuilderFix project on SqueakMap (description: "Fixes MetaClass reshaping bug seen after adding inst var. to ClassDescription") and related http://minnow.cc.gatech.edu/ squeak/3058. It seems to fix exactly this problem... I was not aware of this. Have you, Daniel?

I will look. Thanks. Stef

On 26 oct. 05, at 18:42, Brent Vukmer wrote:

I thought that the MetaClassBuilderFix (or perhaps an edited version of the fix) got put into the update stream for the 3.7 release (or maybe 3.8) ...

On 22.10.2005, at 14:23, Cees De Groot wrote:

Why aren't they "real" images? And, following on the discussion on packaging, MC, update stream yes/no - what is the current strategy of the 39a team to get updates in the 39a canonical image? Is there any way I can help?

Ups. Forget to answer that...

Help: yes!

The discussion about this seems to be mainly on the sqPackages list. I 'm not yet up to speed on the issue to give a good quick overview of the problem... so the best might be to look into the archiveL

http://discuss.squeakfoundation.org/cgi-bin/ezmlm-browse?list=packages

especially the mail by adrian:

http://discuss.squeakfoundation.org/cgi-bin/ezmlm-browse? list=packages&cmd=showmsg&msgnum=377

I will try really to find time to look into that next week...

Marcus

On 22.10.2005, at 15:57, Cees De Groot wrote:

On 10/22/05, Marcus Denker denker@iam.unibe.ch wrote:

...

http://discuss.squeakfoundation.org/cgi-bin/ezmlm-browse? list=packages&cmd=showmsg&msgnum=377

That mail is mostly about (interesting) MC issues, which are mostly important only if communication of new images is done with update streams, not? I mean, if you just run through the inbox and put the end result als 6694 on the FTP site, that'd work fine, not?

No. The mcz files can't be loaded one-after-another. they need to be loaded all together. And that mechanism has some strange bugs.

It's around 8MB too big, so the resulting image is not what you can use to build the next on with (with then will be 30MB).

Another problem is that we had problems to actually load it even with "loading all togetger", but I think stef managed to fix that.

As I said: I am a bit out of sync with all that... Sorry.

Marcus

On 10/23/05, stéphane ducasse ducasse@iam.unibe.ch wrote:

One of the problem left is that the image grows too much, even flushing the cache.

Gee, am I the only one who also reads mails here? Here's for the third time, and now completely out of the back of my head because it is so trivial, the patch that Idunnowho suggested a week ago, and I repeated yesterday:

MCHttpRepository>>flushCache super flushCache. readCache := nil

I may have the classname for the Http repository wrong, but as I said yesterday, this indeed gets my post-Plustools image back from 30+ to around 16Mb.

For the record:

- Win32 VM 'Squeak3.7 of ''4 September 2004'' [latest update: #5989]' - download 6693 image - save 6694 and 6695 changesets - open file list - select 6694 -> install - select 6695 -> install (takes a while indeed :-)).

After that, applied the MC patch, flushed all caches.

End result: - 14M image - BalloonMMFlash, EToys, FlexibleVocabularies, MorphicExtras are marked dirty in MC Browser (Monticello as well but I assume that's because of my manually applied MC patch).

Excellent.

For the record:

• Win32 VM 'Squeak3.7 of ''4 September 2004'' [latest update: #5989]'
• download 6693 image
• save 6694 and 6695 changesets
• open file list
• select 6694 -> install
• select 6695 -> install (takes a while indeed :-)).

Yes you see how you can lost focus :)

After that, applied the MC patch, flushed all caches.

End result:

• 14M image
• BalloonMMFlash, EToys, FlexibleVocabularies, MorphicExtras are

marked dirty in MC Browser (Monticello as well but I assume that's because of my manually applied MC patch).

Yes the marked dirty is a pending bug of MC. Great! In fact the 6695 is not loading the latest version (as the update stream does) since when I tried the latest script I got conflicts so I went back in time last friday and tried to find one script that would work....This is how I realized that I got a problem with my machine.

Stef