Hi Marcus,

since every other project (package) depends on the integrity of the source  
code mechanism, I hereby volunteer to get a new source code subsystem  
(incl. code history) done during this summer. We have no time to wait for  
a new (reliable, scalable, available) source code mechanism, so I intend  
to make resources available for this project.

Here's a draft for a new source code subsystem:

0] (digit for Wolfgang ;-) there are at least three preferences:

1] use the traditional subsystem as is

2] use Dan Ingalls Source Compression as suggested earlier

3] use a service based (network based) mechanism

I've studied the recent additions which where made to CompiledMethod  
w.r.t. MethodProperties, this has to be cleaned up before anything else  
can be done.
	No, I'm not a friend of storing any MetaData *in* the meta data's object.
I propose to put the MethodProperties into the MethodDictionary where they  
belong (same method can *and will* have different properties per class =  
one MethodProperties in each class' method dictionary). As a consequence,  
today's MethodProperties would all be garbage collected (except for the  
few pragmas), because all they store is the selector. And  
CompiledMethod>>#selector is resolved by #methodClass and #keyAtValue: so  
#who can disappear as is intended.

After that, the *new* source code information can be put into the new  
MethodProperties, which allows an easy migration because the old source  
code pointer won't be touched until after migration.

Comments, suggestions, critique, all appreciated.

/Klaus

On Mon, 24 Jul 2006 09:16:58 +0200, Marcus wrote:

>
> On 24.07.2006, at 08:46, Peace Jerome wrote:
>
>> Hi all,
>>
>>
>> I've noticed that condensing sources is on the todo
>> list of the 3dot9 gamma push.
>>
>
> One of the problems is that the .changes is limited to 32 MB,
> and 3.9 7048 is already 25MB, which means people would
> very soon see the limit in normal use (e.g. when loading a bunch
> of packages).
>
> Another problem is that if we remove the linefeeds in those
> couple of hundrets of methods and do a bit of more _ conversion
> (which is intended), then we even hit the 32MB limit while
> in 3.9alpha.
>
>> One of the deliverables with 3dot9 final should be a
>> 3.10 with all changes from 3.0.
>>
>
> This is not possible because of two reasons:
> 	- the MC based process is broken, we can't load from 3.0
> 	  to get 3.9beta. Yes, bad. I am taking full responsibility.
>            (We have the complete code history, though. Just not
> easily loadable)
>   	- The changes file would hit the 32MB limite before you would get
> 	  a complete 39beta even if it would work in theory.
>
> Besides keeping the source, I'm sure you would want to keep
> the changeset information, too. Cost: 5MB of image size for 3.9 alone.
>
> So just for a 3.9 with all changes, all in all we are talking about
> 30MB that nobody needs but system developers. Do we *really*
> want to ship that to all the users?
>
> The history mechanism of Squeak does not scale anyway. Why
> only ship the history from 3.0? why not the *complete* history? What
> do you do in 10 years? 7MB left in the changeset is kind of small...
>
> The whole history mechanism of Squeak does not scale: There
> is no need at all to have the old versions on the local disc at all.
> What we need is a server that has the complete history that
> then can be queried from the clients, everthing else makes
> no sense.
>
> For now, we should keep of course the latest beta version with the
> history of
> 3.9 available. Just that it's not called "3.9", but "3.9 dev" or
> something
> like that.
>
> And we should get a student to work on that code history project...
>
>         Marcus