when it compiles required files
Now that this is fixed, the compilation manager will be (once again)
active when doing online compilation, so if the "Populate compiled
directories" checkbox is check (which it is by default) in the details
section of the language dialog, then online compilation will, as it
compiles your file, write out .zo files that will also be used by the
Run button.
The actual fix to this bug is the change in expanding-place.rkt (and
all it really does is move the setting of the
current-load/use-compiled and current-load parameters earlier so that
CM sees only the modified parameter settings and so doesn't give up on
compilation.
The rest of the changes are a test case (and change to drracket to
support the test case)
commit e503850f21 broke drracket's
interactivity (for some files it could take 2 seconds to do
that one line)
This changes the bindings-table so that it maps to sets instead of
lists. Now, instead of mutating all entries in the table right after
collecting everything, just leave them as sets until we need the info
and just sort a single entry, when it is needed
This should have been like this all along; I think it can lead to
race-conditions with high-priority events. In particular, something
might be pending in the event queue and then the test suite might
queue a high-priority event to check for it, which could happen before
the event that actually does the work that's being checked for!
Changes the implementation of highlight-range so that it
only recomputes all of the new locations from the positions
when on-reflow is called (otherwise only computing the
relevant ones) and make the on-reflow callback chop itself
up, in case there are lots of highlighted ranges to avoid
tying up the event loop.
Changes searching so that it doesn't neccessarily compute
the entire search results in a single event callback
(but also make it start the computation more aggressively)
Overall, this changes the strategy from one that, for any potentially
long-running callback, just tried to push it off into the future, into
a strategy that tries to avoid long-running callbacks by breaking the
work up into chunks, but starting the first chunk immediately (in a
low-priority callback).
Also, misc other changes to make this work better and generally clean
things up.
inside the same collection so this file can (when other
things aren't too different) be used in a version of racket
that doesn't generally have the tests
typing them in, in the module language test suite
this speeds it up; going from 140 to 105 seconds on my (mac)
machine. (drdr was taking 240 or so seconds, tho)
so that it waits until online check syntax actually
finishes (otherwise, there actually is a leak;
the link is broken when the message comes back from the
other place)
raw-module-path inside of a phaseless-spec (see
the #%require docs for the description of these).
Also, Rackety
in conjunction with commit 9047427 (and an earlier
commit in those files/dirs), this commit:
closes PR 7815
closes PR 10455
closes PR 10788
(the way things currently stand, check syntax needs more information
from the fully expanded form, but at least now it has a better chance
to actually use that information, if it were there ...)
related to PR 7815
related to PR 10455
related to PR 10788
Specifically, it seems like about 20% of the time (in drdr),
running the program
(let l()(l))
in DrRacket and then clicking the break button results in a state
where DrRacket's focus is not in the definitions window. I can't seem
to make this happen on my own machine and I'm not sure if this a
race-condition in the test suite or a real bug in DrRacket but it
seems minor enough (given all of the other focus-based testing that is
happening in this (and related) test suites) that I'm just going to
give up on this particular test.
appear in saved wxme format files
also, improve the testing support for testing snip loading
(before this, the testing infrastructure could let one test
"leak" into another one in a way that could mask failures)
please include in release branch
and the change to the racket/gui load-handler
(unfortunately, there is still another problem that keeps
the test suite from passing)
please merge to the release branch
like textual-read-eval-print-loop
There is still a difference, however, because drracket's REPL has a
notion of multiple expressions that are submitted simultaneously that
textual-read-eval-print-loop doesn't. For example, if you type this at
the prompt:
(car) (+ 1 2)
then textual-read-eval-print-loop will print out the error and then 3,
but drracket will print only the error (ditto if (car) were replaced
by a continuation abort).
This difference is, IMO, a good thing, since it lets you use a single
interaction to do multiple things, but stops as soon as there is an
error. (It is also how drracket has behaved for a long time.)
closes PR 12790
