Related to #1500.
This improves the following aspects of the CI config:
* The config now tracks the current stable version of Racket so
package authors don't have to remember to upgrade the config on new
releases. This is a double-edged sword, because it makes it easy to
use features of new Racket version and potentially break
backwards-compatibility by accident. Running CI against a set of
static Racket versions doesn't have this problem since any such change
would end up failing. Maybe a better change here would be to
interpolate the current `(version)` into the CI file instead.
* The job is now set to fail on the first error it encounters on the
assumption that most packages fail due to internal issues and not due
to mismatches between Racket versions. The intent with this change is
to use fewer resources overall when possible. Additionally, the
packages' dependencies are now validated during the setup step.
* Lastly, the install step now avoids building documentation for
dependencies, which can shave off significant amounts of time.
Calling `rationalize` with `+nan.0` as the second argument was causing
a "no exact representation error." This commit changes it to produce
`+nan.0`.
There was an unexercised set of tests for `rationalize` in the test
suite which, once called, demonstrate the bug.
Those tests also specify that `rationalize` should produce an exact
result when the first argument is exact and the second is an infinity.
That's not what the implementation does; it coerces the result to
inexact. I changed the test cases to match the implementation, which
is consistent with other Schemes (Chez, MIT) and standards (R6RS).
When a {u,s}16vector points to memory that's not bytes (e.g. from ffi)
then referencing or setting the memory results in a Chez error:
```
foreign-set!: unrecognized type 'int16
```
The fix is to change the type argument to `'integer-16` and
`'unsigned-16`.
TTo keep stack alignment correct, the `objc_msgSendSuper_stret`
function needs to be used with a structure return type on i386,
instead of making the implicit return-pointer argument explicit.
(For BC, libffi apparently makes the wrong style work anyway.)
A wrapper to align the stack during activation was dropped if the
return type was `void` for a foreign callable, and a callee-popped
argument was not handled right for a foreign call.
It's not necessarily ok to inline a function wrapper by
`make-wrapper-procedure`, because the wrapper might get mutated. We
could add immutable wrapper procedures, but we can also just revert to
a previous approach for code that needed the optimization.
Currently, this repair matters only for PPC32 Mac OS, which is the
only place where alignment of some primitive atomic type is not the
same as its size.
The non-standard ARM Mac OS ABI doesn't just use a different
convention if the function has varargs: it puts each vararg in a
different place than a non-vararg argument of the same type and
position. So, `foreign-procedure` and `foreign-callable` need to know
where varargs start. A `__varargs` declaration is shorthand for
`(__varargs_after 1)`.
For PPC32 Mac OS, we retain the trick that makes varargs foreign calls
work without a `__varargs` declaration, but `(__varargs_after <n>)`
fixes up callable support --- in the extremely unlikely case that
someone needs general varargs callables on PPC32 Mac OS.
Since Chez Scheme now performs the kind of closure conversion that
Racket does --- ensuring that a closure is not allocated if it is
bound to an identifier that is used only in application positions ---
the variant in schemify is not longer run. The hacky macro-based
lifter in the "rumble" layer can also go.
The lifting pass is still preserved in schemify, because it is still
useful to cify. It's not clear whether interpreter mode (which is used
during macro expansion for compile-time code that doesn't cross a
module boundary) is better off with or without schemify's lift, but
it's gone for now.
This commit fixes two bugs:
* `sync/enable-break` didn't implement the guarantee that an event is
selected or a break exception raised, but not both; the problem was
in the handling of making the break-enable state ignored after
committing to an event
* `sync` didn't cancel asynchronous pending commits when a break is
received at certain points; the bug in `sync/enable-break` masked
this bug for existing test cases
Closes#3574
A seemingly-unintentional choice made the following not behave
as expected:
(define-inline (f x) (+ x 1))
(f (f 2))
because the `(f 2)` was not inlined.
Reported by @mflatt and Liwei Chou.
Replace the vfasl writer (which was in C) with a new implementation
(in Scheme). The main result is that the vfasl writer can be used in
cross-build mode.
Racket uses the vfasl format for its boot images, because they can
load faster --- cutting the Chez Scheme plus boot files startup time
in half, which saves about 40msec on a typical machine. That's not
enough to matter for something like DrRacket, but it can matter for
small Racket scripts. Formerly, cross builds disabled vfasl
generation.
A vfasl file is roughly an image of code and data as it will appear in
memory, and a relatively fast linking step makes the image work in a
running process. The old implementation was in C because it reused GC
structures and code, treating fasl creation as copying objects into a
vfasl image instead of a new generation. The new implementation is
more like a fasl reader, loading objects into a vfasl image instead of
the live heap. The two implementations are about the same amount of
code and both involve a certain amount of repeated implementation
(i.e., imitating a collection or fasl load), but the Scheme
implementation is more flexible and works for cross compilation.
Reading `1.0e45` produced a different (and less precise) result than
`1e35`. The problem was in the reader's fast path for simple flonum
conversions, where it converts the mantissa and exponent separately
and then combines them. 10^44 is not represented exactly as a flonum,
so there's imprecision when multiplicy it by 10 versus multiplying
1e45 by 1.
Closes#3548
Callbacks from C generally need to be in atomic mode, but they don't
need to have interrupts disabled at the Chez Scheme level, because
that disables GC.
Without this change, dragging a scrollbar or resizing the window in
DrRacket would suspend GCs as long as the mouse button is pressed ---
which could allocate arbitrary amounts of memory fairly quickly
meanwhile.
Cross-library inlining is willing to inline a procedure body that
refers to a system primitive, but wasn't willing to propagate a
system primitive directly. Enable that, and use it to simplify
`unsafe-struct` inlining.
Related to #3546
Copy any syntax-original property from the parentheses assodictaed
with a `#%app` made explicit, so that originalness is tracked in
the 'origin property.
New `#%app/no-return` and `#%app/value` functions at the Chez Scheme
level allow schemify to communicate that function calls will not
return or will return a single value. The schmeify pass may have this
information because a Racket-level primitive is declared that way
(such as `error` or `raise-argument-error` for no-return, or most
functions for single-valued) or because single-valuedness is inferred.
There's currently no inference for no-return functions, because those
are relatively rare. An `#%app/value` is used by schemify only for
imported, non-inlined functions, since cp0 can already deal with local
functions and primitives.
There's a start here at adapting the "optimize.rktl" test suite for CS
--- and that effort triggered these improvements plus some other
low-hanging fruit. But a lot more is needed to adapt "optimize.rktl"
and to make some additional optimizations happen.
The new encoding of struct constructors and predicates collided with
the encoding of another kind of procedures --- ones that are
unmarshaled on demand in especially large modules. The resulting
symptom was that `object-name` was broken for on-demand procedures.
Avoid a global table to register structure procedures, and instead use
a wrapper procedure. At the same time, adjust schemify to more
agressively inline structure operations, which can avoid a significant
performance penalty for local structure types.
Closes#3535
A procedures that is a value for a structure-type property was not
always inspected correctly. For example, if such a procedure was the
only one to mutate a module variable, then the variable might not be
detected as mutable.
Since CS doesn't use secondary hash code internally, the
`equal-secondary-hash-code` function wasn't really implemented.
Implement it reasonably for applications that might use it to
implement other data structures.
Testing exposed other problems related to error reporting for a broken
hash-function result and for using values within immutable hash
tables.
Closes#3536
Fixes an issue where the distribution assembler expects these to be
`path?`s.
I originally considered making this change in the ctool command in
`cext-lib` instead, but then I noticed the documented contract for
`assemble-distribution` is `(or/c #f path-string?)`.
AArch64 Mac OS will not run an unsigned executable. But it will happily run an
executable with an "ad hoc" signature, which is little more than a sequence of
SHA-256 hashes of the file content.
Meanwhile, new tests highlight how the `pretty-print` family of
functions is inconsistent with the non `pretty-` variants (worth
changing, considering backward compatbility?).
Currently, the pattern matcher always call `vector->list`
on the input vector if a ddk is detected.
However, when there is exactly one ddk and users wish not to
bind an identifier to the ddk, the whole conversion is not needed.
Instead, we can selectively `vector-ref` the prefix and the suffix
of the vector and match them directly against patterns.
Also strengthen an existing test.
They were being converted to fixnum operations in unsafe mode, but
the intent was to use fixnum operations only when the argument are
known to be fixnums.
The latest Mac OS tools automatically sign code when linking, and
"collect-path.rkt" break that signature by changing the executable.
Avoid that problem by removing the signature, first. (Leave it to
distribution tools to install a new signature.)
Code segments are executable and potentially non-writeable in a thread
--- except when specifically enabled, at which point code segments are
made non-executable for that thread. Non-code segments are always made
non-executable.
Commit 8858b34bd92ac8d2b6511dc9ca17ebfa06a1bd93 ("Add LZ4 support and
use it by default for compressing files") added LZ4 support and the
lz4 submodule, but did not update the NOTICE file, unlike zlib support
is handled.
Implement weak and ephemeron generic hashtables, and repair weak and
ephemeron `eqv?` hashtables to be weak on numbers.
Racket's implementation of weak `equal?`-based tables now uses weak
generic tables. Datum interning, which needs a weak `equal?`-based
table and was the bottleneck for unfasling literal data, is much
faster. DrRacket's footprint is 1% smaller.
Use the fixnum-mixing idea of dc82685ce0 on pointers, too.
This change provides a significant improvement on the "hash-mem.rkt"
benchmark, for example, because the allocated objects have a size that
triggers a repeating pattern in the low bits of the allocated address.
Use data instead of code to shrink ".zo" sizes by 10-30%.
When Racket code contains a literal that cannot be serialized directly
by Chez Scheme (such as a keyword or an immutable string that should
be datum-interned), the old approach was to generate Scheme code to
construct the literal through a lifted `let` binding. To handle paths
associated with procedures, however, Chez Scheme's `fasl-write` had
been extended to allow arbitrary values to be intercepted during fasl
and passed back in to `fasl-read`. Using that strategy for all Racket
literals simplifies the implementation and reduces compiled code. It
also makes closures smaller, while increases the number of
relocations. DrRacket's foorprint shrinks by about 1%, but the main
affect is on disk space for a Racket installation.
Show the machine code that constructs lifted constants for a linket.
Also, add a `--partial-fasl` option that shows fasl content in a rawer
form, which is useful for checking how content is presented and that
nothing is getting lost in other reconstructed views.
The 'os* mode is like 'os, but it provides a more specific result for
Unix variants, such as 'linux on Linux.
The 'os* and 'arch modes together are the information that we've
previously accessed indirectly via `(system-library-subpath #f)`.
Closes#3510
Mixing for sequences did not produce enough variety related to the
length of the sequence. For example, '(0 0) and '(0 0 0) and '(0 0 0
0) had the same hash code.
Allow cptypes to convert a `fx{+,-,*}/wraparound` call to unsafe if it
proves that the arguments are fixnums (unlike, say, `fx+`, where the
possibility of overflow remains).
Change hash-code calculations to use `fx+/wraparound` and
`fxsll/wraparound` instead of `#3%fx+` and `#3%fxsll`. The resulting
code should be the same in the default unsafe compilation mode for the
Racket core, but the `wraparound` versions can be checked in safe
mode.
Also, fill in missing tests in Chez Scheme, which exposed cp0 problems
with `fx-/wraparound`.
Expose machine-level operations that stay within the fixnum range,
which can be useful for things like hash-code computations where it's
ok to just lose bits. Operations like `unsafe-fx+` turn out to do that
already in the current implementation, but with no guarantee (and with
no checking of arguments).
For Racket BC, before this commit, JIT-inlined `fxlshift` incorrectly
handled a negative second argument like `arithmetic-shift` instead of
erroring.
When the thread-scheduler timer fires while a thread is in atomic
mode, the thread could check for breaks even when it shouldn't. Worse,
if the atomic region was to implement terminating a thread, the path
to check for a break could end up ressurecting the thread from the
persspective of `thread-dead?`.
A mutable hash table only uses the lower few bits of a hash code,
because it masks the hash code by [one less than] the power-of-two
size of the bucket array. That truncation interacts badly with the
hashing function for fixnums, which is the identity function; if the
the lower several bits of the fixnum stay the same for many keys and
the upper bits change, then there are many hash collisions --- and
that's a relatively likely distribution.
Fix the mutable hash-table implementations by mixing the hash code to
let higher bits influence the lower bits: xor the high half of the
bits with the lower half (which doesn't lose information, because
xoring again would recover the original number), then do the same for
the high one-fourth of bits in the low half, and then (on a 64-bit
platform) the high one-eighth of the low one-fourth of the bits.
Instead if blaming the way the mutable hash-table implementations only
use the lower bits of a hash code, we could blame the hash function on
fixnums for not performing this kind of mixing. In this patch, though,
we take the view that the hash function's job is to map variation in
its domain to variation in the fixnum hash code, and then the hash
table's job is to use that fixnum effectively. That separation of
responsibilities is now documented with `gen:equal+hash`.
There are also improvements here to the hashing function for bignums
in CS and to the secondary hashung function for fixnums and bignums in
BC.
Thanks to Alex Harsanyi for reporting the problem.
On raw racket clones when compiling with `--enable-racket` (i.e. no
pb), there are `find` warnings that DEST does not exist and
compilation still succeeds.
This change however, ensures that we do not have build warnings and
that the symlinks are properly created.
