[squeak-dev] Bootstrapping closures

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Bootstrapping closures

Eliot Miranda-2
(subject changed; was Anyone know the following about Slang?)

On Mon, Jul 7, 2008 at 3:18 AM, Keith Hodges <[hidden email]> wrote:
Eliot Miranda wrote:
David,

   thanks a lot!  I have some integration to do :)   Not least I want to integrate the pragma support in 3.9 back into 3.8 because using pragmas instead of the null statements (self var: #foo type: #barf) etc is so much nicer.  I also have to produce bootstraps for the closure compiler in a few images, e.g. Croquet 1.0, 3.9, 3.10 & Spoon.  Once I get the Croquet bootstrap done I would welcome volunteers for the others.

cheers!
I am curious as to how you intent to distribute these backported bootstraps? Is this something http://installer.pbwiki.com/LevelPlayingField can help you with?

I'm not yet sure how I'll distribute.  Ideally I think a set of Monticello packages plus a Monticello package containing a bootstrap script.  This is what I have internally for our Qwaq Forums image bootrtap (derived from Croquet 1.0, in turn derived from 3.8).

But when I tried to modify this bootstrap to boot a minimal 3.8 for testing the new VM I failed to get it working and gave up after about a day and a half.  The thing I know will work is a set of change sets but that's not ideal.  

Thanks for the pointer to LPF.  That could indeed help.  But the real issue with this bootstrap is the related changes straddling Compiler (a new compiler for Closures), Kernel (a new BlockClosure and related changes in ContextPart, InstructionStream, CompiledMethod et al), System (new specialObjectsArray etc) and Tools (new interface between debugger and contexts).  It is really easy to break the debugger when loading the bootstrap incorrectly and that makes working out what's wrong tricky.  So progress is slow.

Moving to change sets is easier because one doesn't have to filter out as many extraneous changes in a package which are the result of other changes unrelated to closures.