Hi Eliot,

>
> If you write me an explanation of how to install closures, it will  
> be a lot easier to write if you say.... Start with a 3.10-release  
> image. Do a,b,c,d,e and you will have a closures image, we shall  
> call 3.10-closures.
>
> I did that already.  See http://www.mirandabanda.org/files/Cog/Closures0811/Bootstrap/README.txt 
>  from http://www.mirandabanda.org/cogblog/downloads/.  There are two  
> problems with this.

thanks for these

> 1. the closure bootstrap is tricky (ask Juan).  The closure  
> bootstrap has to replace the compiler in just the right order so  
> that the old compiler keeps working until the new compiler is ready  
> to take over.  Turns out that this is very sensitive on what you  
> start from.  The ocmpiler in 37 is different form that in 3.8 and  
> 3.9.  The compiler in a Croquet mage is different.  Things are  
> different if FFI is loaded, if Vassili's variadic ifNotNil: code is  
> in or not, if pragmas are in or not.  I provided two different  
> bootstraps  Croquet 1.0& Squeak 3.9 and did a third one in-house at  
> Teleplace.  I don't have the time to do a generic one and in fact I  
> don't think it's practicable.

Agreed, however I do think that this should be motivation to adopt  
AtomicLoading, it was one of our top priorities. It does work you  
know. It is just traits that are not supported.

Do you think that this would help?

> 2. the closure code has evolved since the bootstrap.  People found  
> bugs and provided tests and I changed the closure analysis to  
> compile inlined blocks (to:by:do: whileTrue: et al) correctly, and  
> fixed debugger bugs, and provided support for closurised compressed  
> temp names.  Then Igor reimplemented the compressed temp names/surce  
> pointer scheme to mase it much better and much more general.  I  
> discovered Colin Putney had done a really nice compiler error  
> formaework that wasn't in the original.  Now two things follow
>
> a) it is simply way too expensive to go back and revamp those two  
> bootstraps so that they end up at the new bugfixed improved code.
>
> b) it is pointless; Pharo, and Cuis

Can allegedly be rebuilt on top of their pre-closure starting point.

> and Squeak trunk
> have all moved on from their pre-closure starting point. What they  
> need is incremental bug fixes installing in their current state.
>
> So what are the instructions to install closures now?  As I'm  
> planning to do this for Etoys sometime soon this is not  
> hypothetical.  The basic approach is to compare the starting point  
> with the desired end-point packages (choose Compiler & Kernel- 
> Methods and sundry associated extensions, being familiar with the  
> compiler will make this easier, but its tediously error-prone).   
> Then produce a set of file-ins that gets from the starting-point to  
> as close to the end-pont ass results in a functioning compiler and  
> Monticello.  Load the relevant packages and you're done.

How about, LPF loads MC1.5 into 3.8 and etoys2.

So if I am not mistaken porting SystemEditor to 3.8 (if matthew hasnt  
already done it for cobalt), will provide AtomicLoading to, 3.8,  
etoys2, sophie, and Cobalt, amongst others.

or am I an incurable optimist?

regards

Keith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100125/9b457c08/attachment.htm