If:
- a field is used in an assertion of interest in facet A
- and that field changes
- to a value that causes the assertion of interest to overlap
with some facet B's assertion of interest
- and an assertion matching that interest was already known to the actor,
Then:
- previously, facet A would not be informed of the matching assertion
- but now, it is informed of the matching assertion.
This more or less only affects "on asserted" endpoints.
The change here should be written up as an erratum to chapter 5 in my
dissertation. Also, syndicate/js needs to be checked for the bug and
probably fixed in an analogous way.
Scenario:
- In script of facet X, (react (stop-when E (react ...)))
- This creates facet Y, child of X.
- Facet X has no endpoints, only its child facet Y.
- When the stop-when fires, without this patch, facet X
will be terminated because the *inner* react above hasn't executed yet.
- With this patch, the check for a useless X is done after the stop-when
has had a chance to run; and so X will survive for now.
- Facet IDs are now lists so arbitrary ancestors can be computed with
repeated application of cdr
- `stop-facet` is new and untested, other than that `stop-when` is
refactored to use `stop-facet`
- *all* matching stop-when instances run now; the limitation that
exactly one instance should match is lifted.
- roughly, (stop-when E X ...) === (on E (stop (current-facet-id) X ...))
Remaining to be done: fix `terminate-facet!` to do the right things in
the right order.
A recent change to Racket must have changed the way `for` expands,
because now in conjunction with `local-expand`, we see *effectively* a
`(begin (values) (void))`. This isn't a problem usually, but in
`#lang syndicate`'s `module-begin` context, we split apart `begin`s
and examine their constituents, leading to examination of something
that will ultimately yield 0 values.
The change accepts either 0 or 1 values when collecting actions for
the module's main boot actor to execute. More than 1 value yielded by
such an expression is still considered an error. Currently, it gives
unhelpful error location information; a future refinement might be to
make the error reporting for this (rare) situation more helpful.
This means that `*gc-priority*` scripts will now reliably run last.
Prior to this change, if some higher-priority script X ran while a
`*gc-priority*` script Y was queued, and it enqueued a high-priority
script Z, then Y would run before Z.
Sam Caldwell
Tony Garnock-Jones
Sam Caldwell