+ 1
Changes are necessary but costly so we should go stepwise.

Stef

> > Comments, suggestions, critique, all appreciated.
>
> Just one: The idea sounds great but can we keep the entirely  
> unrelated issues of a new source code subsystem and the particular  
> implementation of per-method properties separate? I don't see why a  
> new source code subsystem would require a particular implementation  
> of per-method properties and having the two issues separate allows  
> us to discuss and assess the merits independently.
>
> Cheers,
>   - Andreas
>
>
> Klaus D. Witzel wrote:
>> 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
>
>