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

Keith



 

Send instant messages to your online friends http://uk.messenger.yahoo.com