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 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")?

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.

This works interpreted:

(define-symbol-macro .test-symbol-macro.
  "Test Symbol Macro Value")

(defun test-value ()
  .test-symbol-macro.)

But the compiler gives a warning:

;;; Variable .TEST-SYMBOL-MACRO. was undefined. Compiler assumes it is a global.

And the symbol macro isn't expanded:

> (test-value)


Debugger called in: #<thread "Initial" active (26535) 0x7fc2d05d6740 7fc2cdb8b000>.

#<a UNBOUND-VARIABLE 140474510190656>:
    The variable .TEST-SYMBOL-MACRO. is unbound.

It works with an eval-when:

(eval-when
    (:compile-toplevel
     :load-toplevel
     :execute)
  (define-symbol-macro .test-symbol-macro.
    "Test Symbol Macro Value"))

(defun test-value ()
  .test-symbol-macro.)

I don't know if this is a matter of ANSI compliance, but it seems better—i.e. less surprising—if the compiler treats symbol macros the same way as regular macros. The standard says that for defmacro, "the compiler must store the macro definition at compile time, so that occurrences of the macro later on in the file can be expanded correctly." For define-symbol-macro, the standard doesn't say that, but it would seem to be implied.

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.

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.

> (tree-equal 'a 'a)

Debugger called in: #<thread "Initial" active (4318) 0x7f859043e740 7f858d9f3000>.

#<a SIMPLE-ERROR 140211509202688>:
    Both :TEST and :TEST-NOT are specified.

This bug can cause a crash.

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

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

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-

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

(defun is-foo-p (object)
  (typep object '(eql foo)))

Compile:

> (compile 'is-foo-p)

;;; Style Warning: Variable FOO was undefined. Compiler assumes it is a global.
IS-FOO-P
T
NIL

Then:

> (is-foo-p 'bar)

Debugger called in: #<thread "Initial" active (873) 0x7f322f182740 7f322c737000>.

#<a UNBOUND-VARIABLE 139853058003712>:
    The variable FOO is unbound.

Clearly, foo shouldn't be evaluated, since the entire type specifier is quoted.

The culprit would appear to be compiler::expand-typep in src/cmp/cmpopt.lsp.

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+????

For example:

(deftype buffer32 (&optional (size '*))
  `(simple-array (unsigned-byte 32) (,size)))

Then:

> (make-sequence 'buffer32 1024)


Debugger called in: #<thread "Initial" active (3405) 0x7f49db5ee740 7f49d8ba3000>.

#<a SIMPLE-ERROR 139955071156416>:
    Cannot find the element type in vector type BUFFER32

Technically an issue with CFFI, but it's in the contrib directory.

For cffi:foreign-funcall the default calling convention is :cdecl.

(require :asdf)
(require :cffi)

Then:

> (cffi:foreign-funcall "strlen" :string "foo" :int)

Debugger called in: #<thread "Initial" active (10204) 0x7f2cccf3c740 7f2cca4f1000>.

#<a SIMPLE-ERROR 139829904682848>:
    NIL does no denote a valid calling convention.

For mk_si_call_cfun the default calling convention is nil.

This function, si:call-cfun, is called from cffi-mkcl.lisp.