| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Change-Id: Id9d6582de2a95f770c7d734ec5d7baad2293e522
Reviewed-on: https://cl.tvl.fyi/c/depot/+/4518
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Autosubmit: sterni <sternenseemann@systemli.org>
|
|
Change-Id: Idca2ae2829a7ee9e856aa7fcdc716c3055051062
Reviewed-on: https://cl.tvl.fyi/c/depot/+/4363
Reviewed-by: sterni <sternenseemann@systemli.org>
Autosubmit: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
|
|
Change-Id: I2e192dec9eb863a1b2386d40d26eeeeb57e1ed28
Reviewed-on: https://cl.tvl.fyi/c/depot/+/4350
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
Change-Id: I8b6c0c5d1ced89eadaeea3fb619d37e77a439965
Reviewed-on: https://cl.tvl.fyi/c/depot/+/4349
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
Seems to save some allocations and thus recover some performance
compared to the two separate folds we had before.
Change-Id: Ie3d283103e6a9b8aa702db633d9c988fda1b2903
Reviewed-on: https://cl.tvl.fyi/c/depot/+/4348
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
For this we create a directory containing a nix-inject.el file using
writeTextFile where we can string interpolate as much as we please and
merge that into a single emacs.d directory with the config *.el files
tracked in the normal tree using symlinkJoin.
Change-Id: I0e39591587a54527214783d4380456d2763da091
Reviewed-on: https://cl.tvl.fyi/c/depot/+/4324
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Autosubmit: sterni <sternenseemann@systemli.org>
|
|
We can use the reverse swap trick to get a forward fold.
Change-Id: I88185e2ff0b41ec1454f414db2d24b1c8173ac2d
|
|
Change-Id: I39410171402cedc3ee8d9ac972557656ed12de53
|
|
Change-Id: I9cfa8a28854cbee7e8e1b457faf9c572353e803f
|
|
Change-Id: Ibcea43d2e51f14d8b1b021050310f88d44d970d3
|
|
Change-Id: I90e7a47d5418abeff1ae7cc5757b6a8b3b0d1086
|
|
Change-Id: I8c8b535defb42f15eafc816ebe953e51b11ea702
|
|
Change-Id: Id14281f7b18ddaf6875e5dd8398249a10a9474af
|
|
Change-Id: Ie035134a4b3d478ce836aa00016122e0f49a5a28
|
|
Change-Id: Ifbd50274f0b09305991a49e7453ac1f13089e57e
|
|
Change-Id: Iac08e992a4c610a6f152c1dc5e681b17298b8834
|
|
Change-Id: I0781b2aa3624df9a3158296edcbbbf2ee845102b
|
|
* Enforce the U+0000 to U+10FFFF range in `count` and throw an error if
the given codepoint exceeds the range (encoding U+0000 won't work of
course, but this is Nix's fault…).
* Check if the produced bytes are well formed and output an error if
not. This indicates that the codepoint can't be encoded as UTF-8, like
U+D800 which is reserved for UTF-16.
Change-Id: I18336e527484580f28cbfe784d51718ee15c5477
|
|
Previously we would check the first byte only when trying to figure out
the predicate for the second byte. If the first byte was invalid, we'd
then throw with a helpful error message. However this made
wellFormedByte a very weird function.
At the expense of doing the same check twice, we now check the first
byte, when it is first passed, and always return a boolean.
Change-Id: I32ab6051c844711849e5b4a115e2511b53682baa
|
|
This implementation is still a bit rough as it doesn't check if the
produced string is valid UTF-8 which may happen if an invalid Unicode
codepoint is passed.
Change-Id: Ibaa91dafa8937142ef704a175efe967b62e3ee7b
|
|
This is not really used anywhere and kind of useless. A better
decodeSafe would never return null and instead make use of replacement
characters to represent invalid bytes in the input.
Change-Id: Ib4111529bf0e472dbfa720a5d0b939c2d2511de5
|
|
Change-Id: I8de9cd28c822ac5befbcd16e118440cd13cd86e9
|
|
builtins.genericClosure is a quite powerful (and undocumented) Nix
primop: It repeatedly applies a function to values it produces and
collects them into a list. Additionally individual results can be
identified via a key attribute.
Since genericClosure only ever creates a single list value internally,
we can eliminate a huge performance bottleneck when building a list in a
recursive algorithm: list concatenation. Because Nix needs to copy the
entire chunk of memory used internally to represent the list, building
big lists one element at a time grinds Nix to a halt.
After rewriting decode using genericClosure decoding the LaTeX source
of my 20 page term paper now takes 2s instead of 14min.
Change-Id: I33847e4e7dd95d7f4d78ac83eb0d74a9867bfe80
|
|
Change-Id: I6ed03ff8cbc590087cfa58264c0c28a7b1496740
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3825
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
|
|
Change-Id: Iffbe173a48b466c52669efc70f9b5e5d4a6aff9a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3730
Tested-by: BuildkiteCI
Reviewed-by: Alyssa Ross <hi@alyssa.is>
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
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>
|
|
Change-Id: I943343af92665897e2ebc556f3984a2f8ede9a23
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3723
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
Change-Id: I45cc10aaa7bfc7561ef25978c71248659ce6579d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3652
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
|
|
Change-Id: Ib2d7c0c8db8a6a579985b8c84739c72b8e8e395b
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3651
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
|
|
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>
|
|
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>
|
|
Change-Id: I79d30e4e5cbe41fcd0f4a751ed08d12541b453eb
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3487
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
|
|
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
|
|
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>
|
|
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>
|
|
Thanks tazjin!
Change-Id: I3c742e832bbc98fbf4112a7bea367d013a2ef722
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3401
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
|
|
Change-Id: Icbdb52ba5ea51e8594eb46c5f0740e4f7c353be4
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3381
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>
|
|
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>
|
|
This should ease migrating to a distinction between depot.third_party
and pkgs (as in nixpkgs) in the future.
Ref cl/2910, b/108.
Change-Id: I53a854071fddd7c0d0526cc4c5b16998202082c6
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2913
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
|
|
Profpatsch and me are basically the only users of
depot.users.Profpatsch.writers.rustSimple*. To pull in the odd
dependency we usually use buildRustCrate which is rather convenient.
However we've picked up the bad habit of inlining these in a let
somewhere instead of managing them in a more central location although
there has been an (unsuccesful) attempt at this in
//users/Profpatsch/rust-crates.nix.
This CL moves all buildRustCrate based derivations into
third_party.rust-crates and deletes any duplicate derivations we have
accumulated in the tree.
Change-Id: I8f68b95ebd546708e9af07dca36d72dba9ca8c77
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2769
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: Profpatsch <mail@profpatsch.de>
|
|
More or less direct port of https://dotti.me to mdoc(7) with the
following changes:
* Add a RFC3339 column to the EXAMPLES table. RFC3339 is a well
specified subset of ISO8601 whose specification is also more
accessible so this could help someone out.
* Add a SEE ALSO section linking to the web site
* Add an AUTHORS section
Change-Id: I8db00bd402697aa52f6f651f28692617b487f832
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2642
Tested-by: BuildkiteCI
Reviewed-by: edef <edef@edef.eu>
|
|
nint (short for nix interpreter) is a tiny wrapper around nix-instantiate
which allows to run nix scripts, i. e. nix expressions that conform to
a certain calling convention. A nix script runnable using nint must
conform to the following constraints:
* It must evaluate to a function which has a set pattern with an
ellipsis as the single argument.
* It must produce a string as a return value or fail.
When invoked, a the expression receives the following arguments:
* `currentDir`: the current working directory as a nix path
* `argv`: a list of strings containing `argv` including `argv[0]`
* extra arguments which are manually specified which allows for
passing along dependencies or libraries, for example:
nint --arg depot '(import /depot {})' my-prog.nix [ argv[1] … ]
would pass along depot to be used in `my-prog.nix`.
Such nix scripts are purely functional in a sense: The way inputs can be
taken is very limited and causing effects is also only possible in a
very limited sense (using builtins.fetchurl if TARBALL_TTL is 0,
adding files and directories to the nix store, realising derivations).
As an approximation, a program executed using nint can be thought of
as a function with the following signature:
λ :: environment → working directory → argv → stdout
where environment includes:
* the time at the start of the program (`builtins.currentTime`)
* other information about the machine (`builtins.currentSystem` …)
* environment variables (`builtins.getEnv`)
* the file system (`builtins.readDir`, `builtins.readFile`, …) which
is the biggest input impurity as it may change during evaluation
Additionally import from derivation and builtin fetchers are available
which introduce further impurities to be utilized.
Future work:
* Streaming I/O via lazy lists. This would allow usage of
stdin and output before the program terminates. However this would
require using libexpr directly or writing a custom nix interpreter.
A description of how this would work can be found on the website of the
esoteric programming language Lazy K: https://tromp.github.io/cl/lazy-k.html
* An effect system beyond stdin / stdout.
* Better error handling, support setting exit codes etc.
These features would require either using an alternative or custom
interpreter for nix (tvix or hnix) or to link against libexpr directly
to have more control over evaluation.
Change-Id: I61528516eb418740df355852f23425acc4d0656a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2745
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
|
|
We use builtins.split directly as it should be a bit more efficient as
lib.splitStrings. Also its returning of a list for every regex match is
useful to update the state while parsing the tokens:
* The tokens are obtained by splitting the string at every '%'
* Everytime we see a boundary (that is a list in the returned
list of builtins.split), we know that the first two chars of
the next string are a percent encoded character.
One implementation flaw is that it will currently crash if it encounters
mal-formed URLs (since int.fromHex chrashes if it encounters any non
hex digit characters) and accepts some malformed urlencoding like
"foo %A".
Change-Id: I90d08d7a71b16b4f4a4879214abd7aeff46c20c8
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2744
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
