* origin/ted/ford-no-pit:
pills: update solid
http.c: revert timeout to original ~m10
tests: prime ford %reef cache
http.c: bump timeout from ~m20 to ~m30
http.c: bump timeout from ~m10 to ~m20
tests: fix ford tests for no %reef short-circuit
ford: remove pit short-circuit
* liam-fitzgerald/hoon-spot:
hoon: toggle spot typehints on flag
hoon: support %spot hint in xray
hoon: add %spot typehint
Signed-off-by: Jared Tobin <jared@tlon.io>
If we %add-owned, then we add an entry to the access-control jug matching the
data we put into the synced map. When a permission gets deleted, we remove it
from synced, but previously neglected to clean up the matching access-control
entry.
This ensures that if a permission was deleted, and we had it registered as
owned, that the relevant access-control entry is removed from state.
* origin/philip/gall-ack-fix:
gall: give both acks in case of unexpected ack
gall: make 2140e07 ota-able
gall: properly track remote acknowledgments
Signed-off-by: Jared Tobin <jared@tlon.io>
It's hard to say what's the safest thing to do when we get an ack we
weren't expecting due to losing outstanding.agents.state in +load
3-to-4, so this gives both a watch-ack and a poke-ack. This seems most
likely to succeed.
Does not change state type, but clears outstanding.agents.state since
it's full of garbage values. This introduces a possibility that we may
have been in the middle of something, so we handle that in a reasonably
sane way.
outstanding.agents.state is a queue of what sort of message we sent to a
foreign app. We use it so that when the acknowledgment comes back we
know whether to treat it as a watch-ack, poke-ack, or neither. We used
to put this info in the wire, but this gave us a different ames flow,
which meant %leave and %watch didn't get associated (causing #2079).
The error was that when when retrieving the item from the queue, we put
the new 1-item-shorter queue back in outstanding.agents.state at a
different wire than it came from, so the queues never actually got
shorter, and acknowledgments of the wrong sort were commonly produced.
This caused problems mainly in situations where we poke and peer on the
same wire, and possibly when a subscription was cancelled.
Possibly related to #2206 and #2176. I would expect this bug to cause
those issues, but I haven't verified the converse. Also possibly
related to #2153 and #2079.
"Replace" suggests this function either produces an updated set/map when done,
like +snap, or changes all values in-place, like +turn. In truth, it's more
similar to +roll, which does reduction/accumulation.
("Reduce" specifically was chosen because it maintains the mnemonic relation to
the arm name.)
Adds a `[%spot *]` type to the `note` type annotation definition.
These are added when the %dbug hoon is encountered. Done to enable
jump to defintion in the language-server.
Don't include pkg/arvo/tests and pkg/urbit/tests when running
git-archive(1).
Additionally, move the export-ignore declaration for
pkg/urbit/hashtable_tests into the pkg/urbit/.gitattributes files. For
default operation, git-archive(1) requires that these declarations be
located on the tree being archived.
Removes miscellaneous files that had lingered from pre-monorepoisation:
* pkg/arvo Travis and .gitignore, .gitattributes files
* pkg/urbit CONTRIBUTING.md (subsumed by file in repository root)
Due to asynchronicity, Ford can receive responses from Clay to requests
that it has already attempted to cancel. This removes some overzealous
assertions that this wouldn't happen.
Dynamically compute subject so that language server can see arms
from imports. Fall back to -:!>(..zuse) if the build is an app,
because of opaque payloads.
@ixv recently uncovered a bug (#2180) in Ford that caused certain
rebuilds to crash. @Fang- and I believe this change should fix the bug,
and we have confirmed that the reproduction that used to fail about two
thirds of the time now has not failed at all in the ten or so times
we've run it since then. @Fang- is still running more tests to confirm
the fix with more certainty.
It turned out the cause was that (depending on the rebuild order, which
is unspecified and should not need to be specified), Ford could enqueue
a provisional sub-build to be run but then, later in the same +gather
call, discover that the sub-build was in fact an orphan and delete it
from builds.state accordingly. Then when Ford tried to run the
sub-build, it would have already been deleted from the state, so Ford
would crash when trying to process its result in +reduce.
The fix was to make sure that when we discover a provisional sub-build
is orphaned, dequeue it from candidate-builds and next-builds to make
sure we don't try to run it. I'm about 95% sure this fix completely
solves the bug.
