If the callback takes too long to run, then a second copy was
scheduled --- which likely schedules a third copy, and so on. This
problem could lead DrRacket to get stuck in a GC cycle, for example.
In Schemify's lifting pass, avoid disturbing loop patterns that Chez
Scheme will recognize. Keeping the loops intact is helpful for
floating-point unboxing, where (currently) unbxoing is supported
across loop iterations but not across function boundaries in general.
The problem especially affects `enable-object-counts`, where mark mode
can update an old rtd instead of a copy that is already made.
original commit: 31e2df63894d39b005c6b9984745b44409198d02
Avoid allocating a flonum object for floating-opint calculations
that are consumed only by other floating-point caculations.
For this first cut, unboxing applies only to fl+, fl-, fl*, fl/,
flabs, fl<, fl<=, fl=, fl>, fl>=, bytevector-ieee-double-[native-]ref,
and bytevector-ieee-double-[native-]set!. Local variables can be
unboxed in the same way as implicit temporaries, and loop arguments
can be unboxed, but values in a closure and function-call arguments
are always boxed.
arm32 support is mostly in place, but not yet right. ppc32 support is
not yet implemented.
This commit includes a small change that is incompatible with previous
Chez Scheme versions: `(fl= +nan.0)` (and similar for other
comparisons) produces true instead of false.
original commit: 36459e43f10705aa3e383376ca7d54cf2998b7ee
Build and Test 3m and CS under Windows 10
This improves testing considerably on Windows.
For both PRs and Pushes, build 3m and CS on Windows and run tests.
When the result of `load-collections-xref` is used in multiple
document renderings (e.g., multiple calls to `render`), then an
intenal cache behaved the wrong way. Fixing the problem required an
extension to `scribble/xref`.
Kent noticed the bug, where `make-nontail` used `ignored` where it
should have used `effect`. Also, Kent points out that `make-nontail`
can skip the `$values` wrapped in `effect` contexts in unsafe mode.
original commit: edd9ba3d656f3bd712e5e235b77225f756397077
When a `module` or `let-syntax` form is `expand`ed (i.e., when a
syntax object must be generated), then code is expanded to a syntax
object and then parsed again for compilation. In that second parse,
take advantage of the fact that the expression is already expanded,
which means that no new scopes or bindings need to be created.
Related to #3165
