sbcl-help Mailing List for Steel Bank Common Lisp

Export N, E, W, S from package TEST1 and use it in TEST2, or otherwise import the symbols. Otherwise you are comparing TEST1::N and TEST::2 for equality; they are not the same symbol, so the set difference will not treat them as equal.

Alternatively, just use keywords: :N, :E, :W, :S will work fine.
________________________________
From: Shadrock Uhuru <niy...@gm...>
Sent: Thursday, June 11, 2026 4:30 PM
To: sbc...@li... <sbc...@li...>
Subject: [Sbcl-help] help with packages

[Some people who received this message don't often get email from niy...@gm.... Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

;; ------------------------------------------------------------------------
CL(1): (defpackage test1
  (:use :cl)
  (:export :test))
#<PACKAGE "TEST1">

CL(2): (in-package :test1)
#<PACKAGE "TEST1">

TEST1(3):

(defun test (test-val)                       ;; remove items from a list
  (format t "~%the test-val = ~a " test-val) ;; items to remove
  (let ((diff-list (set-difference (list 'N 'E 'W 'S) test-val)))  ;; remove the items
    (format t "~%the first item of test-val = ~a "(first  test-val))  ;; just to prove we get the function parameter
                                                                      ;; and we can operate on it
    (format t "~%the diff-list = ~a " diff-list)                     ;; the resultant list
    (dolist (each-item diff-list)                  ;; get each item of resultant list
    (format t "~%each item = ~a" each-item))))     ;; print item

TEST
TEST1(4): (test (list 'N 'S))

the test-val = (N S)
the first item of test-val = N
the diff-list = (W E)
each item = W
each item = E
NIL


TEST1(5): (defpackage test2
  (:use :cl))
#<PACKAGE "TEST2">

TEST1(6): (in-package :test2)
#<PACKAGE "TEST2">

TEST2(7) (test1:test (list 'N 'S))

the test-val = (N S)
the first item of test-val = N
the diff-list = (S W E N)
each item = S
each item = W
each item = E
each item = N
NIL

TEST2(8):

;; ---------------------------------------------
SBCL 2.6.4.openbsd.sbcl-2.6.4

hi everyone
the function above works when i call it within the package it was created in
but when i call it from another package the call to set-difference
appears to get an empty list as its second parameter,
as the test function works when called from it home package,
i'm assuming that the problem lies with how the packages are set up.
can anyone point me to the error in my code.
thanks shadrock


_______________________________________________
Sbcl-help mailing list
Sbc...@li...
https://lists.sourceforge.net/lists/listinfo/sbcl-help



This e-mail is sent to you from Keepit A/S. Dedicated SaaS Data Protection.
VAT: DK30806883, Per Henrik Lings Allé 4, 7., DK-2100 Copenhagen O, Denmark.

This e-mail is sent to you directly and is meant for nobody else. If the e-mail contains personal data that Keepit is responsible for and the e-mail was not meant for you, please do not forward, distribute, or copy, i.e. but return the e-mail to sender. Also, do not send the e-mail to a third party without making sure that you have our prior consent. Distribution of this e-mail to unauthorized receivers may have legal consequences.
If you have received an e-mail from us and you don't know why, then please refer to our Privacy Policy<https://www.keepit.com/privacy-policy/>.
If you do not want to receive more e-mails from us, please contact bus...@ke...<mailto:bus...@ke...>.

In the first case it's 'test1::n and 'test1::s and in the second case it's
'test2::n and 'test2::s

Чт, 11 июня 2026 г. в 17:32, Shadrock Uhuru <niy...@gm...>:

> ;; ------------------------------------------------------------------------
> CL(1): (defpackage test1
>   (:use :cl)
>   (:export :test))
> #<PACKAGE "TEST1">
>
> CL(2): (in-package :test1)
> #<PACKAGE "TEST1">
>
> TEST1(3):
>
> (defun test (test-val)                       ;; remove items from a list
>   (format t "~%the test-val = ~a " test-val) ;; items to remove
>   (let ((diff-list (set-difference (list 'N 'E 'W 'S) test-val)))  ;;
> remove the items
>     (format t "~%the first item of test-val = ~a "(first  test-val))  ;;
> just to prove we get the function parameter
>                                                                       ;;
> and we can operate on it
>     (format t "~%the diff-list = ~a " diff-list)                     ;;
> the resultant list
>     (dolist (each-item diff-list)                  ;; get each item of
> resultant list
>     (format t "~%each item = ~a" each-item))))     ;; print item
>
> TEST
> TEST1(4): (test (list 'N 'S))
>
> the test-val = (N S)
> the first item of test-val = N
> the diff-list = (W E)
> each item = W
> each item = E
> NIL
>
>
> TEST1(5): (defpackage test2
>   (:use :cl))
> #<PACKAGE "TEST2">
>
> TEST1(6): (in-package :test2)
> #<PACKAGE "TEST2">
>
> TEST2(7) (test1:test (list 'N 'S))
>
> the test-val = (N S)
> the first item of test-val = N
> the diff-list = (S W E N)
> each item = S
> each item = W
> each item = E
> each item = N
> NIL
>
> TEST2(8):
>
> ;; ---------------------------------------------
> SBCL 2.6.4.openbsd.sbcl-2.6.4
>
> hi everyone
> the function above works when i call it within the package it was created
> in
> but when i call it from another package the call to set-difference
> appears to get an empty list as its second parameter,
> as the test function works when called from it home package,
> i'm assuming that the problem lies with how the packages are set up.
> can anyone point me to the error in my code.
> thanks shadrock
>
>
> _______________________________________________
> Sbcl-help mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>

;; ------------------------------------------------------------------------
CL(1): (defpackage test1
  (:use :cl)
  (:export :test))
#<PACKAGE "TEST1">

CL(2): (in-package :test1)
#<PACKAGE "TEST1">

TEST1(3):

(defun test (test-val)                       ;; remove items from a list
  (format t "~%the test-val = ~a " test-val) ;; items to remove
  (let ((diff-list (set-difference (list 'N 'E 'W 'S) test-val)))  ;; remove the items
    (format t "~%the first item of test-val = ~a "(first  test-val))  ;; just to prove we get the function parameter
                                                                      ;; and we can operate on it
    (format t "~%the diff-list = ~a " diff-list)                     ;; the resultant list
    (dolist (each-item diff-list)                  ;; get each item of resultant list
    (format t "~%each item = ~a" each-item))))     ;; print item

TEST
TEST1(4): (test (list 'N 'S))

the test-val = (N S)
the first item of test-val = N
the diff-list = (W E)
each item = W
each item = E
NIL


TEST1(5): (defpackage test2
  (:use :cl))
#<PACKAGE "TEST2">

TEST1(6): (in-package :test2)
#<PACKAGE "TEST2">

TEST2(7) (test1:test (list 'N 'S))

the test-val = (N S)
the first item of test-val = N
the diff-list = (S W E N)
each item = S
each item = W
each item = E
each item = N
NIL

TEST2(8):

;; ---------------------------------------------
SBCL 2.6.4.openbsd.sbcl-2.6.4

hi everyone
the function above works when i call it within the package it was created in
but when i call it from another package the call to set-difference
appears to get an empty list as its second parameter,
as the test function works when called from it home package,
i'm assuming that the problem lies with how the packages are set up.
can anyone point me to the error in my code.
thanks shadrock

I am experimenting with a new testing method, and wonder if there is a
better way to find recent output?


(defun last-lines-of-output (n)
  (serapeum:take n
                 (serapeum:~> *standard-output*
                              swank::real-output-stream
                              swank/gray::data
                              swank/gray::stream-data-buffer
                              serapeum:lines)))

On 2026-05-20 at 18:58:43 -0400,
Greg Bennett <gwb...@gm...> wrote:

[...]

>   The constant +ZOT+ is being redefined (from ("a" "b") to ("a" "b"))
> See also:
>   The ANSI Standard, Macro DEFCONSTANT
>   The SBCL Manual, Node "Idiosyncrasies"

[...]

> Is there a way to avoid this situation ?

Don't redefine your constants?  ;-)

Or use Alexandria's define-constant[0].

Or use defparameter instead of defconstant.

IMO, the two references in the error message describe the error fairly
well, at least well enough to made sense to me the first time I ran into
this.

HTH,
Dan

[0] <https://alexandria.common-lisp.dev/draft/alexandria.html#index-define_002dconstant>

Thanks!

On 2026-05-20 19:05, Michał "phoe" Herda wrote:
>
> Use alexandria:define-constant with :test #'equal.
>
> W dniu 2026-05-21 00:58, Greg Bennett napisał(a):
>
>> Running sbcl 2.6.4 under linux mint 22.3
>>
>> The file ~/RESREVE/test-defconstant.lsp contains the single line
>>
>> (defconstant +zot+ '("a" "b"))
>>
>> Compiling that file and then loading test-defconstant.fasl leads to
>>
>> (load "~/RESERVE/test-constant.fasl")
>>
>> debugger invoked on a DEFCONSTANT-UNEQL in thread
>> #<THREAD tid=391763 "main thread" RUNNING {1200038003}>:
>>   The constant +ZOT+ is being redefined (from ("a" "b") to ("a" "b"))
>> See also:
>>   The ANSI Standard, Macro DEFCONSTANT
>>   The SBCL Manual, Node "Idiosyncrasies"
>>
>> Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
>>
>> restarts (invokable by number or by possibly-abbreviated name):
>>   0: [CONTINUE] Go ahead and change the value.
>>   1: [ABORT   ] Keep the old value.
>>   2:            Exit debugger, returning to top level.
>>
>> (SB-IMPL::%DEFCONSTANT +ZOT+ ("a" "b") 
>> #S(SB-C:DEFINITION-SOURCE-LOCATION :NAMESTRING 
>> "~/RESERVE/test-constant.lsp" :INDICES 32769) NIL)
>> 0] 2
>>
>> Is there a way to avoid this situation ?
>>
>> Cheers,
>> Greg
>>
>>
>> _______________________________________________
>> Sbcl-help mailing list
>> Sbc...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>
>

Found the idiosyncracies item.

Forget the question.

Greg

Use alexandria:define-constant with :test #'equal.

W dniu 2026-05-21 00:58, Greg Bennett napisał(a):

> Running sbcl 2.6.4 under linux mint 22.3
> 
> The file ~/RESREVE/test-defconstant.lsp contains the single line
> 
> (defconstant +zot+ '("a" "b"))
> 
> Compiling that file and then loading test-defconstant.fasl leads to
> 
> (load "~/RESERVE/test-constant.fasl")
> 
> debugger invoked on a DEFCONSTANT-UNEQL in thread
> #<THREAD tid=391763 "main thread" RUNNING {1200038003}>:
> The constant +ZOT+ is being redefined (from ("a" "b") to ("a" "b"))
> See also:
> The ANSI Standard, Macro DEFCONSTANT
> The SBCL Manual, Node "Idiosyncrasies"
> 
> Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
> 
> restarts (invokable by number or by possibly-abbreviated name):
> 0: [CONTINUE] Go ahead and change the value.
> 1: [ABORT   ] Keep the old value.
> 2:            Exit debugger, returning to top level.
> 
> (SB-IMPL::%DEFCONSTANT +ZOT+ ("a" "b") 
> #S(SB-C:DEFINITION-SOURCE-LOCATION :NAMESTRING 
> "~/RESERVE/test-constant.lsp" :INDICES 32769) NIL)
> 0] 2
> 
> Is there a way to avoid this situation ?
> 
> Cheers,
> Greg
> 
> _______________________________________________
> Sbcl-help mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help

Running sbcl 2.6.4 under linux mint 22.3

The file ~/RESREVE/test-defconstant.lsp contains the single line

(defconstant +zot+ '("a" "b"))

Compiling that file and then loading test-defconstant.fasl leads to

(load "~/RESERVE/test-constant.fasl")

debugger invoked on a DEFCONSTANT-UNEQL in thread
#<THREAD tid=391763 "main thread" RUNNING {1200038003}>:
   The constant +ZOT+ is being redefined (from ("a" "b") to ("a" "b"))
See also:
   The ANSI Standard, Macro DEFCONSTANT
   The SBCL Manual, Node "Idiosyncrasies"

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
   0: [CONTINUE] Go ahead and change the value.
   1: [ABORT   ] Keep the old value.
   2:            Exit debugger, returning to top level.

(SB-IMPL::%DEFCONSTANT +ZOT+ ("a" "b") 
#S(SB-C:DEFINITION-SOURCE-LOCATION :NAMESTRING 
"~/RESERVE/test-constant.lsp" :INDICES 32769) NIL)
0] 2

Is there a way to avoid this situation ?

Cheers,
Greg

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
		     19th European Lisp Symposium

			Call for Participation

			    May 11-12 2026
		     Skład Długa, Kraków, Poland

	     https://www.european-lisp-symposium.org/2026
		    Sponsored by Keepit and SISCOG
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Important News
~~~~~~~~~~~~~~~

- Programme and remote attendance instructions now available
- Keynotes announced
  Lambda: the Ultimate Paradigm -- François-René Rideau, Gerbil Scheme
  McCLIM and ECL -- Daniel Kochmański


Important Dates
~~~~~~~~~~~~~~~
- Symposium: May 11-12 2026


Scope
~~~~~

The European Lisp Symposium is a premier forum for the discussion and
dissemination of all aspects of design, implementation, and
application of any of the Lisp dialects, including Common Lisp,
Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan,
SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so
on. We encourage everyone interested in Lisp to participate.

The European Lisp Symposium invites high quality papers about novel
research results, insights and lessons learned from practical
applications, and educational perspectives. We also encourage
submissions about known ideas as long as they are presented in a new
setting and/or in a highly elegant way.

Topics include but are not limited to:

- context-, aspect-, domain-oriented and generative programming
- macro-, reflective-, meta- and/or rule-based development approaches
- language design and implementation
- language integration, inter-operation, and deployment
- development methodologies, support, and environments
- educational approaches and perspectives
- experience reports and case studies


Programme Chair
~~~~~~~~~~~~~~~
Mark Evenson, ABCL.org, Austria


Organizing Chair
~~~~~~~~~~~~~~~~
Didier Verna, EPITA / LRE, France


Programme Committee
~~~~~~~~~~~~~~~~~~~
Alan Ruttenberg, USA
Dave Cooper, Genworks, USA
Dimitris Vyzovitis, Mighty Gerbils
Eitaro Fukamachi, Japan
Jason Hemann, Seton Hall University, USA
Kristopher Micinski, Syracuse University, USA
Marc Battyani, Enfabrica, USA
Mark David, USA
Michael Raskin, LaBRI, France
Robert Goldman, SIFT, USA
Thomas de Grivel, France


Local Chairs
~~~~~~~~~~~~
Wojciech Gac, Keepit, Poland
Michał Herda, Keepit, Poland


Virtualization Team
~~~~~~~~~~~~~~~~~~~
Georgiy Tugai, Configura, Sweden
Yukari Hafner, Shirakumo.org, Switzerland

-- 
Resistance is futile. You will be jazzimilated.

Lisp, Jazz, Aïkido: http://www.didierverna.info

Further analysis suggests that symbol-hash will be fine for the
function-name and slot-name tables. The equivalence predicate wants to be
EQ for names which are symbols, but robinhood hashsets don't have a way to
hash symbols by their address while not messing up if GC moves them. That's
why I naturally thought of an EQUAL table which will properly deal with
SETF names as well as hash symbols by EQ. I think the correct fix will
indeed be a custom mixer but we don't need to involve the package.  Using
this quick test:

(let ((dummies (loop repeat 5000 collect (make-symbol "BLAH")))
      (alist))
  (dolist (sym dummies)
    (let* ((h (sb-kernel:symbol-hash sym))
           (cell (assoc h alist)))
      (if cell
          (incf (cdr cell))
          (push (cons h 1) alist))))
  (sort alist #'> :key #'cdr))

the worst number of colliding symbols was 15.  Even doubling the 5000 to
10000 saw no more than 18 collisions, and using up to 50,000 saw at worst
70 collisions. I then asked how many spelled-the-same symbols I would need
for the robinhood hashset to screw up (using that same quick-and-dirty loop
above), and the answer was over 200,000 symbols.
Or teach robinhood hashsets to use EQ hash and also rehash after key
movement, but I don't really like that as much as just mixing better

That's the right idea. But I was going to change them to EQUAL hash-tables.
Nobody should care if the fun-name-hashset wastes space (for values that
are never needed), as it is GCed after compilation.
And this will incentivize implementing SBCL hash-tables that don't store a
value, which has been on my project list forever.
Slot names might use symbol-hash instead of symbol-name-hash which gives
some pseudorandomness

<html><body><div style="font-family: 'verdana'; font-size: 12px; color: #000;">Maybe the attachments could be worth trying?</div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;">The first one appears to fix the crash for me;</div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;">the second one addresses the same issue on a different hashset.</div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><br>Disclaimer: NO FITNESS FOR ANY PURPOSE IMPLIED.<br>PURE AI SLOP. MAY BE CONFIDENTLY WRONG IN UNEXPECTED<br>WAYS. MAY CRASH YOUR HARD DRIVE. MAY EAT YOU ALIVE.<br>YOU ARE SOLELY RESPONSIBLE FOR ANY USE. ENJOY.</div></body></html>

Confirmed this reproduces the overflow of an (unsigned-byte 8).  Something
needs a stronger hash function. I don't think it will be too hard to come
up with one.

Christophe,

download the files:
https://www.wolvendesignautomation.com/assets/noffi.tgz
https://www.wolvendesignautomation.com/assets/big-file-bug.tgz

untar them somewhere and follow the instructions in
big-file-bug/instructions.txt

I used SBCL 2.5.9 for Windows X86-64.

On Tue, Apr 14, 2026 at 2:15 PM Andrew Wolven <aw...@gm...> wrote:

> Thanks.
>
> I can just send you the file with the 20000 defmethods, and the file with
> the 2500 or so defclasses and the 700 or so defpackages which it
> depends on.  You will need to load noffi, but we have tested that well on
> SBCL.  Give me a little bit to get organized and make sure the bug is still
> there.  (the "256 is not of type (unsigned-byte 8)")
>
> And yes, I can do some profiling on the initialize-instance defmethods and
> subsets thereof.
>
> As far as the big defun goes, I have some smaller "big defuns" for
> cubic/quadratic and quadratic/quadratic.
>
> On Tue, Apr 14, 2026 at 1:28 PM Christophe Rhodes <cs...@ca...>
> wrote:
>
>> Andrew Wolven <aw...@gm...> writes:
>>
>> > Hi.  I'm not ready to file a bug, just have some anecdotes about my
>> > use of SBCL.  Could spend some time tracking down the issues if no one
>> > has suggestions.
>> >
>> > 1. I have problems with extremely large source files.  The workaround
>> > is to break them up into smaller pieces, but just to report: When
>> > compiling a file of about 20 thousand short defmethods, with generic
>> > function method counts usually being less than 5, sbcl often hits a
>> > bug "256 is not of type (unsigned-byte 8)" something to do with a hash
>> > set.  I could replicate it if necessary.
>>
>> I think it would be useful to have a bug report with a reproducer for
>> this.  (A program to generate the file with 20000 defmethods, if
>> appropriate, would be fine).
>>
>> > 2. Extremely long function bodies take a really long time to compile.
>> > So obviously my problems deal with generating code, the previous being
>> > C++ bindings, but I also created a function which computes the
>> > polynomial which can be given to a root finder to compute the closed
>> > form intersection of two cubic rational bezier curves in 2-space.  I
>> > made the function body with maxima.  Takes an extremely long time to
>> > compile with various versions of SBCL.  Like 8 minutes.  Loads fast.
>>
>> This is a reasonably known problem: some of SBCL's optimizations scale
>> worse-than-linearly in the size of the function.  Previous culprits have
>> included the type derivation engine, and particularly the repeated
>> iteration of constraint propagation, towards a fixed point.  Here's an
>> example bug report for something similar:
>> https://bugs.launchpad.net/sbcl/+bug/2112276
>>
>> There are sometimes compiler settings that can be tweaked to discourage
>> SBCL from doing some parts of work too often.  To find out which might
>> be useful in this specific case, it would be good to know which
>> particular part of the compiler is the bottleneck.  If it's possible to
>> shrink the problem a bit, so that the compilation is of the order of a
>> minute or two, it should be possible to get a reasonable picture of
>> what's going on using the statistical profiler.  (It might also work at
>> 8 minutes; that's "only" 48000 samples by default).
>>
>> Other things that can alleviate this include splitting the routine into
>> multiple functions.  I think we have some specialized entry points
>> (e.g. for passing double-floats unboxed) so with tasteful argument lists
>> the compiled code might not be substantially slower.
>>
>> > 3. Initialize-instance, or other CLOS generic functions with large
>> > numbers of methods.  I generated a file for a fairly large C++ dll to
>> > create instances of CLOS wrappers of C++ objects.  So you can just
>> > call make-instance and get and get the method to automatically call
>> > "new" and "constructors" and set up finalizers with destructor and
>> > delete.  So I have an 80,000 LOC file with a few thousand
>> > initialize-instance methods, some just a few lines, others many lines.
>> > It's fast compiling but then takes like 10 minutes to load.
>> >
>> > In another case I compile and load a 250,000 LOC without large numbers
>> > of methods and it compiles and loads in 30 seconds.  So I think large
>> > numbers of methods create a problem.
>>
>> Defining new methods (when loading defmethod forms) inherently invokes
>> parts of CLOS.  In an ideal world this would be linear in the work done,
>> but it wouldn't surprise me to find that something is scaling
>> more-than-linearly.  There are definitely things that have to be done
>> each time (e.g. running `add-method` on `initialize-instance` --
>> wouldn't it be nice to be able to run one `add-methods` rather than a
>> few thousand `add-method` calls?) but maybe some other things can be
>> done more lazily.
>>
>> If you shrink this down to half the size, does it take less than half
>> the time?  Again, a statistical profile report for what's going on here
>> would be interesting.
>>
>> Christophe
>>
>

Thanks.

I can just send you the file with the 20000 defmethods, and the file with
the 2500 or so defclasses and the 700 or so defpackages which it
depends on.  You will need to load noffi, but we have tested that well on
SBCL.  Give me a little bit to get organized and make sure the bug is still
there.  (the "256 is not of type (unsigned-byte 8)")

And yes, I can do some profiling on the initialize-instance defmethods and
subsets thereof.

As far as the big defun goes, I have some smaller "big defuns" for
cubic/quadratic and quadratic/quadratic.

On Tue, Apr 14, 2026 at 1:28 PM Christophe Rhodes <cs...@ca...> wrote:

> Andrew Wolven <aw...@gm...> writes:
>
> > Hi.  I'm not ready to file a bug, just have some anecdotes about my
> > use of SBCL.  Could spend some time tracking down the issues if no one
> > has suggestions.
> >
> > 1. I have problems with extremely large source files.  The workaround
> > is to break them up into smaller pieces, but just to report: When
> > compiling a file of about 20 thousand short defmethods, with generic
> > function method counts usually being less than 5, sbcl often hits a
> > bug "256 is not of type (unsigned-byte 8)" something to do with a hash
> > set.  I could replicate it if necessary.
>
> I think it would be useful to have a bug report with a reproducer for
> this.  (A program to generate the file with 20000 defmethods, if
> appropriate, would be fine).
>
> > 2. Extremely long function bodies take a really long time to compile.
> > So obviously my problems deal with generating code, the previous being
> > C++ bindings, but I also created a function which computes the
> > polynomial which can be given to a root finder to compute the closed
> > form intersection of two cubic rational bezier curves in 2-space.  I
> > made the function body with maxima.  Takes an extremely long time to
> > compile with various versions of SBCL.  Like 8 minutes.  Loads fast.
>
> This is a reasonably known problem: some of SBCL's optimizations scale
> worse-than-linearly in the size of the function.  Previous culprits have
> included the type derivation engine, and particularly the repeated
> iteration of constraint propagation, towards a fixed point.  Here's an
> example bug report for something similar:
> https://bugs.launchpad.net/sbcl/+bug/2112276
>
> There are sometimes compiler settings that can be tweaked to discourage
> SBCL from doing some parts of work too often.  To find out which might
> be useful in this specific case, it would be good to know which
> particular part of the compiler is the bottleneck.  If it's possible to
> shrink the problem a bit, so that the compilation is of the order of a
> minute or two, it should be possible to get a reasonable picture of
> what's going on using the statistical profiler.  (It might also work at
> 8 minutes; that's "only" 48000 samples by default).
>
> Other things that can alleviate this include splitting the routine into
> multiple functions.  I think we have some specialized entry points
> (e.g. for passing double-floats unboxed) so with tasteful argument lists
> the compiled code might not be substantially slower.
>
> > 3. Initialize-instance, or other CLOS generic functions with large
> > numbers of methods.  I generated a file for a fairly large C++ dll to
> > create instances of CLOS wrappers of C++ objects.  So you can just
> > call make-instance and get and get the method to automatically call
> > "new" and "constructors" and set up finalizers with destructor and
> > delete.  So I have an 80,000 LOC file with a few thousand
> > initialize-instance methods, some just a few lines, others many lines.
> > It's fast compiling but then takes like 10 minutes to load.
> >
> > In another case I compile and load a 250,000 LOC without large numbers
> > of methods and it compiles and loads in 30 seconds.  So I think large
> > numbers of methods create a problem.
>
> Defining new methods (when loading defmethod forms) inherently invokes
> parts of CLOS.  In an ideal world this would be linear in the work done,
> but it wouldn't surprise me to find that something is scaling
> more-than-linearly.  There are definitely things that have to be done
> each time (e.g. running `add-method` on `initialize-instance` --
> wouldn't it be nice to be able to run one `add-methods` rather than a
> few thousand `add-method` calls?) but maybe some other things can be
> done more lazily.
>
> If you shrink this down to half the size, does it take less than half
> the time?  Again, a statistical profile report for what's going on here
> would be interesting.
>
> Christophe
>

Andrew Wolven <aw...@gm...> writes:

> Hi.  I'm not ready to file a bug, just have some anecdotes about my
> use of SBCL.  Could spend some time tracking down the issues if no one
> has suggestions.
>
> 1. I have problems with extremely large source files.  The workaround
> is to break them up into smaller pieces, but just to report: When
> compiling a file of about 20 thousand short defmethods, with generic
> function method counts usually being less than 5, sbcl often hits a
> bug "256 is not of type (unsigned-byte 8)" something to do with a hash
> set.  I could replicate it if necessary.

I think it would be useful to have a bug report with a reproducer for
this.  (A program to generate the file with 20000 defmethods, if
appropriate, would be fine).

> 2. Extremely long function bodies take a really long time to compile.
> So obviously my problems deal with generating code, the previous being
> C++ bindings, but I also created a function which computes the
> polynomial which can be given to a root finder to compute the closed
> form intersection of two cubic rational bezier curves in 2-space.  I
> made the function body with maxima.  Takes an extremely long time to
> compile with various versions of SBCL.  Like 8 minutes.  Loads fast.

This is a reasonably known problem: some of SBCL's optimizations scale
worse-than-linearly in the size of the function.  Previous culprits have
included the type derivation engine, and particularly the repeated
iteration of constraint propagation, towards a fixed point.  Here's an
example bug report for something similar:
https://bugs.launchpad.net/sbcl/+bug/2112276

There are sometimes compiler settings that can be tweaked to discourage
SBCL from doing some parts of work too often.  To find out which might
be useful in this specific case, it would be good to know which
particular part of the compiler is the bottleneck.  If it's possible to
shrink the problem a bit, so that the compilation is of the order of a
minute or two, it should be possible to get a reasonable picture of
what's going on using the statistical profiler.  (It might also work at
8 minutes; that's "only" 48000 samples by default).

Other things that can alleviate this include splitting the routine into
multiple functions.  I think we have some specialized entry points
(e.g. for passing double-floats unboxed) so with tasteful argument lists
the compiled code might not be substantially slower.

> 3. Initialize-instance, or other CLOS generic functions with large
> numbers of methods.  I generated a file for a fairly large C++ dll to
> create instances of CLOS wrappers of C++ objects.  So you can just
> call make-instance and get and get the method to automatically call
> "new" and "constructors" and set up finalizers with destructor and
> delete.  So I have an 80,000 LOC file with a few thousand
> initialize-instance methods, some just a few lines, others many lines.
> It's fast compiling but then takes like 10 minutes to load.
>
> In another case I compile and load a 250,000 LOC without large numbers
> of methods and it compiles and loads in 30 seconds.  So I think large
> numbers of methods create a problem.

Defining new methods (when loading defmethod forms) inherently invokes
parts of CLOS.  In an ideal world this would be linear in the work done,
but it wouldn't surprise me to find that something is scaling
more-than-linearly.  There are definitely things that have to be done
each time (e.g. running `add-method` on `initialize-instance` --
wouldn't it be nice to be able to run one `add-methods` rather than a
few thousand `add-method` calls?) but maybe some other things can be
done more lazily.

If you shrink this down to half the size, does it take less than half
the time?  Again, a statistical profile report for what's going on here
would be interesting.  

Christophe

Hi.  I'm not ready to file a bug, just have some anecdotes about my use of
SBCL.  Could spend some time tracking down the issues if no one has
suggestions.

1. I have problems with extremely large source files.  The workaround is to
break them up into smaller pieces, but just to report:  When compiling a
file of about 20 thousand short defmethods, with generic function method
counts usually being less than 5, sbcl often hits a bug "256 is not of type
(unsigned-byte 8)"  something to do with a hash set.  I could replicate it
if necessary.

2. Extremely long function bodies take a really long time to compile.  So
obviously my problems deal with generating code, the previous being C++
bindings, but I also created a function which computes the polynomial which
can be given to a root finder to compute the closed form intersection of
two cubic rational bezier curves in 2-space.  I made the function body with
maxima.  Takes an extremely long time to compile with various versions of
SBCL.  Like 8 minutes.  Loads fast.

3. Initialize-instance, or other CLOS generic functions with large numbers
of methods.  I generated a file for a fairly large C++ dll to create
instances of CLOS wrappers of C++ objects.  So you can just call
make-instance and get and get the method to automatically call "new" and
"constructors" and set up finalizers with destructor and delete.  So I have
an 80,000 LOC file with a few thousand initialize-instance methods, some
just a few lines, others many lines.  It's fast compiling but then takes
like 10 minutes to load.

In another case I compile and load a 250,000 LOC without large numbers of
methods and it compiles and loads in 30 seconds.  So I think large numbers
of methods create a problem.

Obviously I want to come up with ways to narrow down the generated code to
a smaller subset of functionality, but right now I am just seeing the
extents of what types of C++ functions I can wrap.  Maybe I will come up
with a demand-load system.

But does anyone else have problems with slowness and bugs with large source
files on SBCL?

-AKW

On 4/3/26 9:43 PM, Christopher Stacy wrote:
> 
> On 4/3/26 9:23 PM, Stas Boukarev wrote:
>> But now you have more comments to comment out.
> 
> Well, except for the comments, I commented everything but the in-package 
> and the secretly-quoted form, and still didn't get it! If I had 
> commented out the comments, it would have dawned on me quicker. OMG 
> something is wrong with the COMMENTS? (The compiler must REALLY be 
> broken! LOL)
> 
> Seriously though, we should have a commenting tool that follows some 
> (customizable) pattern for commenting out code. And it should have 
> levels. A lot like how email messages do quoting.  m-x undo-commented- 
> code. With arg, prompts for a commenting tag so you can have multiple 
> levels of commented code. Sort of a whole little version branching 
> system based on comments!  c-u show-me-what-the-code-would look-like- 
> for-tags. Think of it as a debugging tool related to literate coding maybe.
> 
> I am not actually kidding.

i believe you.

> Also, a linting tool that does a pass using the source code as a string 
> (stream) so it can look for hinky things like this that READ would skip 
> over. (Or would QUOTED-TOPLEVEL=FORM in.a walker be better?). What other 
> text errors are there, which are perfectly good Lisp? Maybe suspicious 
> #||#s or something....what else?
> 
> 
> 


Hmmm, like a pretty printer?

On 4/3/26 5:35 AM, Christopher Stacy wrote:
>    Here are the results of my latest attempt at testing this.
> 
> I tarted up the system, made an entirely new directory elsewhere, dumped 
> the system in there, and changed its name in the ASD and made the new 
> ASDF CONF file. All my tests are in fresh instances of SBCL. (And I went 
> so far as to manually delete the .cache files to make sure ASDF is 
> compiling the right files!)
> Here's my test incantation:
> 
> (progn
>    (asdf:clear-configuration)
>    (asdf:compile-system :bork :force t)
>    (asdf:load-system :bork)
>    (in-package :o))
> 
> Same incantation (other system name)  when doing the A/B system testing. 
> The rest of the test consists of calling the GF on the atom and cons 
> inputs. I modified the methods with some PRINT statements so I'm sure 
> what I'm seeing.
> 
> ORIGINAL FAILURE MODE:
> Two defemthods one after the other.
> The second one gets defined, the first one does not.
> No compile-time errors or warnings,
> just NO-APPLICABLE-METHOD when I try one of them.
> Manually doing slime-compile-defun on the missing one makes it properly 
> defined. and everything works.
> 
> NOW:
> Hold on to your hats, kids, it's going to get weird.
> 
> The methods are defined, one right after the other, in source file One. 
> If I move them to a subsequent source file Two, they both get compiled 
> and work!
> 
> Well, sorta.
> In file One, before I diked them out, they were immediately followed by 
> a regular defun FOOBAR. Now when I compile, I get an undefined function 
> warning for FOOBAR. And guess what? There's nothing wrong with that 
> function, either, and just like the missing defmethod, I can slime- 
> compile-defun it to fix everything!
> 
> 
> So whatever is in that position in the source file seems to get skipped 
> over by the compiler!  First it was a missing defmethod. Now it's a 
> missing defun.  The obvious question is: What is right before that in 
> the source?
> 
> 
> Well, it's another defmethod. It happens to be an entirely different 
> method, on the same class as the one that was skipped.
> 
> But wait, there's more!
> If I put (warn "WTF")
> And the defun does not get skipped.
> 
> Soooo, I put the defmethods back there, put the WTF in front of them, 
> and then EVERYTHING COMPILES AND WORKS properly.
> 
> It doesn't seem to be the defmethods or CLOS. It's just that*whatever 
> form is in that location in the source file does not get compiled*. And 
> the warn does not go off, either. I can replace it with a NIL and get 
> the same behavior: the form there gets eaten, is not compiled, and 
> everything works.
> 
> So what evil thing in this file, that must be right above the skipped 
> form, is causing this? I commented out whatever it was. Nothing changes 
> -- the form still gets eaten. Something before that, then? Nope. And I 
> tediously went through commenting out one form after another and 
> recompiling in a fresh sbcl and retesting.
> 
> And then I ran out of things to comment out.
> At this point, there is the in-package at the top of the file, then the 
> NIL/WARN, then the form that used to get skipped, and the rest of the 
> original source file that has always been compiled without problem. If I 
> take the NIL/WARN out, the next form gets skipped. Doesn't matter what 
> the next form is.
> 
> (in-package :foo)
> (warn "skip") ;; remove and the next form will be skipped
> (defwhatever sometimes-skipped ()...)
> (more stuff that never had a problem...)
> 
> There can be any forms (or as in the above illustration, no) forms 
> between the in-pacakage and the warn. Anything above the warn gets 
> compiled, anything after the warn gets compiled. Take the warn away, and 
> one form (any defun or defmethod, anyway) will be skipped instead of the 
> warn.
> 


> I've now spent about 40 hours on this problem, and if I don't get it 
> figured out soon, I will just leave that WARN in there, since it solves 
> the problem, and hope for the best.
> 
> Suggestions?
>

you could avoid the progn; try it like this.

(eval-when (:compile-toplevel :load-toplevel :execute)
   ... )

I have this in my dot-emacs file.

(defun si:lisp-eval-when (prefix)
   "Insert an `eval-when' statement."
   (interactive "P")
   (if prefix
       (insert "(eval-when (:execute)\n")
     (insert "(eval-when (:compile-toplevel :load-topleve :execute)\n"))
   (indent-according-to-mode))

On 4/3/26 1:45 PM, Jacek Podkanski wrote:
> I solved my previous <<error printing object>> and now I have another 
> problem. When my example stops running, and I want to (inspect *arbs*) 
> to see the hash, inspect shows 5 objects.
> But when i press 4 to see the pairs of the hash, I see only 4 objects.
> 
> How am I supposed to understand it?


CL-USER> (defvar *hash* (make-hash-table ))
*HASH*

#\d
#\e
#\f
NIL
CL-USER> (loop for i across "abcdef" do (setf (gethash i *hash*) i))
NIL
CL-USER> *hash*
#<HASH-TABLE :TEST EQL :COUNT 6 {100481C203}>


### this is all she wrote.
CL-USER> (inspect '*hash*)

The object is a SYMBOL.
0. Name: "*HASH*"
1. Package: #<PACKAGE "COMMON-LISP-USER">
2. Value: #<HASH-TABLE :TEST EQL :COUNT 6 {100481C203}>
3. Function: #<unbound slot>
4. Plist: NIL
 > 2

The object is a STRUCTURE-OBJECT of type HASH-TABLE.
0. GETHASH-IMPL: #<FUNCTION SB-IMPL::GETHASH/EQL>
1. PUTHASH-IMPL: #<FUNCTION SB-IMPL::PUTHASH/EQL>
2. REMHASH-IMPL: #<FUNCTION SB-IMPL::REMHASH/EQL>
3. CLRHASH-IMPL: #<FUNCTION SB-IMPL::CLRHASH-IMPL>
4. PAIRS: #(6 0 #\a #\a #\b #\b #\c #\c #\d #\d #\e #\e #\f #\f 
#1=#<unbound> #1# T)
5. CACHE: 17592186044414
6. INDEX-VECTOR: #(0 0 0 0 0 0 0 6)
7. NEXT-VECTOR: #(0 0 1 2 3 4 5 0)
8. HASH-VECTOR: NIL
9. FLAGS: 16
10. %LOCK: NIL
11. TEST-FUN: #<FUNCTION EQL>
12. HASH-FUN: #<FUNCTION SB-IMPL::EQL-HASH>
13. TEST: EQL
14. REHASH-SIZE: 1.5
15. REHASH-THRESHOLD: 1.0
16. %COUNT: 6
17. NEXT-FREE-KV: 7
 > q

; No value
CL-USER>

Richard M Kreuter writes:
> So the original point of variable binding rules could not have had to do
> with pretty printing.

This was an editing mistake. "...could not have had to do with pretty
printer functions."

(The printer control variable requirements & prohibitions rules have to
do with pretty printing in that no FORMAT directive is allowed to rebind
*PRINT-PRETTY* except as specified. I believe only ~W does.)

Douglas Katzman <do...@go...> wrote:

> [ANSI] says that ~D,~B,~O,~X,~R (and others) rebind printer
> controls... [W]hat's the point of specifying mandatory rebindings if
> not to either permit or require user-written functions to take over
> the printing as per the print-pretty mechanism?

~D,~B,~O,~X,~nR print a non-integer argument "as by PRINC". So the
mandatory rebindings have an effect when the argument isn't an
integer. What if that was the only point?

In fact, the rules about variable rebinding were finalized months before
Waters's pretty printer was proposed (note the draft dates):

https://www.lispworks.com/documentation/HyperSpec/Issues/iss169_w.htm
https://www.lispworks.com/documentation/HyperSpec/Issues/iss270_w.htm

And before Waters's pretty printer, the variable binding rules could not
have had an observable effect on output from conforming programs' uses
of ~D,~O,~B,~X,~R when the argument is an integer.

So the original point of variable binding rules could not have had to do
with pretty printing. I don't think Waters's pretty printer compelled a
reinterpretation of the role of those rules, as I'll explain below.

(Candidly, I can't offer a rationale for every binding
FORMAT-PRETTY-PRINT required. Some seem unnecessary or redundant, and
the Cleanup committee thread looks like bikeshedding.)

Douglas Katzman <do...@go...> wrote:

> Based on some discussion here, I think we would be receptive to
> well-reasoned claims that ~D,~O,~B,~X "definitely" meant that a value
> is output exactly as specified in the writeup for that directive
> regardless of *print-pretty*, provided the value is an integer. I
> think the claim would be along the line that use of PRINC was merely a
> hidden detail of the implementation in some cases, not a mandate to
> use it, and that CLHS allows either interpretation of whether to
> respect *print-pretty* except in the case when PRINC _must_ be called
> due to the fallback to "~A" when the argument is not an
> integer. Something like that.

I'll stipulate I can't find anything in CLHS to disambiguate things.
However, I don't think the implemented behavior was intended or the
Right Thing for any directives that aren't required to invoke the
printer (~W, ~S, ~A, and ones that fall through to ~A).

I think intent is discoverable enough: Waters's XP, which was presented
as a reference implementation of the pretty printer interface, only
invoked a pretty printer function for ~W, ~S, ~A. This code is neither
bug-free nor normative, but there's a long comment suggesting that his
handling of ~C,~D,~O,~B,~X,~R,~F,~E,~G,~$ was deliberate. So ISTM likely
that the reason his spec was silent about those directives is because he
intended their behavior to remain constant.

https://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/lang/lisp/code/io/xp/

What's more important is how/why that behavior could make sense.

The canonical use of the pretty printing interface is to construct
variants of the "vanilla" Lisp printer that produce extra whitespace &
perhaps style certain things interestingly. The Lisp printer is
parameterized by printer controls, and the entirety of a printed
representation customarily presents all objects as if under a constant
complement of printer control settings. FORMAT directives that present
an atom force styling that disagrees with the Lisp printer: each of
~C,~D,~O,~B,~X,~R,~A,~S, overrule some printer control variable, and
each of ~F,~E,~G,~$ is able to disagree with PRIN1 for some float. So
canonical pretty printer applications won't use these directives very
much. (I believe SBCL's pretty printer has just one use: ~D for an
array's rank. More on that below.)

If canonical uses won't involve ~C,~D,~O,~B,~X,~R,~F,~E,~G,~$, why have
them invoke pretty printer functions? And if there are other,
non-canonical applications (like Robert's) that could use
~C,~D,~O,~B,~X,~R,~F,~E,~G,~$ for their standard styling effects, isn't
it more convenient for the user not to have to worry about regress? That
is, making ~C,~D,~O,~B,~X,~R,~F,~E,~G,~$ "base cases" seems to be a pure
win over the status quo.

Moreover, making ~C,~D,~O,~B,~X,~R,~F,~E,~G,~$ base cases would
eliminate some head-scratchers for users of SBCL. One head-scratcher is
how to decide who's at fault here and what to do about it:

  * (let ((*print-pretty* t)
        (*print-pprint-dispatch* (copy-pprint-dispatch nil)))
      (set-pprint-dispatch
       'integer (lambda (s i) i (write-string "AAA" s)))
      (time (sleep 1)))
  Evaluation took:
    AAA.00AAA seconds of real time
    0.000AAA seconds of total run time (0.0000AAA user, 0.000AAA system)
    0.10% CPU
    AAA forms interpreted
    AAA processor cycles
    AAA bytes consed

A subtler head-scratcher is whether the fact that installing a custom
integer printer does /not/ break how the rank appears in the output of
(pprint (make-array '(2 2))) dependends on the head-scratcher that "~D"
only /sometimes/ invokes a pretty printer function.

Finally, and more abstractly, isn't it a more parsimonious
interpretation of the standard to say that a FORMAT directive is to
behave as if it invokes the Lisp printer only when the CLHS actually
says it is to do so?

Regards,
Richard

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
		     19th European Lisp Symposium

			Call for Participation

			    May 11-12 2026
		     Skład Długa, Kraków, Poland

	     https://www.european-lisp-symposium.org/2026
		    Sponsored by Keepit and SISCOG
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Important News
~~~~~~~~~~~~~~~

- Registration is now open
- Keynotes announced
  Lambda: the Ultimate Paradigm -- François-René Rideau, Gerbil Scheme
  McCLIM and ECL -- Daniel Kochmański


Important Dates
~~~~~~~~~~~~~~~
- Early Registration Deadline:  May 03 2026
- Symposium:                    May 11-12 2026


Scope
~~~~~

The European Lisp Symposium is a premier forum for the discussion and
dissemination of all aspects of design, implementation, and
application of any of the Lisp dialects, including Common Lisp,
Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan,
SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so
on. We encourage everyone interested in Lisp to participate.

The European Lisp Symposium invites high quality papers about novel
research results, insights and lessons learned from practical
applications, and educational perspectives. We also encourage
submissions about known ideas as long as they are presented in a new
setting and/or in a highly elegant way.

Topics include but are not limited to:

- context-, aspect-, domain-oriented and generative programming
- macro-, reflective-, meta- and/or rule-based development approaches
- language design and implementation
- language integration, inter-operation, and deployment
- development methodologies, support, and environments
- educational approaches and perspectives
- experience reports and case studies


Programme Chair
~~~~~~~~~~~~~~~
Mark Evenson, ABCL.org, Austria


Organizing Chair
~~~~~~~~~~~~~~~~
Didier Verna, EPITA / LRE, France


Programme Committee
~~~~~~~~~~~~~~~~~~~
Alan Ruttenberg, USA
Dave Cooper, Genworks, USA
Dimitris Vyzovitis, Mighty Gerbils
Eitaro Fukamachi, Japan
Jason Hemann, Seton Hall University, USA
Kristopher Micinski, Syracuse University, USA
Marc Battyani, Enfabrica, USA
Mark David, USA
Michael Raskin, LaBRI, France
Robert Goldman, SIFT, USA
Thomas de Grivel, France


Local Chairs
~~~~~~~~~~~~
Wojciech Gac, Keepit, Poland
Michał Herda, Keepit, Poland


Virtualization Team
~~~~~~~~~~~~~~~~~~~
Georgiy Tugai, Configura, Sweden
Yukari Hafner, Shirakumo.org, Switzerland

-- 
Resistance is futile. You will be jazzimilated.

Lisp, Jazz, Aïkido: http://www.didierverna.info

Putting either '--without-immobile-space' or '--with-mark-region-gc' in the
make.sh invocation will produce a build of SBCL that does not rely on
SIGSEGV.