Menu
▾
▴
sbcl-help — Support channel for SBCL users and bug-reports.
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(8) |
Jun
|
Jul
(2) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
(2) |
Sep
(3) |
Oct
|
Nov
|
Dec
(8) |
| 2003 |
Jan
(5) |
Feb
(4) |
Mar
(14) |
Apr
|
May
(27) |
Jun
(10) |
Jul
(3) |
Aug
(28) |
Sep
(27) |
Oct
(3) |
Nov
(14) |
Dec
(19) |
| 2004 |
Jan
(32) |
Feb
(15) |
Mar
(21) |
Apr
(69) |
May
(18) |
Jun
(15) |
Jul
(23) |
Aug
(14) |
Sep
(38) |
Oct
(20) |
Nov
(76) |
Dec
(27) |
| 2005 |
Jan
(24) |
Feb
(32) |
Mar
(39) |
Apr
(65) |
May
(69) |
Jun
(37) |
Jul
(32) |
Aug
(28) |
Sep
(28) |
Oct
(17) |
Nov
(30) |
Dec
(24) |
| 2006 |
Jan
(45) |
Feb
(38) |
Mar
(19) |
Apr
(26) |
May
(19) |
Jun
(29) |
Jul
(13) |
Aug
(26) |
Sep
(53) |
Oct
(46) |
Nov
(40) |
Dec
(85) |
| 2007 |
Jan
(45) |
Feb
(51) |
Mar
(69) |
Apr
(48) |
May
(75) |
Jun
(35) |
Jul
(35) |
Aug
(25) |
Sep
(11) |
Oct
(16) |
Nov
(9) |
Dec
(59) |
| 2008 |
Jan
(36) |
Feb
(17) |
Mar
(28) |
Apr
(13) |
May
(1) |
Jun
(25) |
Jul
(24) |
Aug
(52) |
Sep
(19) |
Oct
(52) |
Nov
(43) |
Dec
(80) |
| 2009 |
Jan
(33) |
Feb
(30) |
Mar
(18) |
Apr
(15) |
May
(29) |
Jun
(58) |
Jul
(48) |
Aug
(35) |
Sep
(52) |
Oct
(59) |
Nov
(46) |
Dec
(31) |
| 2010 |
Jan
(26) |
Feb
(45) |
Mar
(55) |
Apr
(59) |
May
(8) |
Jun
(24) |
Jul
(43) |
Aug
(31) |
Sep
(43) |
Oct
(33) |
Nov
(41) |
Dec
(19) |
| 2011 |
Jan
(17) |
Feb
(31) |
Mar
(5) |
Apr
(31) |
May
(17) |
Jun
(28) |
Jul
(15) |
Aug
(38) |
Sep
(21) |
Oct
(25) |
Nov
(21) |
Dec
(21) |
| 2012 |
Jan
(9) |
Feb
(22) |
Mar
(17) |
Apr
(16) |
May
(58) |
Jun
(13) |
Jul
(40) |
Aug
(12) |
Sep
(10) |
Oct
(10) |
Nov
(14) |
Dec
(4) |
| 2013 |
Jan
(9) |
Feb
(8) |
Mar
(17) |
Apr
(10) |
May
|
Jun
(9) |
Jul
(1) |
Aug
(7) |
Sep
(8) |
Oct
(22) |
Nov
(9) |
Dec
(6) |
| 2014 |
Jan
(30) |
Feb
(55) |
Mar
(38) |
Apr
(15) |
May
(7) |
Jun
(17) |
Jul
(15) |
Aug
(13) |
Sep
(21) |
Oct
(29) |
Nov
(7) |
Dec
(10) |
| 2015 |
Jan
(11) |
Feb
(19) |
Mar
(32) |
Apr
(17) |
May
(5) |
Jun
(3) |
Jul
(9) |
Aug
(7) |
Sep
(19) |
Oct
(3) |
Nov
(31) |
Dec
(23) |
| 2016 |
Jan
(11) |
Feb
(5) |
Mar
(8) |
Apr
(10) |
May
(15) |
Jun
(1) |
Jul
(11) |
Aug
(9) |
Sep
(11) |
Oct
(1) |
Nov
(26) |
Dec
(7) |
| 2017 |
Jan
(18) |
Feb
(19) |
Mar
(40) |
Apr
(6) |
May
(12) |
Jun
(1) |
Jul
(14) |
Aug
(21) |
Sep
(27) |
Oct
(22) |
Nov
(42) |
Dec
(3) |
| 2018 |
Jan
(9) |
Feb
(7) |
Mar
(31) |
Apr
(5) |
May
(7) |
Jun
|
Jul
(6) |
Aug
(34) |
Sep
(2) |
Oct
(8) |
Nov
(29) |
Dec
(7) |
| 2019 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(62) |
May
(18) |
Jun
(12) |
Jul
(30) |
Aug
(8) |
Sep
(4) |
Oct
(8) |
Nov
(6) |
Dec
(12) |
| 2020 |
Jan
(24) |
Feb
(4) |
Mar
(11) |
Apr
(16) |
May
(6) |
Jun
(59) |
Jul
(51) |
Aug
(18) |
Sep
(32) |
Oct
(19) |
Nov
(12) |
Dec
(29) |
| 2021 |
Jan
(11) |
Feb
(27) |
Mar
(30) |
Apr
(10) |
May
(29) |
Jun
(14) |
Jul
(10) |
Aug
(3) |
Sep
(12) |
Oct
(10) |
Nov
(18) |
Dec
(19) |
| 2022 |
Jan
(11) |
Feb
(8) |
Mar
(21) |
Apr
(30) |
May
(3) |
Jun
(2) |
Jul
(16) |
Aug
(9) |
Sep
(4) |
Oct
(2) |
Nov
(17) |
Dec
(10) |
| 2023 |
Jan
(16) |
Feb
(21) |
Mar
(42) |
Apr
(8) |
May
(7) |
Jun
(32) |
Jul
(3) |
Aug
(22) |
Sep
(11) |
Oct
(3) |
Nov
(16) |
Dec
(12) |
| 2024 |
Jan
(8) |
Feb
(15) |
Mar
(32) |
Apr
(31) |
May
(23) |
Jun
(51) |
Jul
(13) |
Aug
(19) |
Sep
(20) |
Oct
(15) |
Nov
(10) |
Dec
(11) |
| 2025 |
Jan
(38) |
Feb
(33) |
Mar
(18) |
Apr
(40) |
May
(14) |
Jun
(14) |
Jul
(10) |
Aug
|
Sep
|
Oct
(8) |
Nov
(22) |
Dec
(6) |
| 2026 |
Jan
(2) |
Feb
(39) |
Mar
(31) |
Apr
(47) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Douglas K. <do...@go...> - 2026-04-14 21:54:46
|
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
|
|
From: Douglas K. <do...@go...> - 2026-04-14 21:27:37
|
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 |
|
From: Andreas F. <a.f...@gm...> - 2026-04-14 21:20:21
|
<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> |
|
From: Douglas K. <do...@go...> - 2026-04-14 21:17:28
|
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. |
|
From: Andrew W. <aw...@gm...> - 2026-04-14 20:18:52
|
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 >> > |
|
From: Andrew W. <aw...@gm...> - 2026-04-14 19:15:53
|
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 > |
|
From: Christophe R. <cs...@ca...> - 2026-04-14 18:28:26
|
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 |
|
From: Andrew W. <aw...@gm...> - 2026-04-14 10:23:50
|
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 |
|
From: steve g. <sgo...@gm...> - 2026-04-13 00:46:28
|
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? |
|
From: steve g. <sgo...@gm...> - 2026-04-10 14:46:53
|
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))
|
|
From: steve g. <sgo...@gm...> - 2026-04-10 14:39:11
|
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>
|
|
From: Richard M K. <kr...@pr...> - 2026-04-09 10:38:53
|
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.) |
|
From: Richard M K. <kr...@pr...> - 2026-04-08 21:24:20
|
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 |
|
From: Didier V. <di...@di...> - 2026-04-07 14:42:53
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 |
|
From: Douglas K. <do...@go...> - 2026-04-06 05:46:49
|
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. |
|
From: Marco A. <mar...@un...> - 2026-04-04 14:40:02
|
Hi This is a funny PBCAK :) :) :) In general, I tend to use #| ... |# when commenting stuff out. The fact that CL balances these comments out is a boon. Cheers Marco On Fri, Apr 3, 2026 at 9:43 PM Christopher Stacy <cs...@dt...> 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. > > 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? > > > > _______________________________________________ > Sbcl-help mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-help > -- Marco Antoniotti, Professor, Director tel. +39 - 02 64 48 79 01 DISCo, University of Milan-Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY REGAINS: https://regains.disco.unimib.it/ |
|
From: Christopher S. <cs...@dt...> - 2026-04-04 01:43:16
|
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. 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? |
|
From: Stas B. <sta...@gm...> - 2026-04-04 01:23:35
|
But now you have more comments to comment out. On Sat, Apr 4, 2026 at 4:22 AM Christopher Stacy <cs...@dt...> wrote: > > PPS. > > Note to self: If you ever get to the point where you are commenting out > chunks of code to isolate a problem, don't forget to comment out the > comments that go with it. > |
|
From: Christopher S. <cs...@dt...> - 2026-04-04 01:22:24
|
PPS. Note to self: If you ever get to the point where you are commenting out chunks of code to isolate a problem, don't forget to comment out the comments that go with it. |
|
From: J. G. W. <ga...@te...> - 2026-04-03 21:17:03
|
hi SBCL devs, About a year ago I kicked off a thread https://sourceforge.net/p/sbcl/mailman/sbcl-help/thread/CALfqwAo0OFGU0TYntX1Bzqm0WQe_4SUG2rUUFQGOGhFUW4UO2Q%40mail.gmail.com/#msg59163647) in which I learned that the GC relies on SIGSEGV, but that this mechanism has largely but not completely been removed. It looks like SEGV is still used at least as of 2.6.0 or so. I found a work-around in my application to accommodate this scheme, but it's a bit awkward. So my questions are: - is it still in the cards to complete this work? - is it a significant task? - any other users out there interested in seeing this? - would this be something that would be reasonable for someone completely-unfamiliar with the codebase to tackle? Any insight appreciated! Gareth |
|
From: Christopher S. <cs...@dt...> - 2026-04-03 20:44:58
|
On 4/3/26 11:48 AM, Stas Boukarev wrote: /paraphrasing: maybe turn on debugging?/ Ladies and Gentlemen, We Have A Winner. Stas Boukarev! /(* In the unlikely event you didn't already know he was a winner....)/ I was about to go see if ASDF had a keyword that turns on those flags, but then his suggestion came in and I just went and set them like Stas suggested. Probably more reliable that way, anyway. Thank You, Stas. The problem was then solved and fixed in the source code in under 3 seconds after seeing the verbose compiler output. I can't believe how dumb this one is. And now that I think back, I /have/ seen something like it before, although I can't remember the exact details. (It might have even been this same thing. Too long ago, but rings a bell.) The lesson here is to think of simple things, when very fundamental things seem inexplicably borked. This is a personal vulnerability of mine, and not the first time I have fallen victim to myself this way. A CLOS method doesn't work and my first thought is: "Did I forget something about CLOS?" Followed by: "No, it's supposed to work like I think. So... is CLOS broken?" And I begin imagining all the things that could go wrong based on every CLOS implementation I ever looked at. Most of which are based on PCL, and none of which I've truly studied in depth (ie. not to the point I could re-create them just off the top of my head). The mind whirls. Then it quickly turns to contamination of the compile-time environment, and I go looking for anything I (or any libraries) might have possibly done to mess that up. Or maybe there is a bug in the compiler itself. Down all the rabbit holes of disbelief and panic. Even though the whole time, I am thinking, "Chris, you idiot, this has to be something you did, and it's probably simple." But there's too much bias about it being a bug, and I just don't SEE anything wrong with my code. I've looked at this code a hundred times and haven't seen anything wrong with it! Ahem. In my lame defense, the last time I reported a bug in a CLOS implementation -- a case similar to this -- it was in fact the CLOS implementation that was quite broken. But don't worry, that was in emacs-lisp. Back when I was originally hoping to have cross-compatibility. And it was part of this same project. I got pretty far there but eventually punted to CL-only. And I guess that experience was a factor in my bias this time. Now we know the bug is here. That it has taken human form. Somehow, cstacy must convince a disbelieving world that the nightmare has already begun. Have you guessed what it was, yet? If not, here's the big hint: I am on a standard American QWERTY keyboard. Second huge hint: It is SOooo obvious, and I did actually already look for a much more complex, but even more obvious, similar mistake. Not finding that, I didn't think of the most trivial version. Because I was looking for something intentional I might have done wrong. Rather than something I never remotely intended. READ this far, and still don't know what it was? I am ambivalent about eliciting an educational list of responses on this mailing list, so I will spill the beans here. (Too bad there's no reasonable way to cover this up and uncover it with a click.) I'll just leave you with the following quote: ;; This next piece of code is tricky. '; Here it comes. ;; You'll love this. (wtf) Thanks again! PS. Would a text-based language's compiler (or linter) have noticed this mistake, where Lisp doesn't see it because of READ? |
|
From: Stas B. <sta...@gm...> - 2026-04-03 17:52:00
|
These are unrelated internal things. Better use the slime inspector. On Fri, Apr 3, 2026 at 8:46 PM Jacek Podkanski via Sbcl-help <sbc...@li...> 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? > _______________________________________________ > Sbcl-help mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-help |
|
From: Douglas K. <do...@go...> - 2026-04-03 17:50:36
|
On Fri, Apr 3, 2026 at 1:46 PM Jacek Podkanski via Sbcl-help < sbc...@li...> wrote: > How am I supposed to understand it? > Increase SB-IMPL::*INSPECT-LENGTH* |
|
From: Jacek P. <rub...@go...> - 2026-04-03 17:45:42
|
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? |
|
From: Jacek P. <rub...@go...> - 2026-04-03 16:34:17
|
I found the solution
---------- Forwarded message ---------
From: Jacek Podkanski <rub...@go...>
Date: Fri, 3 Apr 2026 at 16:35
Subject: Re: [Sbcl-help] how to solve <<error printing object>>
To: Dave Tenny <dav...@pr...>
After all it was not a problem with circular objects, but with optional
objects.
Do I need a macro for such situations?
(defmethod print-object ((obj male) stream)
(print-unreadable-object (obj stream :type t :identity t)
(format stream "~a"
(list :name (~> obj name)
:mother (let ((mother (mother obj))) (when mother (name
mother)))
:father (let ((father (father obj))) (when father
(name father)))
:children (loop for c in (~> obj children) collect (~> c
name))
:wives (loop for w in (~> obj wives) collect (~> w
name))
))))
I needed both special variables to understand the problem.
(setf *break-on-signals* T)
(setf *print-circle* T)
On Thu, 2 Apr 2026 at 04:20, Jacek Podkanski <rub...@go...>
wrote:
> Its 92 lines of code.
>
> running it in REPL
> (load "~/Programming/Lisp/lispy-experiments/clos-family.lisp")
> (in-package :clos-family)
> (experiment)
> --------------------- code ----------------------------------
>
> (declaim (optimize (speed 1) (safety 3) (debug 3)))
>
> (eval-when (:compile-toplevel :load-toplevel :execute)
> (ql:quickload '(:alexandria :serapeum :defclass-std)))
>
> (defpackage :clos-family
> (:import-from :serapeum :~>)
> (:import-from :defclass-std :defclass/std)
> (:use #:cl))
>
> ;; (load "~/Programming/Lisp/lispy-experiments/clos-family.lisp")
> (in-package :clos-family)
>
> (defparameter *next-id* 0)
> (defparameter *arbs* (make-hash-table))
>
> ;;;
> ============================================================================
> ;;; === classes
> ================================================================
> (defclass/std arb ()
> ((id)))
>
> (defclass/std person (arb)
> ((name :type string)
> (mother)
> (father)
> (children)))
>
> (defclass/std male (person)
> ((wives)))
>
> (defclass/std female (person)
> ((husband)))
>
> ;;; === methods =========================
>
> ;; these print object methods cause problems -------------------------
>
> (defmethod print-object ((obj male) stream)
> (print-unreadable-object (obj stream :type t :identity t)
> (format stream "~a"
> (list :name (~> obj name)
> :mother :todo ;; (~> obj mother name)
> :father :todo ;; (~> obj father name)
> :children :todo ;;(loop for c in (~> obj children)
> collect (~> c name))
> :wives :todo (loop for w in (~> obj wives) collect
> (~> w name))
> ))))
>
> (defmethod print-object ((obj female) stream)
> (print-unreadable-object (obj stream :type t :identity t)
> (format stream "~a"
> (list :name (~> obj name)
> :mother :todo ;; (~> obj mother name)
> :father :todo ;; (~> obj father name)
> :children :todo ;; (loop for c in (~> obj children)
> collect (~> c name))
> :husband :todo
> ;; (name (husband obj))
> ))))
>
> (defmethod initialize-instance :after ((obj arb) &key)
> (let ((new-id (incf *next-id*)))
> (setf (~> obj id) new-id)
> (setf (gethash new-id *arbs*) obj)))
>
> (defmethod marry ((groom male) (bride female))
> (let ((husband groom)
> (wife bride))
> (setf (~> wife husband) husband)
> (setf (~> husband wives) (cons wife (~> husband wives)))))
>
> (defmethod give-birth-male ((father male) (mother female) name)
> (let ((child (make-instance 'male :name name :mother mother :father
> father)))
> (pushnew child (~> father children))
> (pushnew child (~> mother children))))
>
> (defmethod give-birth-female ((father male) (mother female) name)
> (let ((child (make-instance 'female :name name :mother mother :father
> father)))
> (pushnew child (~> father children))
> (pushnew child (~> mother children))))
>
> ;; (experiment)
> (defun experiment ()
> (let ((aaa *arbs*))
> (setf *break-on-signals* T)
> (let ((abraham (make-instance 'male :name "Abraham"))
> (sarah (make-instance 'female :name "Sarah"))
> (hagar (make-instance 'female :name "Hagar")))
> (marry abraham sarah)
> (marry abraham hagar)
> (give-birth-male abraham hagar "Ishmael")
> (give-birth-male abraham sarah "Isaac")
>
> (break "examine arbs ~S" aaa)))
> ;; end
> )
>
> On Thu, 2 Apr 2026 at 04:09, Dave Tenny via Sbcl-help <
> sbc...@li...> wrote:
>
>> Is there more to the error? For example, I had an error printing objects
>> the other day because I it was from a thread in which bt2:make-thread
>> defaults *print-readably* to T, and my print-object methods were printing
>> unreadable objects.
>> On 4/1/26 8:13 PM, Jacek Podkanski via Sbcl-help wrote:
>>
>> setting *print-circle* to T did not work
>>
>> On Thu, 2 Apr 2026 at 00:44, Jacek Podkanski <rub...@go...>
>> wrote:
>>
>>> I was able to make progress with replacing slot values with todos, but
>>> still do not know how to fix such problems
>>>
>>> (defmethod print-object ((obj male) stream)
>>> (print-unreadable-object (obj stream :type t :identity t)
>>> (format stream "bbbb ~a"
>>> (list :name :todo ;; (~> obj name)
>>> :mother :todo ;; (~> obj mother name)
>>> :father :todo ;; (~> obj father name)
>>> :children :todo ;; (loop for c in (~> obj children)
>>> collect (~> c name))
>>> :wives :todo ;; (loop for w in (~> obj wives)
>>> collect (~> w name))
>>> ))))
>>>
>>> On Thu, 2 Apr 2026 at 00:40, Jacek Podkanski <rub...@go...>
>>> wrote:
>>>
>>>> I am looking for guidelines on solving <<error printing object>>
>>>> error.
>>>>
>>>> I am trying to learn CLOS parts related to relationships between
>>>> objects.
>>>>
>>>> I tried to model ancient family relations where some lived in
>>>> monogamous and some polygamous relationships. And it's not simple.
>>>>
>>>> I suspect there is going in circles involved, but I have no idea how to
>>>> solve it.
>>>>
>>>> I can provide full source if needed.
>>>>
>>>> ;;; === classes =================
>>>> (defclass/std arb ()
>>>> ((id)))
>>>>
>>>> (defclass/std person (arb)
>>>> ((name :type string)
>>>> (mother)
>>>> (father)
>>>> (children)))
>>>>
>>>> (defclass/std male (person)
>>>> ((wives)))
>>>>
>>> _______________________________________________
>> Sbcl-help mailing list
>> Sbc...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>>
>
|
104 messages has been excluded from this view by a project administrator.
