all this did was set .nut. while it could be used with doccords, it is
currently unused, and none of the other values in the sample of _ax are
set this way (bug, def, cox, hay, dom). i experimented a little bit with
trying to make use of this but it made things overall more unreadable,
and it wouldn't make sense to do it without doing the same for other
values of the sample. im guessing this is just an old style.
Previously, fake breaches triggered by a %ruin task would only get sent to
subscribers watching for the affected ship specifically. Now, we send them to
both those subscribers, and the ones watching for pubkey changes on all ships.
when +apse sees a link, it presume that the following a batch comment,
and stops parsing so that it can be picked up by apex:docs next
this required a change to +leap, which has been rewritten to pretty much
look like +gap but stop parsing when encountering doccords.
previously we just threw them out and wasn't sure whether it was the
right answer. this violates the principle of least surprise - even
though it hard to see the value of attaching multiple empty $cuff notes
to an arm, we shouldn't stop the programmer from doing it without any
indication or explanation as to why. its the behaviour you'd expect
given how doccords is structured.
it is desirable for both apex:docs and apse:docs to parse into an
intermediate representation that never ends up in an AST so that it is
clear that these parsed representations may be altered in the future
without worrying about old types nesting with new types. this was
already the case for $whit, but apse:docs parsed directly as a $help,
which is used in ASTs. so apse:docs now parses as a $whiz, which is
simply a cord. in the future, if postfix comments are used for something
like invariants, or allow $links, we may want to change this.
this also changes $whit to remove .use, which was unused. similarly,
+glom is removed since its not used anywhere.
this might actually be undesirable, don't want to leave this as a trap
for somebody in the future thinking we knew it was definitely the right
answer. having batch comments follow the chapter declaration does make a
certain amount of sense, stylistically
future-proofing %gist specs by putting a %help tag on the $help. this
looks pointless at first glance, but it allows the opportunity for %gist
specs to have a $% in the future in a way such that the old type nests
with the new one, eliding the need for a typo->type migration
Most of the memory stays in gall anyway, and this means you need to
recompile everything the next time anything changes, which could be
counterproductive. It's important that %trim not make things worse.
The functionality is moved to the debug %stir task.
These were originally added because they reduced memory usage, primarily
by clearing the memoization cache. Now that the memoization cache is
no longer used, we use less memory without them. On ~wicdev-wisryt with
~30 apps, updating Clay now takes ~320MB.
(addendum to +team change)
address feedback from ~rovnys-ricfer, ~master-morzod,
~ritpub-sipsyl, ~tacryt-socryp, ~wicdev-wisryt, and others.
the original functionality of +team has been split out
between +team:title and +moon:title.
also:
fixes "middle core" and "surface core" comments in title
this is to handle potential future cases where doccords might be kinds
of notes other than %help notes. example: #6085 to document invariants
in clay.
$whit (used for apex:docs/batch comments) also ought to be changed but
im still thinking about what that should look like.
partial revert of 3d3ea61d53, which introduced core names by completing
an unimplemented feature that was already present in hoon.hoon. we've
decided to remove this for the initial launch since it violates the
principle of least surprise for the name of a core to end up in its
$garb and yet only be used for doccords, as opposed to something like a
wing resolution. it was also confusing that this only worked for |% and
|@.
this breaks two of the tests for the dprint library, which have been
commented out. these tests ought to be restored once dprint is rewritten
in order to implement a different way to refer to cores not built by arms
this constitutes a pretty major rework of how whitespace is handled in
hoon in order to change the doccords syntax from :> and :< to ::.
in summary: throughout the hoon parser (+vast) many instances of +gap
have been replaced by +jump, which first tries to remove whitespace (+leap)
until it arrives at something that can be parsed as a prefix
doccord (+apex:docs:vast). if it does not encounter a doccord, it
instead uses +gap as normal.
if you follow along with the parser, you will notice that every time
jump is called, it then tries to call +apex:docs via +scye or +seam. if
apex:docs succeeds, it will end up consuming a newline at the end,
hiding the fact that there was valid whitespace from the parser. thus
+apex:docs then inserts a newline after successfully parsing a prefix
doccord, which will then be consumed by a subsequent invocation of +gap,
ensuring that there was proper whitespace if the doccord would have been
consumed by +gap instead of +leap.
there are a few other changes:
+hint in the compiler throws out doccords attached to %noun types. this
was already the behavior before doccords, and the change was made before
i understood what i was doing.
similarly for commenting out the %note case in +open:ap - this was an
earlier mistake
postfix comments for chapters are now enabled.
+expx was unused and removed in order to be rid of the
convention-defying +exp1. other unused +ex(p/q)* were commented out.
arms that handle batch comments (+glow and +whap) were refactored
+toad, which was used to change between tall and wide form, tries to
+jump before +gap. since +jump is ;~(pose leap:docs gap), i would have
thought that just using +jump there would be fine, but it fails for some
reason.
some parsers built with |@ were rewritten to use |*
|$ was made so that any doccords put on the spec are converted into hoon
doccords on the $ arm. it wouldn't compile otherwise. there's probably a
more principled way to do this but it works fine for now.
- fix `fragment-num` and `num-fragments` having duplicate faces
- fix faces being wrapped around wrong things in various places
- fix `bone` not being printed in "hear last in-progess" message
- make pretty tape interpolation style more uniform
in the past, +team meant "our / our moon", but
it has been primarly used to represent "our"
moons as having the full permissions of their
parents doesn't make a lot of sense anymore
this looks like the more elegant solution
instead of changing each instance of +team
I've combed through the uses of +team throughout
urbit/urbit and I'm quite sure that each instance
is better off as just "our"
The +on-cork handler asserts that the peer is known to us. This is the
incorrect behaviour, because it will crash when corking a flow to a peer
that is still an %alien. This can happen, for instance, when making a
gall subscription for the first time and then corking it before the
alien naturalises.
