release team proposal
trygver at ifi.uio.no
Mon Nov 27 10:38:26 UTC 2006
Here's a class initialization scheme that worked well with in the past:
1) The classes of a package are loaded in any sequence (but not
2) Class initialization is done by a kernel method that initializes
ALL classes as follows:
2a) First, send #initialize to ALL classes that have it implemented.
someClass class>>initialize initializes constants etc. It is local
to the class, only using kernel classes such as String, Integer, ...
2b) Second, send e.g., #squeakInitialize to ALL classes that have
it implemented. someClass class>>squeakInitialize sets up required
links. It can reference any class, since all classes have been loaded.
2c) If #squeakInitialize can only be run in a certain sequence, the
classes are too fragile and should be redesigned.
3) Some library classes did not tolerate repeated initializations. We
regarded that as a weakness and fixed the offending classes to enable
the above scheme.
On 25.11.2006 06:32, Ralph Johnson wrote:
> On 11/24/06, Keith Hodges <keith_hodges at yahoo.co.uk> wrote:
>> I put forward some work I am doing as a kind of example scenario, how
>> would the process handle this one, kind of thing.
>> I am looking at pulling together some recent tweaks and bug fixes to the
>> DateAndTime code. (see mantis 474 which doesnt have my final code as yet
>> , see below).
>> Atomic loading might help, since loading in code that modifies
>> DateAndTime-#now, really upsets the code that is loading and time
>> stamping the newly installed methods as they are compiled. As soon as
>> someone calls #now, before the class is fully loaded and importantly
>> before the class has been initialized we crash and burn.
> i don't know the answer to this, but I will guess.
> I am far from a Monticello expert, but I have been looking at the code.
> It looks to me that class PackageLoader could be changed to load
> Basically, instead of making one pass through MCDefinitions (such as
> MCMethodDefinition, MCCLassDefinition and MCScript) and loading each
> one, the PackageLoader should first make a pass doing a preload and then
> a pass doing a load. Classes will be loaded during the preload and
> methods will be compiled during the preload, but actually installed during
> the load.This would mean that you wouldn't run the compiler during the
> actualy loading of methods. Something similar would have to be done
> for unloading.
> Do people who know more about MC than I do think this would work?
>> Second Problem, I am struggling to work out how to test my new code
> No code is every tested fully. The question is whether it is tested
> Perhaps you should settle for less complete tests.
>> 1. It turns out that the millisecondClockValue supplied by the vm, is
>> one of those SmallInteger things which will roll over every once in a
>> while. One needs to set up the scenario just before and after the roll
>> over in order to see that everything is handled smoothly.
> Mock up the millisecondClockValue from the VM. Make a little "clock"
> object that you can replace with a mock object for testing.
>> 2. I have organised this implementation around a call
>> #milliSecondsSinceMidnight, and it is necessary to test that the
>> transition from 23:59.59 to 00:00.00 also goes smoothly.
>> So within my test environment I have no control over the vm's
>> millisecondClock. Secondly all of the interesting things, like timing
>> offsets are stored in Class variables so my test code can't really mess
>> with them. The best I can probably manage is to test the 'algorithm' and
>> hope for the best. Any ideas?
> Mock these as well. Redesign the class so it is easy to test.
> Or just have easier tests.
Trygve Reenskaug mailto: trygver at ifi.uio.no
Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver
N-0378 Oslo Tel: (+47) 22 49 57 27
More information about the Squeak-dev