[V3dot10] And to 3.10

[stephane ducasse]

On 19 janv. 07, at 14:30, Keith Hodges wrote:

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

why does the release team do not use pavel's removal?

> 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

Yes this would be good.

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

exact

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

You should publish that somewhere and ask for feedback in the mailing- 
list
Now I looked at SSpec in the past and I wonder why it is better than  
SUnit for what you want to specify (but this is another discussion)
I have the impression that for the image it would be good to have one  
single test framework.

> I have also pulled out the classes needed to support running in a  
> browser into a separate package.

I do not understand this one.

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


Sorry but what is the process of edgar?