Note: The code on the named readtables side looks completely allright. I'm posting this issue here because I suspect this might an mkcl bug.

When trying to load https://github.com/melisgl/named-readtables via quicklisp in MKCL (in the SLIME REPL) I get the following:

CL-USER> (asdf:load-system "named-readtables")
;;; Warning: in file /user/home/mel/my/quicklisp/dists/quicklisp/software/named-readtables-20220331-git/src/named-readtables.lisp, end position 14949,
;;;     and form: (DEFINE-API MERGE-READTABLES-INTO (RESULT-READTABLE &REST NAMED-READTABLES) ...)
;;;   Too many arguments passed to SET-MACRO-CHARACTER

and then in a slime backtrace buffer:

COMPILE-FILE-ERROR while compiling
   #<ASDF/INTERFACE::NAMED-READTABLES-SOURCE-FILE "named-readtables" "named-readtables">
   [Condition of type UIOP/LISP-BUILD:COMPILE-FILE-ERROR]

Restarts:
 0: [RETRY] Retry compiling #<ASDF/INTERFACE::NAMED-READTABLES-SOURCE-FILE "named-readtables" "named-readtables">.
 1: [ACCEPT] Continue, treating compiling #<ASDF/INTERFACE::NAMED-READTABLES-SOURCE-FILE "named-readtables" "named-readtables"> as having been successful.
 2: [RETRY] Retry ASDF operation.
 3: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration.
 4: [RETRY] Retry ASDF operation.
 5: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration.
 --more--

Backtrace:
  0: LAMBDA, closure generated from SWANK-DEBUGGER-HOOK
  1: BYTECODE [Evaluation of: (ASDF/OPERATE:LOAD-SYSTEM "named-readtables")]
  2: LAMBDA, closure generated from LAMBDA
  3: TRACK-PACKAGE
  4: LAMBDA, closure generated from LAMBDA
  5: LAMBDA, closure generated from REPL-EVAL

I am a bit lost what the problem is, since also I seem to be able to load the referenced file juts fine:

CL-USER> (load "/user/home/mel/my/quicklisp/dists/quicklisp/software/named-readtables-20220331-git/src/named-readtables.lisp")
#P"/user/home/mel/my/quicklisp/dists/quicklisp/software/named-readtables-20220331-git/src/named-readtables.lisp"
CL-USER> 

The two occurrences of SET-MACRO-CHARACTER in the file also look totally fine and have 4 arguments which should be fine according to the CLHS.

Admittedly this issue is a bit of a fishing expedition. I'm a bit lost how to debug this on the MKCL side. Perhaps you can give me some pointers?

The MKCL version I'm using:

$ mkcl --version
MKCL 1.1.11.187-19222c1

If I start with an empty compilation cache I get some additional warnings, which as precursors might be of interest. I'll document those in an extra reply-

I'm having trouble loading osicat via quicklisp. The error I get is

Unknown CFFI type: :STRUCT.

It seems this is a known issue with older versions of CFFI.

Would it be possible to include a pkg-config mkcl.pc file in the MKCL distribution (installed into /usr/local/lib/pkgconfig or the like), so that adding a build dependency on MKCL would be as easy as the following in any project that uses the Autotools + pkg-config toolchain:

PKG_CHECK_MODULES([MKCL], [mkcl >= 1.1.9])

If this feature would be welcome in principle, I could see about contributing it. Thanks for your consideration.

With a current installation of MKCL, what one has is:

• a cmp.a in sys, along with a functional cmp.asd
• a cmp.asd in sys:contrib, which is broken, though, in that it refers to a cmp.a in the same directory, which does not exist.

Since cmp.asd in sys:contrib is broken, something should be changed here. I'll try to lay out a few paths that I've considered.

A search in asdf for the cmp system in the order

• first sys:contrib
• then sys

will first find a broken asd file and lead to all kinds of errors.

Moreover, a search that only looks in sys:contrib will never find the correct system. Since sys: is not part of the source registry, such a search is typical.

This suggests that

• either cmp.asd in sys:contrib.asd could refer to ../cmp.a if cmp.a should continue to live in sys for some reason.
• or cmp.asd and cmp.a could be moved from sys to sys:contrib
• or cmp.asd from sys:contrib could be removed if sys was added to the source registry or
• something else that I haven't thought of

could be done in order to make handling of the cmp system from within ASDF easier.

(this is connected to https://gitlab.common-lisp.net/asdf/asdf/merge_requests/11)

Hi,

While trying to compile and load my personal project with ql:quickload I got a compilation error for cl-ppcre. I logged a issue with cl-ppcre in github and got an answer that MKCL compiler is broken somewhere and I need to fix it. Can anyone here please help me do that?

Please find the answer from cl-ppcre pasted below.

The compiler is broken at

(funcall
(compile nil
`(lambda (a)
(declare (optimize (safety 0)))
(prog1 (char "abc" (car a))
(setf (car a) 1))))
(list 0))
=>

\U+????

Please consider the following piece of code:

(defmacro f (a b)
  b)

(defun g ()
  (format t "This is what we found: ~a~%" (f 'defined 'not-defined)))

(g)

Running it should print "This is what we found: NOT-DEFINED". Compiling it will typically yield a warning about how a is never used. If I go back and replace my original code with

(defmacro f (a b)
  (declare (ignorable a b)) ;; this is new!
  b)

(defun g ()
  (format t "This is what we found: ~a~%" (f 'defined 'not-defined)))

(g)

then the warning should disappear. And it does (I've check this with CMU CL, ECL, SBCL, and others)... but not on MKCL. On MKCL, I continue to get the same warning. Sure enough, it disappears if I use (declare (ignore a)) instead, leaving me with

(defmacro f (a b)
  (declare (ignorable a b))
  #+mkcl (declare (ignore a)) ;; new now!
  b)

(defun g ()
  (format t "This is what we found: ~a~%" (f 'defined 'not-defined)))

(g)

which is the portable version that doesn't generate a warning. This looks like a bug to me, though

The following will give me all the directories in /home/pipping/test/ (also via symlinks) e.g. on ECL:

(directory (merge-pathnames "/home/pipping/test/*/"))

On other lisps it returns all kinds of things. On MKCL, it signals an error. I'd like to ask if this is intentional.

The snippet

(format nil "~a" #\LATIN_SMALL_LETTER_L_WITH_STROKE)

works as expected(*) with

• acl 10.0
• ccl 1.11
• clisp 2.49
• cmucl 21a
• ecl 16.1.2
• sbcl 1.3.8

It currently does not work (for me) with abcl/lispworks/mkcl, even though mkcl defines :unicode. It would be nice if it did.

(*) with cmucl you need to surround the expression with (ext:string-encode ... :utf-8) to get it to print what one would expect.

The MKCL version is currently only reported as 1.1.10, both when the REPL comes up and e.g. by (lisp-implementation-version), even though the git master is currently somewhere between 1.1.9 and 1.1.10. I'm not aware of a way to extract the git revision from the MKCL executable. This means that

• caches are mixed
• it's not possible to reliably label logs that might show a problem one revision exhibited but another did not.

Would it be possible to include the git revision (potentially in git describe format?) into the version the way that e.g. SBCL does it (1.3.9 + 55 commits leading to revision 25088e3 gives me "1.3.9.55-25088e3")?

Hello,

Observing the support for MKCL in CL+J, and having taking up an interest about applying SWIG for C++ FFI in Common Lisp - specifically with LLVM on FreeBSD - moreover, towards ensuring a broader support for Common Lisp on FreeBSD, I've begun tinkering with developing a port for MKCL to FreeBSD. I've attached a preliminary diff of what I've been able to hack out for the port, so far.

I believe that my patch may need some cleanups -- for instance, I would like to make sure I've not missed any __linux declarations in the source tree, such that could be accompanied with defined(BSD) compatibly. Furthermore, I'm not altogether certain if the patched source tree may be compatible with the project's style guidelines. In all candor, I've not been a lot of comfortable with C or C++ but I understand that there may a manner of a normative language model to each, in any respective edition of the C or C++ languages.

Concerning the following patch, it does not go to much further of a semantic depth than preprocessor directives.

Presently, I'm hoping that there may be any advice available as to how to address the following errors form the compiler.

This is produced with the LLVM toolchain, more specifically the clang C compiler and the LLVM C++ compiler, on FreeBSD 10.3 amd64. I've attached a transcript of the entire build session, along with the patch.

If it may be possible to build MKCL successfully on FreeBSD, I believe that there may be a good time to provide a patch to the cl-asdf port on FreeBSD, such as to ensure that the cl-asdf system on FreeBSD would have support for MKCL, along with some more of Common Lisp implementations that may already be available via FreeBSD ports

Any advice would be welcomed. Cheers

threads.d:1367:23: warning: implicit declaration of function 'MK_GC_get_stack_base' is invalid in C99 [-Wimplicit-function-declaration]
if (MK_GC_SUCCESS != MK_GC_get_stack_base(&sb))
^
threads.d:1371:10: warning: implicit declaration of function 'MK_GC_register_my_thread' is invalid in C99 [-Wimplicit-function-declaration]
switch (MK_GC_register_my_thread(&sb))
^
threads.d:1406:26: warning: implicit declaration of function 'MK_GC_unregister_my_thread' is invalid in C99 [-Wimplicit-function-declaration]
MKCL_GC_NO_INTR(env, MK_GC_unregister_my_thread());
^
../mkcl/external.h:2317:30: note: expanded from macro 'MKCL_GC_NO_INTR'
MKCL_REALLY_NO_INTR(env, expr);
^
../mkcl/external.h:2284:6: note: expanded from macro 'MKCL_REALLY_NO_INTR'
(expr);
^
threads.d:1519:31: warning: implicit declaration of function 'MK_GC_invoke_finalizers' is invalid in C99 [-Wimplicit-function-declaration]
MKCL_GC_NO_INTR(env, count = MK_GC_invoke_finalizers()); /* returns the number of finalizers that were run, if we care... /
^
../mkcl/external.h:2317:30: note: expanded from macro 'MKCL_GC_NO_INTR'
MKCL_REALLY_NO_INTR(env, expr);
^
../mkcl/external.h:2284:6: note: expanded from macro 'MKCL_REALLY_NO_INTR'
(expr);
^
threads.d:1632:3: error: unknown type name 'MK_GC_finalizer_notifier_proc'; did you mean 'GC_finalizer_notifier_proc'?
MK_GC_finalizer_notifier_proc old_notifier;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
GC_finalizer_notifier_proc
/usr/local/include/gc/gc.h:181:29: note: 'GC_finalizer_notifier_proc' declared here
typedef void (GC_CALLBACK * GC_finalizer_notifier_proc)(void);
^
threads.d:1634:39: warning: implicit declaration of function 'MK_GC_get_finalizer_notifier' is invalid in C99 [-Wimplicit-function-declaration]
MKCL_GC_NO_INTR(env, old_notifier = MK_GC_get_finalizer_notifier());
^
../mkcl/external.h:2317:30: note: expanded from macro 'MKCL_GC_NO_INTR'
MKCL_REALLY_NO_INTR(env, expr);
^
../mkcl/external.h:2284:6: note: expanded from macro 'MKCL_REALLY_NO_INTR'
(expr);
^
threads.d:1634:37: warning: incompatible integer to pointer conversion assigning to 'GC_finalizer_notifier_proc' (aka 'void ()(void)') from 'int' [-Wint-conversion]
MKCL_GC_NO_INTR(env, old_notifier = MK_GC_get_finalizer_notifier());
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../mkcl/external.h:2317:30: note: expanded from macro 'MKCL_GC_NO_INTR'
MKCL_REALLY_NO_INTR(env, expr);
^
../mkcl/external.h:2284:6: note: expanded from macro 'MKCL_REALLY_NO_INTR'
(expr);
^
threads.d:1636:24: warning: implicit declaration of function 'MK_GC_set_finalizer_notifier' is invalid in C99 [-Wimplicit-function-declaration]
MKCL_GC_NO_INTR(env, MK_GC_set_finalizer_notifier(/(MK_GC_finalizer_notifier_proc)/ request_finalization));
^
../mkcl/external.h:2317:30: note: expanded from macro 'MKCL_GC_NO_INTR'
MKCL_REALLY_NO_INTR(env, expr);
^
../mkcl/external.h:2284:6: note: expanded from macro 'MKCL_REALLY_NO_INTR'
(expr);
^
7 warnings and 3 errors generated.
gmake[2]: *** [GNUmakefile:81: threads.o] Error 1
gmake[2]: Leaving directory '/usr/local/src/mkcl-impl/mkcl-src/src/c'
gmake[1]: *** [Makefile:312: mkclmin.a] Error 2
gmake[1]: Leaving directory '/usr/local/src/mkcl-impl/mkcl-src/src'
gmake: *** [Makefile:86: all] Error 2

patch_1.diff.txt
build.script.txt

The following is the error message.

make[2]: Leaving directory /home/loong0/mkcl-1.1.4/src/c' cd gc; make make[2]: Entering directory/home/loong0/mkcl-1.1.4/src/gc'
make[3]: Entering directory /home/loong0/mkcl-1.1.4/src/gc' /bin/sh ./libtool --tag=CC --mode=compile gcc -fPIC -DHAVE_CONFIG_H -I./include -I./include -fexceptions -DMK_GC_BUILD -D_GNU_SOURCE -fno-strict-aliasing -g -O2 -fPIC -pthread -fno-strict-aliasing -MT allchblk.lo -MD -MP -MF .deps/allchblk.Tpo -c -o allchblk.lo allchblk.c libtool: compile: gcc -fPIC -DHAVE_CONFIG_H -I./include -I./include -fexceptions -DMK_GC_BUILD -D_GNU_SOURCE -fno-strict-aliasing -g -O2 -fPIC -pthread -fno-strict-aliasing -MT allchblk.lo -MD -MP -MF .deps/allchblk.Tpo -c allchblk.c -o allchblk.o In file included from allchblk.c:17:0: ./include/private/gc_priv.h:797:3: error: unknown type name 'MK_AO_t' ./include/private/gc_priv.h:2031:5: error: unknown type name 'MK_AO_TS_t' make[3]: *** [allchblk.lo] Error 1 make[3]: Leaving directory/home/loong0/mkcl-1.1.4/src/gc'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory /home/loong0/mkcl-1.1.4/src/gc' make[1]: *** [gc/.libs/libgc.a] Error 2 make[1]: Leaving directory/home/loong0/mkcl-1.1.4/src'
make: *** [all] Error 2