I'm not sure why it was doing this before, but in addition to fixing PR
14644, this should also make the font size slider a lot more responsive.
also, redraw the editor after changing the font size to make sure
the blue arrows get redrawn properly.
closes PR 14644
In the case that the current time equals exactly the timeout of
a `sync/timeout`, the Racket process could get stuck (using no CPU)
instead of continuing as it should.
How did we not find this before? Why am I suddenly able to replicate
the problem (i.e., hitting exactly the target timeout in the secheduler
at the millisecond granularity)?
Merge to v6.1
For example, if you accidentally type `raco pkg install` in your
"racket" directory, you'd rather have an error rather than competing
module paths that reach all libraries.
This change requires a coordinated change to the snip-lib pkg and to
the gui-lib package. The docs are in the gui-doc pkg and yet point to
the snip-pkg as the containing pkg, so I updated the version number
for snip-lib and left the version number for gui-lib alone
The `(or/c evt? any/c)` result contract is, of course, equivalent to
`any/c`, but the verbose variant hopefully helps explain that `evt?`
is really expected.
Yes, it would be better if the result contract actually was `evt?`
(and I implemented `replace-evt` that way before re-reading the
`guard-evt` docs).
A test tries to fill a TCP output stream so that it's no longer ready
for writing. There's no real guarantee that it's possible to setup up
and detect that situation, and a failure or two is not too suspicious,
but it really should be possible to fill the buffer. Trying 5 times
should make failure of the test especially unlikely in practice.
The workaround for the way that `test-begin` fails to compose
would drop a lot of information about the test failure. Allow
RackUnit's default printer to show that information but then
also abort.
(My more concrete goal is to understand why a particular test
sometimes fails on DrDr.)
