On Sun, Jan 24, 2010 at 4:12 PM, keith <keith_hodges at yahoo.co.uk> wrote:

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

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.


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

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.


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

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.

The approach I've been taking does that merge as I go along.

or am I an incurable optimist?
>

I could care less ;)


>
> regards
>
> Keith
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100124/2e4c25b1/attachment.htm