<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Eliot,<div><br><div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div><br></div><div>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.</div> </div></div></blockquote><div><br></div><div>I did that already. See <a href="http://www.mirandabanda.org/files/Cog/Closures0811/Bootstrap/README.txt">http://www.mirandabanda.org/files/Cog/Closures0811/Bootstrap/README.txt</a> from <a href="http://www.mirandabanda.org/cogblog/downloads/">http://www.mirandabanda.org/cogblog/downloads/</a>. There are two problems with this.</div></div></blockquote><br>thanks for these<br><div><br></div><blockquote type="cite"><div class="gmail_quote"><div>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 <span class="Apple-style-span" style="font-family: monospace; font-size: medium; white-space: pre-wrap; "> Croquet 1.0& Squeak 3.9<span class="Apple-style-span" style="font-family: arial; white-space: normal; font-size: small; "> 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.</span></span></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Do you think that this would help?</div><div><br></div><blockquote type="cite"><div class="gmail_quote"> <div>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</div> <div><br></div><div>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.</div><div><br></div><div>b) it is pointless; Pharo, and Cuis </div></div></blockquote><div><br></div><div>Can allegedly be rebuilt on top of their pre-closure starting point.</div><div><br></div><blockquote type="cite"><div class="gmail_quote"><div>and Squeak trunk</div></div></blockquote><blockquote type="cite"><div class="gmail_quote"><div> have all moved on from their pre-closure starting point. What they need is incremental bug fixes installing in their current state. </div> <div><br></div><div>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.</div></div></blockquote><div><br></div><div>How about, LPF loads MC1.5 into 3.8 and etoys2.</div><div><br></div><div>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.</div><div><br></div><div>or am I an incurable optimist?</div><div><br></div><div>regards</div><div><br></div><div>Keith</div></div><br></div></body></html>