`setup/private/path-utils'.
The API is a little different: instead of getting the alist and the
path, there's a curried function that gets the alist and produces a
function to do the substitutions.
`setup/path-relativize'.
`setup/path-relativize' is freed from a bunch of things that were due to
historical baggage, but some remain. (Also, update its docs.)
* Lists are now either blocks or splices depending on whether they
appear inside a block or a splice (default to block).
* Adjusted the docs and a single test where this mattered.
* Change the documentation to be "text.html" and to be titled "text
generation".
I originally picked "under" as the preposition to go before
a platform name, but obviously you should build "on" a
platform, and "under" suddenly annoys me. The choice of "on"
is now codified in the documentation style guide. Meanwhile,
"Unix" insted of "X" seems more clear and consistent in the
`racket/gui' docs.
More usefully, this patch also fixes a few out-of-date
platform-specific claims.
Revert "Fix interface."
Revert "Add more scribble forms that evaluate code and display the results."
This reverts commit a621eaf041.
This reverts commit 7e9dbded4c.
by default; a new optional argument restores the old behavior
(but the default behavior is consistent with the old docs and with
the vast majority of existing uses)
The implementation is ugly for performance reasons. A new primitive
`prop:arity-incomplete' property determines when to return #f for
`procedure-arity-includes?' in default mode. A nicer implementation
would be to redefine `procedure-arity-includes?' at the kw-proc level,
but the bytecode optimizer's and JIT's treatment of the built-in
`procedure-arity-includes?' is important. The implementation choice
could be revisited after cross-module inlining is implemented.
Closes PR 11978
The new version fixes some problems with the previous one, most notably
it can create a keyworded function when the last input is is keyworded.
`compose1' is a restricted variant that requires single values in the
composed pipeline -- besides being potentially faster (probably more
if/when there is cross module inlining), it has a semantical
justification, similar to the restricting function call arguments to
return single values, with similar robustness benefits. The
implementation of both is done in a generalized way, and the results can
be faster for both `compose' and `compose1'. (Not by much -- 20% and
30% resp.)
One thing that it could do is to reduce the resulting arity to match the
last given function. I didn't do this since it adds a significant
overhead to the result. (No strong opinion on doing that...)
Actually, the new `thunk' is a nullary function, which I think is very
popular expectation for the name. Since there are possible uses for the
any-arity version, it's added too, as `thunk*'.
because the previous documentation didn't actually define the form;
the examples were good, but epecting a reader to infer meaning
from examples wasn't good enough. The use of a `module-path?' contract
in the old docs wasn't appropriate; contracts apply to values, while
grammar productions should be used to document syntax constraints.
Also, `module-path?' was too permissive (only literal strings and
identifiers are actually allowed), while the actual syntax allows
either a single path or a sequence.
This makes it correspond to the license page we have on downloads that
talks about the "lesser" GPL rather than the "library" one.
Also, change the file name to have a more friendly .txt suffix, and add
some more responsible properties for things in doc/release-notes.
so that they conceptually apply after the current
transformation, instead of before the current transformation;
more general rotation problems were related to aligned drawing
and the calculation of the effective scale for alignment
- the `lam' structure from `compiler/zo-struct' changed to include a
`toplevel-map' field
This change helps solve a finalization problem in `racket/draw',
which in turn sigificantly reduces the peak memory use of `raco setup'
during the doc-building phase (because some documents load `racket/draw'
to render images, and multiple copies of `racket/draw' were retained
before finalization was fixed).
The change is an extreme way to solve a specific finalization
problem, but it's a kind of space-safety improvement; space safety
almost never matters, but when it does, then working around a lack of
space safety is practically impossible. In this case, it's not clear
how to otherwise solve the `racket/draw' finalization problem.
The improvement doesn't change the representation of closures, but it
requires special cooperation with the GC. All closures in a module
continue to share the same array of globals (plus syntax objects);
that is, instead of completely flat closures, Racket uses a two-level
environment where top-/module-level variables are grouped
together. The code half of a closure now records which
top-/module-level variables the body code actually uses, and the mark
phase of GC consults this information to retain only parts of the
top-/module-level environment frame that are actually used by some
closure (or all of the frame if it is accessible through some other
route). In other words, the GC supports a kind of "dependent
reference" to an array that is indexed by positions into the array
--- except that the code is more in the "Racket" directory instead of
the "GC" directory, since it's so specific to the closure
representation.
- no more attempt to support places with the Boehm GC
- no more libatomic (which was for places + Boehm GC)
- remove unsupported configuration options
- strip Racket-specific configure options before libffi configure
- port two leftover Perl scripts to Racket scripts
and documented and adjusted these libraries:
racket/contract/base
racket/contract/exists
racket/contract/parametric (renamed from exists)
racket/contract/region
because it's often useful to show more values, and a
tail `raise-mismatch-error' instead of a nested `format'
can avoid some safe-for-space work in the JIT output
which creates a little more sharing than the automatic
caching of modules, but only for a program that explicitly
attaches module declarations to share
