Implement a first pass at a "fire" command, which allows throwing rocks,
the max distance and the damage of which is based on the weight of the
item and the strength of the player.
Currently the actual numbers here likely need some tweaking, as the
rocks are easily throwable at good distances but don't really deal any
damage.
Change-Id: Ic6ad0599444af44d8438b834237a1997b67f220f
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3764
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
That machine doesn't exist anymore. Some of them are partially
retained for use on tverskoy instead, but I've mostly nuked it.
Change-Id: Ia358b46353d408798c29c4c90ec06b116b322b5d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3761
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
This will also be used for the TVL blog, with status updates of
projects like Tvix.
Note that while this commit evaluates, there are still some things
specific to my blog in this code which I'll untangle in a future commit.
Change-Id: If59431161b165d7249cbb856073a4cae84a1bfbf
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3732
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
The C code from which this is translated uses sentinel values for
various things, this commit replaces them with standard Rust types
instead (amongst a bunch of other small improvements).
Change-Id: I892811a7afebb5a0f3b825824fc493ab0b399e44
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3735
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Since this code is essentially a fairly plain translation from C, it
is a bit confusing to deal with the original untyped code. This is an
attempt to try and clean some of it up.
Change-Id: Icd21f531932e1a811c0d6dbf2e9acba61ca9c45d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3734
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
I intend to use this for updates on TVL projects, which will end up on
the homepage, which is outside of //users.
Change-Id: I03542d1bcef3d9fc4599294655caab5ed22ba5d9
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3728
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
The default gcc version for pkgsCross.avr.buildPackages is 10.x, which
seems to be able to build the layout derivation just fine.
Change-Id: Ib7790419f38121ea2b1a09c790ef3a04afc0f9f8
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3712
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
nixpkgs-crate-holes can build a markdown report detailing all vulnerable
crates pinned in cargoDeps vendors in nixpkgs according to RustSec's
advisory db. This report is intended to be pasted into a GitHub issue.
The report is produced by a derivation and can be obtained like this:
nix-build -A users.sterni.nixpkgs-crate-holes.full \
--argstr nixpkgsPath /path/to/nixpkgs
Example output: https://gist.github.com/sternenseemann/27509eece93d6eff35cd4b8ce75423b5
Additionally, you can obtain a more verbose report for a single
attribute of nixpkgs, in HTML format since we just reuse the command
line output of cargo-audit and convert it to HTML using ansi2html:
nix-build -A users.sterni.nixpkgs-crate-holes.single \
--argstr nixpkgsPath /path/to/nixpkgs --argstr attr ripgrep
Change-Id: Ic1c029ab67770fc41ba521b2acb798628357f9b2
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3715
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
... the amount of times I've not had this and nix-shell'd it is ridiculous.
Change-Id: I8ac3a7a2915e68d235f8349373b2575e6ebe1cb5
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3710
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
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>
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>
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
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
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>
