14 May 18:19
slate bootstrap bug status report
From: Timmy Douglas <lists <at> timmy.tmbx.com>
Subject: slate bootstrap bug status report
Newsgroups: gmane.comp.lang.slate.general
Date: 2007-05-14 16:19:59 GMT
Subject: slate bootstrap bug status report
Newsgroups: gmane.comp.lang.slate.general
Date: 2007-05-14 16:19:59 GMT
I've been looking into a bug in the bootstrap process.
After you make a new image with: Image bootstrapBasedOn: VM new, slate
tries to load that image, and that's where it fails. The image file
is made by parsing a lot of slate files which are defined in
build.slate and then concatenating them into one function that
initializes a normal slate environment. Since some of the functions
used in earlier files depend on functions fully defined in later
files, pre-bootstrap.slate is loaded first with some common functions
defined in simpler terms to keep things from crashing because of
missing dependancies.
However, somewhere in numeric.slate, things go wrong.
The first define:
numerics define: #Comparable &parents: {Cloneable}.
causes the Cloneable object to be transformed into a Compareable
object, and things go spiraling out of control when Float is defined,
which somehow causes the #traits3 = #traitsWindow to invoke
CoercibleNumberMixin's specializer coerceTo (because Symbol's
inheritance graph has changed to have Float where Cloneable would be),
which fails on symbols because they don't have a level.
I added this code to vm.c to realized this, but I'm not sure if the
code is correct:
#ifdef DEBUG_MSG
fprintf(stderr, "%d ", i->framePointer);
(Continue reading)
RSS Feed