By factoring their shared logic out into +build-dependency, which gets
passed the relevant details about how to track the file being built in
the dependency stack.
Hoon files may want to import nouns from all files in a given directory.
/~ lets you do so, importing as a (map @ta *) (but with typed values).
Note the description as "directories" here, instead of "path prefix".
The behavior, as implemented, will not include /path/hoon for /~ /path,
instead only including /path/more/hoon and more deeply nested files.
This seems to be, generally, the behavior you want, for example when
importing from /app/myapp/* for /app/myapp/hoon.
Actually using the resulting map requires some manual casting, which is
not ideal. Some code style improvement work remains to be done as well.
In +en-json, the vast majority of our time is in +jesc (json string
escaping). Since ships will always be string-safe, we pretend they're
numbers to bypass the escaper. This saves about a second on initial
landscape load.
Avoid allocating hundreds of thousands of cells when giving large
requests. This took the footprint of this function on initial landscape
load from 1 second to 100 ms.
We commonly print many names in a row, often the same ones. For
example, on landscape's initial load, we send all the members of all the
groups we're in, and there's substantial overlap.
At least half the cost is in +fein, which is not currently jetted, but I
believe there's an old jet in the git history.
Fixes#4598.
#4474 made the JSON time conversion no longer invertible, which caused
problems for chat, which uses message timestamp in milliseconds as a key
-- so chat would send a message with ms timestamp x, it would get
encoded as @da x, but then when it went back through the conversion to
milliseconds, it would often (not always) get encoded as x-1.
I still do not fully understand why this is -- and why it doesn't seem
to be a problem with seconds based on cursory testing -- but integer
multiplication and division generally do not invert. And adding a half a
millisecond to the input date before converting it resolves the issue
and makes the functions invertible.
I added a regression test, so hopefully the next courageous adventurer
who winds up here after wondering why +unm looks funny will have a
safeguard against some of the mistakes I made.
State before: in chrono:userlib, there were second-resolution
@da-to-unix and unix-to-@da functions. In en/dejs:format, there were
millisecond-resolution @da-to-unix and unix-to-@da functions. The
@da-to-unix path in time:enjs confusingly rounded to the nearest
millisecond, meaning millisecond n was a label for [n-0.5, n+0.5) rather
than [n, n+1).
This adds a millisecond-resolution @da-to-unix and unix-to-@da to
chrono:userlib, and a second-resolution conversion to en/dejs:format.
It makes use of the chrono:userlib functions in en/dejs, and doesn't do
any rounding.
Backwards-incompatible changes:
- made unt:chrono:userlib take a @da rather than @.
