5d8490d2fc
Setting meta.targets to include all derivations in the different package sets in Profpatsch's user folder makes them checked by CI until they do the readTree refactor as promised. To reduce code duplication we handle this in a simple function which is exposed from nix.utils which may be a good place for depot specific bits and bops we accumulate over time. To get around the issue of too nested sets we perform the following renames: * users.Profpatsch.tests gets moved into its own directory * users.Profpatsch.arglib.netencode now lives in its own file instead of the default.nix * users.Profpatsch.netstring.tests gets moved into its own directory Change-Id: Icd039c29d7760a711c1c53554504d6b0cd19e120 Reviewed-on: https://cl.tvl.fyi/c/depot/+/2603 Tested-by: BuildkiteCI Reviewed-by: Profpatsch <mail@profpatsch.de> |
||
---|---|---|
.. | ||
tests | ||
default.nix | ||
README.md |
Netstring
Netstrings are a djb invention. They are intended as a serialization format. Instead of inline control characters like \n
or \0
to signal the end of a string, they use a run-length encoding given as the number of bytes, encoded in ASCII, at the beginning of the string.
hello -> 5:hello,
foo! -> 4:foo!,
こんにちは -> 15:こんにちは,
They can be used to encode e.g. lists by simply concatenating and reading them in one-by-one.
If you need a more complex encoding, you could start encoding e.g. tuples as netstrings-in-netstrings, or you could use netencode
instead, which is what-if-json-but-netstrings, and takes the idea of netstrings to their logical conclusion.
Resources:
Spec: http://cr.yp.to/proto/netstrings.txt Wiki: https://en.wikipedia.org/wiki/Netstring