clisp-list Mailing List for CLISP - an ANSI Common Lisp

thinking this might be related to building on a rather old system,
I tried it on a more recent one, with different arch:
$ uname -a
Linux cmcora1.cmceast.org 5.15.0-319.201.4.2.el9uek.aarch64 #2 SMP Mon Apr 13 02:03:20 PDT \
2026 aarch64 aarch64 aarch64 GNU/Linux

$ ./configure --with-libsigsegv-prefix=/usr/local --disable-maintainer-mode --with-debug --\
with-module=rawsock build-dir2
 ...
To continue building CLISP, the following commands are recommended
  (cf. unix/INSTALL step 4 ff):
    cd build-dir2
    vi config.lisp
    make
# CLISP self-test:
    make check
# Test non-portable features and modules
    make extracheck mod-check
[2026-06-07 14:09:03 don@cmcora1 ~/clisp202607]
$   cd build-dir2
[2026-06-07 14:09:15 don@cmcora1 ~/clisp202607/build-dir2]
$ make
 ...
gcc  -I/home/don/clisp202607/src -I/home/don/clisp202607/build-dir2/gllib -I/home/don/clisp\
202607/src/gllib  -g -O2 -no-integrated-cpp -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-\
type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -Wno-shift-\
negative-value -Wno-address -Wno-cast-function-type -Wno-type-limits -Wno-tautological-comp\
are -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wno-\
unused-but-set-variable -Wno-unused-local-typedefs -fwrapv -fPIC -fno-strict-aliasing -ggdb\
 -O0 -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DNO_ASM -DENABLE_UNICODE -D\
DYNAMIC_FFI -DDYNAMIC_MODULES -I. -c spvw.c
In file included from ../src/spvw.d:23:
../src/lispbibl.d:1261: warning: "alignof" redefined
 1261 |   #define alignof(type)  offsetof(struct { char slot1; type slot2; }, slot2)
      |
In file included from ../src/lispbibl.d:335,
                 from ../src/spvw.d:23:
config.h:3310: note: this is the location of the previous definition
 3310 | #   define alignof _Alignof
      |
In file included from ../src/spvw.d:23:
../src/lispbibl.d:9327:37: error: ISO C requires a named argument before ‘...’
 9327 |   typedef Values (*lisp_function_t)(...);
      |                                     ^~~
../src/spvw.d: In function ‘getSP’:
../src/spvw.d:1185:10: warning: function returns address of local variable [-Wreturn-local-\
addr]
 1185 |   return &dummy;
      |          ^~~~~~
../src/spvw.d: In function ‘near_SP_overflow’:
../src/spvw.d:968:3: warning: ignoring return value of ‘__builtin_alloca’ declared with att\
ribute ‘warn_unused_result’ [-Wunused-result]
  968 |   alloca(1);                    /* Makes this function non-inlinable. */
      |   ^~~~~~~~~~~~~~~~~~~
make: *** [Makefile:1108: spvw.o] Error 1

which is not quite the same as before but does agree on the last
line, Makefile:1108: spvw.o


Don Cohen writes:
 > 
 > git log says Bruno made these changes on May 20.
 > Bruno, are you getting this mail?  You know what's wrong?
 > And how to fix it?
 > 
 > Don Cohen writes:
 >  > 
 >  > My nightly build transcript shows problems below.
 >  > I hope someone knows how to fix it.
 >  > 
 >  >   Wed May 20 04:10:10 PDT 2026
 >  >   ... tail tran-cvs-up
 >  >    src/io.d                        |    3 +-
 >  >    src/lisparit.d                  |    3 +-
 >  >    src/lispbibl.d                  |    8 +-
 >  >    src/m4/signal.m4                |   58 +-
 >  >    src/makemake.in                 |   66 +
 >  >    src/sequence.d                  |    4 +-
 >  >    src/spvw.d                      |    1 -
 >  >    src/spvw_language.d             |    6 +-
 >  >    src/unix.d                      |    9 +-
 >  >    53 files changed, 18249 insertions(+), 15049 deletions(-)
 >  >   Wed May 20 04:10:37 PDT 2026
 >  >   Wed May 20 04:10:41 PDT 2026
 >  >   ... tail cbcstep1.log cbcstep2.log cbcstep3.log cbcstep4.log cbcstep5.log
 >  >   ==> cbcstep1.log <==
 >  >   config.status: creating po/Makefile.in
 >  >   config.status: creating gllib/Makefile
 >  >   config.status: creating makemake
 >  >   config.status: creating config.h
 >  >   config.status: executing depfiles commands
 >  >   config.status: executing libtool commands
 >  >   config.status: executing po-directories commands
 >  >   config.status: creating po/POTFILES
 >  >   config.status: creating po/Makefile
 >  >   ===> /bin/sh ../src/configure --disable-option-checking --disable-maintainer-mode --cache-file=config.cache SUCCEEDED
 >  > 
 >  >   ==> cbcstep2.log <==
 >  >   ../src/lispbibl.d:9327:37: error: ISO C requires a named argument before ‘...’
 >  >      typedef Values (*lisp_function_t)(...);
 >  >                                        ^~~
 >  >   ../src/spvw.d: In function ‘parse_options’:
 >  >   ../src/spvw.d:2729:35: warning: result of ‘2ll << 63’ requires 66 bits to represent, but ‘long long int’ only has 64 bits [-Wshift-overflow=]
 >  >                                : vbitm(oint_addr_len+addr_shift)-1)))
 >  >                                      ^~
 >  >   Makefile:1108: recipe for target 'spvw.o' failed
 >  >   make: *** [spvw.o] Error 1
 >  >   ===> make FAILED
 >  > 
 >  >   ==> cbcstep3.log <==
 >  >   ../src/lispbibl.d:9327:37: error: ISO C requires a named argument before ‘...’
 >  >      typedef Values (*lisp_function_t)(...);
 >  >                                        ^~~
 >  >   ../src/spvw.d: In function ‘parse_options’:
 >  >   ../src/spvw.d:2729:35: warning: result of ‘2ll << 63’ requires 66 bits to represent, but ‘long long int’ only has 64 bits [-Wshift-overflow=]
 >  >                                : vbitm(oint_addr_len+addr_shift)-1)))
 >  >                                      ^~
 >  >   Makefile:1108: recipe for target 'spvw.o' failed
 >  >   make: *** [spvw.o] Error 1
 >  >   ===> make check FAILED
 >  > 
 >  >   ==> cbcstep4.log <==
 >  >   ../src/lispbibl.d:9327:37: error: ISO C requires a named argument before ‘...’
 >  >      typedef Values (*lisp_function_t)(...);
 >  >                                        ^~~
 >  >   ../src/spvw.d: In function ‘parse_options’:
 >  >   ../src/spvw.d:2729:35: warning: result of ‘2ll << 63’ requires 66 bits to represent, but ‘long long int’ only has 64 bits [-Wshift-overflow=]
 >  >                                : vbitm(oint_addr_len+addr_shift)-1)))
 >  >                                      ^~
 >  >   Makefile:1108: recipe for target 'spvw.o' failed
 >  >   make: *** [spvw.o] Error 1
 >  >   ===> make extracheck FAILED
 >  > 
 >  >   ==> cbcstep5.log <==
 >  >   config.h:3310:0: note: this is the location of the previous definition
 >  >    #   define alignof _Alignof
 >  > 
 >  >   In file included from gen-clispc.c:1:0:
 >  >   ../src/lispbibl.d:9327:37: error: ISO C requires a named argument before ‘...’
 >  >      typedef Values (*lisp_function_t)(...);
 >  >                                        ^~~
 >  >   Makefile:2481: recipe for target 'clisp.c' failed
 >  >   make: *** [clisp.c] Error 1
 >  >   ===> make base-mod-check FAILED
 >  > 
 >  > 
 >  > ----------------------------------------------------------------------
 >  > 
 >  > ----------------------------------------------------------------------
 >  > _______________________________________________
 >  > clisp-list mailing list
 >  > cli...@li...
 >  > https://lists.sourceforge.net/lists/listinfo/clisp-list
 > 
 > 
 > _______________________________________________
 > clisp-list mailing list
 > cli...@li...
 > https://lists.sourceforge.net/lists/listinfo/clisp-list

TL;DR - Can you point me to Lisp code that does, or even some table
that has, transliterations to ASCII for some useful set of common
non-ASCII characters, especially those in ISO-8859-1 (Latin-1)?

WHAT I'M REALLY DOING:

I'm extracting descriptive statistics from hundreds of files
containing English text encoded in ISO-8859-1 (Latin-1).  Almost all
of this is ASCII.  For obscure technical reasons this is done by a
process whose *ERROR-OUTPUT* must be ASCII.  I occasionally need to
report errors processing some line, & if the line isn't all ASCII,
describing the line causes the error reporting process to error out.

WHAT I TRIED SO FAR:

I Googled it, of course!  I typed a question into an ordinary
Google search box and got a fascinating answer in the AI Overview.

==================== query in Google search box =====================^
How can I change the output-error-action
for an encoding in Common Lisp?
=============== start of complete Google AI overview ================|
To change the output-error-action for an encoding in Common Lisp,
you need to use the EXT:MAKE-ENCODING function, which is an
implementation-specific extension primarily used in CLISP.  This
allows you to specify how streams handle characters that cannot be
represented by the chosen character set during output operations.

The :output-error-action keyword argument
controls what happens when an output error occurs:

:error - Signals an error if an unencodable character is output (the default).

:ignore - Ignores the character (it is dropped from the output).

:translit - Translates/transliterates the
character to a close equivalent if possible.

Or you can provide a specific replacement character.

Example Usage

Here is how you define a new encoding that ignores unencodable characters or
falls back to transliteration:

--------------------------------
;; Define an encoding that drops unencodable characters
(defvar *my-encoding*
  (ext:make-encoding :charset 'charset:iso-8859-1
                     :line-terminator :unix
                     :output-error-action :ignore))

;; Define an encoding that transliterates characters if possible
(defvar *my-translit-encoding*
  (ext:make-encoding :charset 'charset:iso-8859-1
                     :line-terminator :unix
                     :output-error-action :translit))
--------------------------------

Applying the Encoding

To use this new encoding, you pass the resulting encoding object
as the :external-format argument when opening a file or stream:

--------------------------------

Applying the Encoding

To use this new encoding, you pass the resulting encoding object
as the :external-format argument when opening a file or stream:

--------------------------------
(with-open-file (stream "output.txt"
                        :direction :output
                        :if-exists :supersede
                        :external-format *my-encoding*)
  (write-string "Hello, world!" stream))
--------------------------------
Use code with caution.

Modifying Global System Settings

If you want to change the encoding settings for the standard global I/O
streams in CLISP, you can bind or modify the corresponding variables using
EXT:LETF or EXT:LETF* (as these are typically system symbol-macros):

(ext:letf ((*pathname-encoding* *my-encoding*))
  (print "Your output goes here"))
--------------------------------
Use code with caution.

For more exact details on supported charsets and their
behaviors, consult the official CLISP Encodings Documentation.
================ end of complete Google AI overview =================$

"Fascinating is a word I use for the unexpected."  -- Spock, STTOS 1x17

Why this was fascinating:
- I didn't mention CLISP in my prompt.
  - How did Google AI know I was using CLISP?  Spooky.
- The answer told me *everything* I needed
  in order to code exactly what I wanted.
- The answer told me about :TRANSLIT, which I hadn't
  known about because it wasn't in the impnotes.  Hmm,
  I thought, maybe I'll submit a documentation patch.
- When I happily coded what I needed, it didn't work,
  because CLISP didn't know about :TRANSLIT either.

OK, I thought, this is Debian Bookworm (oldstable) so
it's CLISP v2.49.93+, and I guess Debian Trixie (stable)
must have it.  ...Nope, Trixie has the same version.

Sigh.  How about Fedora?  That has v2.49.95+,
but that still doesn't know about :TRANSLIT.

Heavier sigh.  I need to install and build HEAD?!

But then I found this:
======== from <https://sourceforge.net/p/clisp/feature-requests/51/> =========^
#51 add :output-error-action :translit to make-encoding
   Milestone: None
   Status: open
   Owner: Bruno Haible
   Labels: None
   Priority: 5
   Updated: 2017-04-14
   Created: 2017-04-14
   Creator: Sam Steingold
   Private: No

It would be nice if make-encoding accepted :output-error-action
:translit, using the //TRANSLIT suffix on platforms
which support it (at least GNU libc & GNU libiconv).

See
  - http://clisp.org/impnotes/encoding.html
  - https://sourceforge.net/p/clisp/mailman/message/35787517/
  - https://www.gnu.org/software/libiconv/
====== from <https://sourceforge.net/p/clisp/mailman/message/35787517/> ======|
Re: make-encoding error-action translit?
From: Bruno H. <br...@cl...> - 2017-04-13 23:35:51

Hi Sam,

> Why doesn't make-encoding support
> :input-error-action/:output-error-action value :translit?

You are right, make-encoding :output-error-action :translit
would make a lot of sense when implemented through the
//TRANSLIT suffix (available in GNU libc and GNU libiconv).

make-encoding :input-error-action :translit would be nonsense.

Why clisp doesn't support it?  Purely for historical reasons: Because
clisp's make-encoding function was designed before GNU libiconv and
before I realized how useful the //TRANSLIT suffix in glibc is.

Bruno
==============================================================================$
And that was 9 years ago, & it's still "Status: Open".

So I have questions.

If it is the case that CLISP does not now support and has not
ever supported :TRANSLIT, whence came Google AI's astonishingly
lucid confabulation (a better term than "hallucination")?

If there *is* some Lisp (especially a CLISP) out there that supports
:TRANSLIT, where is it, where's it documented, how can I get it, etc?
And is its documentation a plausible source of Google AI's answer?

Back in this universe:

Wouldn't it be easier for me to just wrap my error
output functions with something handling encoding
errors, so I can do transliterations by hand?

Here's my error output code:
=====================================================================^
(defmacro show (&rest forms)
  `(handler-case
       (progn ,@(loop for form in forms
                      collect `(format *error-output*
                                       "~&~S: ~S~%"
                                       ',form
                                       ,form)))
     (error (e)
       (format *error-output* "~&E: ~S" e))))

(defvar *debug-level* 0
  "How much debugging information should be output")

(defmacro dbg (&rest forms)
  (let ((cutoff (if (realp (car forms))
                  (pop forms)
                  1)))
    `(when (>= *debug-level* ,cutoff)
       ,(if (stringp (car forms))
          `(handler-case
               (format *error-output* ,@forms)
             (error (e)
               (format *error-output* "~&E: ~S" e)))
          `(show ,@forms)))))
=====================================================================$

That allows, for example,
  (show x y z)
to produce 3 lines of output,
  X: [value of X]
etc; or something like
  (dbg 2 "~&Checkpoint 8")
to output "Checkpoint 8" only if -DD was on the command line, while
  (dbg "~&Checkpoint 8")
outputs "Checkpoint 8" only if -D was on the command line.

And they can be combined:
  (dbg 3 x y z)
does (show x y z) only if -DDD was on the command line.

So, for example, running
  (when t
    (setf x (code-char 222))
    (show x)
    (handler-case
        (princ x)
      (error (e)
        (format *error-output* "~&E: ~S" e)
        (when nil
          (format *error-output* "~&E: ~A" e))))
    (bye 66))
gives output
  --------------------------------
  X: #\LATIN_CAPITAL_LETTER_THORN
  E: #<SIMPLE-CHARSET-TYPE-ERROR #x00001000003276D1>
  --------------------------------
which is correct.

But changing the "when nil" above to "when t" gives
  --------------------------------
  X: #\LATIN_CAPITAL_LETTER_THORN
  E: #<SIMPLE-CHARSET-TYPE-ERROR #x00001000003276D1>
  E:
  PRINC: Character #\u00DE cannot be represented in the character set CHARSET:ASCII
  --------------------------------
because the final FORMAT tried to write a
non-ASCII character to an ASCII stream.

I'm planning to hook (format "~A") of ISO-8859-1 characters so
that when a charset error occurs, I can go through the string
character-by-character, transliterating to some appropriate
ASCII string, such as "u:" for "u" with an umlaut.  Because
the text is mostly ASCII, that will only rarely happen,
so the impact on efficiency-of-output will be minimal.

Can anybody offer code that already does that transliteration,
or even just a pointer to a convenient table of transliterations
to ASCII of the characters in the high half of ISO-8859-1?

git log says Bruno made these changes on May 20.
Bruno, are you getting this mail?  You know what's wrong?
And how to fix it?

Don Cohen writes:
 > 
 > My nightly build transcript shows problems below.
 > I hope someone knows how to fix it.
 > 
 >   Wed May 20 04:10:10 PDT 2026
 >   ... tail tran-cvs-up
 >    src/io.d                        |    3 +-
 >    src/lisparit.d                  |    3 +-
 >    src/lispbibl.d                  |    8 +-
 >    src/m4/signal.m4                |   58 +-
 >    src/makemake.in                 |   66 +
 >    src/sequence.d                  |    4 +-
 >    src/spvw.d                      |    1 -
 >    src/spvw_language.d             |    6 +-
 >    src/unix.d                      |    9 +-
 >    53 files changed, 18249 insertions(+), 15049 deletions(-)
 >   Wed May 20 04:10:37 PDT 2026
 >   Wed May 20 04:10:41 PDT 2026
 >   ... tail cbcstep1.log cbcstep2.log cbcstep3.log cbcstep4.log cbcstep5.log
 >   ==> cbcstep1.log <==
 >   config.status: creating po/Makefile.in
 >   config.status: creating gllib/Makefile
 >   config.status: creating makemake
 >   config.status: creating config.h
 >   config.status: executing depfiles commands
 >   config.status: executing libtool commands
 >   config.status: executing po-directories commands
 >   config.status: creating po/POTFILES
 >   config.status: creating po/Makefile
 >   ===> /bin/sh ../src/configure --disable-option-checking --disable-maintainer-mode --cache-file=config.cache SUCCEEDED
 > 
 >   ==> cbcstep2.log <==
 >   ../src/lispbibl.d:9327:37: error: ISO C requires a named argument before ‘...’
 >      typedef Values (*lisp_function_t)(...);
 >                                        ^~~
 >   ../src/spvw.d: In function ‘parse_options’:
 >   ../src/spvw.d:2729:35: warning: result of ‘2ll << 63’ requires 66 bits to represent, but ‘long long int’ only has 64 bits [-Wshift-overflow=]
 >                                : vbitm(oint_addr_len+addr_shift)-1)))
 >                                      ^~
 >   Makefile:1108: recipe for target 'spvw.o' failed
 >   make: *** [spvw.o] Error 1
 >   ===> make FAILED
 > 
 >   ==> cbcstep3.log <==
 >   ../src/lispbibl.d:9327:37: error: ISO C requires a named argument before ‘...’
 >      typedef Values (*lisp_function_t)(...);
 >                                        ^~~
 >   ../src/spvw.d: In function ‘parse_options’:
 >   ../src/spvw.d:2729:35: warning: result of ‘2ll << 63’ requires 66 bits to represent, but ‘long long int’ only has 64 bits [-Wshift-overflow=]
 >                                : vbitm(oint_addr_len+addr_shift)-1)))
 >                                      ^~
 >   Makefile:1108: recipe for target 'spvw.o' failed
 >   make: *** [spvw.o] Error 1
 >   ===> make check FAILED
 > 
 >   ==> cbcstep4.log <==
 >   ../src/lispbibl.d:9327:37: error: ISO C requires a named argument before ‘...’
 >      typedef Values (*lisp_function_t)(...);
 >                                        ^~~
 >   ../src/spvw.d: In function ‘parse_options’:
 >   ../src/spvw.d:2729:35: warning: result of ‘2ll << 63’ requires 66 bits to represent, but ‘long long int’ only has 64 bits [-Wshift-overflow=]
 >                                : vbitm(oint_addr_len+addr_shift)-1)))
 >                                      ^~
 >   Makefile:1108: recipe for target 'spvw.o' failed
 >   make: *** [spvw.o] Error 1
 >   ===> make extracheck FAILED
 > 
 >   ==> cbcstep5.log <==
 >   config.h:3310:0: note: this is the location of the previous definition
 >    #   define alignof _Alignof
 > 
 >   In file included from gen-clispc.c:1:0:
 >   ../src/lispbibl.d:9327:37: error: ISO C requires a named argument before ‘...’
 >      typedef Values (*lisp_function_t)(...);
 >                                        ^~~
 >   Makefile:2481: recipe for target 'clisp.c' failed
 >   make: *** [clisp.c] Error 1
 >   ===> make base-mod-check FAILED
 > 
 > 
 > ----------------------------------------------------------------------
 > 
 > ----------------------------------------------------------------------
 > _______________________________________________
 > clisp-list mailing list
 > cli...@li...
 > https://lists.sourceforge.net/lists/listinfo/clisp-list

C Habs writes:
 > https://sourceforge.net/p/clisp/mailman/message/59222570/
 > 
 > not a solution, however that spvw related code seems quite problematic -
 > the above was reported albeit relating to 32bit and threads.

It seems clear that the problem has something to do with
the 53 files changed since the previous successfull build
(~24 hrs earlier).  Such changes are pretty rare for clisp.
I hope whoever made them will know what to do about it.

https://sourceforge.net/p/clisp/mailman/message/59222570/

not a solution, however that spvw related code seems quite problematic -
the above was reported albeit relating to 32bit and threads.

regards

On Wed, 20 May 2026 at 17:39, Don Cohen <
don...@is...> wrote:

>
> My nightly build transcript shows problems below.
> I hope someone knows how to fix it.
>
>   Wed May 20 04:10:10 PDT 2026
>   ... tail tran-cvs-up
>    src/io.d                        |    3 +-
>    src/lisparit.d                  |    3 +-
>    src/lispbibl.d                  |    8 +-
>    src/m4/signal.m4                |   58 +-
>    src/makemake.in                 |   66 +
>    src/sequence.d                  |    4 +-
>    src/spvw.d                      |    1 -
>    src/spvw_language.d             |    6 +-
>    src/unix.d                      |    9 +-
>    53 files changed, 18249 insertions(+), 15049 deletions(-)
>   Wed May 20 04:10:37 PDT 2026
>   Wed May 20 04:10:41 PDT 2026
>   ... tail cbcstep1.log cbcstep2.log cbcstep3.log cbcstep4.log cbcstep5.log
>   ==> cbcstep1.log <==
>   config.status: creating po/Makefile.in
>   config.status: creating gllib/Makefile
>   config.status: creating makemake
>   config.status: creating config.h
>   config.status: executing depfiles commands
>   config.status: executing libtool commands
>   config.status: executing po-directories commands
>   config.status: creating po/POTFILES
>   config.status: creating po/Makefile
>   ===> /bin/sh ../src/configure --disable-option-checking
> --disable-maintainer-mode --cache-file=config.cache SUCCEEDED
>
>   ==> cbcstep2.log <==
>   ../src/lispbibl.d:9327:37: error: ISO C requires a named argument before
> ‘...’
>      typedef Values (*lisp_function_t)(...);
>                                        ^~~
>   ../src/spvw.d: In function ‘parse_options’:
>   ../src/spvw.d:2729:35: warning: result of ‘2ll << 63’ requires 66 bits
> to represent, but ‘long long int’ only has 64 bits [-Wshift-overflow=]
>                                : vbitm(oint_addr_len+addr_shift)-1)))
>                                      ^~
>   Makefile:1108: recipe for target 'spvw.o' failed
>   make: *** [spvw.o] Error 1
>   ===> make FAILED
>
>   ==> cbcstep3.log <==
>   ../src/lispbibl.d:9327:37: error: ISO C requires a named argument before
> ‘...’
>      typedef Values (*lisp_function_t)(...);
>                                        ^~~
>   ../src/spvw.d: In function ‘parse_options’:
>   ../src/spvw.d:2729:35: warning: result of ‘2ll << 63’ requires 66 bits
> to represent, but ‘long long int’ only has 64 bits [-Wshift-overflow=]
>                                : vbitm(oint_addr_len+addr_shift)-1)))
>                                      ^~
>   Makefile:1108: recipe for target 'spvw.o' failed
>   make: *** [spvw.o] Error 1
>   ===> make check FAILED
>
>   ==> cbcstep4.log <==
>   ../src/lispbibl.d:9327:37: error: ISO C requires a named argument before
> ‘...’
>      typedef Values (*lisp_function_t)(...);
>                                        ^~~
>   ../src/spvw.d: In function ‘parse_options’:
>   ../src/spvw.d:2729:35: warning: result of ‘2ll << 63’ requires 66 bits
> to represent, but ‘long long int’ only has 64 bits [-Wshift-overflow=]
>                                : vbitm(oint_addr_len+addr_shift)-1)))
>                                      ^~
>   Makefile:1108: recipe for target 'spvw.o' failed
>   make: *** [spvw.o] Error 1
>   ===> make extracheck FAILED
>
>   ==> cbcstep5.log <==
>   config.h:3310:0: note: this is the location of the previous definition
>    #   define alignof _Alignof
>
>   In file included from gen-clispc.c:1:0:
>   ../src/lispbibl.d:9327:37: error: ISO C requires a named argument before
> ‘...’
>      typedef Values (*lisp_function_t)(...);
>                                        ^~~
>   Makefile:2481: recipe for target 'clisp.c' failed
>   make: *** [clisp.c] Error 1
>   ===> make base-mod-check FAILED
>
> _______________________________________________
> clisp-list mailing list
> cli...@li...
> https://lists.sourceforge.net/lists/listinfo/clisp-list
>

My nightly build transcript shows problems below.
I hope someone knows how to fix it.

  Wed May 20 04:10:10 PDT 2026
  ... tail tran-cvs-up
   src/io.d                        |    3 +-
   src/lisparit.d                  |    3 +-
   src/lispbibl.d                  |    8 +-
   src/m4/signal.m4                |   58 +-
   src/makemake.in                 |   66 +
   src/sequence.d                  |    4 +-
   src/spvw.d                      |    1 -
   src/spvw_language.d             |    6 +-
   src/unix.d                      |    9 +-
   53 files changed, 18249 insertions(+), 15049 deletions(-)
  Wed May 20 04:10:37 PDT 2026
  Wed May 20 04:10:41 PDT 2026
  ... tail cbcstep1.log cbcstep2.log cbcstep3.log cbcstep4.log cbcstep5.log
  ==> cbcstep1.log <==
  config.status: creating po/Makefile.in
  config.status: creating gllib/Makefile
  config.status: creating makemake
  config.status: creating config.h
  config.status: executing depfiles commands
  config.status: executing libtool commands
  config.status: executing po-directories commands
  config.status: creating po/POTFILES
  config.status: creating po/Makefile
  ===> /bin/sh ../src/configure --disable-option-checking --disable-maintainer-mode --cache-file=config.cache SUCCEEDED

  ==> cbcstep2.log <==
  ../src/lispbibl.d:9327:37: error: ISO C requires a named argument before ‘...’
     typedef Values (*lisp_function_t)(...);
                                       ^~~
  ../src/spvw.d: In function ‘parse_options’:
  ../src/spvw.d:2729:35: warning: result of ‘2ll << 63’ requires 66 bits to represent, but ‘long long int’ only has 64 bits [-Wshift-overflow=]
                               : vbitm(oint_addr_len+addr_shift)-1)))
                                     ^~
  Makefile:1108: recipe for target 'spvw.o' failed
  make: *** [spvw.o] Error 1
  ===> make FAILED

  ==> cbcstep3.log <==
  ../src/lispbibl.d:9327:37: error: ISO C requires a named argument before ‘...’
     typedef Values (*lisp_function_t)(...);
                                       ^~~
  ../src/spvw.d: In function ‘parse_options’:
  ../src/spvw.d:2729:35: warning: result of ‘2ll << 63’ requires 66 bits to represent, but ‘long long int’ only has 64 bits [-Wshift-overflow=]
                               : vbitm(oint_addr_len+addr_shift)-1)))
                                     ^~
  Makefile:1108: recipe for target 'spvw.o' failed
  make: *** [spvw.o] Error 1
  ===> make check FAILED

  ==> cbcstep4.log <==
  ../src/lispbibl.d:9327:37: error: ISO C requires a named argument before ‘...’
     typedef Values (*lisp_function_t)(...);
                                       ^~~
  ../src/spvw.d: In function ‘parse_options’:
  ../src/spvw.d:2729:35: warning: result of ‘2ll << 63’ requires 66 bits to represent, but ‘long long int’ only has 64 bits [-Wshift-overflow=]
                               : vbitm(oint_addr_len+addr_shift)-1)))
                                     ^~
  Makefile:1108: recipe for target 'spvw.o' failed
  make: *** [spvw.o] Error 1
  ===> make extracheck FAILED

  ==> cbcstep5.log <==
  config.h:3310:0: note: this is the location of the previous definition
   #   define alignof _Alignof

  In file included from gen-clispc.c:1:0:
  ../src/lispbibl.d:9327:37: error: ISO C requires a named argument before ‘...’
     typedef Values (*lisp_function_t)(...);
                                       ^~~
  Makefile:2481: recipe for target 'clisp.c' failed
  make: *** [clisp.c] Error 1
  ===> make base-mod-check FAILED

Hello all,

Is there some recent improvements to CLISP?

Where is the latest CLISP source code (compilable on GNU/Linux/Debian/Trixie)

maybe some just-in-time compilation with libgccjit (from GCC) or libjit.com?

Regards.


NB: I am French, did contribute to GCC (https://arxiv.org/abs/1109.0779 ...) and am currently working
(in C++, GPL license) on an open source inference engine.
-- 

Basile STARYNKEVITCH                    basile AT starynkevitch DOT net
8 rue de la Faïencerie                       http://starynkevitch.net/Basile/  
92340 Bourg-la-Reine                         https://github.com/bstarynk
France                                https://github.com/RefPerSys/RefPerSys
                  https://orcid.org/0000-0003-0908-5250

This probably only happens in #+unix and I so far only can
reproduce it when running clisp from an emacs shell buffer:

  Type :h and hit Enter for context help.                                                     

  [1]> 1
  2
  3
I use emacs to create three lines: I type 1, c-o, c-f, 2, c-o, c-f, 3
then enter to send it all

  1
  [2]> 2
  [3]> 3
as expected I get three top level events.

  [4]> (with-keyboard (read-char *keyboard-input*))
  y
  #S(SYSTEM::INPUT-CHARACTER :CHAR #\y :BITS 0 :FONT 0 :KEY NIL)

now try that again
  [5]> 1
  2
  3
  1
  [6]> 

and now the top level only sees the first line.

Outside of emacs I don't even know how to send three lines at once.

I see in src/keyboard.lsp that under #+unix with-keyboard sets *keyboard-input*,
but setting it back to nil does not make the multiple lines get read again.

So what's going on here?

On 2025-08-16 05:37, C Habs wrote:
> Hello clisp-list
> 
> Trying to compile latest clisp  ( that checked out from the master branch
> on gitlab).
> The computer (laptop) is a [old] linux 32bit  celeron M 440  (slackware).
> 
> All dependencies present (i think).
> 
> The problem seems to be when using the flag, --with-threads=POSIX_THREADS
> as without it, all compiles through.
> 
> With the flag the build bails out at 'configure' time.
> 
> Question [firstly I suppose]:  does 'threads' only work on  64 bit arch,
> because there seems to be no trouble on 64 bit arch   ?
> 
> If the above is a 'yes', then no need to go further perhaps.
> 
> Question:  what is spvw.'x'  (.d .c etc)  doing and why is it an issue on
> 32 bit arch ?

spvw.d is the file from which I learned the unforgettable German word for
memory management: speicherverwaltung. 
 
> Question:  the error reported,  is the issue clear and is there a solution
> ?     (i'm not a 'c' or expert coder or familiar with clisp code, so  I
> dont know what to make of it).

This one:

../src/lispbibl.d:7598:15: error: size of array ‘symbol_size_check’ is negative
 7598 |   typedef int symbol_size_check[1 - 2 * (int)(sizeof(symbol_) % varobject_alignment)];
      |  　            ^~~~~~~~~~~~~~~~~

is using an array declaration hack to implement a compile time sanity check:

  typedef int size_check[1 - 2 * CONSTANT_EXPR_THAT_MUST_BE_ZERO]

If CONSTANT_EXPR_THAT_MUST_BE_ZERO is nonzero, size_check is declared
as an array type with a negative dimension, violating an ISO C constraint,
requiring a diagnostic. Most compilers will treat that as a fatal error,
aborting compilation.

In this case, the expression that must be zero is checking that
the sizeof the type symbol_ is a multiple of varobject_alignment.

That not being the case is pointing to some inconsistency in
the configuration: a mismatch between how the content of symbol_
is defined relative to how varobject_alignment is defined.


In addition, the following is probably okay, but could benefit from
modernization:

../src/spvw.d:968:3: warning: ignoring return value of ‘__builtin_alloca’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
  968 |   alloca(1);                    /* Makes this function non-inlinable. */
      |   ^~~~~~~~~~~~~~~~~~~
make: *** [Makefile:1133: spvw.o] Error 1

E.g. define a "notinline" macro like this:

#if __GNUC__
#define noinline __attribute__((noinline))
#else
#define noinline
#endif

notinline void my_function_that_should_not_be_inlined(void)
{
   ...
}

The compiler is noticing that the return value of alloca(1) isn't
being captured and would be justified in optimizing it away,
subsequently allowing the function to be inlined.

Hello clisp-list

Trying to compile latest clisp  ( that checked out from the master branch
on gitlab).
The computer (laptop) is a [old] linux 32bit  celeron M 440  (slackware).

All dependencies present (i think).

The problem seems to be when using the flag, --with-threads=POSIX_THREADS
as without it, all compiles through.

With the flag the build bails out at 'configure' time.

Question [firstly I suppose]:  does 'threads' only work on  64 bit arch,
because there seems to be no trouble on 64 bit arch   ?

If the above is a 'yes', then no need to go further perhaps.

Question:  what is spvw.'x'  (.d .c etc)  doing and why is it an issue on
32 bit arch ?

Question:  the error reported,  is the issue clear and is there a solution
?     (i'm not a 'c' or expert coder or familiar with clisp code, so  I
dont know what to make of it).

Thank you
Habs


file attached (if it works) ...

the line at the top is the 'configure' attempted  (actually it is a
stripped down of modules one than initially tried ).

the rest is where the 'configure' bailed out.

Hi all,

I seem to remember that CLISP only has tail call optimization for self-calls.

Recently I did work on TCO for TXR Lisp. In a first milestone, I made self TCO work,
where a backwards JMP instruction is at the core.

In the current release, I also made cross-call TCO work. I wonder whether a similar
technique could work for CLISP.

I came up with a trick: I added a prefix instruction called TAIL to the VM. The prefix
instruction is inserted before one of several types of fuction calling instructions
that were identified by the compiler as being in a tail position.

The VM can then perform a modified function call (if the target function is a VM
function). whereby it allocates the callee's frame in the same space as the
caller.

If the caller needs more space, I alloca() the difference. Some trickery is used to
propagate the arguments. They have to be prepared while the old stack frame is
still valid, and then be available to the new frame after the old one is overwritten.

It's possible to ignore the TAIL instruction as a no-op and everything will work,
minus the tail semantics.

On Sat, 02 Nov 2024 19:38:06 +0100 Stephen Berman via clisp-list <cli...@li...> wrote:

> Today I updated my local git repo of clisp to the latest commit
> 0e67ff47e and successfully configured and built clisp, but install
> failed with many errors like this (I've attached a file with the full
> shell output of make install):
>
> In file included from /usr/include/string.h:462,
>                  from /home/steve/src/clisp/build_20241102/gllib/string.h:41,
>                  from clisp.c:23:
> /home/steve/src/clisp/build_20241102/gllib/strings.h:42:3: error: #error "Please include config.h first."
>    42 |  #error "Please include config.h first."
>       |   ^~~~~
>
> A web search found many reports with this error, but I could not find
> anything that made make install succeed.  My system is GNU/Linux with
> gcc-14.2.0 and glibc-2.40.  My last build of clisp, where make install
> also succeeded, was last May 21, using the latest git commit at that
> time; that system was with gcc-13.2.0 and glibc-2.39.
>
> I'd be grateful for any help in solving this issue.

I just updated again and now make install succeeded too.  Perhaps the
problem I had yesterday was fixed by this commit?

* 79d82fcb6..: Bruno Haible 2024-11-03 build: Build the clisp driver program without gnulib, part 2.

Steve Berman

On Sat, 02 Nov 2024 19:38:06 +0100 Stephen Berman <ste...@gm...> wrote:

> Today I updated my local git repo of clisp to the latest commit
> 0e67ff47e and successfully configured and built clisp, but install
> failed with many errors like this (I've attached a file with the full
> shell output of make install):

Apparently the list server deleted the attachment; I can post the full
output inline if desired.

Steve Berman

Today I updated my local git repo of clisp to the latest commit
0e67ff47e and successfully configured and built clisp, but install
failed with many errors like this (I've attached a file with the full
shell output of make install):

In file included from /usr/include/string.h:462,
                 from /home/steve/src/clisp/build_20241102/gllib/string.h:41,
                 from clisp.c:23:
/home/steve/src/clisp/build_20241102/gllib/strings.h:42:3: error: #error "Please include config.h first."
   42 |  #error "Please include config.h first."
      |   ^~~~~

A web search found many reports with this error, but I could not find
anything that made make install succeed.  My system is GNU/Linux with
gcc-14.2.0 and glibc-2.40.  My last build of clisp, where make install
also succeeded, was last May 21, using the latest git commit at that
time; that system was with gcc-13.2.0 and glibc-2.39.

I'd be grateful for any help in solving this issue.

Steve Berman

I get the same issue on a laptop (hp probook).

it seems that 4194303  is the max. I found possible using the OP code.

Habs


On Wed, 24 Jan 2024 at 23:32, Don Cohen <
don...@is...> wrote:

>
> I've recently started using oracle cloud and I
> notice that I can't allocate an array of >= 4M characters.
>
> On intel with
>  *features*
> (:REGEXP :WILDCARD :SYSCALLS :I18N :LOOP :COMPILER :CLOS :MOP :CLISP
> :ANSI-CL
>  :COMMON-LISP :LISP=CL :INTERPRETER :LOGICAL-PATHNAMES :MT :SOCKETS
>  :GENERIC-STREAMS :FFI :GETTEXT :UNICODE :BASE-CHAR=CHARACTER :WORD-SIZE=64
>  :PC386 :UNIX)
> (length (make-array  (* 1024 1024 4)
>         :element-type 'character
>         :fill-pointer t :adjustable t))
> => 4194304
>
> but on ampere with
> *features*
> (:READLINE :REGEXP :WILDCARD :SYSCALLS :I18N :LOOP :COMPILER :CLOS :MOP
> :CLISP
>  :ANSI-CL :COMMON-LISP :LISP=CL :INTERPRETER :LOGICAL-PATHNAMES :SOCKETS
>  :GENERIC-STREAMS :SCREEN :FFI :GETTEXT :UNICODE :BASE-CHAR=CHARACTER
>  :WORD-SIZE=64 :UNIX)
> *** - string too long: desired length 4194304 exceeds the supported
> maximum length
>
> Both say
> array-dimension-limit
> 4294967296
> (interestingly, one MORE than impnotes says should be the value
> for a 64 bit cpu)
>
>
> _______________________________________________
> clisp-list mailing list
> cli...@li...
> https://lists.sourceforge.net/lists/listinfo/clisp-list
>

I've recently started using oracle cloud and I
notice that I can't allocate an array of >= 4M characters.

On intel with
 *features*
(:REGEXP :WILDCARD :SYSCALLS :I18N :LOOP :COMPILER :CLOS :MOP :CLISP :ANSI-CL
 :COMMON-LISP :LISP=CL :INTERPRETER :LOGICAL-PATHNAMES :MT :SOCKETS
 :GENERIC-STREAMS :FFI :GETTEXT :UNICODE :BASE-CHAR=CHARACTER :WORD-SIZE=64
 :PC386 :UNIX)
(length (make-array  (* 1024 1024 4)
        :element-type 'character
        :fill-pointer t :adjustable t))
=> 4194304

but on ampere with
*features*
(:READLINE :REGEXP :WILDCARD :SYSCALLS :I18N :LOOP :COMPILER :CLOS :MOP :CLISP
 :ANSI-CL :COMMON-LISP :LISP=CL :INTERPRETER :LOGICAL-PATHNAMES :SOCKETS
 :GENERIC-STREAMS :SCREEN :FFI :GETTEXT :UNICODE :BASE-CHAR=CHARACTER
 :WORD-SIZE=64 :UNIX)
*** - string too long: desired length 4194304 exceeds the supported maximum length

Both say
array-dimension-limit
4294967296
(interestingly, one MORE than impnotes says should be the value
for a 64 bit cpu)

> On 8 Nov 2023, at 08:07, Kaz Kylheku <ka...@ky...> wrote:
> 
> [1]> (loop (loop-finish)) 
> 
> *** - (LOOP-FINISH) is possible only from within LOOP
> The following restarts are available:
> ABORT :R1 Abort main loop 
> 
> :)
> 

This is an error in the error message. (issue a bug report)
The LOOP operator introduces two kinds of loops:
- simple loops as the one you wrote,
- extended loops.

LOOP-FINISH is only available in extended loops, not in simple loops.

If you want to use loop-finish, you may add a do keyword to make it an extended loop:
(loop do (loop-finish))


-- 
__Pascal J. Bourguignon__

[1]> (loop (loop-finish)) 

*** - (LOOP-FINISH) is possible only from within LOOP
The following restarts are available:
ABORT :R1 Abort main loop 

:)

Hi,

On 23.07.23 02:20, Raymond Toy wrote:
> FYI, clisp is now on gitlab, not sourceforge: 
> https://gitlab.com/gnu-clisp/clisp and the last change was 4 days ago.
> 
> I didn't know this until I was just setting up gmane on thunderbird and 
> read the clisp list there.
Thanks for this information!

The CLISP web page still does not mention GitLab, only SourceForge.
I've checked "http://clisp.org", "https://clisp.sourceforge.io/",
and "https://www.gnu.org/software/clisp/" right now.

It would be great if the CLISP project would update this information.
Thanks in advance!

Best regards,
Erik

On 7/22/23 5:20 PM, Raymond Toy wrote:
> FYI, clisp is now on gitlab, not sourceforge: 
> https://gitlab.com/gnu-clisp/clisp and the last change was 4 days ago.
>
> I didn't know this until I was just setting up gmane on thunderbird 
> and read the clisp list there.
>
Oops.  Wrong to address.

FYI, clisp is now on gitlab, not sourceforge: 
https://gitlab.com/gnu-clisp/clisp and the last change was 4 days ago.

I didn't know this until I was just setting up gmane on thunderbird and 
read the clisp list there.

> * Don Cohen <qba...@vf...> [2023-07-14 02:15:04 +0000]:
>
> (setf list '("abc" "def" "qwe
> rty
> uiop" "zxc"))
>
> (with-output-to-string (s)(loop for x in list do (format s "~s~c" x #\tab)))
> "\"abc\"        \"def\"
> \"qwe
> rty
> uiop\"  \"zxc\" "
>
> Why is there an extra new line before the list element that contains
> the newlines?
> Is there some way to suppress it ?

https://clisp.sourceforge.io/impnotes/faq.html#faq-pp-newline
;-)
https://clisp.sourceforge.io/impnotes/faq.html#faq-fine



-- 
Sam Steingold (https://aphar.dreamwidth.org/) on Pop 22.04 (jammy) X 11.0.12101004
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://thereligionofpeace.com https://camera.org https://honestreporting.com
Booze is the answer. I can't remember the question.

I see I asked the same question in 2016 !!
And the answer is the same now -- print-pretty is t


Don Cohen writes:
 > 
 > (setf list '("abc" "def" "qwe
 > rty
 > uiop" "zxc"))
 > 
 > (with-output-to-string (s)(loop for x in list do (format s "~s~c" x #\tab)))
 > "\"abc\"        \"def\"
 > \"qwe
 > rty
 > uiop\"  \"zxc\" "
 > 
 > Why is there an extra new line before the list element that contains
 > the newlines?
 > Is there some way to suppress it ?

(setf list '("abc" "def" "qwe
rty
uiop" "zxc"))

(with-output-to-string (s)(loop for x in list do (format s "~s~c" x #\tab)))
"\"abc\"        \"def\"
\"qwe
rty
uiop\"  \"zxc\" "

Why is there an extra new line before the list element that contains
the newlines?
Is there some way to suppress it ?

Hi,

it seems to me as if the clisp.org (and www.gnu.org/software/clisp) site
show outdated information by only mentioning the SourceForge Mercurial
repository and the SourceForge bug tracker.  Bug reports are directed
to the SourceForge bug tracker, neither to a mailing list nor the GitLab
issue tracker.

It seems to me as if this is no longer good advice, and perhaps it might
be helpful to update those web pages.

(I tried to report a bug and followed the directions from clisp.org to
add it to the SourceForge bug tracker.  I did not receive any reply,
so I do not know if it has been seen.  I have seen another recent bug
report there, which might have been overlooked, but I do not know that.)

Kind regards,
Erik
-- 
A distributed system is one in which the failure of a computer you didn't
even know existed can render your own computer unusable.
                        -- Leslie Lamport