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
Make "Example" the second section again since it got a bit buried under
a lot of detailed documentation you won't necessarily need right away.
Change-Id: I481354d1761c590e5872dfce8c3cf9934e278673
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3421
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
CCL and SBCL create executables by dumping their image. As a
consequence, some part of the respective compiler is embedded in the
resulting executable which is executed and loads the image. For CCL and
SBCL this piece of software seems to unconditionally parse arguments
which can't be prevented since it happens before any lisp is loaded.
Luckily in both cases the parsing stops at `--`, so we can just pass
this via the wrapper — we just need to work around the problem that this
will of course be left in argv and confuse any later code. This can be
rectified by deleting everything prior to the first `--` in the global
argument list on startup in both cases.
In cases we do want to pass arguments to the image loader, we can use
the special NIX_BUILDLISP_LISP_ARGS environment variable which is
understood by the wrapper.
Note: This fix doesn't interfere with ECL since it is not using the
wrapper script at the moment.
Fixes b/136.
Change-Id: I3f95aa61e945e51428021ca18232ff15c923f870
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3357
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: grfn <grfn@gws.fyi>
Doing this in a separate CL to avoid having to track the intermediate
changes no one will ever see in documentation as well which would be
unnecessary effort.
* Multi-implementation support introduced in cl/3292 and refined in
cl/3368 in terms of the user interface.
* Implementation specific srcs and deps introduced in cl/3321
* Implementation passthru attrs and rename from .sbcl -> .repl was done
in cl/3359
* ECL added in cl/3297, CCL in cl/3350
Change-Id: Ia13f2aea4e7e091c00991fcbfc601de364413979
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3380
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Instead of using a string to refer to an internal set defined in
buildLisp, we just expose the relevant sets (as nix.buildLisp.sbcl,
nix.buildLisp.ecl, …) and receive them as the `implementation`
argument directly. This has several advantages:
* It becomes easier to extend buildLisp, even for downstream users:
Since you can just pass your own set, there's nothing stopping you
from adding support for another implementation in a downstream
derivation without having to edit the buildLisp file in any way which
is great if you're using e. g. builtins.fetchGit to import it.
* Users can mess with the implementation set by changing out some parts
of it for customization purposes. Note that currently the sets use a
lot of self-references which aren't even bound by a fix-point, so to
make this work smoothly, we'd need to add some overriding mechanism.
* The buildLisp code becomes quite a bit clearer. Since we're now always
dealing with the implementation set, the confusing distinction between
`impl`, `impl.name` and `implementation` no longer exists. `impl` is
now exclusively an abbreviation of `implementation` (we could make
this more consistent in the future even).
Change-Id: I36d68069dd1315610b2f7159941507b465469b7c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3368
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
This adds support for Clozure's CL implementation to buildLisp. This is
quite trivial in comparison to ECL since SBCL and CCL have very similar
in how they work (so much so that CCL also suffers from b/136).
Also the similarities in the code actually added here are striking, so
I'll try to make an effort to reduce the code duplication in the
future.
To fix builds with CCL the following changes were made:
* //3p/lisp/nibbles: The double inclusion of the types.lisp file was
fixed. CCL doesn't like double definitions and refuses to compile
otherwise.
* //3p/lisp/physical-quantities: Update to a new bug fix release which
contains a compilation fix for CCL.
* //3p/lisp/routes: apply a patch fixing the build which was previously
failing due to a double definition.
* //3p/lisp/usocket: only depend on sb-bsd-sockets for SBCL and ECL, the
latter of which seems to have a SBCL compatible implementation of the
package.
* Conditionally include a few CCL-specific source files and add
`badImplementation` entries for the remaining failures which are
//fun/gemma (to be expected) and //web/panettone which fails with an
incredibly vague message.
Change-Id: I666efdc39a0f16ee1bb6e23225784c709b04e740
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3350
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>
For every implementation we support an extra passthru attribute with the
name of the implementation is created which points to a version of the
derivation built with that implementation. E. g. if we support CCL, ECL
and SBCL, third_party.lisp.alexandria would have:
* third_party.lisp.alexandria.sbcl
* third_party.lisp.alexandria.ecl
* third_party.lisp.alexandria.ccl
To make this possible, the REPL derivation which was called `sbcl`
originally has been renamed to `repl`.
Since some things won't build with all implementations, we introduce a
brokenOn argument which influences the meta.targets list that is
created, but won't prevent the passthru attrs from being created to
ease debugging failures.
Change-Id: Icd6af345143593fac30ded10deabf31172e5d48a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3359
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Both the deps and srcs arguments may now have special “filter sets” in
the lists they receive as arguments. When building, buildLisp checks if
such sets either have a attribute named like the current implementation
or a "default" attribute. If yes, the set is replaced by the respective
attribute's value. If no, the set is removed from the list without
replacement.
This can be used to add elements for (a) specific implementation(s):
{ sbcl = buildLisp.bundled "sb-posix"; }
{ sbcl = ./sbcl/optional-sbcl.lisp; }
or to switch between files for different implementations:
# If a implementation case is missing and no default set present,
# no file will be added. Compilation will likely fail as a result.
{
ecl = ./tf-ecl.lisp;
ccl = ./tf-ccl.lisp;
sbcl = ./tf-sbcl.lisp;
}
or to account for special behavior for a certain implementation:
{
ccl = ./ccl-quirk-impl.lisp
default = ./ansi-impl.lisp;
}
Change-Id: I082c3701d1f5063b92100bf336a83425471c269d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3321
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
By implementing a bundled function for an implementation, we can use a
custom one for a specific implementation. This is useful for
implementations like ECL where a require will be compiled as an
instruction rather than importing all new symbols into a dump, so using
the underlying static or shared object directly would be beneficial.
overrideLisp for bundled libraries now only allows overriding the name
and implementation arguments.
Change-Id: I9036b29157e8daa4d86ff87d603b044373711dbf
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3301
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Concept is roughly:
* receive extra argument `implementation` that refers to the name of an
implementation or rather an attribute in an internal attribute set
telling buildLisp how to do certain build steps.
* We assume an implementation can execute lisp files as scripts and that
we can implement the following main tasks in lisp:
- Building a library (`genCompileLisp`)
- Building an executable (`genDumpLisp`)
- Loading a library dynamically (`genLoadLisp`)
Based on that we can implement:
- Running a test suite (`genTestLisp`)
- A REPL preloaded with a libraries and their dependencies (`lispWith`)
Additional attributes for implementing these parts genericly are
added as needed (`faslExt` and `runScript`).
* `genCompileLisp` no longer prints a shell script which concatenates
the individual FASLs. Instead it does the step previously done by the
shell script itself. In essence `genCompileLisp` now writes a lisp
script which compiles and installs the library to build.
This will allow us extra freedom for different implementations, e. g.
for ECL we'll want to build a object file archive additionally to fasl
files in order to be able to link proper executables.
* `genLoadLisp` and `genTestLisp` are almost generic (the former just
sometimes would need to use different file extensions), but we
integrate them into the implementation “API” to facilitate minor
tweaks we need to do like the `fasc` extension for ECL's native FASL
files.
Change-Id: I1b8ccc0063159638ec7af534e9a6b5384e750193
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3292
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
This fixes all compilation warnings except the one about 'tvl lacking
a parent group, which we can look into later (it doesn't matter that much).
Change-Id: Iaff5e7f5f251f0670afb0a47031ccf197de69818
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3408
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
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
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>
This is because I'm bored of CAS gradually consuming all the RAM on Whitby.
Change-Id: Idcc14c19d99a6d3553739c5765be3faf2bdf9d84
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3233
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Reviewed-by: tazjin <mail@tazj.in>
This is a bit of an under-documented feature, but if the "tag" field for
a gerrit review starts with the string
"autogenerated:<something>~<something-else>", only the last comment per
instance of <something> will be shown by default on the CL page (with
the rest viewable by toggling the "Show all entries" switch). The idea
behind the "<something-else>" tag is to be used for the "type" of
comment within a particular system - gerrit's documentation gives the
example of one tag for "the build is running" and another for "the build
has finished, here's the result".
Change-Id: I9199a6ed97beca1b3a51ec5d6230c6c8358ba2b3
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3374
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Wanted to port my emacs config to depot, but missing a dependency from
the channel. Adjustments:
* Downgrade grfn's Kernel to 5.10: The ck1 patch is not yet available
for 5.13 unfortunately and the 5.12 set has been removed upstream.
Change-Id: Ifaf315427bda2af590549ca0abec02a79f19a3ec
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3375
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: grfn <grfn@gws.fyi>
The dropping of `www.` is intentional, that was unused.
Change-Id: I300f82bb6e5626e2658be8fc5b5e3cf872ab7099
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3384
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Adds a new module for the nixery.dev domain and serves it from whitby.
Note that the DNS records do *not* point to whitby yet, so deploying
this will lead to a failed TLS provisioning unit - but this is
intentional.
Change-Id: I911f67a0aa24f8df3cb52d2cfc49a8b6132cf718
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3383
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
We'll need to do a DNS switchover, likely with a short amount of
downtime due to TLS provisioning.
It would be possible to avoid this by provisioning a cert manually
pre-hoc through the DNS challenge and then configuring whitby to use
that, however I simply don't have time for that right now and the
Google Cloud Project for Nixery is going away in O(days) for $reasons.
Change-Id: I88dface5aaacec5acfa525ae117462f8ad296d92
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3382
Tested-by: BuildkiteCI
Reviewed-by: kn <klemens@posteo.de>
Someone asked for this, so here it is.
Change-Id: I00c52deb8c3f4e8f786cf4763b39d862ad041f6d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3371
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
I'm using gerrit at work now, and would like to use tvl.el to interact
with it via Emacs, but we use a different default branch than "canon".
This makes it configurable, and also marks it as safe so I can configure
it in .dir-locals.el
Change-Id: I66d4c7ce94351f2df863ec49dbc3e1d1d6d1547a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3369
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Telega keeps getting loaded with old sources, the origin of which I
can not figure out, and which are not compatible with my Emacs
anymore. This means that opening Telega essentially breaks the active
Emacs until the telega process is killed.
Until I have time to properly sit down and debug where Nix decides to
get an old version of telega from (building the package directly from
a Nix REPL yields the expected one), I'll disable it to avoid
accidentally breaking my Emacs via muscle-memory.
Change-Id: I937ac3a2b208c08fa0ef0b6e3e201526baa3a522
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3367
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
Seems to fix weird issues related to CCL I encountered.
Change-Id: Id5c34c7c98e22b2bc56d6723af85cac1e031ed72
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3365
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Also allows us to enable the SBCL opt modules. Upstream changes as
sharplispers has the only maintained nibbles fork atm.
Change-Id: I6f0d1b9e4e570169e5f5c584364948e2031063af
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3364
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
This was previously propagated from somewhere else, but is actually
needed here.
Change-Id: I921758320ff5567b451291c69c8532d43a5c898c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3358
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
... mostly to get CI.
Note that this adds the Cargo.lock file because we require pinning,
but it is generally not required for Rust libraries.
Change-Id: I565c7c8e899694accf3efd825ff46225f3c47d1a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3363
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
... mostly to get CI.
Note that this adds the Cargo.lock file because we require pinning,
but it is generally not required for Rust libraries.
Change-Id: Iedbd3758e8df8a7f60fe67b6b06c8e41aba8f345
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3362
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
This release includes fixes for the audience claim. It has also been
pointed out to me that the repository URL on crates.io was pointing at
the old location.
Change-Id: Ie6265c86932a67a8f8c0210271f1d69b6394756b
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3361
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
This is required when people change their email addresses (e.g.
cl/3349) as nothing in Gerrit will update that information from the
OAuth provider.
Change-Id: I1eafdf22efd37898dcd0d06bb9a5d1471ffb5e31
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3356
Tested-by: BuildkiteCI
Reviewed-by: eta <eta@theta.eu.org>
Reviewed-by: sterni <sternenseemann@systemli.org>
Reviewed-by: lukegb <lukegb@tvl.fyi>
