Chez Scheme now supports a single-pass combination of `collect` and
`compute-size-increments`, which makes a GC with accounting about
twice as fast. Meanwhile, other GC improvements reduce non-accounting
full-collection times by 10-20%.
Much of the GC implementation is now generated from a "Parenthe-C"
description, so update the bootstrap process for that step.
The module is named `hi` but the text said that it was named `hello`
which is quite confusing since `"hello"` is actually the string that
is bound to `greeting`.
This fixes a major issue in arm 32bits, detected by ubsan, where
conversion of type to milliseconds results in overflow.
```
rktio_time.c:92:21: runtime error: signed integer overflow: 1584975753 * 1000 cannot be represented in type 'long int'
```
GCC 9.3 things that `h2` might reach line 385 uninitialized.
```
./hash.c:385:14: warning: 'h2' may be used uninitialized in this function [-Wmaybe-uninitialized]
385 | h = (h + h2) & mask;
| ~~~^~~~~
```
A Chez Scheme garbage collection involves a rendezvous among threads
that are used to implement places and futures (and potentially other
things that create Chez-level threads). The thread that is used to
drive the garbage collection was not formerly specified, and callbacks
like the GC icon in DrRacket can only be run in the initial thread.
When a major collection was run in a non-initial thread, the callback
was simply skipped.
The Racket branch of Chez Scheme now drives a collection in the
initial thread whenever that thread is active. In Racket CS, the
initial thread can be inactive if it's waiting for external events,
and a place can meanwhile trigger a GC. Now, when the Racket CS GC
callback is called for a major collection in any thread other than the
initial one, it defers the major collection to an asynchornous
callback in the main thread (and meanwhile performs a minor
collection).
So, a major collection might now be delayed by just a little while if
the main thread is inactive, such as when it's waiting for external
events, but callbacks like the GC icon in DrRacket will be reliably
invoked for major collections.
It's still unclear what the specification of syntax->string regarding whitespace
before closing parens should be. The implementation also has not dealt with
the issue. This PR therefore removes whitespace before closing parens from
the tests.
Once the discussion at
https://github.com/racket/racket/issues/3071#issuecomment-601984438
has reached a conclusion and implemented, we can add these tests back.
Implementing a thorough `clean` target for a repo-based is tedious and
error-prone. Instead, make the `clean` target suggest `git clean -d -x
-f .`, which is more effective in most situations (but seems too
dangerous to run automatically).
The `call-in-continuation` function generalizes applying a
continuation to values by accepting a thunk that is called in the
restored continuation. In other words, insteda of having to use the
pattern
((call/cc (lambda (k)
.... (set! saved-k k) ...
(lambda ()
original-result))))
...
(saved-k (lambda () new-result))
The extra call and thunk on the capture side can be omitted:
(call/cc (lambda (k)
.... (set! saved-k k) ...
original-result))
...
(call-in-continuation saved-k (lambda () new-result))
At the Chez Scheme level, a `call-in-continuation` in tail position
within a function can avoid forming a closure for its second argument.
The `call-in-continuation` function at the Racket CS level doesn't yet
provide that benefit.
The `call-in-continuation` operation is called `continuation-slice` in
Feeley's "A Better API for First-Class Continuations".
Expansion of a procedure with keywords is quadratic due to generating
a nested sequence of `let`s, but speed it up by roughly a constant
factor by using a dintinct symbol for each nested layer.
Related to #3070
Using `call-in-continuation` to apply a thunk within a continuation
slightly simplifies and speeds up parts of the implementation of
delimited continuations.
The expansion of `struct` created far too much code to parameterize
`struct-field-index`, making expansion of a `struct` form with just
100 or 200 fields take a noticeably long time to expand.
