On Sat, Sep 23, 2023 at 10:36 AM Blake McBride <blake@mcbridemail.com> wrote:

I am running a current 64-bit Fedora Linux system.

The version of mkcl I am using is the latest at https://gitlab.common-lisp.net/mkcl/mkcl.git

on branch "master".

Sorry but this is a somewhat oldish backup git repo for MKCL, it is outdated by a couple of commits.

I have to update it manually since the automatic updates got broken a few years ago and I haven't done it often enough lately.

You should use https://github.com/jcbeaudoin/MKCL.git instead.

I did a fresh test and, perhaps, it may be loading. After building a fresh copy, I did the following:

[blake@i9-tower xx]$ mkcl

This is ManKai Common Lisp 1.1.11

Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya

Copyright (C) 1993 Giuseppe Attardi

Copyright (C) 2000 Juan J. Garcia-Ripoll

Copyright (C) 2010-2022 Jean-Claude Beaudoin

ManKai Common Lisp (MKCL) is free software,

and you are welcome to redistribute and/or

modify it under the terms of the GNU LGPL.

See file 'Copyright' in the source code for details.

Type :h for Help.

Top level in: #<thread "Initial" active (15479) 0x7fbbe03a9740 7fbbd8a0f000>.

> (load "quicklisp")

==== quicklisp quickstart 2015-01-28 loaded ====

To continue with installation, evaluate: (quicklisp-quickstart:install)

For installation options, evaluate: (quicklisp-quickstart:help)

#P"/home/blake/tmp/xx/quicklisp.lisp"

> (load #P"/home/blake/quicklisp/setup.lisp")

#P"/home/blake/quicklisp/setup.lisp"

>

So, it actually did load. However, here was the problem. When I did '(load #P"/home/blake/quicklisp/setup.lisp")' it took so long to load that I thought it was hung. (I am on on an I9 with 64GB RAM, running at about 4 Ghz.) It did, however, complete. The second time I tried this it was nearly instantaneous. So I suppose the first time it was compiling everything.

I did exactly what you just said. On very first use QuickLisp compiles itself and that manifests as a fairly long pause, it is a design choice that QuickLisp did on its own...

However, after I got QuickLisp loaded, I tried: (ql:quickload :cl-ppcre) and got the following error:

> (ql:quickload :cl-ppcre)

To load "cl-ppcre":

Load 1 ASDF system:

cl-ppcre

; Loading "cl-ppcre"

.

;;; Error: in file /home/blake/quicklisp/dists/quicklisp/software/cl-ppcre-20230618-git/convert.lisp, end position 14464,

;;; and form: (DEFUN MAYBE-ACCUMULATE (STR) ...)

;;; The function SI::FUNCTION-RETURN-TYPE is undefined.

;;; Compilation failed!

Debugger called in: #<thread "Initial" active (16383) 0x7fdeeaa93740 7fdee30f9000>.

#<a UIOP/LISP-BUILD:COMPILE-FILE-ERROR 140594891262688>:

COMPILE-FILE-ERROR while compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cl-ppcre" "convert">

Available restarts:

Command Restart Name Description

:r1 RETRY Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cl-ppcre" "convert">.

:r2 ACCEPT Continue, treating compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cl-ppcre" "convert"> as having been successful.

:r3 RETRY Retry ASDF operation.

:r4 CLEAR-CONFIGURATION-AND-RETRY Retry ASDF operation after resetting the configuration.

:r5 RETRY Retry ASDF operation.

:r6 CLEAR-CONFIGURATION-AND-RETRY Retry ASDF operation after resetting the configuration.

:r7 ABORT Give up on "cl-ppcre"

:r8 REGISTER-LOCAL-PROJECTS Register local projects and try again.

:r9 RESTART-TOPLEVEL Go back to Top-Level REPL.

:r10 ABORT Abort this computation: (SI:TOP-APPLY SI:SAFE-EVAL (SI:TOP-LEVEL) NIL -7).

:r11 TERMINATE-THREAD Terminate this thread: #<thread "Initial" active (16383) 0x7fdeeaa93740 7fdee30f9000>.

Type :h for Help.

Broken at IHS[14]> LAMBDA. In: #<thread "Initial" active (16383) 0x7fdeeaa93740 7fdee30f9000>.

File: "/home/blake/quicklisp/quicklisp/setup.lisp" (Position #6166)

>>

I just tried this in my working copy of MKCL, see the result:

> (ql:quickload :cl-ppcre)
To load "cl-ppcre":
Load 1 ASDF system:
cl-ppcre
; Loading "cl-ppcre"
[package cl-ppcre]...............................
(:CL-PPCRE)
> (lisp-implementation-version)

"1.1.11.188-f731a69"
>

So, no error reported! Your problem does not seem to reproduce in my context. So much harder to debug...

See the value returned by "(lisp-implementation-version)" just above? What is it in your instance?