release team proposal
keith_hodges at yahoo.co.uk
Sat Nov 25 04:28:21 UTC 2006
I put forward some work I am doing as a kind of example scenario, how
would the process handle this one, kind of thing.
> What do you mean that MC doesn't do atomic loading? It only loads one
> at a time, doesn't it? Do you mean that it can die half-way through
> loading a
> package, with some classes loaded and some not? I know that normally
> a MC
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). As you highlight I don't currently know the process for
publishing these changes once they work. Nor do I have the tools with
which to achieve testing, packaging or distribution.
First Problem ref. your comment about Atomic loading (which I have heard
rumour MC2 does support! yay!)
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.
As I understand it atomic loading ensures that all methods are loaded
and classes initialised and actually ready to use before anyone 'out
there' in the system actually tries to use them. The new code is
'switched in' in one atomic operation, which will either work or break
things. The non-atomic situation frequently causes problems in the
part-loaded, not quite initialised state. Fixing fileIn with a fileIn,
or indeed tweaking the compiler is usually a no-no.
Second Problem, I am struggling to work out how to test my new code fully.
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.
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?
Without MC2, I was expecting to shrink KernelImage's Chronology to a
bare minimum, load an implementation with safe methods only, get
everything initialised and then load the unsafe methods in in a hand
crafted change set.
any further ideas would be appreciated
Send instant messages to your online friends http://uk.messenger.yahoo.com
More information about the Squeak-dev