SVN 2029 now builds for me as well, thank you. -Russ
On Sat, Jul 4, 2026 at 9:01 AM <[email protected]> wrote: > Send Bug-apl mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnu.org/mailman/listinfo/bug-apl > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Bug-apl digest..." > > > Today's Topics: > > 1. Re: Has anyone else seen build breakage to do with ncurses > and -ltinfo... (Dr. Jürgen Sauermann) > 2. SVN 2029 (Dr. Juergen Sauermann) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 3 Jul 2026 21:38:27 +0200 > From: Dr. Jürgen Sauermann <[email protected]> > To: Blake McBride <[email protected]> > Cc: Russtopia <[email protected]>, "M.Hall" <[email protected]>, Paul > Rockwell <[email protected]>, bug-apl <[email protected]> > Subject: Re: Has anyone else seen build breakage to do with ncurses > and -ltinfo... > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hi Russ, Paul, M.Hall, and Blake, > > Fixed in *SVN 2029*: the three warnings about "bitwise operation between > different enumeration types" (-Wdeprecated-enum-enum-conversion) seen on > newer compilers. > > The root cause: the low byte of a TokenTag encodes its TokenClass, and the > high byte encodes its TokenValueType, so extracting them requires > masking tag > against TC_MASK (a TokenClass constant) and TV_MASK (a TokenValueType > constant). GCC 12+ flags cross-enum bitwise operations as deprecated under > -Wdeprecated-enum-enum-conversion. The fix is an explicit cast of both > operands to int before the &: > > TokenClass(int(tag) & int(TC_MASK)) > > Applied in Token.hh, Function.hh, Token.cc, Archive.cc, Prefix.cc, > Tokenizer.cc, and Quad_CR.cc (7 files). A similar Svar_state & Svar_Control > pattern in Svar_record.cc was fixed by the same method. > > Jürgen > > P.S. The fix was prepared with Claude Code (https://claude.ai/code); the > SVN > commit was done manually. Savannah project page: > https://savannah.gnu.org/projects/apl > > > On 7/3/26 16:44, Blake McBride wrote: > > It now builds for me, but I get a lot of warnings. See the two > > attached files. > > > > Thanks! > > > > Blake > > > > > > On Fri, Jul 3, 2026 at 8:41 AM Dr. Jürgen Sauermann > > <mail@jürgen-sauermann.de <mailto:mail@j%C3%BCrgen-sauermann.de>> wrote: > > > > Hi Russ, Paul, M.Hall, and Blake, thanks for reporting. > > > > Fixed in *SVN 2027*: tools/ncurses_emul.cc was an obsolete > > development tool > > that was never used by the APL interpreter itself; it has now > > been removed > > and all configure.ac <http://configure.ac> checks for libtinfo, > > libcurses, and libncurses, > > as well as the BUILD_NCURSES_EMUL conditional, have been removed. > > > > Jürgen > > > > P.S. The fix was prepared with Claude Code > > (https://claude.ai/code); the SVN > > commit was done manually. Savannah project page: > > https://savannah.gnu.org/projects/apl > > > > --- > > Changes made: > > - configure.ac <http://configure.ac>: removed > > ncurses.h/curses.h/term.h header checks, AC_CHECK_LIB > > for tinfo/curses/ncurses, and > > AM_CONDITIONAL([BUILD_NCURSES_EMUL], ...) > > - tools/Makefile.am: removed ncurses_emul_SOURCES, > > ncurses_emul_LDADD, and > > the if BUILD_NCURSES_EMUL block > > - src/Output.hh: updated stale comment from "initialize curses > > library" to > > "initialize terminal output (ANSI sequences)" > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.gnu.org/archive/html/bug-apl/attachments/20260703/f5d89f97/attachment.htm > > > > ------------------------------ > > Message: 2 > Date: Fri, 3 Jul 2026 22:36:12 +0200 > From: "Dr. Juergen Sauermann" <[email protected]> > To: bug-apl <[email protected]> > Subject: SVN 2029 > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi all, > > SVN r2028/29 introduces "packed ravels" for GNU APL 2.0. This is a large > internal change, so some previously undiscovered issues may surface. > > Background > ---------- > Every APL value is a Shape plus a flat array (ravel) of Cell objects. > Each Cell is a tagged union of 24 bytes. Computing with a ravel of > doubles therefore requires dispatching through the Cell abstraction on > every element, which prevents auto-vectorisation and adds per-element > overhead. > > What changed > ------------ > A new 16-bit "ravel type" field (RavelType) is stored in the VF_Flags > word of each Value. When all cells in a ravel have the same type and > the ravel is longer than a short-value threshold (12 elements), the > ravel is tagged as packed. Scalar functions can then check the ravel > type once and execute a tight typed loop directly over the underlying > data without constructing or dispatching through Cell objects. The > packed ravel is created lazily via try_pack() and inflated back to > Cells on demand via explode(). > > Supported packed types: > > RPT_BOOL, RPT_UNICODE16, RPT_UNICODE32, RPT_INT64, > RPT_FLOAT64, RPT_COMPLEX > > Performance measurements (cc = core count, N = 1 000 000 or 10 000 000 > elements): > > N = 1M (fits roughly in L3 cache), 1 core: > > int A-B: 38 ns/elem (no INT64 fast path yet; Cell fetcher used) > flt A-B: 1 ns/elem (FLOAT64 fast path) > int -B: 26 ns/elem > flt -B: 1 ns/elem > > N = 10M (DRAM-bound), sequential and parallel: > > cc int(A-B) flt(A-B) int(-B) flt(-B) [ns/elem] > 1 54 7.6 39 6.6 > 2 38 5.2 32 7.6 > 4 42 2.7 27 3.4 > 6 41 2.7 25 4.6 > 8 39 2.6 25 4.2 > 10 36 2.4 32 5.4 > > The "memory wall" is the observation (Wulf & McKee, 1995) that CPU > clock rates have historically grown much faster than DRAM bandwidth. > For a memory-bound operation like A+B on large arrays, adding more > cores eventually saturates the memory bus rather than the arithmetic > units, so throughput stops scaling. For the FLOAT64 fast path that > wall is hit around 4 cores (7.6 → 2.7 ns, ≈2.8× speedup). Beyond > 4 cores the gain is marginal. > INT64 has no dedicated fast path yet; it goes through the Cell fetcher > which has more overhead. > > Known limitations / caution > ---------------------------- > - This is a large structural change. All scalar functions, ⎕CR, and > other code paths accept packed ravels as input, but corner cases > that have not yet been exercised may still surface. > - A future commit will add an INT64 fast path in ScalarFunction.cc > (currently only FLOAT64 has one). > - Please report any regressions to [email protected]. > > Best Regards, > Jürgen > > P.S. The benchmarks were run with Claude Code (https://claude.ai/code); > the SVN commit was done manually. > Savannah project page: https://savannah.gnu.org/projects/apl > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Bug-apl mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/bug-apl > > > ------------------------------ > > End of Bug-apl Digest, Vol 153, Issue 2 > *************************************** >
