Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I94337f7af76ff554370593709088503ee4b21564
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3645
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
The previous impl of this was formatting the pre-save contents of the
buffer, effectively preventing saving any changes (oops).
Change-Id: I17d4b8ba0943964d700f7dca81af4f46b149c0b8
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3644
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
|
|
Change-Id: I525aa3ddcacb583e6d3a3ba1529d718b43379273
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3643
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
|
|
This is really just not worth the performance hit
Change-Id: I6f603aa154c562da2803bd8f73b1135faad243be
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3642
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
|
|
This doesn't work right now, and I'm not currently writing any idris
Change-Id: I7c090ad9f05c5d24f4f80fdd444e8995629aaba4
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3641
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
|
|
Change-Id: I215b010ea4595d1c6b76138cf7f7b1fb7f435085
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3639
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
Change-Id: I4e00168328e1129f43f4e2e4016ad0543607a73f
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3638
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
Change-Id: If50683716939eb93991f00d2911580ea7800d444
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3637
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
Change-Id: I1f151858de0abfe90f7d441641ada5b1deae6df3
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3636
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
|
|
It's worth trying out with a small initial list of feeds that I
normally read anyways.
Change-Id: I196bf522c159e9630624e60dd1b6419ba987bcd9
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3635
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
|
|
These are then loosely referenced by corresponding words in the big
word list.
I think what I'll be aiming for is a bunch of interesting lookup
functions (give me all words I know with this root etc.)
Change-Id: I664976c3c1521334ea58c7ba943f5c18d5513bf9
|
|
Change-Id: Id3325fcb1c29cbd4d3f9f7933f50ce2c2f25731f
|
|
Still not sure what it is, but I have some ideas now.
Change-Id: Iad67f8429516f28516136bd2e4590f9f9686e4af
|
|
What is this? Well, I don't know yet - but I'm going to figure out a
way to make it useful.
Change-Id: I7fbfdf226d85d3edfff479c52308304ef41d6091
|
|
Included fixes:
* grfn/mugwump: removed superfluous Buildkite agent user
* tazjin/camden: Disabled bitlbee (user config is broken)
* grfn/home/vim: vimUtils expects a `pname`
* 3p/nixpkgs: Pick awscli2 from stable channel
Change-Id: I64ed726b3350f75c7a8a0e6552bcf1d8d9ba7d46
|
|
Change-Id: I5a79f4d6ccd8ddae4a6e24c356d4b7498ffb3c49
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3569
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
There's no longer an Egyptian fireball in the sky, so I can go back to
normal.
Change-Id: I6fdcd12f3d3e62c367115f3712cc0fd36eeff78d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3568
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
|
|
Change-Id: I088d2b0526f10d848da56d8192e93b79d6297746
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3539
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
Change-Id: I49c8f5c0c18ac7664f5f120ad23a55c3bc19bd5b
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3545
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
For now mblog only contains the mnote-html executable which takes a mime
message from a maildir and prints the equivalent HTML fragment to
stdout. It is intended to work with the mblaze(7) utilities,
i. e. mnote-html resolves all `object` tags to proper `img` inclusions
with the correct filename, so mshow(1)'s -x version can supply the
needed image files. A note created using Apple's Notes app (tested with
the iOS version) can be converted in a viewable HTML file like this:
$ mnote-html path/to/msg > fragment.html
$ mshow -x path/to/msg
$ cat <(echo "<!DOCTYPE html>") fragment.html > document.html
$ xdg-open document.html
Note that only the limited feature set of Apple Notes when using the
IMAP backend is supported. The iCloud-based one has more (quite neat)
features, but its notes can only accessed via an internal API as far as
I know.
This CLI is a bit impractical due to the big startup overhead of loading
the lisp image. mblog should be become a fully fletched static site
generator in the future, but this is a good starting point and providing
the mnote-html tool is certainly useful.
Change-Id: Iee6d1558e939b932da1e70ca2d2ae75638d855df
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3271
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
This is mostly to yet another silly idea which turns out to be
possible. This may be actually useful should I implement more
sophisticated format specifiers like "%xd" or "%f".
Change-Id: Ia56cd6f5793a09fe5e19c91a8e8f9098f3244d57
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3537
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
hpack is a bit dumb when generating the list of modules for a cabal
file's component if multiple of them live in the same directory.
Specifically it seems to assume that all modules in the source-dirs
of a particular component are also necessary for its compilation.
This is quite bad in the case of xanthous since both library and
executable have source-dirs: src, so all modules will be compiled
twice: Once for the library and then again for the executable
despite it depending on the library (actually 4 times in total
since we need to build a unprofiled and profiled object for each
module…).
To fix this we just move Main.hs into its own directory and change
the executable's source-dirs, so hpack doesn't get confused anymore.
Since all components now have their own source-dirs, unnecessary
redundant compilation should be down to 0. The diff of the cabal
file shows quite nicely how many module recompilation we've gotten
rid of.
Change-Id: I2df4fab9b0299b3a2b5d3005508c79b2d9796039
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3533
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: grfn <grfn@gws.fyi>
|
|
Change-Id: I5268ea93cf9727ad7fc1beedf9ec72a9d9e6eae8
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3526
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
|
|
Since //web/bubblegum depends on nint, we need to move it to a non user
directory to conform with the policy established via cl/3434.
Note that this likely doesn't mean greater stability (which isn't
really implied in depot anyways), since I still would like to use a more
elaborate calling convention to allow for additional useful features.
Change-Id: I616f905d8df13e3363674aab69a797b0d39fdd79
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3506
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
This allows me to add stuff without doing a commit for every feed. I can
always import them in bunches if I want to later.
Change-Id: I080f40b3627940a1f68cf13598c102953f4994b1
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3505
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
Change-Id: I8429f09525e7ca78893b62f6efb8037687ac36a3
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3494
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
https: //www.youtube.com/watch?v=nH4Gr2U50i8
Change-Id: Iaf998cee07325900272f1fef29478f724b19fe34
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3501
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
`config.home.homeDirectory` is never set, meaning that when this builds
in CI it just uses the $HOME of the buildkite agent that's running,
causing it to almost always rebuild on new changes - I'm never going to
have a username on a system other than `grfn`, so this is fine to just
hardcode.
Change-Id: I920a0c546f4c06d0429534d116465e8f732218e7
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3495
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Reviewed-by: tazjin <mail@tazj.in>
|
|
I have some secret stuff here (not security-secret, just secret that I'm
installing it in my system) so this has to be conditionally included
Change-Id: Idb12e5bbab507ad3dc5eb610199fd384789c0e20
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3491
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
|
|
Change-Id: I20eab33ab10a44b6fc230a1fc1c232208c221554
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3489
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
|
|
Change-Id: I30b956cfbeb0b8f8553c8ee41c4979d4ec0c363b
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3488
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
|
|
Change-Id: I79d30e4e5cbe41fcd0f4a751ed08d12541b453eb
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3487
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
|
|
The backported fix is no longer required and we can just apply the
patch in the overlay, this makes everything a little easier.
Change-Id: I654a1bb002eef5c578b8e576e133a159bde3f850
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3483
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
This lets us benefit from the recent OpenSSL security-related
update [1]. Since nixos-unstable is still stuck, we temporarily
use nixos-unstable-small as our unstable channel.
Fixes necessary:
* //users/sterni/nix/char:
Someone has decided to drop writers.writeC upstream [2],
so we reimplement it ad-hoc using runCommandCC
[1]: https://www.openssl.org/news/secadv/20210824.txt
[2]: https://github.com/nixos/nixpkgs/commit/982f46985e37a6488d8e904b46e0cba2060adc71
Change-Id: Id84756e2e370296b7a27e1a3f1744f58f8fe3c47
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3463
Reviewed-by: sterni <sternenseemann@systemli.org>
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
|
|
Unfortunately this doesn't work with Gerrit yet, but it's fine for SSH auth.
Change-Id: Idcfebb117ca39e47ef5595f5bb64ea31dbef3af7
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3442
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
Bug introduced by the previous static asset move.
Change-Id: I827976e468e4ce877a12dfbca6126b3a7445e783
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3440
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
This machine no longer exists
Change-Id: I8e549b8397777a01404bd84c10c195e80f281744
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3431
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Reviewed-by: tazjin <mail@tazj.in>
|
|
I no longer use this, I just use the rebuild-system that all nixos
systems get now.
Change-Id: I2272ff13b21b3194c06b51dbc340c19b8bb336a9
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3430
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
|
|
It's now more like my personal homepage depends on TVL assets, not the
other way around.
Change-Id: Ifb9d61aa8ec2cab549e25de3a3dfbbd08f3d336c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3435
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
Change-Id: I6d5935279069c8af7e7a5f21f9d221c93a533d8e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3428
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
Couldn't sleep, so I made a surprisingly neat way to render HTML
documents in Nix using our favorite feature __findFile:
let
inherit (depot.users.sterni.nix.html) __findFile esc;
in
<html> {} [
(<head> {} [
(<meta> { charset = "utf-8"; } null)
(<title> {} (esc "hello"))
])
(<body> {} [
(<h1> {} (esc "hello world"))
])
]
=> "<html><head><meta charset=\"utf-8\"/><title>hello</title></head><body><h1>hello world</h1></body></html>"
Change-Id: Id36808a56ae3da3b5263c06f29342fc22d105c21
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3410
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
Prevent flycheck-next-error and flycheck-prev-error from being repeated
by evil, since they're movement commands rather than editing commands.
This lets me spam `]e.` if I have to do the same thing to all the errors
in a buffer, for example.
Change-Id: I5993f6d19b71b63e5f4be1f3ce9e0cfd0357cc6e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3425
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
|
|
This was missing a path segment, plus calling it rust-analyzer makes it
clearer what's going on
Change-Id: I8f71fe1b438d72f743472ab10ec939f686ad0da1
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3424
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
|
|
Change-Id: Ic79fec6b19c185a6e094dfc9571ea783a1e07148
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3423
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
|
|
Change-Id: I79bcd37f498ec8a337b65b069d085c672b830ee9
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3247
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
Adds ECL as a second supported implementation, specifically a statically
linked ECL. This is interesting because we can create statically linked
binaries, but has a few drawbacks which doesn't make it generally
useful:
* Loading things is very slow: The statically linked ECL only has byte
compilation available, so when we do load things or use the REPL it is
significantly worse than with e. g. SBCL.
* We can't load shared objects via the FFI since ECL's dffi is not
available when linked statically. This means that as it stands, we
can't build a statically linked //web/panettone for example.
Since ECL is quite slow anyways, I think these drawbacks are worth it
since the biggest reason for using ECL would be to get a statically
linked binary. If we change our minds, it shouldn't be too hard to
provide ecl-static and ecl-dynamic as separate implementations.
ECL is LGPL and some libraries it uses as part of its runtime are as
well. I've outlined in the ecl-static overlay why this should be of no
concern in the context of depot even though we are statically linking.
Currently everything is building except projects that are using cffi to
load shared libaries which have gotten an appropriate
`badImplementations` entry. To get the rest building the following
changes were made:
* Anywhere a dependency on UIOP is expressed as `bundled "uiop"` we now
use `bundled "asdf"` for all implementations except SBCL. From my
testing, SBCL seems to be the only implementation to support using
`(require 'uiop)` to only load the UIOP package. Where both a
dependency on ASDF and UIOP exists, we just delete the UIOP one.
`(require 'asdf)` always causes UIOP to be available.
* Where appropriate only conditionally compile SBCL-specific code and
if any build the corresponding files for ECL.
* //lisp/klatre: Use the standard condition parse-error for all
implementations except SBCL in try-parse-integer.
* //3p/lisp/ironclad: disable SBCL assembly optimization hack for all
other platforms as it may interfere with compilation.
* //3p/lisp/trivial-mimes: prevent call to asdf function by substituting
it out of the source since it always errors out in ECL and we hardcode
the correct path elsewhere anyways.
As it stands ECL still suffers from a very weird problem which happens
when compiling postmodern and moptilities:
https://gitlab.com/embeddable-common-lisp/ecl/-/issues/651
Change-Id: I0285924f92ac154126b4c42145073c3fb33702ed
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3297
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: eta <tvl@eta.st>
|
|
This has been folded into dash itself.
Change-Id: I19e7a9fbc4d6206e3624b7c226de2225153689c6
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3407
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
|
|
Lets trust that the Emacs overlay is using the right packages from the
right sources by default. I'm not overly attached to any specific
versions.
Change-Id: Id53a4587f680965f13b5cd329a10f0384ff97c13
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3406
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
|
|
Change-Id: I96dd768b89273d748c3a865cf8605877716c26be
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3405
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
|
|
The channel has caught up with this fix.
Change-Id: I86287a6808e6936e50e5d43cbafc74b9362e0bd8
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3404
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|