This is mostly to help in tracing through the core dumps for b/58, but
is also generally a good idea while we're still in hardcore
debugging-mode.
Fixes: b/63
Change-Id: Ib816a2a98bf3b8afa6e8b255a74ccb93af6508c5
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1937
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
This reverts commit a41c3dedb1.
Reason for revert: I believe its time has come.
Change-Id: I4133dc8a3b57b40b280646d1622ed7a0409c5246
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1941
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: kanepyork <rikingcoding@gmail.com>
Write *all* build logs (essentially everything that wasn't a DLOG), not
just the stdout of the builder, to the client-bound log_sink_ that's
threaded through build.cc. These logs are significantly more useful on
the client, both when debugging tvix itself and (more importantly) when
building things with it.
To make this all work, this commit also refactors the passing-around of
the log sink in build.cc slightly - the main reference is now owned by
the Worker class, which already stores pointers to itself on the Goals
it creates, so those Goals can then load the log sink from the Worker.
This change was originally made to allow for logging to the log_sink
from instance methods of the worker, but actually feels significantly
more natural than storing the sink on the goal anyway.
Change-Id: I461685bc7f5c0a326054940ac5971b568dd43f8e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1925
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
The main bottleneck of our builds right now is Nix evaluation, which
means that most of the time is spent idling during builds.
Since we're evaluating in parallel, lets give it a few more builders.
I don't want to go all the way to 64 immediately to first see if we
get any adverse effects from highly concurrent builds running
concurrently (if we do we could group them into different "concurrency
groups" in Buildkite).
Change-Id: Ibc3f89fb59cb4ee471b152ff36887ffe2b39f8f8
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1932
Tested-by: BuildkiteCI
Reviewed-by: glittershark <grfn@gws.fyi>
In the past I used `defconst` in many of my Elisp libraries where I should've
used something like:
```elisp
;; some/path/to/some-lib.el
(defgroup some-lib nil)
(defcustom some-lib-setting nil
:group 'some-lib)
```
When I encounter code that I should've structured this way, I'm cleaning it up
to prefer this more idiomatic pattern.
This has somehow stopped being a thing in newer vterm versions,
causing the weird behaviour with my term switcher - buffers with the
correct name were sticking around, but no longer in the right mode.
Change-Id: Ie641eb3db91808d7d1016de1e8ef3ad271c8995e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1931
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
Since upgrading to Emacs 27 I have observed a strange behaviour where
this terminal switcher sometimes fails to select a valid buffer, in
which case it falls through to the case that just opens a new buffer
instead.
This is kind of annoying and to aid in debugging this change makes the
creation of new buffers explicit and fails if no matching buffer is
found.
Note that this is likely not a fix for the issue itself, but it will
help debug what is going on.
Change-Id: I906869aba7d25156aaf92c090b169ce02785b85e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1930
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
While attempting to debug why pressing `C-s-s` from an X-window screenshots my
entire screen, I switched from `call-process` to `make-process`, which is
async.
I still haven't debugged the original issue, but I think this is an improvement
regardless.
Since I'm calling `(require 'general)` in `wpc-package.el`, which gets called at
the beginning of my `init.el` file, all sub-modules have `general`. I originally
wanted this, but I'm beginning to rethink that preference.
After `script.el` broke my CI because of a missing `general` dependency, I'm
fixing it for `buffer.el` and all other modules that consume `general`.
Since script.el depends on buffer.el now, buffer.el fails to evaluate because of
a missing dependency on ts.el.
Blindspots like this make me want to eventually support testing individual loads
of each of the libraries in my .emacs.d/wpc directory.
Problem: `(bufferp "*Warnings*")` always returns `nil` because it expects a
buffer object. Thankfully I wrote a function called `buffer-exists?`, which is a
more DWIM alternative of `bufferp`.
Hopefully now CI should fail!
TL;DR:
- Assert that the path to the init.el exists
- Check *Errors* buffer in case an error is uncaught but logged
- Log a message when Emacs successfully initializes
TL;DR:
- Remove `require` statements from init.el
- Remove unused, auto-install KBDs for bookmark.el
- Remove unused `require` statements from clipboard
- Remove unused, commented-out code
I would like for an Elisp linting stage to test for unused `require` statements,
but I'm unsure how practical that is to support.
Here's what happened:
My `emacs.glinux` derivation relies on gLinux `/usr/bin/emacs`, and Google
recently published version 27, so all corporate machines (i.e. this laptop)
switched from Emacs 26 to Emacs 27 overnight.
However, my Nix derivation was building all of the packages for Emacs 26, so
some packages were compatible while others weren't.
The Elisp package, `emr`, doesn't build for version 27, so I dropped it
altogether.
After switching my namespace separator from "/" to "-" the function,
`alist-get`, clashed (surprise!) with the pre-existing function, `alist-get`. As
I was struggling to debug my broken Emacs (it broke bc Emacs 27 rolled out), and
I changed the module name, "alist", to "al" attempting to defuse the issue.
Auto-generate org agenda commands from project tags of the form
`project__foo_bar`, prefixed with `p` and named based on the first
letters of the words in the project. there is (obviously) some overlap
here but that can be fixed by just adding extra underscores to things to
disambiguate.
Change-Id: If07b15a21d8bcb6df6245e8c6e4731041930ecc1
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1926
Reviewed-by: glittershark <grfn@gws.fyi>
Tested-by: BuildkiteCI
These were not used anyway, and *may* have been causing a weird series
of problems leading to things sometimes aborting. Or maybe it has
nothing to do with it - the only correlation we've found is from
disassembling the output of a core dump. Regardless, this feels
stylistically like a good idea.
Change-Id: I288b50945e74ea90c118a21767fa4387c9f47f7d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1921
Tested-by: BuildkiteCI
Reviewed-by: kanepyork <rikingcoding@gmail.com>
I created a strangely named Elisp module, >.el, just to appease the CI gods. My
gut tells me that this is a desperate idea and fails the smell test. I'm pretty
eager to pass the linting phase of my Elisp CI, however, and I can always revert
this.
In order for this to scale, I need to solve two things:
1. Ad-hoc ignore fill-column rules for URLs and other exceptions.
2. Run Elisp flychecker without evaluating my Elisp code and firing its
side-effects.
Rather than printing "Nix" in the version string, print "Tvix". This is
cosmetically nice, but also is very useful when making sure I actually
have installed tvix on a system successfully.
Change-Id: Idd1a9954bd66509327f52b7457cfba2f090ab30c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1924
Reviewed-by: kanepyork <rikingcoding@gmail.com>
Tested-by: BuildkiteCI
This allows distinguishing between an empty value and no value.
Patch ported from upstream at
ba87b08f85
Change-Id: I061cc8e16b1a7a0341adfc3b0edca1c0c51d5c97
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1884
Tested-by: BuildkiteCI
Reviewed-by: kanepyork <rikingcoding@gmail.com>
When the nix daemon starts up, first check (using sd_listen_fds) whether
we have been systemd socket-activated. If so, instead of passing the nix
daemon socket path to grpc, start a manual accept(2) loop, passing the
client file descriptors to grpc via AddInsecureChannelFromFd. There's an
open grpc issue at https://github.com/grpc/grpc/issues/19133 for
building support into grpc to do this automatically, but as of right now
this appears to be the only way to make this happen.
Making this happen, by the way, was a bit of a journey - at one point I
attempted to ServerBuilder's experimental AddExternalConnectionAcceptor
API, and that didn't work either - it appears that the final missing
piece to getting this working was explicitly fcntl(2)ing the client file
descriptors to set O_NONBLOCK before passing them into gRPC. With that
set, this all works inside of the test vm.
Fixes: b/56
Change-Id: I5d2ab2b5b02eb570249b30a9674e115c61b0ab0e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1882
Reviewed-by: kanepyork <rikingcoding@gmail.com>
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
Expose depot to the test vm via NIX_PATH, so we can test the build of
depot packages from inside the test vm.
Change-Id: I26314634895ab1339f5715c0b0b261028eefdaa3
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1923
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Allow 16 things to happen in parallel, which is useful now that the
CI granularity is on a per-target level.
Change-Id: Ie65dd119ea0666618fbb249613e70a68276db834
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1902
Reviewed-by: glittershark <grfn@gws.fyi>
Tested-by: BuildkiteCI
