The `cast` function is supposed to auto-promote its second argument to
a GCable type if the value to convert is a GCable pointer. This
promotion did not happen for `_bytes` and other string-like types.
Also, in CS, `malloc` did not alocate GCable memory by default when
given the `_bytes` type, which would sometimes interfere with getting
a GCable pointer result.
This bug explains why the "draw-test/tests/racket/draw/dc.rkt" test
would occassionally have an `unscaled-alpha-set` failure on DrDr (for
many years).
The new functions provide a more direct way to serialize and
deserialize syntax objects than compiling and running a `quote-syntax`
form. The new functions also offer additional configuration related to
preserving extra syntax properties and limiting the use of shared
"bulk binding" tables (i.e., tables that must provided by module
declarations in the namespace).
This change does not add syntax-object support to `serialize` or
`s-exp->fasl`, because serialized syntax objects are still in many
ways like code: they are version-specific, and their invariants can be
broken by mangling the serialized form (in much the same way that
compiled code can be broken by mangling, and with similar safetly
implications).
When referring to a Git repo with a "https://" URL, the URL must end
with ".git" to distinguish the URL for directory and file URLs. A
"git+https://" URL specifies that the Git-over-HTTP protocol should be
where the URL cannot contain ".git". For example, SourceHut URLs do
not include ".git" (while hosting services like GitHub or BitBucket
allow ".git" to be in the URL).
When using `raco pkg`, it was possible to specify `--type git` for an
"https://" reference, but for consistency and internal tracking, a
".git" would be added to the URL, anyway. Using `--type git-url` can
similarly force the interpretation of an "https://" reference without
triggering the addition of ".git". The new state is mostly internal,
but it is reflected in the output of `raco pkg show`, which shows
`git` for such references (as opposed to `url` as shown for others).
The CS implementation was missing a level of indirection. It worked
for a typical handler `(lambda (thunk) (thunk))` for the case when the
callback can run atomically, but it did not work for caces where
`thunk` is made to run later (potentially out of atomic mode).
Also, fix the management of interrupt state, including for some place-
and future-related asynchronous callbacks.
Thanks to @rmculpepper for the `async-apply` report, new `async-apply`
tests, and the repair for the interrupt-state bug.
Add `#:eager` options to `stream-cons` to control whether the head
and/or tail expression is delayed. Also add `stream-lazy` to
explicitly construct a lazy stream and `stream-force` (normally not
needed) to force a stream.
Delayed expressions in `stream-cons` are now non-reentrant, like
promises created by `delay`. This is a change in behavior, but I'm
hoping that no one relied on the old behavior, which has the bad
property that the delayed expression is retained until its result is
received.
For consistency, this commit also changes `stream*` to delay the
stream-construction expression when its the only one expression that
is given.
Internally, changes to the stream implementation reduce allocation.
The `stream-lazy` form would be more natrally called `stream-delay`,
but that creates a conflict with existing packages.
Although setting `PLT_SETUP_OPTIONS` as an environment variable works
for the makefile created by `configure` in a source distribution, it's
better used/described as a makefile variable.
Closes#3735
Another try at the commit reverted by 471f18c02d, but this time with a
`SINGLE_BRANCH_FLAG` makefile variable that can be set to turn it off
for the rare system that has Git older than version 1.7.10.
The cross-library inlining improvement in commit 6020b944ef did not
manage internal names correctly, and it could mix up bindings that
have the same printed form.
Closesracket/ChezScheme#35
In this example, after the check with eq? or eqv? the value of
the variables x and y are known, so cptypes replaced the
reference to the variable with it. But it can interact badly
with the eq? test, for example in this case the first (eq? x y)
can be #f and the second be reduced by the compiler to #t.
In spite eq? cannot be used to compare numbers reliably, this
behavior is too confusing and it's better to avoid it.
(define (one)
(let ([r (random 2)])
(if (= r 0) (one) r)))
(define (f x y)
(define first-comparison (eq? x y))
(when (and (eqv? x 7.0)
(eqv? y 7.0))
(define second-comparison (eq? x y))
(eq? first-comparison second-comparison)))
(f (+ 6.0 (one)) (+ 6.0 (one)))))
BC did not take a lock for `hash-clear!`. Maybe the intent was that a
lock isn't needed from the perspective of `hash-clear!` when it isn't
traversing the table, but failing to take a lock before modifying the
table can break other operations (that do take a lock) in progress.
Furthermore, some iterations that intentionally did not take a lock
also did not guard against changes well enough. Various repairs here
avoid crashes, and now `hash-clear!` consistently takes a lock.
CS had a similar (but more subtle and more limited) instance of the
problem in `hash-map` and `hash-for-each`. That problem is corrected
(without adding any new lock acquisitions).
The existing CS implementation of `equal-hash-code` for hash tables
takes a lock more than the BC implementation. A possibly surprising
result: when attempting to add a mutable hash table to itself as part
of a key, the `hash-set!` can block forever on the hash table's lock,
instead of doing something more random as a result of having a mutated
key. The documentation now notes that possibility.
Related to #3738
With list-assuming-immutable? and the internal construct
immutable-list the compiler can assume that some lists will
not be mutated.
Also, change the definition of interned-char?, because in CS all chars
are interned.
