sbcl-help — Support channel for SBCL users and bug-reports.

Re: [Sbcl-help] who's using arm64/macos?

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

Yes.

On Sun, Oct 19, 2025 at 10:49 PM Andrew Wolven <aw...@gm...> wrote:
>
>
>
> On Sun, Oct 19, 2025 at 9:01 AM Stas Boukarev <sta...@gm...> wrote:
>>
>> I'm using it.
>>
>
> Does the profiler work?

Re: [Sbcl-help] who's using arm64/macos?

[Andrew W. <aw...@gm...>]

On Sun, Oct 19, 2025 at 9:01 AM Stas Boukarev <sta...@gm...> wrote:

> I'm using it.
>
>
Does the profiler work?

Re: [Sbcl-help] who's using arm64/macos?

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

I'm using it.

On Sun, Oct 19, 2025 at 5:00 PM Andrew Wolven <aw...@gm...> wrote:
>
> Hi,
> I just wanted to get an indication of how many folks are using SBCL on arm64/mac.  I'm considering investing in an M-chip mac finally after five years of them being out, and I was wanting to know if my preferred lisp has decent support on that platform.
>
> Thanks,
> Andrew Wolven
> _______________________________________________
> Sbcl-help mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help

[Sbcl-help] who's using arm64/macos?

[Andrew W. <aw...@gm...>]

Hi,
I just wanted to get an indication of how many folks are using SBCL on
arm64/mac.  I'm considering investing in an M-chip mac finally after five
years of them being out, and I was wanting to know if my preferred lisp has
decent support on that platform.

Thanks,
Andrew Wolven

Re: [Sbcl-help] sbcl for RISC-V?

[Faried N. <fa...@gm...>]

Douglas Katzman via Sbcl-help <sbc...@li...> writes:

> We need to see the specific errors rather than merely a report that it
> doesn't work
> I just built for risc-v at the latest commit. This was on cfarm95 on the
> gcc farm. cfarm94 which is Alpine doesn't compile the C runtime.

I used to build sbcl for a couple of years with "make.sh
--without-sb-thread" and a small change to riscv/parms.lisp, and it
would build and run the tests without crashing.  Now, if I build with
that flag, I end up at an ldb prompt during the build; without that
flag, I see the memory corruption for some of the tests (and the tests
end prematurely).

Part of this is probably self-inflicted, and I can move the discussion
to -devel.

First, the good news.  I can build 2.5.4 and 2.5.9 using 2.5.3.  2.5.3's
*features* is

(:RISCV :GENCGC :64-BIT :ANSI-CL :COMMON-LISP :ELF :IEEE-FLOATING-POINT :LINUX
 :LITTLE-ENDIAN :PACKAGE-LOCAL-NICKNAMES :SB-LDB :SB-PACKAGE-LOCKS :SB-THREAD
 :SB-UNICODE :SBCL :UNIX)

2.5.9's *features* is the same, as expected.

My build command:

git clean -fx && rm -fr obj/* output/* && git checkout sbcl-2.5.9 && sh ./make.sh

Neither 2.5.4 nor 2.5.9 will pass the tests (sh run-tests.sh) without
crashing.

For 2.5.4:

// Running /home/fn/repos/sbcl/tests/gethash-concurrency.pure.lisp in COMPILE evaluator mode
::: SKIPPED-BROKEN (HASH-TABLE :UNSYNCHRONIZED) Test broken on this platform
::: Running (HASH-TABLE :SYNCHRONIZED)
::: Success (HASH-TABLE :SYNCHRONIZED)
::: Running (HASH-TABLE :PARALLEL-READERS-EQ-TABLE)
CORRUPTION WARNING in SBCL pid 2041481 tid 2041549:
Memory fault at 0xd (pc=0x4fc99b58)
The integrity of this image is possibly compromised.
Exiting.
   0: [I]0x7fffa76ce8a0 pc=0x4fc99b58 {0x4fc993c0+0798} RANDOM
   1:     0x7fffa76ce7c0 pc=0x52036f80 {0x7fffa7acc7a0+aa56a7e0} {code_serialno=a7acd180}
   2:     0x7fffa76ce648 pc=0x4f03deb0
   3:     0x7fffa76ce4d0 pc=0x4f03ee20
   4:     0x7fffa76ce2f0 pc=0x4f03d7b0
   5:     0x7fffa76ce178 pc=0x4f03e520
   6:     0x7fffa76ce000 pc=0x4f03d310 {0x4100010+4af3d300} CORRUPTION WARNING in SBCL pid 2041481 tid 2041549:
Memory fault at 0x820002b (pc=0x5555698be90c)
The integrity of this image is possibly compromised.
Exiting.
test failed, expected 104 return code, got 1

2.5.9:

// Running /home/fn/repos/sbcl/tests/gethash-concurrency.pure.lisp in COMPILE evaluator mode
::: SKIPPED-BROKEN (HASH-TABLE :UNSYNCHRONIZED) Test broken on this platform
::: Running (HASH-TABLE :SYNCHRONIZED)
::: Success (HASH-TABLE :SYNCHRONIZED)
::: Running (HASH-TABLE :PARALLEL-READERS-EQ-TABLE)
CORRUPTION WARNING in SBCL pid 2043123 tid 2043277:
Memory fault at 0x7fffbae4d7d0 (pc=0x4fc9fa28)
The integrity of this image is possibly compromised.
Exiting.
   0: [I]0x7fffbb6448a0 pc=0x4fc9fa28 {0x4fc9f930+00f8} RANDOM
   1:     0x7fffbb6447c0 pc=0x510a1100 {0x7fffbba427b0+9565e950} {code_serialno=bba43180}
   2:     0x7fffbb644648 pc=0x4f03dda0
   3:     0x7fffbb6444d0 pc=0x4f03ee40
   4:     0x7fffbb6442f0 pc=0x4f03d690
   5:     0x7fffbb644178 pc=0x4f03e350
   6:     0x7fffbb644000 pc=0x4f03d2a0
Note: [I] = interrupted
test failed, expected 104 return code, got 1

parallel-readers-eql-table and parallel-readers-equal-table are marked
broken on riscv; what happens if i skip parallel-readers-eq-table by
marking it broken as well?  On 2.5.9, it fails immediately after that:

// Running /home/fn/repos/sbcl/tests/gethash-concurrency.pure.lisp in COMPILE evaluator mode
::: SKIPPED-BROKEN (HASH-TABLE :UNSYNCHRONIZED) Test broken on this platform
::: Running (HASH-TABLE :SYNCHRONIZED)
::: Success (HASH-TABLE :SYNCHRONIZED)
::: SKIPPED-BROKEN (HASH-TABLE :PARALLEL-READERS-EQ-TABLE)
    Test broken on this platform
::: SKIPPED-BROKEN (HASH-TABLE :PARALLEL-READERS-EQL-TABLE)
    Test broken on this platform
::: SKIPPED-BROKEN (HASH-TABLE :PARALLEL-READERS-EQUAL-TABLE)
    Test broken on this platform
::: Running (HASH-TABLE :SINGLE-ACCESSOR :PARALLEL-GC)
CORRUPTION WARNING in SBCL pid 2045003 tid 2045163:
Memory fault at 0x7fff885f5be0 (pc=0x4f371fc0)
The integrity of this image is possibly compromised.
Exiting.
   0: [I]0x7fff8983f870 pc=0x4f371fc0 {0x4f371f00+00c0} SB-IMPL::GETHASH/EQL-HASH
   1:     0x7fff8983f7c0 pc=0x51470bf0 {0x4f7b90c0+1cb7b30} CORRUPTION WARNING in SBCL pid 2045003 tid 2045163:
Memory fault at 0x9e801b37 (pc=0x555593935e06)
The integrity of this image is possibly compromised.
Exiting.
test failed, expected 104 return code, got 1

The failure is erratic; running "sh ./run-tests.sh gethash-concurrency.pure.lisp" works sometimes.

What about turning threading off?  I end up dropped into the debugger
during the build.  I've uploaded my 2.5.4 and 2.5.9 build outputs to

https://node.pk/tmp/sbcl-builds/

I typed "ba" at the ldb prompt and it didn't have a backtrace to print.
Unfortunately, my interaction with ldb wasn't captured in the build
files.

This is on a vendor distribution based on Debian sid; uname -a:

Linux rockos-eswin 6.6.66-win2030 #2025.01.14.09.00+4683e0f56 SMP Tue Jan 14 09:09:40 UTC 2025 riscv64 GNU/Linux

with libc6 2.40-3

No vector support on this processor (eswin 7700x), but it builds sbcl in
about 12 minutes (cfarm95 might be 30 minutes if it has the Spacemit K1
processor?).


Faried.

Re: [Sbcl-help] Callbacks to Lisp from C (and SIGSEGV handling)

[J. G. W. <ga...@te...>]

Necro'ing this thread...

I have been keeping an eye on releases for the removal of SIGSEGV from the
GC mechanism, but have not noticed any such?

Is it still on the timeline?

TIA,
Gareth

On Sat, Mar 22, 2025, 2:48 p.m. Douglas Katzman <do...@go...> wrote:

> There is restore_sbcl_signals() in the C runtime.  But using it sounds
> like a bad idea to me. Since signal handlers are not per-thread, there's no
> way to make this reliable. An SBCL-internal thread (of which there is at
> least one, but could be more) could do an operation that receives sigsegv
> while some random thread called the C thing that changed the handler. The
> SBCL thread will probably react badly to having the wrong handler called.
> On a more positive note, we are almost at the point where there is no need
> for sigsegv. Most of the so-called dynamic space does not use it.  I have
> to remove sigsegv for tracking writes to slots of symbols, and there's not
> a lot else. (One other object type, falling under "not a lot else").  Maybe
> by the next SBCL release (April, not the pending one), I can complete the
> work needed to confine use of sigsegv for actual faults and not "normal"
> activity.
>

Re: [Sbcl-help] sbcl for RISC-V?

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

We need to see the specific errors rather than merely a report that it
doesn't work
I just built for risc-v at the latest commit. This was on cfarm95 on the
gcc farm. cfarm94 which is Alpine doesn't compile the C runtime.

$ ./run-sbcl.sh

This is SBCL 2.5.9.29-92e807be9, an implementation of ANSI Common Lisp.

More information about SBCL is available at <http://www.sbcl.org/>.


SBCL is free software, provided as is, with absolutely no warranty.

It is mostly in the public domain; some portions are provided under

BSD-style licenses.  See the CREDITS and COPYING files in the

distribution for more information.

Missing required foreign symbol 'fun_end_breakpoint_trap'

Missing required foreign symbol 'fun_end_breakpoint_end'

Missing required foreign symbol 'fun_end_breakpoint_guts'

* *features*

(:RISCV :GENCGC :64-BIT :ANSI-CL :COMMON-LISP :ELF :IEEE-FLOATING-POINT
:LINUX

 :LITTLE-ENDIAN :PACKAGE-LOCAL-NICKNAMES :SB-LDB :SB-PACKAGE-LOCKS
:SB-THREAD

 :SB-UNICODE :SBCL :UNIX)

$ uname -a

Linux cfarm95 6.6.36-cfarm #1 SMP PREEMPT Sun Oct  6 18:27:25 UTC 2024
riscv64 GNU/Linux

On Fri, Oct 10, 2025 at 6:31 AM Faried Nawaz <fa...@gm...> wrote:

> James Cloos <cl...@jh...> writes:
>
> Unfortunately a change between 2.5.3 and 2.5.4 broke it.  I used git
> bisect to track it down to this commit:
> 66aca772c4b4a1b6c967800c7989518a62c4f4e0
>
> (It's in a series of commits; that's just the first one where it
> breaks.)
>
>
> Faried.
>
>
>
> _______________________________________________
> Sbcl-help mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>

Re: [Sbcl-help] sbcl for RISC-V?

[Faried N. <fa...@gm...>]

James Cloos <cl...@jh...> writes:

Unfortunately a change between 2.5.3 and 2.5.4 broke it.  I used git
bisect to track it down to this commit:
66aca772c4b4a1b6c967800c7989518a62c4f4e0

(It's in a series of commits; that's just the first one where it
breaks.)


Faried.

Re: [Sbcl-help] what's the correct behavior of directory-namestring

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

Michał "phoe" Herda <ph...@di...> wrote:

> W dniu 2025-07-31 14:14, Richard M Kreuter via Sbcl-help napisał(a):
> 
>     Correct in that Windows and Unix are different, but do you think it's
>     ideal for DIRECTORY-NAMESTRING to leave off the device for a Windows
>     pathname?
> 
> It is also correct because this is what DIRECTORY-NAMESTRING is defined to do
> - see 
> http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_namestrin_h-namestring.html
> . Returning the device in addition to the directory would violate the
> language specification.

I don't think this is so clear. The standard says

   DIRECTORY-NAMESTRING returns the directory name portion. 

ANSI doesn't define the phrase, "the directory name portion". How should
we interpret it? I'll agree it could mean "the namestring representation
of the directory component", but, y'know, the sentence doesn't mention
components, even though the immediately preceding sentence about
FILE-NAMESTRING does. Do the different constructions signify anything? I
suppose that's up to whoever's reading the standard.

In particular, I don't see an argument that the phrase cannot mean "the
portion of the pathname that names a directory (as in a specific thing
in the file system)". For an MS-DOS-style Windows pathname with a
non-NIL device, such as #P"Z:\\foo\\bar.txt", ISTM that each of
"Z:\\foo\\" and "\\foo\\ can be said to name a directory in the file
system, though the first one is a more precise name for the directory,
since the second one only sometimes refers to that particular
object. Anyhow, ISTM either string would be a valid result from
DIRECTORY-NAMESTRING, if that's how you understand "the directory name
portion".

> As for "ideal", what is the actual intent here? Get the whole
> namestring? # 'NAMESTRING will do fine in that case.

Well, you used the word "correct", and now I think you believe there's a
unique conforming answer to what

  (directory-namestring "z:\\foo\\bar.txt")

should return. I think there are multiple conforming options, and I'd
like to reserve "correct" to one conforming option that's better than
others. So I switched to "ideal". :-)

Specifically, ISTM that if you have "z:\\foo\\bar.txt", you might want
each of

(a) an operator that will get you "Z:\\foo\\",

(b) an operator that will get you just "\\foo\\".

If DIRECTORY-NAMESTRING is (a), (b) should probably just be

  (lambda (pn)
    (directory-namestring
     (make-pathname :device nil :defaults pn)))

That seems like a more useful arrangement than if DIRECTORY-NAMESTRING
is (b) and you need Windows-specific (and, unfortunately,
implementation-specific) code for (a), don't you think?

Finally, note that

  (lambda (pn)
    (namestring
     (make-pathname :name nil :type nil :version nil
                    :defaults pn)))

might conformingly produce a string containing a host, e.g.,
"localhost:Z:\\foo\\". So NAMESTRING isn't necessarily an ideal tool for
doing (a) or (b). I suspect that's why DIRECTORY-NAMESTRING and
FILE-NAMESTRING exist at all.

Regards,
Richard

P.S., In fact, I believe the phrase, "the directory name portion" got
into ANSI via a couple editing mistakes a few years apart. In CLtL,
DIRECTORY-NAMESTRING was defined as [1]:

  ... the result of DIRECTORY-NAMESTRING represents just the
  /directory-name/ portion; ...

That is, /directory-name/ was a hyphenated & italicized token, seemingly
intended as a defined term. But CLtL doesn't define it, and so, I guess,
some X3J13 editor de-jargonized it into two words in normal font.

Can we say what /directory-name/ might have meant as jargon? I think so:
the first two drafts of CLtL (Swiss Cheese, Aug 1981 [2] & Flat Iron,
Feb 1982 [3]) didn't have pathnames, but instead had Maclisp's namelist
representation for file names. A namelist had this structure (see page
238 in Swiss Cheese, or 248 in Flat Iron):

  ((host-name . directory-name) . file-name)

That is, /host-name/, /directory-name/, and /file-name/ are fields in
the namelist representation; and HOST-NAMESTRING, DIRECTORY-NAMESTRING,
and FILE-NAMESTRING were defined in terms of those fields in those
drafts. So DIRECTORY-NAMESTRING's original definition in Common Lisp
called for including the device in the string (when one was not missing;
namelists had a counterpart of NIL pathname component values).

Pathnames got into Common Lisp in the Colander draft (Jul
1982 [4]). Namelists were dropped, but DIRECTORY-NAMESTRING's definition was
not updated to use concepts in the pathname model, though
FILE-NAMESTRING's definition was. But nothing about the switchover from
namelists to pathnames compelled a change to the information included in
DIRECTORY-NAMESTRING's result: a roughly contemporaneous LispM manual
(1984) defines DIRECTORY-NAMESTRING as [5]:

  Returns a string showing just the device and directory of PATHNAME.

So I guess people who worked on CLtL either didn't notice the stray
undefined italicized jargon, or perhaps felt that some vagueness made
whatever their implementations already did legal, and left CLtL that
way. But I don't think DIRECTORY-NAMESTRING was intended to contain only
the directory component, though as I said above, I see how that's a
valid interpretation of how ANSI ended up.

[1] https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node214.html#SECTION002716000000000000000

[2] https://www.softwarepreservation.org/projects/LISP/common_lisp_family/cmu/Steele-CLRM-Swiss_Cheese-Aug_1981-Annotated.pdf

[3] https://www.softwarepreservation.org/projects/LISP/common_lisp_family/cmu/Steele-CLRM-Flat_Iron-Feb_1982-Annotated.pdf

[4] https://www.softwarepreservation.org/projects/LISP/common_lisp_family/cmu/Steele-CLRM-Colander-Jul_1982.pdf

[5] https://github.com/hanshuebner/lmman/blob/1bfe47e4cb47527558a42383ada01ff66b2ddb6b/pathnm.xml#L930

Re: [Sbcl-help] what's the correct behavior of directory-namestring

[Michał p. H. <ph...@di...>]

W dniu 2025-07-31 14:14, Richard M Kreuter via Sbcl-help napisał(a):

> Correct in that Windows and Unix are different, but do you think it's
> ideal for DIRECTORY-NAMESTRING to leave off the device for a Windows
> pathname?

It is also correct because this is what DIRECTORY-NAMESTRING is defined 
to do - see 
http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_namestrin_h-namestring.html. 
Returning the device in addition to the directory would violate the 
language specification.

As for "ideal", what is the actual intent here? Get the whole 
namestring? #'NAMESTRING will do fine in that case.

Re: [Sbcl-help] what's the correct behavior of directory-namestring

[Basile S. <ba...@st...>]

On Thu, 2025-07-31 at 08:14 -0400, Richard M Kreuter via Sbcl-help wrote:
> Michał Herda | Keepit via Sbcl-help wrote:
> 
> > It's not that neither is correct. It's worse - *both* are correct, and
> > correctness depends on context in this case.
> 
> Correct in that Windows and Unix are different, but do you think it's
> ideal for DIRECTORY-NAMESTRING to leave off the device for a Windows
> pathname?
> 

I am not very familiar with Windows, being a French open source developer on
Linux. I actually never coded on Windows, and used it only for bureaucratic
activities.

BTW I am coding a GPL licensed inference engine named RefPerSys. In C++; it has
lots of features in common with SBCL but don't use SBCL or its runtime.

(I am even seeking partnership like HorizonEurope on it).

Indeed the notion of directory is very different on Windows and on Linux. The
device name is strange (and AFAIK not immediately visible if using WSL on
Windows to run SBCL).

Regards.

-- 
Basile STARYNKEVITCH                            <ba...@st...>
8 rue de la Faïencerie                       http://starynkevitch.net/Basile/  
92340 Bourg-la-Reine                         https://github.com/bstarynk
France                                https://github.com/RefPerSys/RefPerSys

Re: [Sbcl-help] what's the correct behavior of directory-namestring

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

Michał Herda | Keepit via Sbcl-help wrote:

> It's not that neither is correct. It's worse - *both* are correct, and
> correctness depends on context in this case.

Correct in that Windows and Unix are different, but do you think it's
ideal for DIRECTORY-NAMESTRING to leave off the device for a Windows
pathname?

Regards,
Richard

Re: [Sbcl-help] what's the correct behavior of directory-namestring

[Marco A. <mar...@un...>]

Correctness or incorrectness is in the eye of the beholder :)

Problem is, "context" is not just Windows vs FreeBSD.  It is also SBCL vs
LW vs CCL etc etc.

Cheers

MA



On Thu, Jul 31, 2025 at 12:26 PM Michał Herda | Keepit <mh...@ke...>
wrote:

> It's not that neither is correct. It's worse - *both* are correct, and
> correctness depends on context in this case.
> ------------------------------
> *From:* Marco Antoniotti <mar...@un...>
> *Sent:* Thursday, July 31, 2025 9:33 AM
> *To:* Michał Herda | Keepit <mh...@ke...>
> *Cc:* Jinsong Zhao <js...@ye...>; sbc...@li... <
> sbc...@li...>
> *Subject:* Re: [Sbcl-help] what's the correct behavior of
> directory-namestring
>
> ... which means neither is correct :)
>
> Oh, the joys of pathname munging taking into account ITS and TOPS :)
>
> Cheers
>
> MA
>
>
> On Wed, Jul 30, 2025 at 10:20 AM Michał Herda | Keepit via Sbcl-help <
> sbc...@li...> wrote:
>
> Both are correct - the parsing of namestrings is different on Windows and
> Linux.
>
> Try (DESCRIBE #P"R:/Temp/abc/") on both Windows and Linux to see which
> pathname slots are populated, and how, on which OS.
> ------------------------------
> *From:* Jinsong Zhao <js...@ye...>
> *Sent:* Wednesday, July 30, 2025 8:23 AM
> *To:* sbc...@li... <sbc...@li...>
> *Subject:* [Sbcl-help] what's the correct behavior of directory-namestring
>
> [Some people who received this message don't often get email from
> js...@ye.... Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi there,
>
> I am using SBCL on Windows. I also have SBCL install on Debian Linux and
> FreeBSD.
>
> I have to deal with some pathnames, for example:
> #P"R:/Temp/abc/"
>
> When passing the pathname to directory-namestring in SBCL 2.5.7 on
> Windows, I got:
>
> * (directory-namestring #P"R:/Temp/abc/")
> "/Temp/abc/"
>
> SBCL 2.2.9 on Debian and 2.5.6 on FreeBSD, booth give:
>
> * (directory-namestring #P"R:/Temp/abc/")
> "R:/Temp/abc/"
>
> Which is the correct behavior?
>
> Best,
> Jinsong
>
>
>
> _______________________________________________
> Sbcl-help mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>
>
>
> This e-mail is sent to you from Keepit A/S. Dedicated SaaS Data Protection.
> VAT: DK30806883, Per Henrik Lings Allé 4, 7., DK-2100 Copenhagen Ø,
> Denmark.
>
> This e-mail is sent to you directly and is meant for nobody else. If the
> e-mail contains personal data that Keepit is responsible for and the e-mail
> was not meant for you, please do not forward, distribute, or copy, i.e. but
> return the e-mail to sender. Also, do not send the e-mail to a third party
> without making sure that you have our prior consent. Distribution of this
> e-mail to unauthorized receivers may have legal consequences.
> If you have received an e-mail from us and you don’t know why, then please
> refer to our Privacy Policy <https://www.keepit.com/privacy-policy/>.
> If you do not want to receive more e-mails from us, please contact
> bus...@ke....
> _______________________________________________
> 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/
>


-- 
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/

Re: [Sbcl-help] what's the correct behavior of directory-namestring

[Michał H. | K. <mh...@ke...>]

It's not that neither is correct. It's worse - *both* are correct, and correctness depends on context in this case.
________________________________
From: Marco Antoniotti <mar...@un...>
Sent: Thursday, July 31, 2025 9:33 AM
To: Michał Herda | Keepit <mh...@ke...>
Cc: Jinsong Zhao <js...@ye...>; sbc...@li... <sbc...@li...>
Subject: Re: [Sbcl-help] what's the correct behavior of directory-namestring

... which means neither is correct :)

Oh, the joys of pathname munging taking into account ITS and TOPS :)

Cheers

MA


On Wed, Jul 30, 2025 at 10:20 AM Michał Herda | Keepit via Sbcl-help <sbc...@li...<mailto:sbc...@li...>> wrote:
Both are correct - the parsing of namestrings is different on Windows and Linux.

Try (DESCRIBE #P"R:/Temp/abc/") on both Windows and Linux to see which pathname slots are populated, and how, on which OS.
________________________________
From: Jinsong Zhao <js...@ye...<mailto:js...@ye...>>
Sent: Wednesday, July 30, 2025 8:23 AM
To: sbc...@li...<mailto:sbc...@li...> <sbc...@li...<mailto:sbc...@li...>>
Subject: [Sbcl-help] what's the correct behavior of directory-namestring

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

Hi there,

I am using SBCL on Windows. I also have SBCL install on Debian Linux and
FreeBSD.

I have to deal with some pathnames, for example:
#P"R:/Temp/abc/"

When passing the pathname to directory-namestring in SBCL 2.5.7 on
Windows, I got:

* (directory-namestring #P"R:/Temp/abc/")
"/Temp/abc/"

SBCL 2.2.9 on Debian and 2.5.6 on FreeBSD, booth give:

* (directory-namestring #P"R:/Temp/abc/")
"R:/Temp/abc/"

Which is the correct behavior?

Best,
Jinsong



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



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

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

Re: [Sbcl-help] what's the correct behavior of directory-namestring

[Marco A. <mar...@un...>]

... which means neither is correct :)

Oh, the joys of pathname munging taking into account ITS and TOPS :)

Cheers

MA


On Wed, Jul 30, 2025 at 10:20 AM Michał Herda | Keepit via Sbcl-help <
sbc...@li...> wrote:

> Both are correct - the parsing of namestrings is different on Windows and
> Linux.
>
> Try (DESCRIBE #P"R:/Temp/abc/") on both Windows and Linux to see which
> pathname slots are populated, and how, on which OS.
> ------------------------------
> *From:* Jinsong Zhao <js...@ye...>
> *Sent:* Wednesday, July 30, 2025 8:23 AM
> *To:* sbc...@li... <sbc...@li...>
> *Subject:* [Sbcl-help] what's the correct behavior of directory-namestring
>
> [Some people who received this message don't often get email from
> js...@ye.... Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi there,
>
> I am using SBCL on Windows. I also have SBCL install on Debian Linux and
> FreeBSD.
>
> I have to deal with some pathnames, for example:
> #P"R:/Temp/abc/"
>
> When passing the pathname to directory-namestring in SBCL 2.5.7 on
> Windows, I got:
>
> * (directory-namestring #P"R:/Temp/abc/")
> "/Temp/abc/"
>
> SBCL 2.2.9 on Debian and 2.5.6 on FreeBSD, booth give:
>
> * (directory-namestring #P"R:/Temp/abc/")
> "R:/Temp/abc/"
>
> Which is the correct behavior?
>
> Best,
> Jinsong
>
>
>
> _______________________________________________
> Sbcl-help mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>
>
>
> This e-mail is sent to you from Keepit A/S. Dedicated SaaS Data Protection.
> VAT: DK30806883, Per Henrik Lings Allé 4, 7., DK-2100 Copenhagen Ø,
> Denmark.
>
> This e-mail is sent to you directly and is meant for nobody else. If the
> e-mail contains personal data that Keepit is responsible for and the e-mail
> was not meant for you, please do not forward, distribute, or copy, i.e. but
> return the e-mail to sender. Also, do not send the e-mail to a third party
> without making sure that you have our prior consent. Distribution of this
> e-mail to unauthorized receivers may have legal consequences.
> If you have received an e-mail from us and you don’t know why, then please
> refer to our Privacy Policy <https://www.keepit.com/privacy-policy/>.
> If you do not want to receive more e-mails from us, please contact
> bus...@ke....
> _______________________________________________
> 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/

Re: [Sbcl-help] what's the correct behavior of directory-namestring

[Michał H. | K. <mh...@ke...>]

Both are correct - the parsing of namestrings is different on Windows and Linux.

Try (DESCRIBE #P"R:/Temp/abc/") on both Windows and Linux to see which pathname slots are populated, and how, on which OS.
________________________________
From: Jinsong Zhao <js...@ye...>
Sent: Wednesday, July 30, 2025 8:23 AM
To: sbc...@li... <sbc...@li...>
Subject: [Sbcl-help] what's the correct behavior of directory-namestring

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

Hi there,

I am using SBCL on Windows. I also have SBCL install on Debian Linux and
FreeBSD.

I have to deal with some pathnames, for example:
#P"R:/Temp/abc/"

When passing the pathname to directory-namestring in SBCL 2.5.7 on
Windows, I got:

* (directory-namestring #P"R:/Temp/abc/")
"/Temp/abc/"

SBCL 2.2.9 on Debian and 2.5.6 on FreeBSD, booth give:

* (directory-namestring #P"R:/Temp/abc/")
"R:/Temp/abc/"

Which is the correct behavior?

Best,
Jinsong



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



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

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

Re: [Sbcl-help] what's the correct behavior of directory-namestring

[David S. <d.s...@go...>]

I think it's not defined by the Common Lisp standard. Pathnames also have a
"device" component, this should be the drive letter in Windows, e.g. "R:"
in your case.

Jinsong Zhao <js...@ye...> schrieb am Di., 29. Juli 2025, 23:56:

> Hi there,
>
> I am using SBCL on Windows. I also have SBCL install on Debian Linux and
> FreeBSD.
>
> I have to deal with some pathnames, for example:
> #P"R:/Temp/abc/"
>
> When passing the pathname to directory-namestring in SBCL 2.5.7 on
> Windows, I got:
>
> * (directory-namestring #P"R:/Temp/abc/")
> "/Temp/abc/"
>
> SBCL 2.2.9 on Debian and 2.5.6 on FreeBSD, booth give:
>
> * (directory-namestring #P"R:/Temp/abc/")
> "R:/Temp/abc/"
>
> Which is the correct behavior?
>
> Best,
> Jinsong
>
>
>
> _______________________________________________
> Sbcl-help mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>

[Sbcl-help] what's the correct behavior of directory-namestring

[Jinsong Z. <js...@ye...>]

Hi there,

I am using SBCL on Windows. I also have SBCL install on Debian Linux and 
FreeBSD.

I have to deal with some pathnames, for example:
#P"R:/Temp/abc/"

When passing the pathname to directory-namestring in SBCL 2.5.7 on 
Windows, I got:

* (directory-namestring #P"R:/Temp/abc/")
"/Temp/abc/"

SBCL 2.2.9 on Debian and 2.5.6 on FreeBSD, booth give:

* (directory-namestring #P"R:/Temp/abc/")
"R:/Temp/abc/"

Which is the correct behavior?

Best,
Jinsong

Re: [Sbcl-help] SBCL 2.3.11: Core dump after typing Control-4

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

Whoops, so it is. Exclude that one from consideration.

So I guess the question is how likely it is SBCL might ever need other
async signals for internal use, right?

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

> SIGUSR2 is SIG_STOP_FOR_GC, don't do that.
> 
> On Wed, Jun 25, 2025 at 4:41 PM Richard M Kreuter via Sbcl-help
> <sbc...@li...> wrote:
> >
> > Would there be much downside letting users do the equivalent of
> >
> >   signal(SIGQUIT, SIG_IGN);
> >
> > ? And likewise for SIGHUP, SIGUSR1, SIGUSR2.
> >
> > And while I'm asking, how about letting users do
> >
> >   signal(SIGINT, SIG_DFL);
> >
> > for cases where you don't want SBCL's SIGINT handler?
> >
> > Note that I'm only thinking about the two handlers defined in the C
> > standard, not arbitrary user-defined ones.
> >
> > Thanks,
> > Richard
> >
> >
> > _______________________________________________
> > Sbcl-help mailing list
> > Sbc...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbcl-help

Re: [Sbcl-help] SBCL 2.3.11: Core dump after typing Control-4

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

SIGUSR2 is SIG_STOP_FOR_GC, don't do that.

On Wed, Jun 25, 2025 at 4:41 PM Richard M Kreuter via Sbcl-help
<sbc...@li...> wrote:
>
> Would there be much downside letting users do the equivalent of
>
>   signal(SIGQUIT, SIG_IGN);
>
> ? And likewise for SIGHUP, SIGUSR1, SIGUSR2.
>
> And while I'm asking, how about letting users do
>
>   signal(SIGINT, SIG_DFL);
>
> for cases where you don't want SBCL's SIGINT handler?
>
> Note that I'm only thinking about the two handlers defined in the C
> standard, not arbitrary user-defined ones.
>
> Thanks,
> Richard
>
>
> _______________________________________________
> Sbcl-help mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help

Re: [Sbcl-help] SBCL 2.3.11: Core dump after typing Control-4

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

Would there be much downside letting users do the equivalent of

  signal(SIGQUIT, SIG_IGN);

? And likewise for SIGHUP, SIGUSR1, SIGUSR2.

And while I'm asking, how about letting users do

  signal(SIGINT, SIG_DFL);

for cases where you don't want SBCL's SIGINT handler?

Note that I'm only thinking about the two handlers defined in the C
standard, not arbitrary user-defined ones.

Thanks,
Richard

Re: [Sbcl-help] SBCL 2.3.11: Core dump after typing Control-4

[<2Qd...@po...>]

On 2025-06-22 at 19:28:29 -0400,
tp...@gm... wrote:

> Michał "phoe" Herda <ph...@di...> writes:
> 
> > On 23.06.2025 00:43, tp...@gm... wrote:
> >> Is there an argument for continuing the current behavior,
> >> that is, is it useful for SBCL to allow a user to interrupt
> >> the lisp and dump core under some circumstances?
> >
> > The behaviour you are describing is the default for all Unix processes 
> > running in terminals. It's not the duty of SBCL to document OS defaults.
> >
> 
> It is the behavior, but it does not have to be.  Is it
> useful behavior or does it serve no purpose?

SIGQUIT serves exactly the purpose you discovered:  to cause a running
program to dump its core.  Maybe you personally don't have a use for
core files in general, or SBCL's core files in specific, but that
doesn't mean that the behavior is not useful, or that some user won't
get surprised (in the bad way) if SBCL changes its behavior now.

In the general case, a core file can be the last resort to debug
compiler problems or other issues that baffle even a good debugger.

> > Speaking in another way: is the behaviour you describe documented 
> > anywhere for Python, Ruby, Perl, Erlang, and so on? I'm asking because 
> > the Unix python/irb/perl/erl programs react in the very same way - 
> > quitting and optionally producing core dumps.
> >
> 
> I do not know about how those programs behave, but it is
> beside the point of my question.

POSIX systems are general purpose, and designed to serve multiple uses
and multiple users (often simultaneously, on both fronts).  Running SBCL
is one such use, and I imagine that the number of POSIX users who use
their system exclusively to run SBCL is relatively small.

I'm not arguing against documenting SBCL's behavior in the face of a
SIGQUIT, if only to note that SBCL doesn't do anything special (although
the argument against documenting standard OS or glibc behavior is pretty
strong).

> > Or in yet another way: where does the man page for the Unix cat binary 
> > mention this? Because hitting Ctrl+4 on a running cat process does the same.
> >
> 
> That ‘cat’ does is not significant as it is not a program
> that users expect to interact with for long period without
> dying unexpectedly.  Also, ‘cat’ might well want to
> recognize a quit signal.  Does it serve a lisp to recognize
> the quit signal and if so what purpose does it serve?  And
> if not, can it be changed so that it intercepts and ignores
> a quit signal (as many other programs do)?

Again, your expectations of cat may or may not be typical.  I've been at
this for decades, and I still get surprised by other user's workflows.

It could well serve a lisp to recognize SIGQUIT and execute
save-lisp-and-die (or equivalent) with a particular set of arguments.
(I am not proosing such a thing, but I know better than to preclude
someone else from creating a workflow that I hadn't thought about.)

Re: [Sbcl-help] SBCL 2.3.11: Core dump after typing Control-4

[<tp...@gm...>]

Michał "phoe" Herda <ph...@di...> writes:

> On 23.06.2025 00:43, tp...@gm... wrote:
>> Is there an argument for continuing the current behavior,
>> that is, is it useful for SBCL to allow a user to interrupt
>> the lisp and dump core under some circumstances?
>
> The behaviour you are describing is the default for all Unix processes 
> running in terminals. It's not the duty of SBCL to document OS defaults.
>

It is the behavior, but it does not have to be.  Is it
useful behavior or does it serve no purpose?

> Speaking in another way: is the behaviour you describe documented 
> anywhere for Python, Ruby, Perl, Erlang, and so on? I'm asking because 
> the Unix python/irb/perl/erl programs react in the very same way - 
> quitting and optionally producing core dumps.
>

I do not know about how those programs behave, but it is
beside the point of my question.

> Or in yet another way: where does the man page for the Unix cat binary 
> mention this? Because hitting Ctrl+4 on a running cat process does the same.
>

That ‘cat’ does is not significant as it is not a program
that users expect to interact with for long period without
dying unexpectedly.  Also, ‘cat’ might well want to
recognize a quit signal.  Does it serve a lisp to recognize
the quit signal and if so what purpose does it serve?  And
if not, can it be changed so that it intercepts and ignores
a quit signal (as many other programs do)?

-- 
The lyf so short, the craft so long to lerne.
- Geoffrey Chaucer, The Parliament of Birds.

Re: [Sbcl-help] SBCL 2.3.11: Core dump after typing Control-4

[Michał p. H. <ph...@di...>]

On 23.06.2025 00:43, tp...@gm... wrote:
> Is there an argument for continuing the current behavior,
> that is, is it useful for SBCL to allow a user to interrupt
> the lisp and dump core under some circumstances?

The behaviour you are describing is the default for all Unix processes 
running in terminals. It's not the duty of SBCL to document OS defaults.

Speaking in another way: is the behaviour you describe documented 
anywhere for Python, Ruby, Perl, Erlang, and so on? I'm asking because 
the Unix python/irb/perl/erl programs react in the very same way - 
quitting and optionally producing core dumps.

Or in yet another way: where does the man page for the Unix cat binary 
mention this? Because hitting Ctrl+4 on a running cat process does the same.

Re: [Sbcl-help] SBCL 2.3.11: Core dump after typing Control-4

[<tp...@gm...>]

Michał "phoe" Herda <ph...@di...> writes:

> On 22.06.2025 23:24, tp...@gm... wrote:
>> SBCL users probably want to know
>>     - about this behavior
>>     - how to prevent it (besides "Do not press Ctrl-4.")
>
> This is like teaching users of SBCL that sending a SIGTERM to a process 
> is going to ask it to terminate. This is not SBCL's domain, but that of 
> the operating system that SBCL runs on.
>
> The SIGQUIT behaviour is defined by libc, see 
> https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html#index-SIGQUIT. 
> That's where the user should look to learn about the behaviour and how 
> to prevent it.
>

You are probably correct that this is how the maintainers
see this behavior (given how long SBCL has been in use).
There are many programs that can be run from a shell prompt
and not all of them take this approach.  Instead, they
intercept the signals and prevent them from causing a core
dump.

Is there an argument for continuing the current behavior,
that is, is it useful for SBCL to allow a user to interrupt
the lisp and dump core under some circumstances?  If so,
that could be documented.

-- 
The lyf so short, the craft so long to lerne.
- Geoffrey Chaucer, The Parliament of Birds.