Swap order of argument for `environment-variables-get'
and `environment-variables-set!', so that the environment
variables come first --- which follows the usual order.
This change means that the parameter isn't used to get
the default environment variables, but that seems ok; the
convenient interface is `getenv' and `putenv'.
On Windows, case-normalized environment variable names.
Also, change the implementation to use an immutable hash
internally.
By default, a sandbox gets a fresh environment variable set,
which means that it does not affect environment variables
outside the sandbox (which means that sandboxed code cannot
set the Racket process's OS-level environment variables).
Closes PR 13667
The `current-environment-variables' parameter determines the current
mutable "environment variable set". If that set is the initial one for
a Racket process, then using the set corresponds to working with OS
environment variables. Otherwise, it's really just a hash table that
is packaged up as OS environment variables if a subprocess is created.
The new environment-variable interface works in terms of bytes, instead
of assuming that environment variable names and values fit in a string
encoding.
The string-based `getenv' and `putenv' are still available as
convenience wrappers. The checking on environment-variable names
for those wrappers is a little tighter, preventing any attempt to use a
name that contains "=".
This commit extends make-base-eval, make-base-eval-factory, and
make-eval-factory with an #:eval and input-program inputs so that
these functions are more like racket/sandbox make-evaluator.
This change revisits commit eb7fa6f066. I think the problem
is not in the rendering of index entries but on the generation
side. The generator was converting Xexprs to strings, except
that strings were left as-is, which is inconsistent. So,
I've reverted commit eb7fa6f066 and fixed the generator.
Added contract checking to arity=?, arity-includes?, and normalized-arity.
Removed contract checking from normalize-arity to make it a total predicate.
Updated documentation for normalize-arity to reflect this change.
Restore MysterX-style handling of parameterzied properties in
`com-get-property'. It turns out that the original `com-get-property'
handles parameterized properties by allowing a list in place of a
property-name string, and that handling got lost in the re-write.
Fix the name of `com-get-active-from-from-coclass'.
Fix arity checking for optional arguments.
Closes PR 13603
Closes PR 13604
Noted by ozzloy on IRC. The search page appears to fail when
searching for the term 'string<?'; in truth, the search succeeds, but
the search link-printing code doesn't escape the '<?' part of the
identifier.
Allow a thread to be GCed when it is blocked on a place
channel for reading and the place channel's write end
is inaccessible.
GC is limited to threads that do not participate in cycles
of such threads, where the otherwise unerachable threads
are blocked on place channels that are reachable among the
set of threads. In other words, the GC finds the greatest
fix point (as measured by the threads to retain) instead of
least fix point --- which isn't what you want, but finding
the least fix point seems to require significant extra GC
machinery across places.
This improvement was intended to solve the same problem as
commit 7b0608c, but that case seems to run into the limitation
on cycles.
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.
