The validator was not as smart as the compiler in determining
that a `let' expression could be relied on to produce a
constant-shaped function (without side effect or error) in the case
that a right-hand side expression is a call to a known structure
constructor or predicate.
Closes PR 13679
Merge to v5.3.4
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 "=".
A symptom of mismatched `for-label' imports was that searching for "<="
would show red-underlined links to the `plai/{gc2/}mutator' documentation.
Merge to v5.3.4
When places are not enabled, then `raco setup' uses multiple
Racket processes that commuincate via pipes. Don't try to send
a place channel over a pipe.
Merge to v5.3.4
The code duplication was there only to support
constructing the name for the optimized contract;
instead we actually just built the name as we go
(the old version actually built the old contract
and then used that to get the name)
also:
- racket/contract/base now requires basic-opters.rkt
so all of the opters are registered when racket/contract/base
is loaded, not just the non-basic ones
- fix the ordering of the names of subcontracts in or/c
- make opt-contracts print a more meaningful name
for online expansion errors
This avoids drawing the margin highlight when it isn't inside the
region being repainted and it avoids even figuring anything out about it
when there is currently no error range
NOT for the release branch
Specifically, allow a name to be specified with an
extension such that subsequent uses of those extensions
will replace mixins instead of adding new ones
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.
The mrlib/terminal library fits in the mrlib collection in that it is
a random library that uses our GUI system that doesn't belong in
racket/gui somewhere.
It also doesn't really fit into the framework as the framework is
supposed to be a colleciton of useful mixins for our racket/gui
classes.
It does, however, benefit from using the framework (and the string
constants library) so the best option seems to be to think of mrlib as
consisting of separate libraries that fit into two different layers
of the dependency hierarchy. So that's what this commit does.
drracket's "install package" menu item
It will infer whether to use 'raco pkg update' or
'raco pkg install' based on the currently installed
set of packages (but, of course, the details
section of the dialog lets you override this inference
if necessary)
* Some racketisms.
* Use explicit `in-list' etc in for loops.
* Remove some redundant requires from `net/dns'.
* Move all tests to `tests/net', including a new `tests/net/ip'. In the
future there's a plan to have things like stripped zos etc for
distribution, but we're not there yet, and the net collection is
already organized nicely so this also makes it more uniform.
* Include the dns tests in the main test file.
The library currently lives in a private subfolder so
that the interface can still be changed. The idea is to
eventually make it a top-level `net` library once it is
more mature.
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.
For instance, (normalize-arity (list 1 (arity-at-least 2))) now produces
(arity-at-least 1). The implementation and the tests for normalize-arity both
reflect this change. The randomized tests now also check that the output
represents the same arity as the input.
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
A scroll request could fail if a resize notification is still
in flight (i.e., queued but not yet executed), so double-check
the size on a scroll request.
Closes PR 13582
Making a pathcollects-relative at contract-formation time means a
lot of extra work then and a change to the needed sandbox permissions.
Aormalizing at error time is more consistent with other parts of a
contract message.
The lexer mishandled cases like "#x1E+2", because "E" is
not an exponent marker for hexadecimal --- and it has been that
way forever, but the repair isn't all that difficult.
These result from something like
@racket[(x y)]
being treated by Scribble as multiple RktXXX items rather than one. As
a result the Markdown emitted was:
`(``x`` ``y``)`
But obviously instead we want:
`(x y)`
Kludgosity alert: Although it would probably be more-correct to
consolidate the RktXXX items at the Scribble structure level, I don't
easily see how. `@racket` is baking in the concept of Racket
lexing (classifying text as various kinds of Racket elements). This is
handy when the render will be HTML or Latek, and is benignly N/A when
it will be plain text. But it's a bit square-peg/round-hole when the
render will be Markdown. Rather than attempt to "un-lex" the Scribble
structures (I'm having trouble seeing how), I'm handling it
"after-the-fact" -- adjusting the generated Markdown text.
If anyone thinks the preceding is an elaborate rationalization for an
ugly kludge, I wouldn't argue, but I would need some help
understanding the preferable way to go about it.
Unlike plain `racketblock`, `examples` and `interaction` are
"nested". As a result we emitted bad Markdown like:
```racket
Examples:
```racket
some-code
```
```
Markdown code blocks can't nest, so this needs to be:
```racket
Examples:
some-code
```
Also: Updated the unit test with examples of `examples` and
`interaction`.
This simplifies the implementation, and also generalizes it so that it finds
documentation from installed packages, linked collections, and other sources.
Because of a limitation in our GC tech (and because I have not
sorted out how to program around it (which should be possible))
when the "is it safe to rename this variable" check may silently
just say "yes" when it really doesn't know the correct answer.
It turns out that this was happening on every attempt to rename
after the first one (in a given online check syntax run) due to
a bug, now fixed in this commit (the "loop" didn't actually loop...)
Also, moved the creation of the thread to its own function to
make the things it closes over more syntactically apparent.
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.
A tail call with certain kinds of primitives would fail to
clear local bindings in a detectable way. For example, a
tail call to `sync' that blocks could retain references
to unreachable data in the context of the `sync' call.
Primitives that can cause problems in the run-time system
are already identified as "imemdiate" primitives. The
safe-for-space pass now inserts clearing actions before a tail
call, unless the call it to a known immediate primitive or a
Racket-implemented function.
Clearing operations are now omitted before non-tail calls
to immediate operations like structure predicates.
The newly added clearing operations could affect performance,
but they probably won't, since the clear operations are still
avoided in tail-call cases that are otherwise fast. The newly
omitted clearing operations may improve performance.
The shortcut could be triggered in a bad case (first
argument as `#f' in non-timeout mode) and returned the
wrong result (void instead of the semaphore).
It's possible to go from a state where one scroll bar is needed
(vertical or horizontal) to a state where each scrollbar is
needed iff the other scrollbar is needed. In that case, the
auto-scrollbar algorithm couldn't find either fixpoint and
would loop forever.
- handle parameters correctly when simplifying disequations
- rework term generation/disequation checking for parameters
- fix define-extended-metafunction w/r/t the above
