This seems to be unnecessary: It doesn't muffle any SBCL warnings that
affect a current version and does nothing special otherwise.
Change-Id: I36efde761fc95d9df735f29d2eb369c6b61853c9
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3486
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Luckily we don't need to deal with this mess since all our
implementations work similarly wrt streams and “wide” characters.
Change-Id: I3ccc606a59c42791f2591d752673c867d848a332
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3485
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
The following changes are required to make mime4cl build:
* file-position doesn't like to be called with NIL as the position
argument, so we have to make sure to not do that in
stream-file-position. My workaround is a bit clunky, but works.
* Tests discover the sample file via relative path resolution. This
doesn't work when they are imported into the nix store as individual
files. Instead we make use of the fact that DEFVAR is a no-op if the
variable is already defined and inject a file via the nix build that
sets the relevant ones. For the path to sample1.msg, we need to create
a new variable.
Change-Id: I74eeda7bf2c2a4f64cc2b90e72081513ec3285d5
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3270
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Used http://wcp.sdf-eu.org/software/mime4cl-20150207T211851.tbz (sha256
5a914669bba7561efe59a4fd0817204c07ad2add98b03ae206ef185ac04affb3).
Importing seems sensible since there's no upstream repo nor has their
been a release since 2015.
This is just an import commit, so the changes made to make it build are
more discoverable as their own commit.
Change-Id: I2ff28c3c7433abdf7857204bc89eaf9edc0b1cbc
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3378
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Used http://wcp.sdf-eu.org/software/npg-20150517T144652.tbz (sha256
42e88f6067128fbdb3a3d578371c9b0ee2a34f1d36daf80be8a520094132d828).
There's no upstream repository nor a release since 2015, so importing
seems to make a lot of sense.
Since we can't subtree making any depot-related changes in a separate CL
-- this is only the source import.
Change-Id: I64c984ca0a84b9e48c6f496577ffccce1d7bdceb
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3377
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Adding the default.nix is quite straightforward, however we have to make
today's SBCL happy: due to package locking it no longer likes sclf using
an sb-impl internal constant for some reason. This is however a good
opportunity to clean up the stat-*-time code: It converted the times in
an implementation specific way even though time.lisp does provide a
generic way to convert between unix and universal time. Note that the
updated ASDF file is untested, but should be a trivial enough change.
Change-Id: If193bf830ac704cc53e0855d8e9fff2b5a5ef291
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3268
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Used http://wcp.sdf-eu.org/software/sclf-20150207T213551.tbz (sha256
a231aeecdb9e87c72642292a1e083fffb33e69ec1d34e667326c6c35b8bcc794).
There's no upstream repository nor a release since 2015, so importing
seems to make a lot of sense.
Since we can't subtree making any depot-related changes in a separate CL
to make them more discoverable -- this is only the source import.
Change-Id: Ia51a7f4029dba3abd1eee4eeebcf99aca5c5ba4c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3376
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
This one requires a bit of jumping through hoops. Patching the dtd /
catalog lookup is quite straightforward and similar to cxml, but the
CLOSURE-HTML:*html-dtd* variable gives us a bit of trouble: It is
defined quite late in `html-parser.lisp`, but files that need to be
built first already reference it. SBCL has apparently decided to be
particular about this and emits a `WARNING` (!) condition for this
which is also worthy of `failure-p` of `compile-file` being true,
so that `buildLisp` will abort compilation. We workaround this issue
by injecting an extra source file which `defvar`s the desired symbol.
A similar issue exists with `dump-dtd` which references
`CL-USER:*HTML-DTD*` for some reason. Since this is a helper intended
for development (?) and not exported we just throw it away via a
patch.
Change-Id: Ic0f92815a21f3793925c49a70a72f4a86791efe4
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3263
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
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>
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>
Rename my //users directory and all places that refer to glittershark to
grfn, including nix references and documentation.
This may require some extra attention inside of gerrit's database after
it lands to allow me to actually push things.
Change-Id: I4728b7ec2c60024392c1c1fa6e0d4a59b3e266fa
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2933
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: lukegb <lukegb@tvl.fyi>
Reviewed-by: glittershark <grfn@gws.fyi>
sbcl 2.0.9 introduced a new warning:
> minor incompatible change: the compiler signals a warning at
> compile-time when an initform of T, NIL or 0 does not match
> a STANDARD-CLASS slot's declared type.
This broke a few packages, but they all have been fixed upstream in the
meantime and we only need to bump their versions. The culprits are:
* defclass-std which possibly has become unmaintained since the fix
(december 2020).
* cl-prevalence which also needs one symbol from bt now
* lisp-binary which also includes a new file now
Change-Id: I06bb47a129d5ef912a623315c1281aedd1ceac2a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2934
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: glittershark <grfn@gws.fyi>
In preparation for the solution of b/108, we need to consistently use
`depot.third_party` for packages that are only packed in the TVL depot
and `pkgs` for things that come from nixpkgs.
This commit cleans up a huge chunk of these uses in //third_party
Change-Id: Ic382c0cdea7330a84d5f0b7d109c824ddceb94e7
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2912
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Something changed in the upstream we fetch this source from that's
causing the fetch to fail - I can only assume it's a yanked rev, but
I'm not really sure. fetchgit from nixpkgs appears to be a little bit
more robust than builtins.fetchGit, so let's switch to that, and also
upgrade to a rev that we know is present.
Fixes: b/96
Change-Id: I8983c2df11ab4fa20f60915f950c6a7378efd2fd
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2691
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Included fixes for random breakage:
* 3p/awscli: pick from the stable channel; it is broken on unstable
* 3p/googletest: bumped version & removed patches that nixpkgs applies
* 3p/lisp/cffi: bumped library version for SBCL compat
* 3p/nix: fix libsystemd attribute
* 3p/nix: reformatted (clang-format handling of ternaries changed)
* glittershark/home: Use home-manager from nixkpgs
* glittershark/kernel: bumped linux-ck patch hash
* glittershark/kernel: removed "patch patch"
* multi/whitby: Use home-manager from nixpkgs
* tazjin/frog: drop Sourcetrail (it doesn't build currently)
Note that in addition to these changes, some previous CLs updated the
versions of git and cgit which was necessary for this channel bump,
but which could not be done in the same commit due to the nature of
the subtree merges.
Change-Id: If2563e8a68e2750c4b913a976ff7b93b42e8b7f3
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2110
Tested-by: BuildkiteCI
Reviewed-by: multi <depot@in-addr.xyz>
Reviewed-by: glittershark <grfn@gws.fyi>
Add ironclad, a common lisp library for cryptography. This is a huge
library with a lot of moving parts - probably most notable here is that
I've had to turn off compiling with `:ironclad-assembly`, as it was
causing an infinite loop in the compiler due to
https://github.com/sharplispers/ironclad/blob/master/src/opt/sbcl/cpu-features.lisp#L9-L10,
a mutually self-recursive function that looks like:
(defun aes-ni-support-p ()
(aes-ni-support-p))
Without knowing much about how sbcl handles native-compiled assembly, it
seems like this definition should actually be skipped entirely, due to
it being defined as a `defknown` in `fndb.lisp`:
(defknown ironclad::aes-ni-support-p
()
(boolean)
(any)
:overwrite-fndb-silently t)
But something about how we're compiling things was causing that not to
happen, and the infinite recursion caused the compiler to hang. This
should be fixed at some point, but given I only need this library as a
transitive dependency down a level I'm not going to attempt to do so now.
Change-Id: Id768717991404f959b003c7e2f28f1f4d532b94b
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1333
Tested-by: BuildkiteCI
Reviewed-by: kanepyork <rikingcoding@gmail.com>
