[V3dot10] And to 3.10

[Keith Hodges]

As I understand 3.10 is not really about adding new functionality. I aim 
to test everything that is needed for the build process in 3.9.1, 
freeing 3.10 to focus on removing and refactoring things.

At present as I understand it 3.10 is 3.9 with some pieces removed. To 
move forward I think that we need to capture Edgars "piece removal" 
process. Then it can easily be applied to 3.9.1 also.

I think that some strategic work needs to happen at the other end of 
things, in the guts of the "untamed beast" in order to facilitate moving 
forward with 3.10. My reasoning being as follows:

Recently I was invited to help someone to fix a broken image. They had a 
broken Morphic process of some kind that was encouraging the vm to 
crash. I thought (naively) that I would be able to run a startup script 
that deleted the problem process. However it turns out in the current 
scheme that the startup document is not invoked until well after Morphic 
is up and running, and has crashed by then. I even tried creating my own 
update server to try and load the script. I couldn't even run a simple 
script at startup. Being able to solve this type of early startup 
problem should be a goal of the 3.10+ back to basics excercise. And as 
an aside, where is the Logging to tell me what is going on and where 
things went wrong?

So this got me thinking, what is the absolute minimum useful image that 
we might be left with after we have pulled out everything. My answer: an 
image that can run the equivalent of:  ruby -e "p 2+2" without any 
unnecessary activity such as initialising a display e.g.

#squeak minimalImage.image Script e="2+2"
#4

While Edgar is wielding the axe on some easier to remove components. I 
have noticed in relation to this idea that many pieces are difficult to 
remove. For example it is difficult to have a headless image with 
doesn't need any display functionality because in the autostart process 
all the bits like Display and Cursor etc are all initialised up front, 
and as I said the startup document is only run after the whole startup 
process is complete.

If the image can been trimmed this extent such that it is still usable 
well, then the process of reloading components reliably should then be 
much easier. (as discussed in the previous email)

In developing the auto-build process I have been looking at the 
AutoStart functions and thinking that they could really use a revamp.

So as a sub-project I would aim to write some tests which define the 
needed/expected behaviour of the AutoStart process. To do this I feel 
that SSpec may well be the better (than SUnit) framework. (as an aside 
SSpec in VW uses underscores in selectors, but hey you cant have 
everything).

I have already refactored AutoStart into something clearer and more 
flexible. I have also pulled out the classes needed to support running 
in a browser into a separate package. There is a fair bit of work needed 
to ensure that this fundamental re-write is going to satisfy the needs 
of the masses without breaking anything. The aim of the build system is 
to enable radical rewrites of this kind to happen, without being 
constrained by the "when I reload things" it will break everything 
problem. When I have finished the re-write I will solve the problem of 
loading it! Actually I hope that someone else will solve that problem by 
radically re-writing something else, i.e. by providing Atomic loading in 
monticello, or releasing MC2.

So... to 3.10, I am hoping that Edgar's process can be captured in the 
build system in  the From39To310, and at some point I can contribute 
this AutoStart replacement to that process too.

best regards

Keith




		
___________________________________________________________ 
Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html