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.
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`.
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
Two "self" module path indexes are treated the same on load when they
have the same resolved module name. Fix the serialization intern table
to take that into account and avoid some GC-based non-deterministism.
Related to #3165
On a second look, 6d06086dad unnecessarily duplicates work already don
by `copy-file` in most cases. For the case where `copy-file` was not
used, there was code to explicitly set an executable bit, but the new
approach is better and should be used just there.
Changes `_ptr`, `_list`, and `_vector` syntax to be more permissive.
Matching by symbol rather than binding is usually the wrong choice,
but the position where `i`, `o`, or `io` is recognized in `_ptr` and
company is not an expression position. Also, `i`, `o`, and `io` are
not otherwise bound. So, it's difficult to justify the current
behavior. If `_ptr` and company were defined today, we'd use keywords
like `#:i` instead of symbols like `i`.
A potential drawback of this change is that a `i`, `o`, or `io` might
be written with the intent of referring to a binding, and this change
makes such a reference silently allwowed instead of an errror. That
seems relatively unlikely, however, while having to avoid `i`, `o`, or
`io` as a binding is occassionally a pain --- something I've run into
once or maybe twice.
Closes#887
