cl-docker-images issueshttps://gitlab.common-lisp.net/groups/cl-docker-images/-/issues2024-01-31T16:48:58Zhttps://gitlab.common-lisp.net/cl-docker-images/allegro/-/issues/2Running Allegro docker image fails because Express (free) license has expired2024-01-31T16:48:58ZRobert GoldmanRunning Allegro docker image fails because Express (free) license has expiredSee [this CI job transcript](https://gitlab.common-lisp.net/rgoldman/alexandria/-/jobs/65314)See [this CI job transcript](https://gitlab.common-lisp.net/rgoldman/alexandria/-/jobs/65314)https://gitlab.common-lisp.net/cl-docker-images/official-images/-/issues/1How-to for building images?2024-01-25T21:24:23ZRobert GoldmanHow-to for building images?If I want to build a Docker image using these scripts (e.g., I forked the `allegro` repo to make a docker image for Allegro version 11), how do I do that?
I'm afraid I can't figure out how to do this. It seems like there's a long toolch...If I want to build a Docker image using these scripts (e.g., I forked the `allegro` repo to make a docker image for Allegro version 11), how do I do that?
I'm afraid I can't figure out how to do this. It seems like there's a long toolchain involved here, and I'm not sure what README file tells me how to build the docker images given a forked and updated image repo. Thanks!
Do I need to install `bashbrew`? And if so, what do I do once I have? Also the generate-stackbrew-library.sh script does something, but I'm not sure what or how to use it.
Maybe add a README to the `cl-docker-images` group? Thankshttps://gitlab.common-lisp.net/cl-docker-images/allegro/-/issues/1Suggested improvement for Allegro install-quicklisp2023-03-31T15:05:15ZRobert GoldmanSuggested improvement for Allegro install-quicklispIf we install QL with the existing script, we get an ancient version of ASDF in QL, one that's much older than what Franz distributes with Allegro. Suggestion: add `-e '(require :asdf)'` to the install-quicklisp script.
If you are inter...If we install QL with the existing script, we get an ancient version of ASDF in QL, one that's much older than what Franz distributes with Allegro. Suggestion: add `-e '(require :asdf)'` to the install-quicklisp script.
If you are interested, I could make a MR: running this up the flagpolehttps://gitlab.common-lisp.net/cl-docker-images/clasp/-/issues/1Clasp image failing when used in tests for iterate2022-12-12T15:35:43ZRobert GoldmanClasp image failing when used in tests for iterateThe tests for ITERATE fail on clasp, because when we try to start up the clasp docker image we get an error that "shell not found". Not sure what this means. See [transcript](https://gitlab.common-lisp.net/iterate/iterate/-/pipelines/7...The tests for ITERATE fail on clasp, because when we try to start up the clasp docker image we get an error that "shell not found". Not sure what this means. See [transcript](https://gitlab.common-lisp.net/iterate/iterate/-/pipelines/7592).https://gitlab.common-lisp.net/cl-docker-images/clisp/-/issues/1mistake in instructions2022-10-24T16:02:02ZVibhu Mohindramistake in instructionsThe instructions for "Run a single Common Lisp script" list this as the command:
```
clisp -c -l ./your-daemon-or-script.lisp
```
But it should not have the -c or -l flags, which respectively compile a file without loading it, and emit a...The instructions for "Run a single Common Lisp script" list this as the command:
```
clisp -c -l ./your-daemon-or-script.lisp
```
But it should not have the -c or -l flags, which respectively compile a file without loading it, and emit an assembly language file. So this command does not run the script, it only compiles it.
```
$ ls
test.lisp
$ cat test.lisp
(print "hallo")
$ clisp -q -norc -ansi test.lisp
"hallo"
$ ls
test.lisp
$ clisp -q -norc -ansi -c -l test.lisp
;; Compiling file /home/vibhu/t/test.lisp ...
;; Wrote file /home/vibhu/t/test.fas
;; Wrote file /home/vibhu/t/test.lis
0 errors, 0 warnings
$ ls
test.fas test.lib test.lis test.lisp
```https://gitlab.common-lisp.net/cl-docker-images/abcl/-/issues/1Unable to build ABCL for 1.9.02022-07-27T18:21:23ZRobert GoldmanUnable to build ABCL for 1.9.0I forked the repo for the ABCL images, and tried to execute the steps described on its README (btw, it would be helpful to tell people they need to install `bashbrew`, but that didn't take long to figure out).
I got stuck on the followi...I forked the repo for the ABCL images, and tried to execute the steps described on its README (btw, it would be helpful to tell people they need to install `bashbrew`, but that didn't take long to figure out).
I got stuck on the following -- maybe there's a version coded into the script that no longer exists?
Here's the error message:
```
$ ./generate-stackbrew-library.sh
failed fetching repo "https://github.com/docker-library/official-images/raw/master/library/openjdk:11-jdk-windowsservercore-ltsc2016"
tag not found in manifest for "openjdk": "11-jdk-windowsservercore-ltsc2016"
# this file is generated via https://github.com/cl-docker-images/abcl/blob/cd5916cbc69e9ee384ff7a007b979ef2004331c2/generate-stackbrew-library.sh
Maintainers: Eric Timmons <nasafreak@gmail.com> (@daewok)
GitRepo: https://github.com/cl-docker-images/abcl.git
./generate-stackbrew-library.sh: line 124: parentRepoToArches[$variantParent]: unbound variable
```
Note, I was doing this on an M1 Mac; but I don't know that this is relevant.https://gitlab.common-lisp.net/cl-docker-images/sbcl/-/issues/3package-local-nicknames unsupported: "unrecognized define-package keyword :LO...2022-08-03T13:44:00ZVincent Dardelpackage-local-nicknames unsupported: "unrecognized define-package keyword :LOCAL-NICKNAMES".Hi,
I defined a package with `uiop:define-package` that contains `:local-nicknames`. The build (Gitlab CI) fails:
> caught ERROR:
>; (during macroexpansion of (UIOP/PACKAGE:DEFINE-PACKAGE BOOKSHOPS.MODELS ...))
>; unrecognized defi...Hi,
I defined a package with `uiop:define-package` that contains `:local-nicknames`. The build (Gitlab CI) fails:
> caught ERROR:
>; (during macroexpansion of (UIOP/PACKAGE:DEFINE-PACKAGE BOOKSHOPS.MODELS ...))
>; unrecognized define-package keyword :LOCAL-NICKNAMES
It turns out the ASDF version shipped in this image (SBCL 2.2.4, `image: clfoundation/sbcl`) is 3.3.1, which dates from 2017. My local version at "3.3.4.15" works as expected.
What can we do about this, update ASDF in the image?
Best,
---
package definition:
```lisp
(uiop:define-package bookshops/web
(:use :cl)
(:import-from :easy-routes
:defroute)
(:local-nicknames (#:utils #:bookshops.utils)
(#:a #:alexandria)))
```https://gitlab.common-lisp.net/cl-docker-images/cl-devel/-/issues/2Add Allegro CL?2022-06-20T21:05:13ZAnton VodonosovAdd Allegro CL?A separate allegro image exists, why not add allegro to the cl-devel image?A separate allegro image exists, why not add allegro to the cl-devel image?https://gitlab.common-lisp.net/cl-docker-images/cl-devel/-/issues/1ABCL needs maven for FFI2022-06-16T17:59:17ZAnton VodonosovABCL needs maven for FFIWhen trying to load an FFI dependent lisp library, e.g. cl-glfw-opengl-sgix_shadow_ambient, with ABCL, one gets error like this:
```
; Caught SIMPLE-WARNING:
; Please obtain and install maven-3.0.3 or later locally from <http://maven....When trying to load an FFI dependent lisp library, e.g. cl-glfw-opengl-sgix_shadow_ambient, with ABCL, one gets error like this:
```
; Caught SIMPLE-WARNING:
; Please obtain and install maven-3.0.3 or later locally from <http://maven.apache.org/download.html>, then set ABCL-ASDF:*MVN-LIBS-DIRECTORY* to the directory containing maven-core-3.*.jar et. al.
Unhandled SERIOUS-CONDITION of type COMMON-LISP:ERROR is signaled: Class not found: com.sun.jna.Pointer
```
This is because ABCL uses maven to download the JNA library it uses for FFI.
My current workaround is to have maven downloaded from the said URL to a directory mounted to the docker image as the `cl` user home, and then have M2_HOME and M2 variables exported in my main script (located in the same mounted directory)
```bash
THIS_DIR=$(realpath "`dirname $0`")
export M2_HOME=$THIS_DIR/apache-maven-3.8.6
export M2=$M2_HOME/bin
# ... run lisp
```
(Actually any one of the two variables would be enough I believe, although not tested, because I needed both in my environment for some other reason).
Note, maven by default downloads libraries to ~/.m2/, so having home directory mounted helps here - the download happens only once and then reused by the container on next run.
The ABCL code that looks up for Maven installation is here: https://github.com/armedbear/abcl/blob/master/contrib/abcl-asdf/maven.lisp
But I don't know which of these functions are required for most crucial things like FFI, and which are optional or used only in specific situations.
It may be good to have in the Docker image Maven already installed, and maybe JNA already downloaded.https://gitlab.common-lisp.net/cl-docker-images/cl-docker-images.common-lisp.dev/-/issues/3ecl: error while loading shared libraries: libffi.so.7: cannot open shared ob...2022-06-09T20:50:23ZAnton Vodonosovecl: error while loading shared libraries: libffi.so.7: cannot open shared object file: No such file or directory```
$ ecl
ecl: error while loading shared libraries: libffi.so.7: cannot open shared object file: No such file or directory
``````
$ ecl
ecl: error while loading shared libraries: libffi.so.7: cannot open shared object file: No such file or directory
```https://gitlab.common-lisp.net/cl-docker-images/cl-docker-images.common-lisp.dev/-/issues/2Clarify: what ASDF is used by the lisp implementations?2022-06-09T08:13:13ZAnton VodonosovClarify: what ASDF is used by the lisp implementations?The web page - https://cl-docker-images.common-lisp.dev/images/development.html - says:
> Additionally, the following Lisp utilities are installed:
>
> ASDF v3.3.4: The source code is located in /usr/local/share/common-lisp/source/as...The web page - https://cl-docker-images.common-lisp.dev/images/development.html - says:
> Additionally, the following Lisp utilities are installed:
>
> ASDF v3.3.4: The source code is located in /usr/local/share/common-lisp/source/asdf. The first time you attempt to use ASDF for anything non trivial, it will upgrade itself to this version.
Does it mean the lisp implementations are configured to use this ASDF installation instead of the default ASDF that comes with the lisp impl?
For example, when a user simply runs `sbcl` or `ccl` does he anyhow get this ASDF v3.3.4 installation, or the default ASDF normally coming with the lisp implementations will be upgraded to that version at some point?
I have tested, SBCL and CCL seem to use different ASDF version, but the wording of this paragraph leaves impression the ASDF version may be overridden for all the implementations.https://gitlab.common-lisp.net/cl-docker-images/sbcl/-/issues/2How to use Quicklisp inside the image?2021-09-28T14:25:28ZVincent DardelHow to use Quicklisp inside the image?Hi,
I followed your usage instructions (https://hub.docker.com/r/clfoundation/sbcl).
But my lisp file that runs the application (./your-daemon-or-script.lisp) expects quicklisp (`ql`) to be available.
On my machine, my .sbclrc loads i...Hi,
I followed your usage instructions (https://hub.docker.com/r/clfoundation/sbcl).
But my lisp file that runs the application (./your-daemon-or-script.lisp) expects quicklisp (`ql`) to be available.
On my machine, my .sbclrc loads it if it finds it:
```lisp
;;; The following lines added by ql:add-to-init-file:
#-quicklisp
(let ((quicklisp-init (merge-pathnames "quicklisp/setup.lisp"
(user-homedir-pathname))))
(when (probe-file quicklisp-init)
(load quicklisp-init)))
```
However
- there is no home directory in the docker image
- I found the `/usr/local/bin/install-quicklisp` shell script to install Quicklisp
- so, why not install it by default? or offer an image with Quicklisp available? I think it was the case of daewok/lisp-devel, and it was handy :)
- the script uses `/usr/local/share/common-lisp/source/quicklisp/quicklisp.lisp` and I see no `setup.lisp`
- edit: after digging, I found that quicklisp's setup script is in /root/quicklisp/setup.lisp (could be useful to know) (created after we install Quicklisp)
- the script uses an environment variable ($QUICKLISP_ADD_TO_INIT_FILE) that must be set to "true" to "add-to-init-file". So the command that does it is:
QUICKLISP_ADD_TO_INIT_FILE=true /usr/local/bin/install-quicklisp
- to bad it isn't the default :]
- it is not documented :( How to best use it in a .gitlab-ci.yml too?
SO, it seems that the one Dockerfile command required to enable Quicklisp is:
RUN QUICKLISP_ADD_TO_INIT_FILE=true /usr/local/bin/install-quicklisp
What's the best practice to use Quicklisp with this Docker image anyways?
Would it be possible to declare Quicklisp dependencies inside the Dockerfile, to speed up the start up process (hopefully)?
TLDR; more doc about this is welcome :]
Thanks!