if a copyNAR generator was not drained to completion it would not read
the full nar data from its source. this could happen if the copier was
passed to parseAndDump wrapped as a source because copyNAR would yield
nar metadata *before* it had read it, and GeneratorSource will drain a
generator fully *only* if the source is allowed to throw EndOfFile. in
the parseAndDump case this never happened because parseAndDump expects
to be given an unterminated stream, and thus the combination left some
nar metadata in the input Source, breaking the remote store protocols.
fixes#732
Change-Id: Ia59a53375992bfcdb7bc6b37764ca779622bc8f7
Documenting fetchTree is an exercise in frustration because of the sheer
amount of stringly typed everything in it. I do not know which fields
exist without reading the entirety of libfetchers. However, we can write
something slightly perfunctory but at least perhaps somewhat helpful
documentation-wise.
Fixes: https://git.lix.systems/lix-project/lix/issues/609
Change-Id: I991391b53fcd69172dbc7efb9d384e62bc847b91
`prim_toString` uses `state.coerceToString`, which in turns defers to
`std::to_string` for floats, which 'Converts a floating point value to a
string as if by std::sprintf(buf, "%f", value)'.
Finally, the `%f` specifier 'Converts floating-point number to the
decimal notation in the style [-]ddd.ddd. Precision specifies the exact
number of digits to appear after the decimal point character. The
default precision is 6.'
Closes#747
Change-Id: I42339651005d20f272459cf9f80b274f2076b1e3
this would've caught the missing aio await. also disable some rather
annoying deprecation and missing initializer warnings in dev builds.
Change-Id: Ibbb9dfc67eada0e7843081b669b7c8726a02ec29
This is a redesign from 9b1f3cbc13 where
this was introduced.
I deleted the AbstractConfig::toKeyValue since it was conspicuously and
obviously broken for two years since 450e5ec618.
I asked myself if anyone was using it, given that it only emitted
settings that were aliases (broken!), and found that nobody used it.
The motivation for this change is the same for only emitting overridden
settings to the protocol: the nix inside there may not be able to parse
our defaults, as is the case of CppNix since the consensual
accept-flake-config was added to Lix.
Fixes: https://git.lix.systems/lix-project/lix/issues/739
Change-Id: Ib9874a52137f1f22220c25bcfa2425a4802509c7
In cl/1549, this function was changed from calling `getFile(path, sink)`
to returning `getFile(path)`. As a result, the `StringSink` is no longer
used. However, the sink was still being allocated.
Change-Id: I26c8556f20bc4f922912d8a921e8f47aa2bf975e
Missing these is really annoying, causes massive problems for debugging
(if you don't to enable build logs), and there's basically no reason we
can't just always show them.
In the future we might want to emit these to syslog/systemd/etc, but for
now let's just always print them to the console.
CC: https://git.lix.systems/lix-project/lix/issues/675
Change-Id: Ib6c47f3e34e553505298ed49c8bdb43f3db317a4
This removes static initializers for `nix` subcommands. cl/1905 made
the same change but for legacy commands.
See: #359
Change-Id: I23c99755719cef8e73fc720b685d4d1cf9b4ef15
This should be submitted as part of a stack, doesn't make too much sense
on its own, but it's mechanical and it builds it's easy to split it out
of the diff.
Change-Id: I453061482476c72a5fc6fb2662b000d79b87fc1b
Fixes these warnings:
[WARNING] hook id `check-executables-have-shebangs` uses deprecated
stage names (commit) which will be removed in a future version.
run: `pre-commit migrate-config` to automatically fix this.
Change-Id: Iab7d35999244df0eb4c32541b1f9c6a2dc2f3e28
Previously, only the `install` target in the `justfile` took extra
`*OPTIONS`, which meant you could run `just build install test` (or
`just clean setup build install test` for a clean build). This is much
more convenient than `just build && just install && just test`.
However, sometimes you *do* need extra options for some of those other
targets, so over time they have gained extra arguments. But these
prevent you from chaining the targets together:
$ just clean setup build install test
rm -rf build
meson setup build --prefix="$PWD/outputs/out" $mesonFlags build install test
usage: meson [-h]
{setup,configure,dist,install,introspect,init,test,wrap,subprojects,rewrite,compile,devenv,env2mfile,reprotest,format,fmt,help}
...
meson: error: unrecognized arguments: install test
error: Recipe `setup` failed on line 13 with exit code 2
As a compromise, I've renamed the targets with extra arguments to
include a `-custom` suffix, and added aliases for the old targets to
call the `-custom`-suffixed target with no extra arguments.
This makes it possible to run `just build install test` again, but keeps
the ability to run `just build-custom EXTRA_MESON_BUILD_ARGS`.
BONUS:
- Added `test-unit` and `test-integration`, because I always forget the
arguments to run a particular test suite and the names of those test
suites.
- Added doc comments to `lint` and `lint-fix`.
Change-Id: I61ec66f5e4d38c12bbae4fa226d7b4cea94579d1
Once I add `registerNixDaemon` and similar for the new-style commands,
they'll conflict with the old `register*` functions, so let's add
`legacy` to their names.
Change-Id: I3fc0f15985abe43bc1f257be3ebd9021b66055a3
This name made sense at the time, but now I'm looking at making the
corresponding change to `CommandRegistry`, and I don't think `Commands`
is a good name for _that_ type, but I don't want the types to be
mismatched, so here we are.
Change-Id: I06068cbde00f49ff3d720c505a567a152b00b61c
This sorts lines alphabetically between `keep-sorted start` and
`keep-sorted end` markers.
See: https://github.com/google/keep-sortedCloses#730
Change-Id: Ib36f3da81fcf5e2f588ffb998860456405607eea
Right now, Lix waits for quite a while five times[1] if a substituter is
down. If the substituter is not reachable for that long, it's probably
down or so slow that it doesn't make sense to download from it. Also,
most people would abort earlier assuming that Lix just behaves weird in
that case.
Reducing the timeout to 5s to make the behavior a little better.
If people live in areas with poor connection where a higher timeout
would be appropriate, I'd argue that they should increase the timeout
rather than requiring everbody else to set it to a non-zero value.
Additionally, communicate how often we're re-trying.
[1] Because of `download-attempts` from `nix.conf(5)`
Change-Id: I8500dce0c8230247dd492e43cc7af4d3b58c4710
Closes#703
The problem boils down to:
* A testcase with a segfaulting worker due to a stack overflow from the
evaluation.
* When the controller encounters that the pipes are down, the worker's
state is checked and a potential infrec is reported if it stopped with
SIGSEGV.
* However, in a few cases, the worker didn't exit yet, but only had closed
pipes (which is how the error is detected). In that case, a different
error message is printed breaking the test.
This bug handling only affects error cases, so this race doesn't happen
on normal shutdown. To mitigate the problem a bit, the controller will
wait for a second and re-check the state of the worker process then.
While this should make the error reporting for end-users a little more
reliable, it's still no guarantee for a non-racy test. Hence, the test
asserts against both cases now and it passes if either the infrec error
or the "worker still running, but pipes are closed" error is returned.
Change-Id: Ifdc7a05bc86b6aecd5d03118d3e3ffc9affe1c5e
This is to some extent a simple transliteration of bench.sh, but also
adds some additional features:
- the ability to select which benchmarks to run, instead of having to
run all at once (via --cases option)
- help text (--help), and argument parsing
- ability to profile instruction counts (via --mode icount).
Instruction count is a stable metric, that correlates to the execution
time, but is less affected by the environment (like other heavy programs
running, or the system hardware).
Other projects (most notably rustc) use instruction count as a primary target metric.
Change-Id: I791cac499e64983efb8bcd4ea1faef13ded09ee6
spawning threads is not free. reusing threads is also not free, but a
lot cheaper than spawning now ones. the difference can add up quite a
bit on nixos system evaluation; we've seen 20k threads cycled through
on even modestly sized configurations, and at 20µs per thread just to
launch and tear down (excluding any work done) that's potentially not
insignificant. in our test config this was a 3% eval time difference.
Change-Id: I40f901813e700fb99f5def82da54ca969711961b
