The LSP setup is very basic at the moment, I'll probably want lsp-ui as
well and other bits and pieces.
Change-Id: Ic0360bbfde98e99990aa3ccb68ea045b522e67ce
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5386
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Autosubmit: sterni <sternenseemann@systemli.org>
I've had the notion that builtins.genericClosure can be used to express
any recursive algorithm, but a proof is much better than a notion of
course! In this case we can easily show this by implementing a function
that converts a tail recursive function into an application of
builtins.genericClosure.
This is possible if the function resolves its self reference using a
fixed point which allows us to pass a function that encodes the call to
self in a returned attribute set, leaving the actual call to
genericClosure's operator. Additionally, some tools for collecting meta
data about functions (argCount) and calling arbitrary functions (apply,
unapply) are necessary.
Change-Id: I7d455db66d0a55e8639856ccc207639d371a5eb8
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5292
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Autosubmit: sterni <sternenseemann@systemli.org>
This script is somewhat usable by humans (it even has a help screen!)
and can be reused in //users/sterni/nixpkgs-crate-holes. We are using
bash since that allows us to exit with the actual exit code of
cargo-audit - something that's not possible in execline.
Change-Id: I3331ae8222a20e23b8e30dc920ab48af78f0247c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5228
Tested-by: BuildkiteCI
Reviewed-by: Profpatsch <mail@profpatsch.de>
* //3p/nix: probably not worth investing time into this anymore
* //users/sterni/emacs: The emoji problem disappeared by itself with a
newer emacs version, however a different one remains…
* //web/panettone: If we ever want to change the behavior, we should
just decide the behavior statically instead of using conditions and
restarts, as we only call it in one place, so making different
decisions depending on call sites is not really a use case we have.
Change-Id: Iff9d439ce356db41ce34d690fb7b6a01822022fa
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5223
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
Autosubmit: sterni <sternenseemann@systemli.org>
Buildkite doesn't understand GitHub Flavored Markdown and having a read
only checklist in there is probably not much use.
Change-Id: I41538487087e8c817b1a5e653f077bb0fbe6eb47
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5201
Reviewed-by: sterni <sternenseemann@systemli.org>
Reviewed-by: tazjin <tazjin@tvl.su>
Autosubmit: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
In the spirit of the readTree filter we should also not include files in
user directories from the outside.
Change-Id: I1abe36a721048900d2758b5986063b68b8d1af93
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5200
Reviewed-by: sterni <sternenseemann@systemli.org>
Reviewed-by: tazjin <tazjin@tvl.su>
Autosubmit: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
Accessing the headers of a MIME message feels like something mime4cl
should handle. We implemented this ad hoc in mblog before in order to
not need to worry about doing it in a sensible way. Now we introduce a
decent-ish interface for getting a header from a MIME message,
mime-message-header-values:
* It returns a list because MIME message headers may appear multiple
times.
* It decodes RFC2047 only upon request, as you may want to be stricter
about parsing certain fields.
* It checks header name equality case insensitively.
The code for decoding the RFC2047 string is retained and still uses
babel for doing the actual decoding.
Change-Id: I58bbbe4b46dbded04160b481a28a40d14775673d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5150
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Depending on the stream backing this, read-sequence should be more
efficient.
Change-Id: I5d0461f76f4b132ac6e6c3a2e503f0173d5f4114
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5194
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
This change finally sort of puts the parts together: We take a maildir,
render all its note messages as standalone HTML, extract the attachments
alongside and finally generate a global index page linking all notes.
The new executable and mnote-html are both contained in the same image
and we dispatch the right functionality based on argv[0].
Change-Id: I5a5bdbfaca79199f92e73ea4a2f070fa900d2bc4
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5113
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
This is the only thing we need from that package and it avoids having
to solve the annoying conflict between closure-html and who.
Change-Id: Iacfb8d4948d1987e767ffc456b8e141b468ef6d9
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5111
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Non ASCII Subjects will use RFC2047 to encode their content. Using
mime4cl's parse-RFC2047-text we obtain a list of ASCII strings and byte
vectors tagged with their encoding. Using babel we can then decode the
byte sequence, assuming the encoding is named the same in babel and
RFC2047 (which it is for UTF-8 at least…).
Change-Id: I2840672409452bd194fb1635721e338364d9b484
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5078
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
* Upon creation of an apple-note object we can check if certain fields
we are interested in are present and of the right type etc.
These currently are:
- UUID (for links later)
- Subject (title)
- Time
- Text part with supported MIME type
These are then put into their own shortcut fields in the apple-note
subclass which allows for easier access and forces us to make sure
they are present.
* Split out everything note related into its own package. Using the new
type, we can expose an interface which sort of makes sense.
Change-Id: Ic9d67518354e61a3cc8388bb0e566fce661e90d0
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5072
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>
* 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
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
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>
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>
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]: 982f46985e
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
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>
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>
We make use of the -O man=… option of mandoc(1) which allows to convert
cross references via the .Xr macro into actual hyperlinks in the output.
This can be disabled (by passing "none") or done in two modes:
* all: links all .Xr cross references as if they were in
$out/%N.%S.html. This will lead to broken links of course.
* inManDir: only link to files in $out if the man page is found in
manDir, use the template defined in linkXrFallback if not.
all is the default, since we don't require all man pages to be in
manDir, so it would be potentially confusing if the path attribute was
used in the pages list.
linkXrFallback uses the debian online man viewer by default currently,
since it can be decently hyperlinked and debian has a lot of packages.
Other options would be:
* https://manpages.ubuntu.com/manpages/latest/en/man%S/%N.%S.html
* https://man.archlinux.org/man/%N.%S.en
* https://man.openbsd.org/%N.%S
* https://www.man7.org/linux/man-pages/man%S/%N.%S.html
Change-Id: I1363b9dfdda25cb7383c7310b8115c335444bd3d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2597
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
htmlman is a very simple nix based static site generator which is
intended for rendering HTML representations for man pages plus an index
page listing all available pages. For the sake of simplicity (and unlike
previous iterations of this piece of code) other documentation artifacts
and formats are not supported.
Usually web services like GitHub and depot's web interface are pretty
good at displaying "normal" documentation artifacts like markdown files,
but man pages are usually not rendered — with the additional problem
that it's source is virtually unreadable. htmlman should provide a
simple static site generator which can be plugged into GitHub actions or
the like to automatically generate rendered version of man pages tracked
in version control.
Change-Id: Ib53292964b3ff84c32d70c5fde257a2edb8c2122
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2596
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: Profpatsch <mail@profpatsch.de>
Reviewed-by: sterni <sternenseemann@systemli.org>
users.sterni.nix.utf8 implements UTF-8 decoding in pure nix. We
implement the decoding as a simple state machine which is fed one byte
at a time. Decoding whole strings is possible by subsequently calling
step. This is done in decode which uses builtins.foldl' to get around
recursion restrictions and a neat trick using builtins.deepSeq puck
showed me limiting the size of the thunks in a foldl' (which can also
cause a stack overflow).
This makes decoding arbitrarily large UTF-8 files into codepoints using
nix theoretically possible, but it is not really practical: Decoding a
36KB LaTeX file I had lying around takes ~160s on my laptop.
Change-Id: Iab8c973dac89074ec280b4880a7408e0b3d19bc7
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2590
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
switch would probably otherwise be called match, but has been renamed so
it isn't confused with string.match and the enum matching capabilities
yants has.
It implements the closest to pattern matching nix can come which is
still flexible enough to not be painful: Syntactically it works like
cond, but is given a value. Instead of booleans it checks passed
predicates or equality if simple values are passed. Both types of checks
can be mixed.
Change-Id: I40f000979cfd469316e15fd58d6c3a80312c1cc4
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2589
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Since nix ends the substring at the end of the string anyways we can
just statically use the largest nix integer as the length of the string.
According to my testing this it ever so slightly faster as well.
Change-Id: I64566e91c7b223f03dcebe3bc5710696dc4261bc
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2587
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
After all it only matches strings.
Change-Id: I3d2e5221ef43f692de69028e78ed98b6b11f82d1
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2586
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
What you see here is mostly the fallout of me implementing a correct
urlencode implementation in nix for Profpatsch's blog implementation
(although they'll probably keep it at arm's length).
Where I want to go from here:
* Extend this library towards general purpose nix™, mainly by
implementing missing interfaces which you'd still have to use
<nixpkgs/lib> for right now. Reexposing parts of <nixpkgs/lib>
with better naming is fine for now, at some point I'd contemplate
making this depend on nothing outside of depot, maybe even itself
(should be easy we only use yants for an easily replaceable check).
* Improve error messages possibly by carefully reintroducing yants. I
originally typed essentially everything using yants, but turns out
this can a) be dangerous when stuff you are handling throws because
type checking means evaluating and b) has a incredible performance
cost in some cases.
* Reexpose builtins with better naming and slightly wrapped so they
don't unrecoverably throw in cases where a null or something would
suffice.
Change-Id: I33ab08ca4e62dbc16b86c66c653935686e6b0e79
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2541
Reviewed-by: sterni <sternenseemann@systemli.org>
Reviewed-by: Profpatsch <mail@profpatsch.de>
Tested-by: BuildkiteCI
This way ci should pick up on clhs-lookup since only a single derivation
is exposed with the default.nix and it is less cumbersome to type the
attribute path (users.sterni.clhs.clhs-lookup →
users.sterni.clhs-lookup). The exposed CLHS wasn't used for anything
anyways and I can always expose it again using passthru or extra if it's
ever merged.
Change-Id: I6c5aeba1b58ca650700c6efa0913e4b42685ea6b
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2461
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Probably very similar to M-x sly-hyperspec-lookup: take a list of
common lisp symbols on the command line open the corresponding pages
in a local copy of the hyperspec in $BROWSER. Optionally the paths can
be printed to stdout.
Change-Id: I389e254f14eb0fc8fd8b18a4dbfe7adeeda9ba72
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2397
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
