Hi Barak, thank you for your follow-up (2 items). All items are dealt with in *SVN 2158*.
Summary ------- Fixed: 2 (#1 ⎕RVAL random_ieee() byte order, #2 hard-coded socket constants) Fixed ----- #1 Your patch was applied as is. I also checked that the old and the new code produce the same bits on amd64 (for 10 million random inputs), so the random sequences are unchanged there. I also searched the sources for other code that depends on the byte order in the same way (unions and byte-wise access to numbers) but found nothing else. #2 No need to patch the testcases: I fixed this in the interpreter. The hard-coded Linux/x86 values were not only in the testcases but also in FIO∆SockHelper of workspace 5 FILE_IO (generated once, on x86, by tools/sockconst.c), so APL socket programs using it were broken on sparc64 as well. The new ⎕FIO[62] returns the socket constants of the platform on which the interpreter was compiled: ⎕FIO[62] 'AF_INET' 'SOCK_STREAM' 'IPPROTO_TCP' 2 1 6 ⎕FIO[62] 'SOL_SOCKET' 1 ⍴⎕FIO[62] '' ⍝ all of them, as a name/value table 68 2 FIO∆SockHelper (in FILE_IO.apl and FILE_IO1.apl) and the testcases File_IO.tc, Quad_FIO.tc and Quad_FIO1.tc now take their constants from ⎕FIO[62], and tools/sockconst.c is gone. It would be great if you could run trunk on sparc64 once more, in particular Quad_RVAL.tc, Domino_stress.tc, File_IO.tc, Quad_FIO.tc and Quad_FIO1.tc. ⎕FIO[62] 'SOL_SOCKET' 'SO_REUSEADDR' should give 65535 4 there. 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 11/3/26 20:09, Barak A. Pearlmutter wrote:
Jürgen, That all looks fine, and the latest trunk (SVN: 3892", "2026-11-02 22:17:43 CET") builds/tests without issue on sparc64. Including the four testcases you mentioned (Quad_CR, ZZ17_Regression, AP100 and AP210) which all pass. In my latest debian packaging I enabled build-time testing using some debian/tests/ scripts, but some of the "upstream" tests failed so I only run the ones that ran okay. This is how the sparc64 (bigendian) issues were picked up. I'll let you know if the multiple-arch builds pick up anything else. I do have a pretty heavily patched 2.0, with 14 patches (https://tracker.debian.org/pkg/gnu-apl has a link "debian patches" that shows them, if you don't want to deal with git.) All the important ones are already deal with in the SVN trunk, what's left is reconstructed-texi-files (you have apl-library.info without the corresponding .texi source); spelling is merged but there's a stray new "GNU Public License" that should read "GNU General Public License"; and the doc-info-html stuff with info_TEXINFOS. Would you like me to modify the doc-info-html patch to hot-wire things so if makeinfo isn't available the build falls back to using prebuilt documentation files? Anyway, release 2.0 is pretty old at this point. Should I just wait for a new release? Or should I package a snapshot of the SVN trunk at some point? Cheers, --Barak.
