next-error and prev-error are weirdly broken in ways I don't entirely
understand, but I only really use flycheck so I can just use the
flycheck ones instead
Change-Id: Icdb25950f6fdcca163c68db30366af0f6fa28d7d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3108
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Owothia graduates, or something.
Mostly I don't want infrastructure to depend on stuff in //users.
Does anyone know where owothia is running anyways?
Change-Id: I198c7ac935736c7aee3ba4fbda1453b82aa10283
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3103
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
`write` returns the written usize; now I wonder why rustc didn’t at
least produce a warning because the result was unused. Do we need to
add any flags to `rustSimple`?
Change-Id: If8d51d95c993dec6c92e46dbc82cd8cdd398f441
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3056
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
I think it’s solid enough to use in a wider context.
Change-Id: If53e8bbb6b90fa88d73fb42730db470e822ea182
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3055
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Reviewed-by: lukegb <lukegb@tvl.fyi>
Moving to toplevel so I can use them with `runExecline`. They should
be pretty atomic, and are proven to work (tests are still in my user
dir, since they test the producers indirectly via the python parser
and I don’t want to pull it out right now).
Change-Id: Id0baa3adcb2ec646458a104c7868c2889b8c64f5
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3054
Reviewed-by: Profpatsch <mail@profpatsch.de>
Tested-by: BuildkiteCI
Like `eprint-stdin`, but reads stdin as netencode and pretty-prints it
to stderr.
Change-Id: I430c010b0cac45f077cde9dadfd79adfa7a53eca
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2533
Tested-by: BuildkiteCI
Reviewed-by: Profpatsch <mail@profpatsch.de>
Simple pretty printer for netencode values, as a rust library and an
accompanying command line tool which takes netencode on stdin and
prints the pretty version to stdout.
Change-Id: I0a57c644985162bc08a9bf1ee78f7be278400199
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2532
Tested-by: BuildkiteCI
Reviewed-by: Profpatsch <mail@profpatsch.de>
It’s the inverse of record-splice-env! It sucks up the environment and
prints it as a netencode dict! Only the utf-8 clean parts at least.
Change-Id: I96c19fc5ea3a67a23e238f15f4d0fa783081859c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2527
Tested-by: BuildkiteCI
Reviewed-by: Profpatsch <mail@profpatsch.de>
The user expects the editor to remember the positions of fields they
navigated from to a new level, so when they return they get put in the
same spot.
We push the index from one field into every level of the value.
Unfortunately this introduces pointers and all the woes they bring.
Change-Id: I889c28b71fd7082b765e1d6874faeb1b36dade60
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2866
Tested-by: BuildkiteCI
Reviewed-by: Profpatsch <mail@profpatsch.de>
This will be needed to factor the current cursor position into vals.
Change-Id: I73635b13c29b6b8925c68005c8db1c4dda93f15d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2865
Tested-by: BuildkiteCI
Reviewed-by: Profpatsch <mail@profpatsch.de>
Since items are aligned per-line, it makes more intuitive sense to use
up/down for previous/next item, and left to go up and right to go
down.
Change-Id: I6bc33bd4e6e8f9fb245d252ca063dfabf972147d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2864
Tested-by: BuildkiteCI
Reviewed-by: Profpatsch <mail@profpatsch.de>
This makes it possible to pipe json dicts to the program and fully
navigate them.
Change-Id: I18dd8683d6f00c8ea967eb0c8dc89d1e0735fbcb
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2863
Tested-by: BuildkiteCI
Reviewed-by: Profpatsch <mail@profpatsch.de>
A take at a TUI-based structural editor, which should eventually read
a type definition of a structure and some values, and build a GUI to
edit it.
So far you can only pipe it some restricted json (lists, strings and
floats) and “navigate” through the structure with the arrow keys.
Change-Id: I7c8546459ff86c766fc03723f732c7d9f863ceaa
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2862
Tested-by: BuildkiteCI
Reviewed-by: Profpatsch <mail@profpatsch.de>
We don't need these in the depot anymore as the Emacs overlay now
provides newer versions of them, or because they are not used anymore.
Change-Id: I393e1580b66450d0bb128213bc79668172dadacc
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3005
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
This is currently done ad-hoc in a bunch of our systems, but we should
just do it centrally.
The commit message is a bit of a lie, as this doesn't yet update
grfn's systems.
Change-Id: Ic771c1a1da78ec5de9cffbf94c296dce5e11fd84
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3047
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Provide ddcutil and paperlike-go in $PATH. Provide the necessary udev
and kernel module plumbing so they work as non-root.
Icecream-Required-From: Vincent Ambo <mail@tazj.in>
Change-Id: Ic9323a45cdbb75571e8f8b3aca4b9a763c271968
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3029
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Implement tuple expressions, types, and patterns, all the way through
the parser down to the typechecker. In LLVM, these are implemented as
anonymous structs, using an `extract` instruction when they're pattern
matched on to get out the individual fields.
Currently the only limitation here is patterns aren't supported in
function argument position, but you can still do something like
fn xy = let (x, y) = xy in x + y
Change-Id: I357f17e9d4052e741eda8605b6662822f331efde
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3027
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Rather than pinning a nixpkgs in here, just import the relative path to
the depot to load nixpkgs.
Change-Id: I452727d45e4f44ecc99b86d17e88a413c1911c59
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3025
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
I want notmuch to open in a full window, not as a bottom-of-the-screen
popup.
Change-Id: If539ff315fabae94d5a849c526c4322f9bdf8c61
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3024
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
This... mostly works! I had to install it from the latest master branch
to get it functioning on my CPU, hopefully once they release a new
version I can remove the override.
Change-Id: I863d2e822b149838c58aa1c1e7dc73a127a0aeb8
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3022
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
It is easier to do the inverse of this solution: Filter out the
package on the machines that get it from elsewhere.
Change-Id: I2abe112e4e38822d0fc7a47ea0bcedec1e0a96e3
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3010
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
... but keep defaulting to standard Emacs27, for $reasons
Change-Id: Ife243ab18a03e6b0270a39c639cc493d71240362
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3007
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
Since we need to override random to 1.2.0 globally for xanthous
(otherwise propagation causes two versions of random to be propagated
for xanthous) evaluating haskell related stuff using import from
derivation can be very expensive since utilities like hpack and
cabal2nix need to be built for that. This means that for every channel
bump we potentially need to do a world rebuild of haskellPackages first.
To solve this we check in the cabal2nix-generated nix expressions for
owothia and xanthous.
Change-Id: I8fff70b4b6c303d1920f8bcac53520a09999b206
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2921
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Reviewed-by: tazjin <mail@tazj.in>
Instead of having two ways of accessing the path to the depot (one of
which was stuttering, depot.depotPath) we settle on only one:
depot.path.
This was mostly used for NixOS module imports.
Co-Authored-By: Florian Klink <flokli@flokli.de>
Change-Id: I2c0db23383fc34f6ca76baaad4cc4af2d9dfae15
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2962
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Reviewed-by: sterni <sternenseemann@systemli.org>
As a complementation to builtins.functionArgs this function checks if
the function has a set pattern that contains an ellipsis
(i. e. `{ [arg, [ arg1, [ … ]]] ... }:`). The implementation of this is
pretty cursed however since there is no clean way to do this in vanilla
nix: We need to match on the output of builtins.toXML which does try to
serialize functions by outputting their argument and information about
it (whether it is a normal argument or a attribute set pattern, in the
latter case it also serialize every component of the pattern).
Change-Id: I0f33721811a3180cec205a0c98e6d92e10e92075
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2950
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
I'm not using cloudfront for gws.fyi anymore, so this invalidation step
on deploy is pointless
Change-Id: I153848666dc70acfc456b5dcf276bab2410c4716
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2946
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Looks kinda like rebuild-mugwump, only for home
yes, yes, this could gc halfway through, that's so unlikely that I don't
care
Change-Id: Iab3fdac15796e9f8158a9778b897bc3fe88e536e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2942
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
