Condensed Sources vs. Squeak Maintainence

Andreas Raab andreas.raab at gmx.de
Mon Jul 24 12:00:16 UTC 2006


 > 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
> 
> 
> 
> 




More information about the Squeak-dev mailing list