<br><br><div class="gmail_quote">On Sun, Jan 24, 2010 at 4:12 PM, keith <span dir="ltr"><<a href="mailto:keith_hodges@yahoo.co.uk">keith_hodges@yahoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word">Hi Eliot,<div><br><div><div class="im"><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" target="_blank">http://www.mirandabanda.org/files/Cog/Closures0811/Bootstrap/README.txt</a> from <a href="http://www.mirandabanda.org/cogblog/downloads/" target="_blank">http://www.mirandabanda.org/cogblog/downloads/</a>. There are two problems with this.</div>
</div></blockquote><br></div>thanks for these<div class="im"><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 style="font-family:monospace;font-size:medium;white-space:pre-wrap"> Croquet 1.0& Squeak 3.9<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><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></div></div></blockquote><div><br></div><div>Yes, in those versions of Monticello that support it, and only if one can atomically load more than one package (I forgot to say that the closure compiler changes also touch System and Tools, not just Compiler and Kernel-Methods. So relying on solving a really hard problem (atomic loading) before one can solve a smaller problem (closures) wasn't a viable option this time around. But when it is available then of course it's the right approach, _provided_ every distro wants the same Kernel, System, Tools and Compiler and... they all differ, some (System, Tools) significantly. Oops.</div>
<div><br></div><div><br></div><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><blockquote type="cite"><div class="gmail_quote">
<div class="im"><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><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></div></div></blockquote><div><br></div><div>I doubt that very much. Of course it is possible, but not without hard work. A naive install of the changed packages will fall over horribly (for reasons I allude to above). At least you have to use a closure-enabled VM.</div>
<div><br></div><div><br></div><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><div class="im"><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-point as results in a functioning compiler and Monticello. Load the relevant packages and you're done.</div>
</div></blockquote><div><br></div></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></div></div></blockquote><div><br></div><div>I don't know, try it (porting SystemEditor and then trying to atomically load closures) and see. You still have to do a merge of the bits of Compiler, Kernel, System and Tools affected by closures to know what to load atomically.</div>
<div><br></div><div>The approach I've been taking does that merge as I go along.</div><div><br></div><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><div>or am I an incurable optimist?</div></div></div></div></blockquote><div><br></div><div>I could care less ;)</div><div> </div><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><div><br></div><div>regards</div><div><br></div><div>Keith</div></div><br></div></div><br><br>
<br></blockquote></div><br>