Inserting keys with sequential hash codes --- as in 0, 1, 2, 3, etc.
--- performed badly compared to random keys, because it triggered the
worst case of allocation: allocate a node of size 1, then 2, then 3,
then 32, then 32 plus a subtree of size 1, then 32 plus a subtree of
size 2, and so on. By rearranging the bits in a hash code, arrange
for nodes that are more like 4-wide instead of 32-wide. In other
words, the tree become wider with thinner branches, instead of growning
just as a thick branch to the left.
Of course, there's now a different sequence of inserts that used
to perform well and now perform badly (the inverse of the new
reordering), but that case seems much more likely than the cae
of sequential inserts.
In (~and p1 p2), a failure in p2 now always dominates a failure in p1.
Consequently, if a pattern succeeds, its failures don't matter.
Add {pat,hpat,action}:ord wrappers, ord prframes. Apply ordering to
main pattern and side clauses. Add better progress analysis to
eliminate order wrapping.
Although the JIT would not try to use a block of shared code for more
than a certain number of arguments, it could in rare cases (related to
self tail calls, for example) generate the code and attempt to install
it in the array of shared-code pointers.
When an array value is provided, make sure that it's an array
with at least the expected length (or longer) and same element
layout. That's weaker than checking that the array elements have
the right type, because an `eq?` check at the ctype layer seems
too strong, and the ctype API doesn't provide enough information
for a more flexible equality.
This push makes the exn:misc:match exception transparent. This
matches other racket-raised user exceptions.
The motivation for this change was breakage in the handin-server;
specifically, the discussion in
https://groups.google.com/forum/#!topic/racket-users/nEos3-osoWE
...in which the handin-server was not behaving the same on exn:misc:match
because it was not transparent. This caused the handin server to
refuse to rewrite these exceptions, resulting in less helpful
messages for users.
The previous fix (1acaf011) caused a performance regression
(compilation time?), reported by stchang. Reverting to quote.
Apparently, the problem with gensym and deterministic compilation
isn't the uninterned-ness; it's the global counter used for the
name. So use a compilation-local counter instead.
Avoid creating a result that is intended as a module path but
has elements that are not syntactically allowed, such as a "."
in a collection-path element.
A phase shift was mising on `begin-for-syntax`es introduced by
`syntax-local-lift-module-end-declaration`, which is in turn
used to implement` module+`, so `module+` didn't work under
two or more `begin-for-syntaxes`.
Closes#1312
Syntax objects generally make sense as properties in other syntax
objects, but they require special care when marshaling to bytecode
(as syntax objects do in general). To make that special handling
possible and reliable, constrain the shape of allowed values.
The name `path-extension` created a conflict for an existing
registered package, so it should not have been added to
`racket/path`.
Also, `path-get-extension` was intended to work on a path
that is syntactically a directory, so fix and test that.
Change the one expansion mode as far as I can tell) that disables
lifts so that lifts are now allowed, which means that
`(syntax-transforming?)` implies `(syntax-transforming--with-lifts?)`.
The old documentation incorrectly characterized when lifts
were allowed. Ryan noticed the documentation problem, and that
observation led to this simplication.
Although excessive fragmentation is already detected at the end
of a major GC, it can get out of hand already during a long
incremental phase. So, check for excessive fragmentation and
bail out to a major GC when it happens.
Related to PR 15287
Fixes a failure in the web server tests caused by d23b296627.
Formerly, `(string->url "http://racket-lang.org")`, with no trailing
slash, would produce a `url` structure with `path-absolute?` as #f.
That doesn't exactly make sense, because a URL with a host must always
have an absolute path component. Claiming a relative path component
interacts badly with extending a URL with a path later. (Although
`combine-url/relative` compenstate, a similar function in the web
server doesn't.) The revised `url->string` always sets `path-absolute?`
to #t when a host is present, and whether the path is empty or contains
an empty string still records whether a trailing "/" was present.
The `url->string` function, meanwhile, now needs to use whether the
path is empty to determine whether a "/" should be added after
the host name, not whether `path-absolute?` is true.
