Re: Problem with SBCL pprint

Robert Goldman <[email protected]> Fri, 27 Mar 2026 17:17:42 -0500
Newsgroups gmane.lisp.steel-bank.general
Message-ID <[email protected]>
--===============4392431416683983723==
Content-Type: multipart/alternative;
 boundary="=_MailMate_D1CF4215-2E07-442C-BCA5-B16CE39A57B1_="
Content-Transfer-Encoding: 8bit


--=_MailMate_D1CF4215-2E07-442C-BCA5-B16CE39A57B1_=
Content-Type: text/plain; charset=UTF-8; format=flowed; markup=markdown
Content-Transfer-Encoding: 8bit

On 27 Mar 2026, at 15:55, Stas Boukarev wrote:

> You have
> (set-pprint-dispatch 'integer
>                      #'(lambda (str obj)
>                          (format str "~d" obj))
>                      0 *pddl-pprint-dispatch*)
>
> Which results in endless recursion.

I just retried the test with the `set-pprint-dispatch` calls for 
`integer` and `float` preceded by `#-sbcl`, but I am getting the same 
failure as before (possibly from a different cause).




Thank you very much, Stas!  Do you have any clue why this infinite 
recursion would be happening only in SBCL?
>
> On Fri, Mar 27, 2026 at 11:32 PM Robert Goldman 
> <[email protected]> wrote:
>>
>> Still working on my error. I have found a minimum case, and it's 
>> available here:
>>
>> https://github.com/rpgoldman/pddl-tools/pull/24
>>
>> This merge request gives instructions for replication. In summary, 
>> it's just sbcl --load "do-test.lisp"
>>
>> There's a relatively small file that is read and then pprinted. This 
>> causes a stack overflow on SBCL. On Allegro, it prints fine. There 
>> appears to be some sort of spurious proliferation of stack frames, 
>> which may indicate an actual bug in SBCL (or there's something 
>> standards-variant that Allegro and CCL do differently).
>>
>> I would never bet on my having found a bug in SBCL versus making some 
>> obscure mistake, though!
>>
>> _______________________________________________
>> Sbcl-help mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/sbcl-help

--=_MailMate_D1CF4215-2E07-442C-BCA5-B16CE39A57B1_=
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/xhtml; charset=3Dutf-8"=
>
</head>
<body><div style=3D"font-family: sans-serif;"><div class=3D"markdown" sty=
le=3D"white-space: normal;">
<p dir=3D"auto">On 27 Mar 2026, at 15:55, Stas Boukarev wrote:</p>
<blockquote style=3D"margin: 0 0 5px; padding-left: 5px; border-left: 2px=
 solid #777777; color: #777777;">
<p dir=3D"auto">You have<br>
(set-pprint-dispatch 'integer<br>
#'(lambda (str obj)<br>
(format str &quot;~d&quot; obj))<br>
0 <em>pddl-pprint-dispatch</em>)</p>
<p dir=3D"auto">Which results in endless recursion.</p>
</blockquote>
<p dir=3D"auto">I just retried the test with the <code style=3D"margin: 0=
 0; padding: 0 0.25em; border-radius: 3px; background-color: #F7F7F7;">se=
t-pprint-dispatch</code> calls for <code style=3D"margin: 0 0; padding: 0=
 0.25em; border-radius: 3px; background-color: #F7F7F7;">integer</code> a=
nd <code style=3D"margin: 0 0; padding: 0 0.25em; border-radius: 3px; bac=
kground-color: #F7F7F7;">float</code> preceded by <code style=3D"margin: =
0 0; padding: 0 0.25em; border-radius: 3px; background-color: #F7F7F7;">#=
-sbcl</code>, but I am getting the same failure as before (possibly from =
a different cause).</p>
<p dir=3D"auto">Thank you very much, Stas!  Do you have any clue why this=
 infinite recursion would be happening only in SBCL?</p>
<blockquote style=3D"margin: 0 0 5px; padding-left: 5px; border-left: 2px=
 solid #777777; color: #777777;">
<p dir=3D"auto">On Fri, Mar 27, 2026 at 11:32=E2=80=AFPM Robert Goldman <=
a href=3D"mailto:[email protected]" style=3D"color: #777777;">rpgoldman=
@sift.info</a> wrote:</p>
<blockquote style=3D"margin: 0 0 5px; padding-left: 5px; border-left: 2px=
 solid #777777; border-left-color: #999999; color: #999999;">
<p dir=3D"auto">Still working on my error. I have found a minimum case, a=
nd it's available here:</p>
<p dir=3D"auto"><a href=3D"https://github.com/rpgoldman/pddl-tools/pull/2=
4" style=3D"color: #999999;">https://github.com/rpgoldman/pddl-tools/pull=
/24</a></p>
<p dir=3D"auto">This merge request gives instructions for replication. In=
 summary, it's just sbcl --load &quot;do-test.lisp&quot;</p>
<p dir=3D"auto">There's a relatively small file that is read and then ppr=
inted. This causes a stack overflow on SBCL. On Allegro, it prints fine. =
There appears to be some sort of spurious proliferation of stack frames, =
which may indicate an actual bug in SBCL (or there's something standards-=
variant that Allegro and CCL do differently).</p>
<p dir=3D"auto">I would never bet on my having found a bug in SBCL versus=
 making some obscure mistake, though!</p>
<hr style=3D"border: 0; height: 1px; background: #333; background-image: =
linear-gradient(to right, #ccc, #333, #ccc);">
<p dir=3D"auto">Sbcl-help mailing list<br>
<a href=3D"mailto:[email protected]" style=3D"color: #99999=
9;">[email protected]</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/sbcl-help" style=3D=
"color: #999999;">https://lists.sourceforge.net/lists/listinfo/sbcl-help<=
/a></p>
</blockquote>
</blockquote>

</div>
</div>
</body>

</html>

--=_MailMate_D1CF4215-2E07-442C-BCA5-B16CE39A57B1_=--


--===============4392431416683983723==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============4392431416683983723==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Sbcl-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-help

--===============4392431416683983723==--