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
