When molds were changed to crash on bad input, mook was not updated.
It relied on the old behavior of bunting on bad input. +moko
(the replacement +mook) simply doesn't include stack items that don't
have the proper type (in constrast to +mook, which currently crashes
and used to leave a "blank"/bunted stack item for improperly typed
values).
- change the nock interpreter to bail [1 block] instead of [1 block ~]
- modify mink jet to rewrite this error ball to the old style
- add a mino jet that takes advantage of the new style
%hand hints aren't handled by the normal interpreter, so they
were disabled in the test generator.
there was a mismatch in the case of a nock 6 with one invalid branch
(either yes or no), which necessitated a little extra logic when
compiling nock 6. invalid nock is rare in the wild and there are no
tests for this (somewhat subtle) behavior. previously, either branch
invalid was (incorrectly) considered an invalid formula and would not
compile.
+mink, the current virtual nock interpreter, has a couple of problems.
1. it propagates blocks as a list of paths, which is inconsistent with
the way the jet behaves (only a single path is ever blocked on, with
exception semantics).
2. +mush was not updated after the change to molds to crash instead of
bunting. it crashes when not given the right kind of data, which is
inconsistent with the intended semantics of ++mink.
3. it "eats" hints, causing (for example) slogs to disappear when running
without a mink jet.
4. the naming/style was typically cryptic. since +mink will never really
be run, one could argue that its primary purpose is to be read.
+mino (which will be renamed to +mink after some staging) has had its
return type (+tono, to be renamed +tone) modified in the block case so
that it only blocks on one path, has a corrected +mush, carefully
"passes through" all hints to the underlying interpreter, and has more
meaningful names, with the intention of improving readability.
A generator (gen/mino.hoon) is also included in this commit; it contains
tests that were used during the development of +mino. It should be removed
before integration, and is included for posterity. The stack trace semantics
are expected to change in the near future (since they are dependent on jets
faithfully preserving the stack pushes of the pure nock, an onerous burden).
They are, however, tested in gen/mino.hoon, which makes it unsuitable as a
long-term test.
* origin/king-haskell: (411 commits)
Fix counting bug in event log replay.
fix progress bar in daemon mode
Got Linux release builds working again.
king: style improvements
king: Build without warnings.
Fix king-haskell Linux release build.
Update scripts to point to `urbit-king`.
Renamed modules Ur.** to Urbit.** to be consistent with urbit-{atom,hob}
king: Rename `king` package to `urbit-king`.
Clean up `Urbit.Atom` and move it into it's own package.
Module structure, doc strings
Bump stackage version.
Got docs to build.
king haskell: automatically connect to terminal when running a ship
king: add partial-replay and --dry-from
Make sure we close HTTP sockets on close (or reconfigure).
Hack around terminfo database problem.
Fixed bug in HTTP Server (only first block from stream was handled).
Logging for event sourced responses.
Cleanup port binding logic.
...
Signed-off-by: Jared Tobin <jared@tlon.io>
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)
Release tarballs previously didn't include a release directory, so the
files would be unceremoniously dumped into the user's current directory
when extracted.
Fixes#1400.
This reverts commit 94800ca79c, which
fixed a bug with mugs in Vere. Fixing it retroactively invalidated the
mugs in all event logs in the present era, however.
Adds a derivation that uses a patched pkg/urbit/vere/lmdb.c that employs
a sixty gigabyte log limit, instead of the default forty. This is
useful for ships e.g. ~zod that receive a lot of traffic on mainnet.
'installPhase' captures all the important stuff that builder.sh
previously did, and use of the generic builder allows stages of the
build to be more easily overridden.
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.
