Condensed Sources vs. Squeak Maintainence
stéphane ducasse
ducasse at iam.unibe.ch
Mon Jul 24 21:19:26 UTC 2006
+ 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
>
>
More information about the Squeak-dev
mailing list
|