Prune some `with-continuation-marks` forms that aren't observable
(because the body is simple enough that it won't inspect marks). More
significantly, specialize `with-continuation-marks` forms to indicate
when the current frame is known to have no marks and to indicate
when tthe key expression is known to produce a non-impersonator.
Since `#%app` (used where an applicable structure might show up)
injects its own `procedure?` test and makes sure that that a procedure
is returned to the function position of the application, use `#3%$app`
to make Chez Scheme suppress a redundant `procedure?` check for the
appliction.
It's not clear that a thread can be descheduled without the current
thread's work counting as progress, but a descheduled thread certainly
shouldn't coun as a no-progress scheduled thread.
Only one instance of each callback is needed. Allowing them to pile up
is inefficient, and possibly it can trigger a reaction that causes
even more to pile up.
(for ([x (in-value 1 2)]) x)
should raises a run time error, not a syntax error.
Fix similar error in other in-something macros.
Fix name of in-directory, when used as a function outside a for.
Unfortunately, MZ_NORETURN spec is causing a few problems - see #2808
It would be great to fix these but due to lack of time, this is a
workaround that should keep things working until all supported
configurations accept MZ_NORETURN properly.
Use `call-consuming-continuation-attachment` to implement
`with-continuation-marks`, because that avoids duplicating
a set of checks when in tail position.
Looking at `bytes-allocated` usually works, but sometimes lets
memory use spiral out of control. Looking at `current-memory-bytes`
is more reliable, but still makes peak memoy use too high.
Combining those values doesn't limit the peak well enough.
Try the more obvious (in retrospect) approach of comparing
`bytes-allocated` changes and `current-memory-bytes` changes
separately, and triggering a GC if either grows enough.
Commit 1811193285 caused Racket CS to have much higher peak memory
use. Adjust the heuristic again to trigger a major GC when the
`current-memory-bytes` value is the post-GC `bytes-allocated` plus the
post-GC `current-memory-bytes`, which means waiting until
another `bytes-allocated` bytes are allocated (instead of waiting
until the number of newly allocated bytes also catches up to overhead,
such as unserused pages due to locked objects).
Implement a parameter as a Chez Scheme wrapper procedure,
instead of an applicable record. A wrapper procedure can be
applied more directly, saving 10-20% of the time for some
parameter lookups.
The grammar for pregexps includes:
| \p{‹property›} Match (UTF-8 encoded) in ‹property›
| \P{‹property›} Match (UTF-8 encoded) not in ‹property›
and <property> is defined as:
‹property› ::= ‹category› Includes all characters in ‹category›
| ^‹category› Includes all characters not in ‹category›
That is to say, there are two independent ways to negate one of
these character classes. The Racket implementation of regexps
(as opposed to the C implementation) does not recognize negated
categories. This PR fixes that.
Some parts of the GC meant to traverse all objects on a page of
'atomic-interior or 'interior objects used "<" to detect the end of
the page, but "<=" was needed. As a result, things could sometimes go
wrong for the last object on a page for platform and size combinations
where the last object ends exactly at the end of the page.
This change consistenly computes the iteration end in a way that makes
both "<" and "<=" work.
Using MPFR bindings from the `math` library could trigger a problem
(but it's difficult to provoke the problem in a reasonably small
example --- difficult enough that I couldn't do it).
