Enable extflonums in a MSVC build by relying on a MinGW-built DLL,
"longdouble.dll". The DLL is loaded on startup. If the DLL isn't
available, then `extflonum-available?' reports #f.
Instead of setting the floating-point mode globally to extended
precision, the mode is changed only just before (and restored right
after) extflonum arithmetic operations.
Using an impersonator property to represent an application mark was
a bad choice. The property gets propagated, so it is also on any later
chaperone layer, and then things go bad: the docs say that special
treatment is triggered by supplying an argument to `impersonate-property',
but it was actually triggered by the chaperone having the property.
Change the implementation to match the documentation. Using an
impersonator property to supply the mark should be regarded as a hack,
but now the implementaiton is at least consistent with the documentaiton.
"-rdynamic" doesn't work with GCC 4.7 on OpenBSD: "cc: error:
unrecognized command line option '-rdynamic'". The switch isn't
necessary because it is only a wrapper to "-Wl,--export-dynamic".
Look GCC bug 37454.
For immutable hashes, `hash-iterate-{key,value}' used to take O(N) time on
the first call for a particular table and O(1) thereafter. Now it takes
O(1) time for all calls, the constant is only slightly larger for
the non-first calls, and there's no extra allocation.
The intent is to support phase-crossing data such as the `exn:fail:syntax'
structure type that is instantiaed by macros and recognized by contexts
that use `eval' or `expand'. Phaseless modules are highly constrained,
however, to avoid new cross-phase channels, and a module is inferred to
be phaseless when it fits syntactic constraints.
I've adjusted `racket/kernel' and improved its documentation a little
so that it can be used to implement a phaseless module (which can
import only from other phaseless modules).
This change also adds a `flags' field to the `mod' structure type
from `compiler/zo-structs'.
The bug was introduced when changing the order of unboxed argument
staging along with extflonum unboxing support. The main symptom of
the bug was that icons were sometimes blacked out in DrRacket.
The check was incomplete in the case that both arguments to a binary
[ext]flonum function need to be checked and the second one was not an
[ext]flonum and also not a fixnum.
The problem was exposed by improved error checking
in the expander to detect references to exports of a module that
is not yet visited, and as triggered by the documentation for
`2htdp/planetcute'.
Includes a repair for floating-point `min' and `max' that affects all
x86 builds that use SSE arithmetic, leaving the (otherwise unused)
floating-point stack in a bad state, which might have affected
x87-using C/foreign libraries running alongside Racket.
wrap/handle-evt that receives multiple values must have a handler function with adequate arity.
struct.c:
change contract for wrap/handle-evt from (any/c -> any) to procedure?
thread.c:
adjust sync processing
sync.rktl:
add test for handle-evt, wrap-evt and prop:evt
Repair 73e07f576b added an item to a list without incrementing a
counter for the list length, which cause a different element of
the list to be dropped, which could mess up binding resolution in
arbitrarily bad ways.
(Ths bug falls into the "how did this not get exposed earlier?" bin,
although part of the answer is that it requires a combination of
module re-expansion and simplification of syntax objects in the
residual program.)
Closes PR 13428
An extflonum is like a flonum, but with 80-bit precision and
not a number in the sense of `number?': only operations such as
`extfl+' work on extflonums, and only on platforms where extflonums
can be implemented by hardware without interefering with flonums
(i.e., on platforms where SSE instructions are used for
double-precision floats).
[Patch provided by Michael Filonenko and revised by Matthew.]
The compiler tracks information about bindings that are known to
hold extflonums, but the JIT does not yet exploit this information
to unbox them (except as intermediate results).
The code added to handle expressions mixed with definitions was
not introduced in the right way; fix it to be like macro-introduced
code.
Closes PR 13452
The problem was in the handing of "lightweight continuations" used to
represent suspended computations, and in particular the handling
of continuation marks (such as the ones added by DrRacket's debugging
mode).
Unfortunately, I wasn't able to construct a simpler test case that
triggers the problem. I think the number of installed continuation marks
has to be just right, and there have to be some replacing marks, and
a lightweight continuaiton has to be captured at the right time
as a result of applying a previously captured continuation.
Closes PR 13427
Merge to v5.3.2
It fixes a crash in the installation on OpenBSD. Racket reaches the
limits of the shell when it is compiled with a non-root user account.
Tested on OpenBSD-current amd64.
Merge to v5.3.2
With either
configure --enable-pkgscope=installation
or
raco pkg config -i --set default-scope installation
the default scope of `raco pkg' actions can be changed from
user-specific to installation-wide.
We considered trying to guess when someone building Racket would prefer
installation-wide package scope by default. In particular, someone
building from source for in-place use seems likely to want
installation-wide scope by default. Then again, we don't want to
discourage in-place builds for Unix installations that are intended
for multiple users. So, no guessing for now.
Also, add a `--scope' argument to `raco pkg' commands, which is more in
line with other options, but keep `-i', etc., as shorthands.
The problems were with
* `sqrt' and `expt' on single-flonum complex numbers
* `asin' and `acos' on single-flonum arguments and complex results
* `atan' on mixtures of single-flonum and exact arguments
* `gcd' on mixtures of single-flonum and flonum arguments
For now, SGC must be used, but `configure' does not select it
automatically.
Also, support Cygwin (in addition to MSYS) as a build environment
when using MinGW compilers. Since I build in a Cygwin environment
(which seemed to be the easiest way to get MinGW-w64 gcc), I use
../configure --host=x86_64-w64-mingw32 --enable-sgc
