release team proposal

Ralph Johnson johnson at cs.uiuc.edu
Sat Nov 25 05:32:59 UTC 2006


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 atomically.
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 fully.

No code is every tested fully.  The question is whether it is tested enough.
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.

-Ralph



More information about the Squeak-dev mailing list