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!
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)
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.
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
(since the repl test suite tests the pretty big language's repl and since there was a test case
there that would have discovered a bug that we only found in the hours before the release but had
been lurking for a few days)
