On Tue, 22 Aug 2006 06:02:25 +0200, Peace Jerome wrote:
> Hi Klaus,
>
> Thank you for removing a limitation from squeak.

Would not have been possible without introduction of MethodProperties :)

> I haven't had time to try your patches yet or even
> look at them.
>
> What I wanted to ask was would it be possible to
> extend the number of Source files the system could
> handle.

Easy: SourceFiles is an instance of SourceFileArray which inherits from  
SequenceableCollection.

> Two is a stupid limitation.
>
> The story I want is as follows
>
> for each branch of versioning we would have another
> level of source/changes
>
> in other words source for 3.0
> changes for 3.n
> newchanges for 3.n.m
> etc down to several levels.
>
> That would be a big win.

I agree, this is worth some effort.

> The only file you would have to ship would be the
> change file that matched the current level of image.
> The high level changes would act as source.
>
> We get recursive fractal behaviour and an easy way of
> developing source and distributing changes. Much more
> organic that the current way.
>
> ---
>
> So questions.
>
> Is it possible?

Yes. I want it, so it is possible :)

> How many bits do we need to trade off from the other
> address space?

None (when my patch is used) besides that more tests are needed. The new  
file index is a regular instance variable (in MethodProperties) and even  
could point to a database in the way that Tim remarked in his response.

What I want the community to think about [loud] is, that migration can  
(but must not) address DoIt's as well (was suggested by Stef).

My plan is to scan [at least] all class definitions from the DoIt chunks  
and have them chronologically linked (like versions of methods are  
linked). In order to then access them, sort of "ClassProperties" would be  
necessary for the tail of that linked list; perhaps ClassOrganizer can  
store another remote string oop.

> How much work might it be to do?

Two areas of change I can see: 1) the "release" mechanism, which would be  
responsible for adding the next element to SourceFiles and 2) today the  
.changes have constant file index 2, this has to be adapted. The rest is  
already in place (to be precise the patch does not address coexistence of  
old and new "prior:" links but that will disappear automagically once a  
new set of the files was written).

> Are there resources to do it?

Yes. As discussed with Marcus (here some time ago) the patch waits for 3.9  
final. Until then I'd like to get a bit more than just an idea from where  
and how the historical .sources and .changes can/must be taken. As part of  
migration, the "prior:" link of all "headers" in these files needs to be  
rewritten.

I expect to see more inconsistencies in the current "prior:" links, like  
the two examples I posted earlier. This will require extra resources  
(especially the collective memory of the Squeak community) for finding  
solutions.

/Klaus


> -----
>
> Yours in service, --Jerome Peace