Enhancement: plan for calc v3

[lcn2]

This is a placeholder for TODO items needed to have the release calc version 3 (after calc 2.15.1.x is released and stable). Think of this TOOD list as a planned set of changes that will come with calc v3

Things TODO when starting work on calc v3

master branch

v2.16.1.0 work

• reformat C code using clang-format and the .clang-format file

  See commit bf7608e or later.
  Run:

     make clobber clang-format all chk

• Check in and release calc vision 2.16.1.1 based on the above reformat

calcv3 branch

v3.0.0.0 work

• create calcv3 branch on GitHub

  See How to Create a New Branch in GitHub - What's a Branch, Anyway?
  See Creating and deleting branches within your repository

Until calc version 3 is stable enough to become "_IS_LATEST_TESTED", the master branch will remain calc vision 2.

The calcv3 branch will be experimental, and initially potentially unstable.

Should and issue be discovered in calc version 2, they will be addressed on the master branch (with a possible new release), and if needed, applied to the calcv3 branch as well.

NOTE: For the time being, the calcv3 branch should be considered "experimental" and potentially unusable.

• on calcv3 branch change calc version to 3.0.0.0

• require <inttypes.h>

  eliminate use of have_inttypes.h
  eliminate use of HAVE_INTTYPES_H

• require <limits.h>

  eliminate use of have_limits.h
  eliminate use of HAVE_LIMITS_H

• require <stdbool.h>

  eliminate use of have_stdbool.h
  eliminate use of bool.h
  eliminate use of HAVE_STDBOOL_H
  Change use of FALSE to false
  Change use of TRUE to true
  Change use of BOOL to bool

• require <stdint.h>

  eliminate use of have_stdint.h
  eliminate use of HAVE_STDINT_H

• require <stdlib.h>

  eliminate use of have_stdlib.h
  eliminate use of HAVE_STDLIB_H

• require <string.h>

  eliminate use of have_string.h
  eliminate use of have_strdup.h
  eliminate use of have_memmv.h
  assume use of strdup()
  assume use of memmove()
  assume use of memcpy() and memset()
  eliminate use of HAVE_NEWSTR

• require <unistd.h>

  eliminate use of have_unistd.h
  eliminate use of HAVE_UNISTD_H

• require <time.h>, <sys/time.h>, <sys/times.h>

  eliminate use of have_times.h
  eliminate use of HAVE_TIME_H
  eliminate use of HAVE_TIMES_H
  eliminate use of HAVE_SYS_TIME_H
  eliminate use of HAVE_SYS_TIMES_H

• require use of <stdarg.h>

  eliminate use of have_stdvs.c
  eliminate use of have_varvs.c
  remove code that depends on VARARGS being defined

• assume use of snprintf() and vsnprintf()

  eliminate use of HAVE_VSNPRINTF
  eliminate use of HAVE_SNPRINTF

• do not assume getprid()

  eliminate use of have_getprid.h
  eliminate code that depends on HAVE_GETPRID

• assume C has const

  use const instead of CONST
  eliminate use of have_const.h

• assume C has static

  use static instead of STATIC

• assume C has extern

  use extern instead of E_FUNC and EXTERN
  NOTE: address the DLL need for Cygwin compilers, so perhaps use extern DLL instead?

• Remove use of decl.h and experimental use of WITH_TLS

  Thread Local Storage was never really tested, nor was __thread use fully supported.
  The safely can be added later on, when there is a need, AND when it can be properly tested.

  This will also remove the use defining __declspec(dllexport) or __declspec(dllimport) which was in the decl.h file. Such a DLL import/export can be added later when it can properly tested.

  Under calc version 2.12.1.10 there as an attempt to test such DLL services, however we never fully tested it, nor were we in a position to support it. Support of DLL can be added later on if there is a mean for someone to support and test it.

  Both Thread Local Storage, and DLL can be added later on to calc version 3 when there is someone with the ability to test and support them.

• require use of c17 or later C compiler

  change chk_c.c to test for c17 or later.

  Update banned.h as needed for c17 (but not yet c23).

  Sad that clang v18 is not more wide spread in 2026 otherwise we would support only c23 or later.

• Drop support of Sparc and similar architectures

  Calc will require the processor to be able to access 32 bit values that are not aligned on a 32 bit boCall undary. This was only an issue for the function implementing the SHA1 hash.

• Call libcalc_call_me_last() on exit

  See also GH issuecomment-3194363618.

• Replace malloc(3) calls with calloc(3)

• convert the struct value element v_subtype in value.h into an uint32_t type

• convert the struct value element v_type in value.h int16_t type

  NOTE: A v_type < 0 is used as an error code, not a union type.

  NOTE: Will add an unused as an uint16_t type to the struct value to deal with padding issues.

• remove any #include of calc *.h files that are not needed

v3.0.0.1 work

• Look at all XXX in the code and evaluate if something needs to be fixed

  Fix the XXX issue if reasonably easy, or

  remove the XXX is the issue won't be used and instead add a comment explaining why, or

  if it should be fixed is not easy, add a TODO issue somewhere below (perhaps as a new calc GitHub issue).

• Consider dropping support for i686 and 32-bit architectures

  See GH issuecomment-3717944546.

• eliminate BASEB == 16 option

• Consider adding a BASEB == 64 option

  See issue Enhancement: Try to support BASEB == 64 #48

• test for support of 128-bit and also for 256-bit data types if reasonable

  This might allow for a BASEB of 64 and 128

• remove size restrictions that functions such as zge31b() place on calculations

  For example, in zpowi(), the use of zge31b() prevents calc from using values larger 2^31-1 bits long.

• Fix, if possible, issue Bug: realloc of globalnames by addstr results in heap-use-after-free #47

• Remove calc -O and the old classic defaults

• Change the calc default as of the following had been set:

  config("tilde_space",1),;
  config("fraction_space",1),;
  config("complex_space",1),;

• Support hex float constants

  A "hex float' matches the following regex: [+-]?0x[0-9a-f]+([.][0-9a-f]+)?(p[+-]?[0-9]+)?

  See issue Enhancement: support hex floats #14 for more details.

• Document or flag as syntax error when the numerator is assumed

  When calc is given just /2 (no numerator), calc assumes a numerator of 1.
  This /x becomes equivalent of 1/x. If this a bug, then flag as a syntax error,
  otherwise if this a a feature then document under help/unexpected.
  See issue Enhancement: Document or warn when the numerator is assumed #49 for more details.

• Change #define CONFIG_SOMETHING in config.h into an enum

• Improve how someone can control where calc installs things

  Improve the documentation on how and where calc installs things.
  See issue [Msys2] It will always install to /usr regardless of whether PREFIX is set or not #108

• Improve use of readline and the programmable completion feature

  Look into completing the names of functions, variables, and providing lists of available help files or functions

  See issue command completion? #115.

• Add pre-defined constants to calc

  See comment 1749699647 below.

  See also comment 1751269852, comment 1751309220, and comment 1751332488

• Release calc also as a macOS DMG for universal binary

  NOTE: A single DMG for Apple Silicon

• Release calc also as a s390x RPM

  NOTE: See Support self-hosted runner on linux-s390x platform

  NOTE: See also Run-On-Arch GitHub Action

• Release calc as a Debian ".deb" binary package

  NOTE: See Debian packaging

• Split help/command into separate help files

  Have help/read just report on the read command, for example.
  The help/command should be a concatenation of these separate help files.
  The help/command at the top should suggest help usage and help man.

• Improve help help

  The current help/help file need to be improved, both in the order of items presented as well as to provide topics of better interest.

  Consider how man perl breaks up and names sections. This might be a useful model.

• Add help man to print the formatted calc man page.

  Replace help usage with help man and print the formatted man page.

  Alias help calc.1 to help man.

• Move help/functlist* outside of the help dir

  Put only help files and help/Makefile under the help/ directory.

• Change help/Makefile to print a special help file about calc Makefiles.

  Alias help makefile to help Makefile.

• Change help/usage and change calc -h to print information about the calc command line

  This print a short message about using the help command, and then print a typical command line usage summary.

• Add help faq to print a calc frequently asked questions file

  Look over open and closed discussions and old Email for various FAQ ideas.

• Explore the possibility of being able to save and restore calc history in machine ("native") form

  See comment 1754161473

• Integrate calc with gnuplot(1)

  Come up with a good way for calc to drive gnuplot.

  See issue Enhancement: Plotting #126.

• Rewrite the Blum-Blum-Shub pseudo-random number generator seed code in zrandom.c

  Rewrite the seed code to be a straightforward generator seeding, while maintaining backward compatibility.

  That is, no difference from a user's perspective. Fix the one known and minor calc memory leak as well.

• Add a pipe object

  Give calc the ability to perform I/O with programs it launches: I.e., core concepts relating to "pipes, forks, and I/O with other processes, etc."

See also pull request #153 that was created by @vike2000 for additional ideas.

MORE TODOs to be added over time.

TODO: calcv2 branch

Once version 3 is stable enough to become "_IS_LATEST_TESTED" sometime in the future, we will create a calcv2 branch and then merge the calcv3 branch into the master branch.

[lcn2]

Thank you for your suggestions

We wish to thank @ilyakurdyukov for issue #48 that is now part of this issue.

We wish to thank @ghost for issue #14 that is now part of this issue.

We wish to thank @Gusted for issue #49 that is now part of this issue.

We with to thank @pmetzger for issue #113, #115 and #116.

[lcn2]

Calc version 2.15.0.0 has been released. This is the last major update to calc v2 planned before we start work in calc version 3.

As we work on our initial plan for calc version 3 and update the calc v3 TODO list, we will monitor use of calc v2.15.0. Any issues reported in the short term will be addressed on the master branch and a calc version 2.15.0.x will be released.

Once all seems quiet, and our initial planning for calc version 3 is firm, we will form the calcv2 branch and begin work on the calc v3 TODO list. Should there be a need for a calc v2 bug fix release after that, we will apply such changes to the calcv2 branch.

[lcn2]

In comment 1929072414, @pmetzger suggests:

It would be nice if there were a library of predefined constants just as there's a library of predefined functions. Yes, for some things one can just do e=exp(1) or pi=pi() and so forth at the start of one's session (and I have those in particular in my calc rc file), but it's a bit annoying for beginners. Perhaps a library of common mathematical constants might be made available?

Calc could start off with certain constants as predefine variables, subject to the epsilon() precision. But what if people need a different epsilon?

Perhaps what might be needed is some "rebuild the constants to this epsilon" such as:

constants([eps])

The constants builtin would rebuild the internal constants to a specified epsilon level.

By default (unless calc was given such flag such as calc -L), calc would start out with the constants pre-set to the default epsilon value.

OK: we are talking about the constants that are not rational values. The internal constants for things like 1, 2, -1, and 10 don't count. Well they are part of counting, but you know what we mean. :-)

We also prefer to constants that are reasonably sized. We are not going to load Skewes's number for example. :-) :-) :-) We also need to restrict to constants that are easy to compute, so we are not going to compute Ackermann function related constants either :-) :-) :-). Only simple easy to compute constants. And not too many constants: we don't want to delay calc startup time too much.

If so, what constants should calc pre-define? What are their names?

• c
• pi
• e
• G

Please add your suggestions, in the form of Wikipedia links to the constants you wish calc to pre-compute and pre-define.

[pmetzger]

My own list in my .calcrc looks like this; almost all of these were added at some point because of an immediate need and then left forever. I think most of these aren't a good idea unless some sort of namespacing is provided. (Also, for constants with dimensions, it's hard to know which version of the constant one should use.)

(Adding dimensions to Calc would be interesting of course. But a lot of work! Still, it also would sometimes lead to errors being found which is quite useful.)

Anyway, I'd say "e" and "pi" are of course pretty obvious. If one adds physical constants that aren't dimensionless, they probably should be in MKS (SI) units. If one has namespaces (i.e. if one can say math.pi or phys.G or import things or what have you) then one can add an endless number of these without worrying about them interfering or polluting the namespace.

## Euler's Constant
e = exp(1)
## Pi
pi = pi()

## The Ideal Gas Constant, assuming you're working in Joules or L*kPa
Rj=8.314472
## The Ideal Gas Constant, assuming you're working in KJoules
RkJ=(8.314472/1000.0)
## Avogadro's Number
Na=6.0221415e23
## speed of light in meters per second (EXACTLY)
c_m=299792458.0
## kilometers per second
c_km=c_m/1000.0
## 1 atomsphere, in kPa
StdP=101.325
## hbar
hbar=1.05457E-34
## boltzmann's constant
kb=1.38065E-23