sbcl-devel — Development discussions.

Re: [Sbcl-devel] [PATCH] READ-SEQUENCE can get lost on bad UTF-8

[Stas B. <sta...@gm...>]

Applied. Thanks.

On Thu, Oct 16, 2025 at 12:01 PM Richard M Kreuter via Sbcl-devel
<sbc...@li...> wrote:
>
> The FD-STREAM-READ-SEQUENCE/UTF-8-TO-<foo> family and
> ANSI-STREAM-READ-SEQUENCE-FROM-FRC-BUFFER don't work right in the event
> of a resync or replacement restart.
>
> Small refactor, fix, and tests attached.
>
> _______________________________________________
> Sbcl-devel mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: [Sbcl-devel] replacement character (solved)

[<don...@is...>]

I can run the image used by the server on my laptop and it DOES show
the bug.
And a newer version just sent to the server does not show the bug.
So it's been fixed since 2.5.7.43 and I have a solution to my problem.

Re: [Sbcl-devel] replacement character out of order on network stream ?

[Stas B. <sta...@gm...>]

> Anyone have ideas how to find (or fix) the problem ?

Don't use the old sbcl version with the bug?

On Fri, Oct 17, 2025 at 4:54 AM Don Cohen
<don...@is...> wrote:
>
> Stas Boukarev writes:
>  > #\UD800 is an unencodable character, and it's replaced correctly.
>
> Ok, thanks.
> That does work on my laptop (abc?def) but not on the machine I'm using
> as a server.  So now the question is the difference between the two
> machines or lisp images.
>
> The machine showing the bug:
> * (lisp-implementation-version)
> "2.5.7.43-5a5f29c"
> $ uname -a
> Linux tw16 6.12.40-63.114.amzn2023.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Aug  7 19:30:51 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
> (amazon)
>
> The one not showing the bug:
> * (lisp-implementation-version)
> "2.5.9.50-d62fc4269"
> $ uname -a
> Linux number17.don-eve.org 6.16.10-100.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Oct  2 18:19:14 UTC 2025 x86_64 GNU/Linux
> (fedora 41)
>
> Is this replacement stuff actually done in lisp code?
> I could imagine it being in some c library.
>
> Anyone have ideas how to find (or fix) the problem ?

Re: [Sbcl-devel] replacement character out of order on network stream ?

[<don...@is...>]

Stas Boukarev writes:
 > #\UD800 is an unencodable character, and it's replaced correctly.

Ok, thanks.
That does work on my laptop (abc?def) but not on the machine I'm using
as a server.  So now the question is the difference between the two
machines or lisp images.

The machine showing the bug:
* (lisp-implementation-version)
"2.5.7.43-5a5f29c"
$ uname -a
Linux tw16 6.12.40-63.114.amzn2023.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Aug  7 19:30:51 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
(amazon)

The one not showing the bug:
* (lisp-implementation-version)
"2.5.9.50-d62fc4269"
$ uname -a
Linux number17.don-eve.org 6.16.10-100.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Oct  2 18:19:14 UTC 2025 x86_64 GNU/Linux
(fedora 41)

Is this replacement stuff actually done in lisp code?
I could imagine it being in some c library.

Anyone have ideas how to find (or fix) the problem ?

Re: [Sbcl-devel] replacement character out of order on network stream ?

[Stas B. <sta...@gm...>]

#\UD800 is an unencodable character, and it's replaced correctly.

On Fri, Oct 17, 2025 at 3:49 AM Don Cohen
<don...@is...> wrote:
>
> Stas Boukarev writes:
>  > There's no replacement going on.
>
> Ok, that's why you're not reproducing.
> Can you find a character that DOES get replaced?
> (How do you go about doing that?)
> I can't understand how the decision of what has to be replaced
> can depend on the machine.  That seems to break the compatibility
> which is the whole purpose of unicode, right?

Re: [Sbcl-devel] replacement character out of order on network stream ?

[<don...@is...>]

Stas Boukarev writes:
 > There's no replacement going on.

Ok, that's why you're not reproducing.
Can you find a character that DOES get replaced?
(How do you go about doing that?)
I can't understand how the decision of what has to be replaced
can depend on the machine.  That seems to break the compatibility
which is the whole purpose of unicode, right?

Re: [Sbcl-devel] replacement character out of order on network stream ?

[Stas B. <sta...@gm...>]

There's no replacement going on.

On Fri, Oct 17, 2025 at 3:22 AM Don Cohen
<don...@is...> wrote:
>
> Stas Boukarev writes:
>  > Unable to reproduce.
>
> When you tried to reproduce did you see the original character or the
> replacement?  I only see the out of order characters when a replacement
> is done.  And I couldn't reproduce on my laptop cause I didn't know how
> to find a character that would be replaced.  Do you know how to find
> such a character?  How does it depend on system?

Re: [Sbcl-devel] replacement character out of order on network stream ?

[<don...@is...>]

Stas Boukarev writes:
 > Unable to reproduce.

When you tried to reproduce did you see the original character or the
replacement?  I only see the out of order characters when a replacement
is done.  And I couldn't reproduce on my laptop cause I didn't know how
to find a character that would be replaced.  Do you know how to find
such a character?  How does it depend on system?

Re: [Sbcl-devel] replacement character out of order on network stream ?

[Stas B. <sta...@gm...>]

Unable to reproduce.

On Fri, Oct 17, 2025 at 2:37 AM Don Cohen
<don...@is...> wrote:
>
>
> The punch line below is that I do
>  (format stream1 "~a" (format nil "abc~cdef" #\UD38D))
> with replacement character ?
> expecting abc?def but instead I see ?abcdef.
> On another server that character doesn't seem to qualify for replacement.
> Is this a locale thing?  How do I find a character that should be replaced?
> In the case of the server that did replace it, finding such a character
> was unintentional.  The characters coming out of order caused an error.
>
> Also odd, when I do  (setf SB-EXT:*DEFAULT-EXTERNAL-FORMAT* :UTF-8)
> the character is sent - I expected an error.
>
> Any answers to any of these mysteries would be be appreciated.
>
> test case:
>
>   (setf SB-EXT:*DEFAULT-EXTERNAL-FORMAT* '(:UTF-8 :replacement #\?))
>   (setf listener (make-instance 'sb-bsd-sockets:inet-socket
>                                   :type :stream :protocol :tcp))
>   (sb-bsd-sockets:socket-bind listener  #(127 0 0 1) 5555)
>   (sb-bsd-sockets:socket-listen listener 10)
>   (setf socket (sb-bsd-sockets:socket-accept listener))
>   (setf stream1
>       (sb-bsd-sockets:socket-make-stream
>              socket :input t :output t :buffering :none))
>
> ;; telnet localhost 5555
>
>  (format stream1 "~a" (format nil "abc~cdef" #\UD38D))
>
> ;; => ?abcdef
>
>
> _______________________________________________
> Sbcl-devel mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel

[Sbcl-devel] replacement character out of order on network stream ?

[<don...@is...>]

The punch line below is that I do
 (format stream1 "~a" (format nil "abc~cdef" #\UD38D))
with replacement character ?
expecting abc?def but instead I see ?abcdef.
On another server that character doesn't seem to qualify for replacement.
Is this a locale thing?  How do I find a character that should be replaced?
In the case of the server that did replace it, finding such a character
was unintentional.  The characters coming out of order caused an error.

Also odd, when I do  (setf SB-EXT:*DEFAULT-EXTERNAL-FORMAT* :UTF-8)
the character is sent - I expected an error.

Any answers to any of these mysteries would be be appreciated.

test case:

  (setf SB-EXT:*DEFAULT-EXTERNAL-FORMAT* '(:UTF-8 :replacement #\?))
  (setf listener (make-instance 'sb-bsd-sockets:inet-socket
                                  :type :stream :protocol :tcp))
  (sb-bsd-sockets:socket-bind listener  #(127 0 0 1) 5555)
  (sb-bsd-sockets:socket-listen listener 10)
  (setf socket (sb-bsd-sockets:socket-accept listener))
  (setf stream1
      (sb-bsd-sockets:socket-make-stream
             socket :input t :output t :buffering :none))

;; telnet localhost 5555

 (format stream1 "~a" (format nil "abc~cdef" #\UD38D))
 
;; => ?abcdef

Re: [Sbcl-devel] [Sbcl-commits] master: Allow a chilled SBCL to read its sources

[Douglas K. <do...@go...>]

Is all the printing from the test useful to you or can it be silenced? e.g.

WARNING: SB-UNICODE also exports the following symbols:

  (SB-UNICODE:IDEOGRAPHIC-P SB-UNICODE:LOWERCASE SB-UNICODE:PROPLIST-P

                            SB-UNICODE:LINES SB-UNICODE:UPPERCASE-P

                            SB-UNICODE:UNICODE= SB-UNICODE:CASEFOLD

                            SB-UNICODE:DEFAULT-IGNORABLE-P
SB-UNICODE:CASED-P

....

[Sbcl-devel] [PATCH] READ-SEQUENCE can get lost on bad UTF-8

[Richard M K. <kr...@pr...>]

The FD-STREAM-READ-SEQUENCE/UTF-8-TO-<foo> family and
ANSI-STREAM-READ-SEQUENCE-FROM-FRC-BUFFER don't work right in the event
of a resync or replacement restart.

Small refactor, fix, and tests attached.

Re: [Sbcl-devel] Two trivial build & test nits

[Douglas K. <do...@go...>]

applied something like those. Thanks

Re: [Sbcl-devel] building the system with coverage instrumentation

[Stas B. <sta...@gm...>]

It says
(defknown (asin acos acosh atanh)
  (number) irrational
  (movable foldable flushable /recursive/))

so it thinks everything is fine.

On Tue, Oct 14, 2025 at 10:11 PM Christophe Rhodes <cs...@ca...> wrote:
>
> Stas Boukarev <sta...@gm...> writes:
>
> >> * building in this mode on x86-64 at least miscompiles ATANH -- you get
> >>   an infinite loop from self-calls.  I'm guessing that something isn't
> >>   being propagated through the coverage marker insertions?
> >>   (constraints?  types?)
>
> > Yes, (if (or ..)) becomes opaque to constraint propagation.
>
> Thanks for the fixes.  I'm slightly surprised that this one got through
> without triggering some internal assertion -- I thought we had some
> protection against compiling a full call to the same function while
> building the system (though they were tail calls so maybe that evades
> whatever check we have)?  (How would we know if there are any other
> functions that are also being miscompiled under these circumstances,
> that just happen not to be triggered by a consistency check in the final
> part of the build?)
>
> Christophe

Re: [Sbcl-devel] building the system with coverage instrumentation

[Christophe R. <cs...@ca...>]

Stas Boukarev <sta...@gm...> writes:

>> * building in this mode on x86-64 at least miscompiles ATANH -- you get
>>   an infinite loop from self-calls.  I'm guessing that something isn't
>>   being propagated through the coverage marker insertions?
>>   (constraints?  types?)

> Yes, (if (or ..)) becomes opaque to constraint propagation.

Thanks for the fixes.  I'm slightly surprised that this one got through
without triggering some internal assertion -- I thought we had some
protection against compiling a full call to the same function while
building the system (though they were tail calls so maybe that evades
whatever check we have)?  (How would we know if there are any other
functions that are also being miscompiled under these circumstances,
that just happen not to be triggered by a consistency check in the final
part of the build?)

Christophe

[Sbcl-devel] Two trivial build & test nits

[Richard M K. <kr...@pr...>]

Trivial patch attached.

1) I like to build with 'make.sh >build.log 2>&1'.  The "Computed
perfect hash" messages end up on the tty rather than that log file. IDK
if there's a reason why. Could those go to stdout or stderr?

2) One test in x86-64-codegen.impure.lisp expects not to find some stuff
that's present in #+sb-devel, so I figure it ought to be skipped.

Thanks,
Richard

Re: [Sbcl-devel] building the system with coverage instrumentation

[Stas B. <sta...@gm...>]

> * building in this mode on x86-64 at least miscompiles ATANH -- you get
>   an infinite loop from self-calls.  I'm guessing that something isn't
>   being propagated through the coverage marker insertions?
>   (constraints?  types?)
Yes, (if (or ..)) becomes opaque to constraint propagation.

Re: [Sbcl-devel] building the system with coverage instrumentation

[Stas B. <sta...@gm...>]

I pushed a fix for arm64.

On Mon, Oct 13, 2025 at 9:00 PM Christophe Rhodes via Sbcl-devel
<sbc...@li...> wrote:
>
> Hi,
>
> Following a month with a few nasty surprises in it (on which more
> later), I've been looking at some things which we could do which might
> improve confidence or drive some of our tools (test suite, random
> tester) in particular directions.  I think it would be interesting to
> have at least the option to build the system with coverage
> instrumentation enabled, so that we can gather data on which parts of
> the system are exercised -- and which are not -- from running the test
> suite (or an application, or whatever).
>
> <https://github.com/csrhodes/sbcl/tree/sb-cover-internals> is a first
> attempt at that.  It's not finished, but it does approximately work, and
> does approximately show me a report of which bits of the compiler are
> exercised during make-target-2.lisp, at least the loading part.  (That's
> not very interesting in and of itself but acts as proof of concept.)
>
> Broken bits are summarized in the commit message, but things I'm asking
> for help for in particular:
>
> * building in this mode on x86-64 at least miscompiles ATANH -- you get
>   an infinite loop from self-calls.  I'm guessing that something isn't
>   being propagated through the coverage marker insertions?
>   (constraints?  types?)
>
> * similarly, but more mysteriously to me, the build fails during
>   make-target-2 if it's built with --with-sb-show, with an invalid
>   fixup.  I don't understand why this would happen.
>
> * the build completely fails on ARM64 (according to the github actions)
>   with a surprising error message, apparently saying that something
>   which shouldn't be a string seems to have a string-like widetag during
>   fasl writing.
>
> (There are a lot of pieces of cosmetic improvements and robustification
> that could come after these, but I think of these three things as
> blockers and potentially at least worth looking into independent of the
> rest of the work.)
>
> Thanks,
>
> Christophe
>
>
> _______________________________________________
> Sbcl-devel mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel

[Sbcl-devel] building the system with coverage instrumentation

[Christophe R. <cs...@ca...>]

Hi,

Following a month with a few nasty surprises in it (on which more
later), I've been looking at some things which we could do which might
improve confidence or drive some of our tools (test suite, random
tester) in particular directions.  I think it would be interesting to
have at least the option to build the system with coverage
instrumentation enabled, so that we can gather data on which parts of
the system are exercised -- and which are not -- from running the test
suite (or an application, or whatever).

<https://github.com/csrhodes/sbcl/tree/sb-cover-internals> is a first
attempt at that.  It's not finished, but it does approximately work, and
does approximately show me a report of which bits of the compiler are
exercised during make-target-2.lisp, at least the loading part.  (That's
not very interesting in and of itself but acts as proof of concept.)

Broken bits are summarized in the commit message, but things I'm asking
for help for in particular:

* building in this mode on x86-64 at least miscompiles ATANH -- you get
  an infinite loop from self-calls.  I'm guessing that something isn't
  being propagated through the coverage marker insertions?
  (constraints?  types?)

* similarly, but more mysteriously to me, the build fails during
  make-target-2 if it's built with --with-sb-show, with an invalid
  fixup.  I don't understand why this would happen.

* the build completely fails on ARM64 (according to the github actions)
  with a surprising error message, apparently saying that something
  which shouldn't be a string seems to have a string-like widetag during
  fasl writing.

(There are a lot of pieces of cosmetic improvements and robustification
that could come after these, but I think of these three things as
blockers and potentially at least worth looking into independent of the
rest of the work.)

Thanks,

Christophe

Re: [Sbcl-devel] [Sbcl-commits] master: pcl: Revive compiler-less dfun code.

[Christophe R. <cs...@ca...>]

It would be really nice to have two things along with this:

* some tests that frob the internal special variable, so that even if
  this isn't generally supported, there's some ability to prevent or at
  least notice regressions;
* minimal documentation of what this is doing and why in doc/internals

(the "FIXME: what do these variables mean?" comment is now correct
again, for there being a plural number of mysterious variables)

Christophe

apache--- via Sbcl-commits <sbc...@li...> writes:

> The branch "master" has been updated in SBCL:
>        via  011c56b87119907fb6e86ddd3ceef857b3445aa1 (commit)
>       from  7d0694aec726b655495cbfd2b66787a5023af8bb (commit)
>
> - Log -----------------------------------------------------------------
> commit 011c56b87119907fb6e86ddd3ceef857b3445aa1
> Author: Charles Zhang <cha...@ya...>
> Date:   Mon Sep 29 16:39:07 2025 +0200
>
>     pcl: Revive compiler-less dfun code.
>     
>     This helps applications which do not want to call the compiler at
>     runtime (perhaps allowing for applications which strip the compiler
>     entirely) and also allows flexibility of bootstrapping more pcl code
>     earlier.
>     
>     Currently hidden behind an internal special variable which is always
>     nil, but could be part of a more general interface for controlling the
>     presence of the compiler.
> ---
>  src/cold/build-order.lisp-expr |   1 +
>  src/pcl/dlisp.lisp             |  32 +++++++++
>  src/pcl/dlisp2.lisp            | 143 +++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 176 insertions(+)
>
> diff --git a/src/cold/build-order.lisp-expr b/src/cold/build-order.lisp-expr
> index 5f4a3230d..2ecebf3eb 100644
> --- a/src/cold/build-order.lisp-expr
> +++ b/src/cold/build-order.lisp-expr
> @@ -667,6 +667,7 @@
>   ("src/pcl/fngen"
>    "src/pcl/cache"
>    "src/pcl/dlisp"
> +  "src/pcl/dlisp2"
>    "src/pcl/boot"
>    "src/pcl/vector"
>    "src/pcl/slots-boot"
> diff --git a/src/pcl/dlisp.lisp b/src/pcl/dlisp.lisp
> index cfa18326c..094ce8928 100644
> --- a/src/pcl/dlisp.lisp
> +++ b/src/pcl/dlisp.lisp
> @@ -157,8 +157,16 @@
>  
>  ;;; FIXME: What do these variables mean?
>  (defvar *precompiling-lap* nil)
> +(defvar *emit-function-p* t)
> +
> +;;; Should PCL call compile at runtime to optimize cache functions?
> +(defvar *optimize-cache-functions-p* t)
>  
>  (defun emit-default-only (metatypes applyp)
> +  (unless *optimize-cache-functions-p*
> +    (when (and (null *precompiling-lap*) *emit-function-p*)
> +      (return-from emit-default-only
> +        (emit-default-only-function metatypes applyp))))
>    (multiple-value-bind (lambda-list args rest-arg more-arg)
>        (make-dlap-lambda-list (length metatypes) applyp)
>      (generating-lisp '(emf)
> @@ -264,12 +272,23 @@
>        (:makunbound `(progn (setf ,read-form +slot-unbound+) ,(car arglist)))
>        (:writer `(setf ,read-form ,(car arglist))))))
>  
> +(defmacro emit-reader/writer-macro (reader/writer 1-or-2-class class-slot-p)
> +  (let ((*emit-function-p* nil)
> +        (*precompiling-lap* t))
> +    (values
> +     (emit-reader/writer reader/writer 1-or-2-class class-slot-p))))
> +
>  ;; If CACHED-INDEX-P is false, then the slot location is a constant and
>  ;; the cache holds layouts eligible to use that index.
>  ;; If true, then the cache is a map of layout -> index.
>  (defun emit-one-or-n-index-reader/writer (reader/writer
>                                            cached-index-p
>                                            class-slot-p)
> +  (unless *optimize-cache-functions-p*
> +    (when (and (null *precompiling-lap*) *emit-function-p*)
> +      (return-from emit-one-or-n-index-reader/writer
> +        (emit-one-or-n-index-reader/writer-function
> +         reader/writer cached-index-p class-slot-p))))
>    (multiple-value-bind (arglist metatypes)
>        (ecase reader/writer
>          ((:reader :boundp :makunbound)
> @@ -289,6 +308,14 @@
>                      (when cached-index-p 'index)
>                      (unless class-slot-p '(slots)))))))
>  
> +(defmacro emit-one-or-n-index-reader/writer-macro
> +    (reader/writer cached-index-p class-slot-p)
> +  (let ((*emit-function-p* nil)
> +        (*precompiling-lap* t))
> +    (values
> +     (emit-one-or-n-index-reader/writer reader/writer cached-index-p
> +                                        class-slot-p))))
> +
>  (defun emit-miss (miss-fn args applyp)
>    (if applyp
>        `(apply ,miss-fn ,@args .rest.)
> @@ -303,6 +330,11 @@
>  ;;  METATYPES must be acceptable to EMIT-FETCH-WRAPPER.
>  ;;  APPLYP says whether there is a &MORE context.
>  (defun emit-checking-or-caching (cached-emf-p return-value-p metatypes applyp)
> +  (unless *optimize-cache-functions-p*
> +    (when (and (null *precompiling-lap*) *emit-function-p*)
> +      (return-from emit-checking-or-caching
> +        (emit-checking-or-caching-function
> +         cached-emf-p return-value-p metatypes applyp))))
>    (multiple-value-bind (lambda-list args rest-arg more-arg)
>        (make-dlap-lambda-list (length metatypes) applyp)
>      (generating-lisp
> diff --git a/src/pcl/dlisp2.lisp b/src/pcl/dlisp2.lisp
> new file mode 100644
> index 000000000..523ddba54
> --- /dev/null
> +++ b/src/pcl/dlisp2.lisp
> @@ -0,0 +1,143 @@
> +;;;; This software is part of the SBCL system. See the README file for
> +;;;; more information.
> +
> +;;;; This software is derived from software originally released by Xerox
> +;;;; Corporation. Copyright and release statements follow. Later modifications
> +;;;; to the software are in the public domain and are provided with
> +;;;; absolutely no warranty. See the COPYING and CREDITS files for more
> +;;;; information.
> +
> +;;;; copyright information from original PCL sources:
> +;;;;
> +;;;; Copyright (c) 1985, 1986, 1987, 1988, 1989, 1990 Xerox Corporation.
> +;;;; All rights reserved.
> +;;;;
> +;;;; Use and copying of this software and preparation of derivative works based
> +;;;; upon this software are permitted. Any distribution of this software or
> +;;;; derivative works must comply with all applicable United States export
> +;;;; control laws.
> +;;;;
> +;;;; This software is made available AS IS, and Xerox Corporation makes no
> +;;;; warranty about the software, its performance or its conformity to any
> +;;;; specification.
> +
> +(in-package "SB-PCL")
> +
> +;;;; The whole of this file is dead code as long as *optimize-cache-functions-p*
> +;;;; is true, which it currently _always_ is.
> +
> +
> +(defun emit-reader/writer-function (reader/writer 1-or-2-class class-slot-p)
> +  (values
> +   (ecase reader/writer
> +     (:reader (ecase 1-or-2-class
> +                (1 (if class-slot-p
> +                       (emit-reader/writer-macro :reader 1 t)
> +                       (emit-reader/writer-macro :reader 1 nil)))
> +                (2 (if class-slot-p
> +                       (emit-reader/writer-macro :reader 2 t)
> +                       (emit-reader/writer-macro :reader 2 nil)))))
> +     (:writer (ecase 1-or-2-class
> +                (1 (if class-slot-p
> +                       (emit-reader/writer-macro :writer 1 t)
> +                       (emit-reader/writer-macro :writer 1 nil)))
> +                (2 (if class-slot-p
> +                       (emit-reader/writer-macro :writer 2 t)
> +                       (emit-reader/writer-macro :writer 2 nil)))))
> +     (:boundp (ecase 1-or-2-class
> +                (1 (if class-slot-p
> +                       (emit-reader/writer-macro :boundp 1 t)
> +                       (emit-reader/writer-macro :boundp 1 nil)))
> +                (2 (if class-slot-p
> +                       (emit-reader/writer-macro :boundp 2 t)
> +                       (emit-reader/writer-macro :boundp 2 nil)))))
> +     (:writer (ecase 1-or-2-class
> +                (1 (if class-slot-p
> +                       (emit-reader/writer-macro :makunbound 1 t)
> +                       (emit-reader/writer-macro :makunbound 1 nil)))
> +                (2 (if class-slot-p
> +                       (emit-reader/writer-macro :makunbound 2 t)
> +                       (emit-reader/writer-macro :makunbound 2 nil))))))
> +   nil))
> +
> +(defun emit-one-or-n-index-reader/writer-function
> +    (reader/writer cached-index-p class-slot-p)
> +  (values
> +   (ecase reader/writer
> +     (:reader (if cached-index-p
> +                  (if class-slot-p
> +                      (emit-one-or-n-index-reader/writer-macro :reader t t)
> +                      (emit-one-or-n-index-reader/writer-macro :reader t nil))
> +                  (if class-slot-p
> +                      (emit-one-or-n-index-reader/writer-macro :reader nil t)
> +                      (emit-one-or-n-index-reader/writer-macro :reader nil nil))))
> +     (:writer (if cached-index-p
> +                  (if class-slot-p
> +                      (emit-one-or-n-index-reader/writer-macro :writer t t)
> +                      (emit-one-or-n-index-reader/writer-macro :writer t nil))
> +                  (if class-slot-p
> +                      (emit-one-or-n-index-reader/writer-macro :writer nil t)
> +                      (emit-one-or-n-index-reader/writer-macro :writer nil nil))))
> +     (:boundp (if cached-index-p
> +                  (if class-slot-p
> +                      (emit-one-or-n-index-reader/writer-macro :boundp t t)
> +                      (emit-one-or-n-index-reader/writer-macro :boundp t nil))
> +                  (if class-slot-p
> +                      (emit-one-or-n-index-reader/writer-macro :boundp nil t)
> +                      (emit-one-or-n-index-reader/writer-macro :boundp nil nil))))
> +     (:makunbound (if cached-index-p
> +                      (if class-slot-p
> +                          (emit-one-or-n-index-reader/writer-macro :makunbound t t)
> +                          (emit-one-or-n-index-reader/writer-macro :makunbound t nil))
> +                      (if class-slot-p
> +                          (emit-one-or-n-index-reader/writer-macro :makunbound nil t)
> +                          (emit-one-or-n-index-reader/writer-macro :makunbound nil nil)))))
> +   nil))
> +
> +(defun emit-checking-or-caching-function (cached-emf-p return-value-p metatypes applyp)
> +  (values (emit-checking-or-caching-function-preliminary
> +           cached-emf-p return-value-p metatypes applyp)
> +          t))
> +
> +(defun emit-checking-or-caching-function-preliminary
> +    (cached-emf-p return-value-p metatypes applyp)
> +  (declare (ignore applyp))
> +  (if cached-emf-p
> +      (lambda (cache miss-fn)
> +        (declare (type function miss-fn))
> +        #'(lambda (&rest args)
> +            (declare #.*optimize-speed*)
> +            (with-dfun-wrappers (args metatypes)
> +              (dfun-wrappers invalid-wrapper-p)
> +              (apply miss-fn args)
> +              (if invalid-wrapper-p
> +                  (apply miss-fn args)
> +                  (multiple-value-bind (not-in-cache emf)
> +                      (probe-cache cache dfun-wrappers)
> +                    (if (eq emf not-in-cache)
> +                        (apply miss-fn args)
> +                        (if return-value-p
> +                            emf
> +                            (invoke-emf emf args))))))))
> +      (lambda (cache emf miss-fn)
> +        (declare (type function miss-fn))
> +        #'(lambda (&rest args)
> +            (declare #.*optimize-speed*)
> +            (with-dfun-wrappers (args metatypes)
> +              (dfun-wrappers invalid-wrapper-p)
> +              (apply miss-fn args)
> +              (if invalid-wrapper-p
> +                  (apply miss-fn args)
> +                  (let ((found-p (probe-cache cache dfun-wrappers)))
> +                    (if found-p
> +                        (invoke-emf emf args)
> +                        (if return-value-p
> +                            t
> +                            (apply miss-fn args))))))))))
> +
> +(defun emit-default-only-function (metatypes applyp)
> +  (declare (ignore metatypes applyp))
> +  (values (lambda (emf)
> +            (lambda (&rest args)
> +              (invoke-emf emf args)))
> +          t))
>
> -----------------------------------------------------------------------
>
>
> hooks/post-receive

Re: [Sbcl-devel] [PATCH] Two-way and echo forwarding of 6 misc ops

[Richard M K. <kr...@pr...>]

a.f...@gm... writes:
> > 3) Forward :CLEAR-OUTPUT, :FINISH-OUTPUT, :FORCE-OUTPUT only to the
> > output component. (This is not a change for two-way streams. Echo
> > streams used to forward to the output component.)
>
> Typo? ==> used to forward to the *input* component.

Good catch, and drat! (And I suppose it would have been more precise to
say that echo streams used to forward the 4 buffer operations to both
components, because all those operations return NIL.)

Thanks,
Richard

Re: [Sbcl-devel] [PATCH] Two-way and echo forwarding of 6 misc ops

[<a.f...@gm...>]

> 3) Forward :CLEAR-OUTPUT, :FINISH-OUTPUT, :FORCE-OUTPUT only to the
> output component. (This is not a change for two-way streams. Echo
> streams used to forward to the output component.)

Typo? ==> used to forward to the *input* component.

Re: [Sbcl-devel] [PATCH] Two-way and echo forwarding of 6 misc ops

[Stas B. <sta...@gm...>]

Applied. And I am aware of that failure.

On Sat, Oct 11, 2025 at 6:44 PM Richard M Kreuter <kr...@pr...> wrote:
>
> Attaching a commit that adds those tests to stream.impure.lisp.
>
> For completeness: the attached commit (but not the previous one I sent)
> got a failure in sb-simd on a Windows runner:
>
> https://github.com/kreuter/sbcl/actions/runs/18417100056/job/52483293212
>
> I can't fathom how an sb-simd failure could possibly be related to this
> stream change, so I haven't tried to debug it.
>
> Thanks,
> Richard
>
> Stas Boukarev writes:
> > stream.impure.lisp would be fine.
> >
> > On Fri, Oct 10, 2025 at 10:34=E2=80=AFPM Richard M Kreuter <kreuter@progn.n=
> > et> wrote:
> > >
> > > Sure; see attached. Let me know if you'd prefer a new tests file or
> > > additions to an existing one (stream.impure I imagine), and I'll redo it
> > > as a git commit. (Could also break things into finer-grained tests, if
> > > desired.)
> > >
> > > Thanks,
> > > Richard
> > >
> > > Stas Boukarev writes:
> > > > Would be nice to have tests.
> > > >
> > > > On Mon, Oct 6, 2025 at 11:14=3DE2=3D80=3DAFPM Richard M Kreuter via Sbc=
> > l-devel
> > > > <sbc...@li...> wrote:
> > > > >
> > > > > Hi folks,
> > > > >
> > > > > Can anybody see a reason why two-way and echo streams should do any o=
> > f
> > > > >
> > > > > a) forward :CHARPOS or :LINE-LENGTH to the input component?
> > > > >
> > > > > b) forward :CLEAR-INPUT to the output component?
> > > > >
> > > > > c) forward :CLEAR-OUTPUT, :FINISH-OUTPUT, :FORCE-OUTPUT to the input
> > > > >    component?
> > > > >
> > > > > d) disagree with each other about forwarding any of the above?
> > > > >
> > > > > While it's been this way literally forever in CMUCL, none of this pla=
> > ys
> > > > > nicely with Gray Streams, and (a) leads to almost-certainly unintende=
> > d
> > > > > output when an input component is bidirectional & returns non-NIL fro=
> > m
> > > > > :CHARPOS and/or :LINE-LENGTH, e.g.,
> > > > >
> > > > >   ;; Any bidirectional stream might do; all standard ones will.
> > > > >   (with-open-file (input "/dev/null" :direction :io :if-exists :overw=
> > rite=3D
> > > > )
> > > > >     ;; Or MAKE-ECHO-STREAM
> > > > >     (with-open-stream (stream (make-two-way-stream input *standard-ou=
> > tput=3D
> > > > *))
> > > > >       (format stream "~A~&~A" "abc" "xyz")))
> > > > >   abcxyz
> > > > >   ;; And analogous problems for FORMAT's tabulation & justification,
> > > > >   ;; pretty-printer layout decisions.
> > > > >
> > > > > AFAICT, none of Allegro, CCL, Clisp, ECL, or LispWorks seems to forwa=
> > rd
> > > > > these 6 operations to the component of the "other direction"; so thes=
> > e
> > > > > seem to be just inherited CMUCL weirdnesses.
> > > > >
> > > > > If the attached needs work or new tests, let me know? Passes all
> > > > > existing tests in GH CI.
> > > > >
> > > > > Thanks,
> > > > > Richard
> > > > >
> > > > > _______________________________________________
> > > > > Sbcl-devel mailing list
> > > > > Sbc...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/sbcl-devel
> > >
>

Re: [Sbcl-devel] [PATCH] Two-way and echo forwarding of 6 misc ops

[Richard M K. <kr...@pr...>]

Attaching a commit that adds those tests to stream.impure.lisp.

For completeness: the attached commit (but not the previous one I sent)
got a failure in sb-simd on a Windows runner:

https://github.com/kreuter/sbcl/actions/runs/18417100056/job/52483293212

I can't fathom how an sb-simd failure could possibly be related to this
stream change, so I haven't tried to debug it.

Thanks,
Richard

Stas Boukarev writes:
> stream.impure.lisp would be fine.
>
> On Fri, Oct 10, 2025 at 10:34=E2=80=AFPM Richard M Kreuter <kreuter@progn.n=
> et> wrote:
> >
> > Sure; see attached. Let me know if you'd prefer a new tests file or
> > additions to an existing one (stream.impure I imagine), and I'll redo it
> > as a git commit. (Could also break things into finer-grained tests, if
> > desired.)
> >
> > Thanks,
> > Richard
> >
> > Stas Boukarev writes:
> > > Would be nice to have tests.
> > >
> > > On Mon, Oct 6, 2025 at 11:14=3DE2=3D80=3DAFPM Richard M Kreuter via Sbc=
> l-devel
> > > <sbc...@li...> wrote:
> > > >
> > > > Hi folks,
> > > >
> > > > Can anybody see a reason why two-way and echo streams should do any o=
> f
> > > >
> > > > a) forward :CHARPOS or :LINE-LENGTH to the input component?
> > > >
> > > > b) forward :CLEAR-INPUT to the output component?
> > > >
> > > > c) forward :CLEAR-OUTPUT, :FINISH-OUTPUT, :FORCE-OUTPUT to the input
> > > >    component?
> > > >
> > > > d) disagree with each other about forwarding any of the above?
> > > >
> > > > While it's been this way literally forever in CMUCL, none of this pla=
> ys
> > > > nicely with Gray Streams, and (a) leads to almost-certainly unintende=
> d
> > > > output when an input component is bidirectional & returns non-NIL fro=
> m
> > > > :CHARPOS and/or :LINE-LENGTH, e.g.,
> > > >
> > > >   ;; Any bidirectional stream might do; all standard ones will.
> > > >   (with-open-file (input "/dev/null" :direction :io :if-exists :overw=
> rite=3D
> > > )
> > > >     ;; Or MAKE-ECHO-STREAM
> > > >     (with-open-stream (stream (make-two-way-stream input *standard-ou=
> tput=3D
> > > *))
> > > >       (format stream "~A~&~A" "abc" "xyz")))
> > > >   abcxyz
> > > >   ;; And analogous problems for FORMAT's tabulation & justification,
> > > >   ;; pretty-printer layout decisions.
> > > >
> > > > AFAICT, none of Allegro, CCL, Clisp, ECL, or LispWorks seems to forwa=
> rd
> > > > these 6 operations to the component of the "other direction"; so thes=
> e
> > > > seem to be just inherited CMUCL weirdnesses.
> > > >
> > > > If the attached needs work or new tests, let me know? Passes all
> > > > existing tests in GH CI.
> > > >
> > > > Thanks,
> > > > Richard
> > > >
> > > > _______________________________________________
> > > > Sbcl-devel mailing list
> > > > Sbc...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/sbcl-devel
> >

Re: [Sbcl-devel] [PATCH] Two-way and echo forwarding of 6 misc ops

[Stas B. <sta...@gm...>]

stream.impure.lisp would be fine.

On Fri, Oct 10, 2025 at 10:34 PM Richard M Kreuter <kr...@pr...> wrote:
>
> Sure; see attached. Let me know if you'd prefer a new tests file or
> additions to an existing one (stream.impure I imagine), and I'll redo it
> as a git commit. (Could also break things into finer-grained tests, if
> desired.)
>
> Thanks,
> Richard
>
> Stas Boukarev writes:
> > Would be nice to have tests.
> >
> > On Mon, Oct 6, 2025 at 11:14=E2=80=AFPM Richard M Kreuter via Sbcl-devel
> > <sbc...@li...> wrote:
> > >
> > > Hi folks,
> > >
> > > Can anybody see a reason why two-way and echo streams should do any of
> > >
> > > a) forward :CHARPOS or :LINE-LENGTH to the input component?
> > >
> > > b) forward :CLEAR-INPUT to the output component?
> > >
> > > c) forward :CLEAR-OUTPUT, :FINISH-OUTPUT, :FORCE-OUTPUT to the input
> > >    component?
> > >
> > > d) disagree with each other about forwarding any of the above?
> > >
> > > While it's been this way literally forever in CMUCL, none of this plays
> > > nicely with Gray Streams, and (a) leads to almost-certainly unintended
> > > output when an input component is bidirectional & returns non-NIL from
> > > :CHARPOS and/or :LINE-LENGTH, e.g.,
> > >
> > >   ;; Any bidirectional stream might do; all standard ones will.
> > >   (with-open-file (input "/dev/null" :direction :io :if-exists :overwrite=
> > )
> > >     ;; Or MAKE-ECHO-STREAM
> > >     (with-open-stream (stream (make-two-way-stream input *standard-output=
> > *))
> > >       (format stream "~A~&~A" "abc" "xyz")))
> > >   abcxyz
> > >   ;; And analogous problems for FORMAT's tabulation & justification,
> > >   ;; pretty-printer layout decisions.
> > >
> > > AFAICT, none of Allegro, CCL, Clisp, ECL, or LispWorks seems to forward
> > > these 6 operations to the component of the "other direction"; so these
> > > seem to be just inherited CMUCL weirdnesses.
> > >
> > > If the attached needs work or new tests, let me know? Passes all
> > > existing tests in GH CI.
> > >
> > > Thanks,
> > > Richard
> > >
> > > _______________________________________________
> > > Sbcl-devel mailing list
> > > Sbc...@li...
> > > https://lists.sourceforge.net/lists/listinfo/sbcl-devel
>