calc 2.14.0.10 release

[lcn2]

The following are the changes in this release:

Due to issues with clang and Apple Silicon, ARCH_CFLAGS is now,
by default, empty:

ARCH_CFLAGS=

If you want to use, say, -march=native, then either change
the Makefile or make with:

make all ARCH_CFLAGS='-march=native'

Added arch and hardware as GNU Makefile computed values.
As with ${target}, ${arch} and ${hardware} is computed by uname:

target: uname -a
arch: uname -p
hardware: uname -m

Fixed compiling calc on Apple Silicon with homebrew.  On Apple
Silicon, HomeBrew installs on into a different location.  The
Makefile checks if ${hardware} is arm64 and adjusts the location
of libraries such as readline and history accordingly.

Pluged a number of memory leaks.

Fixed a few cases where v_subtype was not properly initialuzed.

Improved the way that internal pre-defined constants are managed.
Removed unused internal pre-defined constants.  Added code to
prevent an internal pre-defined constant (that was never allocated)
from being freed.

Remove unnecessary spaces inbetween or next to tabs.

Update copright dates to account for 2021 modifications.

---

This discussion was created from the release calc 2.14.0.10 release.

[pmetzger]

MacPorts has been updated to 2.14.0.10

[lcn2]

Thank you @pmetzger on behalf of the mac ports community, for your work!

=-=

Version 2.14.0.10 represented a serious attempt to minimize Valgrind "issues". There were a few minor
issues fixed. A few minor memory leaks were plugged. Nothing major was discovered.

There are still 2 issues that Valgrind "whines" about that are still in calc 2.14.0.10:

1. A minor memory leak when seeding the Blum-Blum-Shub PRNG (srandom() builtin) that we could not
   figure out how to fix: it may be a bug / mis-feature of an over-zealous Valgrind or it may be a real leak issue.
   Nevertheless, it is only triggered by seeing Blum-Blum-Shub PRNG via the srandom() builtin.
   That is something someone might call once in a session so this "leak" is not a serious problem if it a real leak.

2. There is a 1-byte memory read issue relating to variable symbol lookups that is seen during the
   "make check" / regress.cal process when the regression script reads other cal regression resource files.
   We added extra padding for symbol arrays that we initialize to 0 or NULL as needed, but we could not
   figure out how to fix: it may be a bug / mis-feature of an over-zealous Valgrind or it may be a real mim fetch issue.
   Even unoptimized, the look code may prefetch something beyond what it might need. We put in zeroed
   extra padding and we verified that the variable symbol lookup does NOT use that extra 1 byte.
   So this "1 byte read" Valgrind issue, even if it is real, appears to not a serious problem.

=-=

The motivation for the above valgrind work was triggered by macOS 12.0.1. When calc runs on macOS 12.0.1,
on Apple Silicon, calc memory bloats. I (Landon) have been developing code to find large palindrome
primes (see the new cal/palindrome.cal file). At the 10000+ digit scales:

smallest decimal palindrome prime with at least 10000 digits

Calc on an Apple M1 Max bloats to multi-gigabyte scales within a day. So we went on a super-hunt for
calc memory leaks. Now calc 12.14.0.10 under macOS 12.0.1. running on 2.4Ghz 8-Core Intel Core i9 remains
at a sane few megabytes of memory, while calc 12.14.0.10 under macOS 12.0.1 running on an Apple M1 Max
on the exact same palindrome prime search bloats over time (a matter of a day+) to gigabyte levels.

We are NOW convinced this is a BUG caused by Apple macOS+Apple Silicon and not the fault of calc.
We are working on a memory bloat generator demo for Apple that is easier to understand and debug
without the complexity of the internals of calc.

=-=

In the future:

We plan to let version 2.14.0.10 "soak" for a bit (a few weeks) and if all is well, generate a new version that is declared stable: perhaps sometime by the end of 2021. Probably just minor cleanup (such as comment improvement, help file
improvement", etc.: non-executable code impacting stuff and make 2.14.0.11 a stable release by the end of 2021
unless something serious crops up.

There is an effort to add "Feature request: support hex floats #14" and "calc script debugging". However,
and "Feature request: support hex floats #14" would appear in 2.14.1.x release AFTER the 2.14.0.1 stable release.
The "calc script debugging" would appear in a 2.15.x.y release AFTER the 2.14.0.1 stable release.

We are also thinking about a calc DMG release for macOS .. but have not we looked into how or if that is a good idea.

And of course, all those plans are subject to change by impacts of reality. :-)

Comments and suggestions welcome.

Best wishes for the holidays and the new year: "Share and enjoy!" :-)

chongo (Landon Curt Noll) /\oo/\

[lcn2]

This release is no longer recommended as a stable release due to missing critical files.