Hi Mike,
thank you for your report. It is dealt with in *SVN r2136*.
Summary
-------
Fixed: 1 (#1)
Not a bug: 1 (#2)
Fixed
-----
#1 The messages themselves (and the APserver that keeps running): see
my reply to Paul. In short, APserver no longer probes its listening
socket (which macOS rejects with ENOTCONN), and the interpreter now
uses a fresh socket for every attempt to connect to APserver, so
that it actually connects on macOS and APserver exits together with
the last interpreter.
Not a bug
---------
#2 The messages despite "SharedVars Disabled": with SharedVars Disabled,
GNU APL does not start (or even contact) APserver at all. I verified
that with exactly your setting in ~/.config/gnu-apl/preferences.
There are two likely explanations:
a. An APserver left over from an earlier session (started while
shared variables were still enabled). Because of #1 it never
exited on macOS, and it keeps writing its messages to the terminal
in which it was started, also during later sessions. A single
killall APserver
gets rid of it; with the fix in #1 no new orphans are created.
b. Your setting is not used: if ~/.gnu-apl/preferences exists, then
GNU APL reads that file instead of ~/.config/gnu-apl/preferences.
A Profile section in the file can also make a line not apply.
To find out which one it is, *SVN 2136* has a new debug command ]STATUS
(and a command line option *apl --status*, which shows the same and
exits). It lists the optional features of GNU APL and, for every
disabled feature, the first reason why it is disabled. For example:
║ shared variables │ PUSER │ line 1: SharedVars Disabled ║
║ APserver │ - │ not used (shared variables disabled) ║
PUSER means your own preferences file (PSYS would be the system-wide
one, ARGV a command line option). If the shared variables row shows
✓ instead, then your setting is not in effect (see b. above).
Best Regards,
Jürgen
PS: The analysis of your report and the resulting changes were made with
the help of Claude Code (Anthropic). All changes were reviewed by me and
verified against the GNU APL testcases before being committed.
On 10/5/26 23:17, M.Hall wrote:
Same behavior with SVN 2135 on macos 15.8.1.
I have "SharedVars Disabled" in .config/gnu-apl/preferences file, but
got the same messages.
On Mon, Oct 5, 2026 at 1:11 PM Paul Rockwell <[email protected]> wrote:
I preface this by understanding that shared variables ((⎕SVO,etc)
are considered an obsolete feature of GNU APL. I have my
preferences set so that APserver is never started by default. But
I've come across the following when using the default GNU APL
behavior of enabling shared variable support.
When starting the interpreter in SVN 2133 on macOS 26 and 27 with
the shared variable support enabled, I'm greeted with the following:
% apl --SV
/usr/local/bin/APserver: listen socket has died unexpectedly
/usr/local/bin/APserver: listen socket has died unexpectedly
::connect() to supposedly existing APserver failed: Socket is
already connected
______ _ __ __ __ ___ ____ __
/ ____// | / // / / / / | / __ \ / /
/ / __ / |/ // / / / / /| | / /_/ // /
/ /_/ // /| // /_/ / / ___ | / ____// /___
\____//_/ |_/ \____/ /_/ |_|/_/ /_____/
Welcome to GNU APL version 2.0 / SVN: 2133M
Copyright © 2008-2026 Dr. Jürgen Sauermann
Banner by FIGlet: www.figlet.org
<http://www.figlet.org>
This program comes with ABSOLUTELY NO WARRANTY;
for details run: apl --gpl.
This program is free software, and you are welcome to
redistribute it
according to the GNU General Public License (GPL) version 3 or
later.
Svar_DB not connected in Svar_DB::is_registered_id() (APserver not
running; shared variables unavailable)
/usr/local/bin/APserver: listen socket has died unexpectedly
/usr/local/bin/APserver: listen socket has died unexpectedly
)/usr/local/bin/APserver: listen socket has died unexpectedly
off
Goodbye.
Session duration: 4.67723 seconds
paulrockwell@Upstairs ~ % /usr/local/bin/APserver: listen socket
has died unexpectedly
k/usr/local/bin/APserver: listen socket has died unexpectedly
killall/usr/local/bin/APserver: listen socket has died unexpectedly
AP/usr/local/bin/APserver: listen socket has died unexpectedly
serv/usr/local/bin/APserver: listen socket has died unexpectedly
er
The error messages from APserver continue after I stop the
interpreter because the /usr/local/bin/APserver process is still
running in the background. I have to locate and kill the process
manually.
Debugging the source code by executing APserver manually like GNU
APL is doing behind the scenes revealed that the followng code in
src/APs/APserver.cc <http://APserver.cc> function listen_sock() is
returning failure:
// read() cannot be used to probe a Winsock SOCKET on Windows --
// it is not a CRT file descriptor, only recv()/send()/ioctlsocket()
// are valid on it -- so this always (falsely) reported the listen
// socket, and then any freshly accepted connection, as dead on
// every pass, immediately closing real connections again via
// close_fd() below. A dead listen socket has no corrective action
// here anyway (just the message); on Windows a dead per-connection
// socket is still caught by the normal recv() return value once
// real data-handling code runs on it later in the loop, the same
// way most Windows socket servers detect a disconnect.
*if* (0 != read(listen_sock, &dummy, 0))
cerr<< prog<< ": listen socket has died unexpectedly"<< endl;
The read() on listen_sock is returning error code 57 (ENOTCONN),
in case that helps.
I've included the configure output, config.log, and config.h so
you can see how GNU APL has been configured.
A side request: If you consider shared variable support to be
obsolete, could the global GNU APL preferences be configured so
that shared variable support is disabled by default?
- Paul Rockwell
--
Mike Hall
