This version supports newer Cargo features that are starting to appear
in our dependencies.
Change-Id: I2eb7efdf945cacc53e8ced6ac9cb0255d08ca582
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7589
Reviewed-by: flokli <flokli@flokli.de>
Autosubmit: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
As we start using this in more parts of depot, it makes sense to add
it to the available tools.
Change-Id: I148902714167b36bc51aeca4a241c79ad8a59285
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7562
Reviewed-by: flokli <flokli@flokli.de>
Tested-by: BuildkiteCI
Autosubmit: tazjin <tazjin@tvl.su>
Reviewed-by: tazjin <tazjin@tvl.su>
This defines a service that can be used to get and put content-addressed
chunks of data.
Change-Id: I36cf2278ed1daf71848c04fdfd14450b2268c5de
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7135
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
Manually maintained shell target based on the previous "loose"
`shell.nix` file.
We might want to have a function that combines the dependencies of all
the targets automatically, but at a quick glance that was actually
non-trivial so I'm leaving it as an exercise for someone else.
Change-Id: I74754940088f1b58e3b6754fb782470c80ea4292
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7540
Autosubmit: tazjin <tazjin@tvl.su>
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
Introduces granular dependency builds using crate2nix, bootstrapped
off the generated configuration from the newly introduced
workspace (see cl/7533).
This commit checks in the generated Cargo.nix file which can be
regenerated with a parameterless invocation of `crate2nix generate` in
`//tvix`. I tried generating this in IFD, but it turned out to be
harder than what seemed worthwhile for now.
In this setup, the various build targets for Rust projects end up
being attributes of the imported `Cargo.nix` file at the `tvix.crates`
attribute. These still lack configuration, however, which has been
fixed in the various `default.nix` files of individual projects.
Note that we (temporarily) lose the ability to build tvix-eval's
benchmarks in CI. I haven't figured out what magic incantation summons
them from the void again ...
The `eval-okay-readDir` tests from both test suites have been disabled
because they fail for unknown reasons when run in this new derivation.
Somebody will have to debug it!
Change-Id: I2014614ccb9c8951aedbd71df7966ca191a13695
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7538
Autosubmit: tazjin <tazjin@tvl.su>
Reviewed-by: flokli <flokli@flokli.de>
Tested-by: BuildkiteCI
This relates to the (abandoned) cl/7256.
Introduces a Cargo workspace at //tvix that is primarily intended to
be used as a workaround for the annoying Nix+Rust tooling while having
a consistent set of dependencies.
This is driven in part by a desire to adopt crate2nix and get more
granular Nix builds for Tvix's Rust projects, and in part by a need to
split //tvix/eval into something providing the CLI (REPL etc.), and a
library providing eval, without significantly altering the structure
of build targets.
To accomplish this the workspace has been designed to allow projects
to remain independent build targets. I want to avoid lumping all the
projects together - something like //tvix/eval should always be
independent of other parts of tvix.
A helper function in //tvix/default.nix lets downstream naersk
projects construct a sparse root for the project which combines the
workspace's `Cargo.lock` with the project's own `Cargo.toml`.
Note that cargo commands in the workspace itself require the build
dependencies of _all_ projects to be present, which is currently a bit
annoying to accomplish.
This introduces some breakage:
1. It breaks usage of rust-analyser without being in a shell with the
dependencies of *all* Tvix projects, as it is not capable of
respecting only the subset of dependencies for a part of the
workspace.
2. It is no longer possible to run tests using `cargo test`, as the
test generation crate we use does not work with workspaces:
https://github.com/frehberg/test-generator/issues/6
This still works in the Nix build as we construct a Cargo project
that looks like it's not in a workspace there. Until somebody fixes
that crate / writes a new macro / does something else with the test
suite, the way to run the tests is through the Nix build.
Long-term we'll probably want to get rid of cargo completely, it's
just a big wart and most tooling works without it if correctly
configured, but we don't have time for that now.
Change-Id: I846bff7a8429a25c077fd1e9ef4e3c34a299a4a1
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7533
Reviewed-by: flokli <flokli@flokli.de>
Autosubmit: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
This .envrc file causes additional software to be loaded, but there is
no way to opt-out even if the software is not desired:
1. If I opt-in (i.e. `direnv allow`) the file, additional stuff that I
don't need is injected into my environment in a blocking way.
2. If I opt-out, *all* of the depot configuration (including `mg`) is
unloaded, as direnv configurations do not trivially nest.
I have to work around this constantly by making the file contain just
the line `source_up` and then setting `--assume-unchanged` on the git
index to avoid accidentally committing the file changes.
This is kind of silly, the people who *want* this stuff to be loaded
should devise a mechanism that loads it automatically but is opt-in.
This could be done e.g. by gating something on environment variables,
or having a shell hook, or whatever. Breaking expectations that hold
elsewhere in depot is not okay, however.
If you manually want a shell for a project, run `mg shell` either with
a target specification for that project (e.g. `mg shell //tvix/store`)
or in the project's folder.
You can also just use standard nix-shell invocations.
Change-Id: I0de43378424d0cb1e1279c72c47940fecf497bf0
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7531
Reviewed-by: tazjin <tazjin@tvl.su>
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
Autosubmit: tazjin <tazjin@tvl.su>
Looks like a vterm release clobbered these. Let's explicitly define them in the
vterm-mode-map.
Change-Id: I3248050535be903020a75bc0503da38ec9641d85
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7579
Reviewed-by: wpcarro <wpcarro@gmail.com>
Tested-by: BuildkiteCI
This always fails when running due to mismatched glibc versions, which
like... isn't nix supposed to solve thaat? I don't have the energy to
debug, this isn't important
Change-Id: I54fb91a0b8ee46b19af4f4b987e5c17d1cf6984f
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7570
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Autosubmit: grfn <grfn@gws.fyi>
discord just... refuses to launch if you're running an old version, so
we basically always have to override
Change-Id: Ia12b31da1d235fe023c06342e00b53be38d8dcd9
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7569
Reviewed-by: grfn <grfn@gws.fyi>
Autosubmit: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
I cheated a bit to skip implementing multi cycle instructions. The VM is
pretty much a normal tail recursive function, but working with scalars
in BQN is on brand-ish. Array programming helps again when drawing the
picture on screen.
Change-Id: I2562c862e228f633c5fad09e503529c6e0785112
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7556
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Autosubmit: sterni <sternenseemann@systemli.org>
Added utility used to be related, but got dropped in a refactor.
Change-Id: I1f88973d6b42f1302b49cd61c53e4cd1e15b8c6f
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7553
Autosubmit: sterni <sternenseemann@systemli.org>
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
Did not have the motivation to go back and improve things, so this is my
initial attempt.
Change-Id: I3e129523d8f6c03bfbe50351f78d56ec7254a2dc
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7539
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
Autosubmit: sterni <sternenseemann@systemli.org>
A few weeks ago, oberblastmeister did a release to crates.io so we can
stop importing it via GitHub.
Change-Id: I9d5fa5cd281685779c71b12fed45ed201a1db17e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7532
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
By taking advantage of filling (ironically) we can avoid creating a spec
in an ugly way. Additionally we transpose before parsing which doesn't
really make all that much of a difference, though.
Change-Id: Ida593138654f8367d666447f2b62013e8ddff01e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7535
Reviewed-by: sterni <sternenseemann@systemli.org>
Autosubmit: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
Today's problem works very nicely thanks to window although the indexing
sadly is off by a constant amount from what we immediately get. I have a
feeling someone is going to demolish my 31 char k solution.
Change-Id: Ia90786ce2fe321235286a85c466decf7feb669ed
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7534
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
Autosubmit: sterni <sternenseemann@systemli.org>
* take advantage of block header for destructuring
* instead of ModestTake we can split the stack we are picking from into
what we need to move and what to keep, saving us from having to repeat
ourselves.
* remove some unnecessary parens
Change-Id: I1b81a93a27d14dcbb6bdd109e862a356f611aca9
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7530
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Autosubmit: sterni <sternenseemann@systemli.org>
First input that is genuinely fun to parse in BQN. There surely is a
nice trick for _ApplyCmd, but this works and I'm unable to think today.
Change-Id: Iefccc81f1c1db03f45e31aaf7a1703ac0f91306f
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7529
Autosubmit: sterni <sternenseemann@systemli.org>
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
This uses prost-build to build the proto files.
Change-Id: Ia99fcfa4a19c741683cf28a45202e1d9211f9131
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7286
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
Reviewed-by: Adam Joseph <adam@westernsemico.com>
This adds the PathInfo message, which hosts information about a Nix
Store path, mapping to either of a {Directory,File,Symlink}Node.
Change-Id: I79d871b6fad450d6a4ae4101fb72c51f9a83471f
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7132
Reviewed-by: Adam Joseph <adam@westernsemico.com>
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
This moves the castore.proto file into the //tvix/store/protos directory. Per-
component protos might make more sense, than a "tvix-wide" proto directory.
Change-Id: Ie728210174b041e9285a0e2ac605d715d0f0cbda
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7285
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
When pushing a large chain of CLs, builds can fail with OOM issues as
many Nix evaluations of the depot are happening simultaneously.
To work around this, we limit the concurrency of simultaneous Nix
evaluations (i.e. the `:llama` step). This can slow down the start of
builds in a large chain of small changes, but that is a better
tradeoff than failing the builds entirely and making people click
buttons.
Change-Id: If351aaad22d52e2bcf871377f22ab1df594c518d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7501
Reviewed-by: sterni <sternenseemann@systemli.org>
Autosubmit: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
Fixes b/212. Based on feedback in https://cl.tvl.fyi/c/depot/+/7492, all
uses of `NixAttrs::from_map` have been removed. Only `from_iter` and
`from_kv` remain.
Change-Id: I52e25f73018c2aa1843197427516b7a852503e2c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7500
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
Autosubmit: IslandUsurper <lyle@menteeth.us>
Uses the same idea as the BQN solution, but is very concise.
Change-Id: I876208e5e86f28240f4a3384d16321fd92d077eb
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7499
Autosubmit: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
It seems to me that there must be some way to improve this further,
but I'm kind of out of time.
Change-Id: Icf3510b6c126345551125543aec70155b6eeff4e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7498
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Autosubmit: sterni <sternenseemann@systemli.org>