To get the expected contents of the various environment variables, I
used a similar approach to what the build does in `grab_batch_vars':
* Start a cmd.exe shell (not a real shell)
* Dump the env into a buffer
* Run "... Studio/VC/vcvarsall.bat" (modifies envvars, which is why cmd
is needed)
* Dump new env into a new buffer
* Sort both buffers and compare
Hopefully it still works also on Matthew's setup.
Two other small things:
* Use ".obj" suffix on windows to avoid warning.
* Catch error when trying to delete the .so file, since on the x86_64
machine it throws an error. (I'm not sure how it *doesn't* do that
with the i386 machine.)
This change significantly increases the speed of number formatting, making extreme-bounds-tests.rkt run in about 1/4 the time.
Should consider moving these into racket/math, since floor-log/base generalizes order-of-magnitude.
detect if a (n online check syntax) rename would conflict with
an existing name. (This can happen because the remote place's
custodian gets shutdown due to, for example, another tab's online
check syntax running.)
can get "stale" and cause DrRacket to deadlock (this commit just sets
up some stuff to make one fix possible, but that fix doesn't seem to
be working, so the actual fix is disabled (see comment in commit))
It looks like my bound for last time was too conservative,
in that I looked for the lowest number that didn't seem
to fail in 10.6. The range of failing values is apparently
not continuous.
I've tightened the bound to match the lowest
number that produces a useful result on my 10.7 machine,
assuming that it works for a continuous range there.
(The new bound is higher than the number previously used as
a lower bound.)
Merge to 5.2.1
Setting the environment variable causes the bytecode compiler to run
the bytecode validator (which is normally applied to input from a
bytecode file) immediately on all of the compiler's own results.
Certain `lambda'-lifting operations can cause information
about the flonumness of a variable to get lost, leading
to a mismatch between the closure's flags and flags on
a variable reference. (The bytecode validator could detect the
bug when loading the broken bytecode. The broken information,
meanwhile, was only used by the JIT.)
