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.)
As suggested by Jan Dvořák.
The event created by `replace-evt` is a kind of event-gated
version of `guard-evt`. In particular,
(guard-evt thunk)
could be expressed as
(replace-evt always-evt (lambda (_) (thunk)))
Use `replace-evt` as a shortcut for the case when you want to
synchronize on either A or C, but you need to wait for B to get C.
You could wait on A+B and then, if B is selected, wait on A+C;
wrapping B with `replace-evt` to generate C is a kind of shortcut that
is eaiser to write and avoids tear-down and re-setup of A.
The `replace-evt` constructor is more than a shortcut in the sense
that it builds the pattern A+B->A+C into `sync`, which enables
abstractions that need a B->C transition. So, `replace-evt` adds
expressiveness, but (perhap reassuringly) it does not add any new
rendezvous capability.
Naturally, the procedure given to `replace-evt` can produce
another `replace-evt`, and the event argument to
`replace-evt` could also be a `replace-evt`.
