The windows 7 build generated some weird permission issues: the toplevel
directory had a 000 permission as well as all *.exe files. Looks like
it is due to how cygwin translates the permissions of the C:\ drive. A
way to get around this is to have a build directory with pre-set
permissions that cygwin likes, then have the build directory in it.
(This hack might be needed for the other build machine too at some point
in the future.)
Also add /c/Windows/system32 to the PATH, otherwise MS batch files fail
(with obscure errors).
Checking that the optimized and non-optimized versions return the same
results is unnecessary. Optimization logs, which are checked against
an expected log, already contain the results.
(that is, I think that the complaints coming from the
tests\deinprogramm\test-docs-complete.rkt message are
now pointing out things for which there is actually no
documentation, instead of pointing out the need for
different declare-exporting declarations)
- the `lam' structure from `compiler/zo-struct' changed to include a
`toplevel-map' field
This change helps solve a finalization problem in `racket/draw',
which in turn sigificantly reduces the peak memory use of `raco setup'
during the doc-building phase (because some documents load `racket/draw'
to render images, and multiple copies of `racket/draw' were retained
before finalization was fixed).
The change is an extreme way to solve a specific finalization
problem, but it's a kind of space-safety improvement; space safety
almost never matters, but when it does, then working around a lack of
space safety is practically impossible. In this case, it's not clear
how to otherwise solve the `racket/draw' finalization problem.
The improvement doesn't change the representation of closures, but it
requires special cooperation with the GC. All closures in a module
continue to share the same array of globals (plus syntax objects);
that is, instead of completely flat closures, Racket uses a two-level
environment where top-/module-level variables are grouped
together. The code half of a closure now records which
top-/module-level variables the body code actually uses, and the mark
phase of GC consults this information to retain only parts of the
top-/module-level environment frame that are actually used by some
closure (or all of the frame if it is accessible through some other
route). In other words, the GC supports a kind of "dependent
reference" to an array that is indexed by positions into the array
--- except that the code is more in the "Racket" directory instead of
the "GC" directory, since it's so specific to the closure
representation.
