depot/third_party/lisp/cl-fad.nix, branch refs/r/7268 monorepo for the virus lounge http://code.tvl.fyi/depot/atom?h=refs%2Fr%2F7268 2022-01-31T16:11:53+00:00 style: format entire depot with nixpkgs-fmt 2022-01-31T16:11:53+00:00 Vincent Ambo mail@tazj.in 2022-01-30T16:06:58+00:00 urn:sha1:aa122cbae78ce97d60c0c98ba14df753d97e40b1 This CL can be used to compare the style of nixpkgs-fmt against other formatters (nixpkgs, alejandra). Change-Id: I87c6abff6bcb546b02ead15ad0405f81e01b6d9e Reviewed-on: https://cl.tvl.fyi/c/depot/+/4397 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org> Reviewed-by: lukegb <lukegb@tvl.fyi> Reviewed-by: wpcarro <wpcarro@gmail.com> Reviewed-by: Profpatsch <mail@profpatsch.de> Reviewed-by: kanepyork <rikingcoding@gmail.com> Reviewed-by: tazjin <tazjin@tvl.su> Reviewed-by: cynthia <cynthia@tvl.fyi> Reviewed-by: edef <edef@edef.eu> Reviewed-by: eta <tvl@eta.st> Reviewed-by: grfn <grfn@gws.fyi> refactor(3p/lisp): Use sources from nixpkgs where possible 2021-12-15T10:34:02+00:00 Vincent Ambo mail@tazj.in 2021-12-14T21:32:27+00:00 urn:sha1:e9bfa84aafc65896e2fffead2f1ef4853bdd59af nixpkgs includes a lispPackages set which is generated from something. In the meantime, we pretty much never update our Lisp deps. This commit ties our sources to nixpkgs.lispPackages where the desired package is included in nixpkgs (which is actually most of them!) Change-Id: I520a006535980271b2fa4e0ed4e34029475dcbef Reviewed-on: https://cl.tvl.fyi/c/depot/+/4331 Tested-by: BuildkiteCI Reviewed-by: grfn <grfn@gws.fyi> feat(nix/buildLisp): add ccl 2021-08-24T22:00:15+00:00 sterni sternenseemann@systemli.org 2021-08-13T20:24:50+00:00 urn:sha1:d7e70b1d7270548272267e9b01dc9867f94f5f74 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> feat(nix/buildLisp): add ecl 2021-08-24T22:00:15+00:00 sterni sternenseemann@systemli.org 2021-08-09T00:47:07+00:00 urn:sha1:02566cdcfb15043070c990ec17c0405313a13874 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> feat(3p/lisp/cl-fad): 2019-07-28 -> 2021-01-10 2021-08-15T13:55:24+00:00 sterni sternenseemann@systemli.org 2021-08-13T23:01:24+00:00 urn:sha1:f6a128ab97725ef782681f5b305508df83785c78 Change-Id: I695debc8895a347df5aa839b0b03331cacf90039 Reviewed-on: https://cl.tvl.fyi/c/depot/+/3355 Tested-by: BuildkiteCI Reviewed-by: tazjin <mail@tazj.in> refactor(third_party): Consistent use of depot.third_party vs. pkgs 2021-04-10T11:48:55+00:00 Vincent Ambo mail@tazj.in 2021-04-10T00:13:18+00:00 urn:sha1:8361b82d0ac59f436f7ecef283077b0f7d689ca1 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> chore: Rename pkgs->depot in all Nix file headers 2020-02-21T13:54:53+00:00 Vincent Ambo tazjin@google.com 2020-02-21T12:47:29+00:00 urn:sha1:4bbbb58cb537014dd8b0b3c3c560c039ac57ad89 refactor(third_party/lisp): Use buildLisp.bundled for built-in libs 2020-01-26T23:59:07+00:00 Vincent Ambo tazjin@google.com 2020-01-26T23:59:07+00:00 urn:sha1:a41b8c70a68b3b6d848d708cd8058866b23847e6 Deprecates derivations for: * sb-bsd-sockets * sb-posix * sb-rotate-byte * uiop feat(third_party/lisp): Add derivations for hunchentoot & deps 2020-01-22T00:23:09+00:00 Vincent Ambo tazjin@google.com 2020-01-22T00:23:09+00:00 urn:sha1:fe3ea06cbc32c9b727549a6505e69234f3072f6f
This XML file does not appear to have any style information associated with it. The document tree is shown below.
<feed xmlns="http://www.w3.org/2005/Atom">
<title>depot/third_party/lisp/cl-fad.nix, branch refs/r/7268</title>
<subtitle>monorepo for the virus lounge</subtitle>
<id>http://code.tvl.fyi/depot/atom?h=refs%2Fr%2F7268</id>
<link rel="self" href="http://code.tvl.fyi/depot/atom?h=refs%2Fr%2F7268"/>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/"/>
<updated>2022-01-31T16:11:53+00:00</updated>
<entry>
<title>style: format entire depot with nixpkgs-fmt</title>
<updated>2022-01-31T16:11:53+00:00</updated>
<author>
<name>Vincent Ambo</name>
<email>mail@tazj.in</email>
</author>
<published>2022-01-30T16:06:58+00:00</published>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/commit/?id=aa122cbae78ce97d60c0c98ba14df753d97e40b1"/>
<id>urn:sha1:aa122cbae78ce97d60c0c98ba14df753d97e40b1</id>
<content type="text"> This CL can be used to compare the style of nixpkgs-fmt against other formatters (nixpkgs, alejandra). Change-Id: I87c6abff6bcb546b02ead15ad0405f81e01b6d9e Reviewed-on: https://cl.tvl.fyi/c/depot/+/4397 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org> Reviewed-by: lukegb <lukegb@tvl.fyi> Reviewed-by: wpcarro <wpcarro@gmail.com> Reviewed-by: Profpatsch <mail@profpatsch.de> Reviewed-by: kanepyork <rikingcoding@gmail.com> Reviewed-by: tazjin <tazjin@tvl.su> Reviewed-by: cynthia <cynthia@tvl.fyi> Reviewed-by: edef <edef@edef.eu> Reviewed-by: eta <tvl@eta.st> Reviewed-by: grfn <grfn@gws.fyi> </content>
</entry>
<entry>
<title>refactor(3p/lisp): Use sources from nixpkgs where possible</title>
<updated>2021-12-15T10:34:02+00:00</updated>
<author>
<name>Vincent Ambo</name>
<email>mail@tazj.in</email>
</author>
<published>2021-12-14T21:32:27+00:00</published>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/commit/?id=e9bfa84aafc65896e2fffead2f1ef4853bdd59af"/>
<id>urn:sha1:e9bfa84aafc65896e2fffead2f1ef4853bdd59af</id>
<content type="text"> nixpkgs includes a lispPackages set which is generated from something. In the meantime, we pretty much never update our Lisp deps. This commit ties our sources to nixpkgs.lispPackages where the desired package is included in nixpkgs (which is actually most of them!) Change-Id: I520a006535980271b2fa4e0ed4e34029475dcbef Reviewed-on: https://cl.tvl.fyi/c/depot/+/4331 Tested-by: BuildkiteCI Reviewed-by: grfn <grfn@gws.fyi> </content>
</entry>
<entry>
<title>feat(nix/buildLisp): add ccl</title>
<updated>2021-08-24T22:00:15+00:00</updated>
<author>
<name>sterni</name>
<email>sternenseemann@systemli.org</email>
</author>
<published>2021-08-13T20:24:50+00:00</published>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/commit/?id=d7e70b1d7270548272267e9b01dc9867f94f5f74"/>
<id>urn:sha1:d7e70b1d7270548272267e9b01dc9867f94f5f74</id>
<content type="text"> 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> </content>
</entry>
<entry>
<title>feat(nix/buildLisp): add ecl</title>
<updated>2021-08-24T22:00:15+00:00</updated>
<author>
<name>sterni</name>
<email>sternenseemann@systemli.org</email>
</author>
<published>2021-08-09T00:47:07+00:00</published>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/commit/?id=02566cdcfb15043070c990ec17c0405313a13874"/>
<id>urn:sha1:02566cdcfb15043070c990ec17c0405313a13874</id>
<content type="text"> 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> </content>
</entry>
<entry>
<title>feat(3p/lisp/cl-fad): 2019-07-28 -> 2021-01-10</title>
<updated>2021-08-15T13:55:24+00:00</updated>
<author>
<name>sterni</name>
<email>sternenseemann@systemli.org</email>
</author>
<published>2021-08-13T23:01:24+00:00</published>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/commit/?id=f6a128ab97725ef782681f5b305508df83785c78"/>
<id>urn:sha1:f6a128ab97725ef782681f5b305508df83785c78</id>
<content type="text"> Change-Id: I695debc8895a347df5aa839b0b03331cacf90039 Reviewed-on: https://cl.tvl.fyi/c/depot/+/3355 Tested-by: BuildkiteCI Reviewed-by: tazjin <mail@tazj.in> </content>
</entry>
<entry>
<title>refactor(third_party): Consistent use of depot.third_party vs. pkgs</title>
<updated>2021-04-10T11:48:55+00:00</updated>
<author>
<name>Vincent Ambo</name>
<email>mail@tazj.in</email>
</author>
<published>2021-04-10T00:13:18+00:00</published>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/commit/?id=8361b82d0ac59f436f7ecef283077b0f7d689ca1"/>
<id>urn:sha1:8361b82d0ac59f436f7ecef283077b0f7d689ca1</id>
<content type="text"> 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> </content>
</entry>
<entry>
<title>chore: Rename pkgs->depot in all Nix file headers</title>
<updated>2020-02-21T13:54:53+00:00</updated>
<author>
<name>Vincent Ambo</name>
<email>tazjin@google.com</email>
</author>
<published>2020-02-21T12:47:29+00:00</published>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/commit/?id=4bbbb58cb537014dd8b0b3c3c560c039ac57ad89"/>
<id>urn:sha1:4bbbb58cb537014dd8b0b3c3c560c039ac57ad89</id>
<content type="text"> </content>
</entry>
<entry>
<title>refactor(third_party/lisp): Use buildLisp.bundled for built-in libs</title>
<updated>2020-01-26T23:59:07+00:00</updated>
<author>
<name>Vincent Ambo</name>
<email>tazjin@google.com</email>
</author>
<published>2020-01-26T23:59:07+00:00</published>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/commit/?id=a41b8c70a68b3b6d848d708cd8058866b23847e6"/>
<id>urn:sha1:a41b8c70a68b3b6d848d708cd8058866b23847e6</id>
<content type="text"> Deprecates derivations for: * sb-bsd-sockets * sb-posix * sb-rotate-byte * uiop </content>
</entry>
<entry>
<title>feat(third_party/lisp): Add derivations for hunchentoot & deps</title>
<updated>2020-01-22T00:23:09+00:00</updated>
<author>
<name>Vincent Ambo</name>
<email>tazjin@google.com</email>
</author>
<published>2020-01-22T00:23:09+00:00</published>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/commit/?id=fe3ea06cbc32c9b727549a6505e69234f3072f6f"/>
<id>urn:sha1:fe3ea06cbc32c9b727549a6505e69234f3072f6f</id>
<content type="text"> </content>
</entry>
</feed>