this is only a small part of what the apl --cfg outputs and takes up valuable screen space when trying to work on different compiles the apl -v should show what the configure options are like gcc -v does
On Wed, 3 Jul 2024 12:28:59 +0200 Dr. Jürgen Sauermann <m...@xn--jrgen-sauermann-zvb.de> wrote: > Hi, > > *apl -v* should be short. > > You can get all the *./configure* options (and if they were changed) > with command line argument *--cfg*: > > *apl --cfg > > configurable options: > --------------------- > ASSERT_LEVEL_WANTED=1 (default) > SECURITY_LEVEL_WANTED=0 (default) > APSERVER_PATH=/tmp/GNU-APL/APserver (default) > APSERVER_PORT=16366 (default) > APSERVER_TRANSPORT=0 (default) > ... > * > Best Regards, > Jürgen > * > * > On 7/2/24 20:02, enz...@gmx.com wrote: > > Hi > > > > another suggestion > > > > from apl -v output > > config.status: default ./configure options might be good to have the > > options used to configure apl output here like gcc -v does > > > > --- > > > > in case someone is compiling with libapl.a (static libapl) you now need to > > add -lpng to the compile line > > > > --- > > > > there is still this syntax error using c/libapl and python3/gnu_lib_apl > > still for 1 year+ after using )copy and i still have to use my workaround > > to to get fns > > > > SYNTAX ERROR+ > > Tokenizer: No token for Unicode U+2207 (∇) > > Input was: ∇ws > > > > libapl is no longer being maintained i guess - maybe time to remove it from > > the distribution until the basic problems can be workied on so no one tries > > to use this beta libapl thinking it is as good as apl itself > > there was a guy here within the last year who had problems with libapl that > > were never resolved > > > > > > On Mon, 1 Jul 2024 12:08:50 +0200 > > Dr. Jürgen Sauermann<m...@xn--jrgen-sauermann-zvb.de> wrote: > > > >> Hi, > >> > >> yes it is a snapshot of the current SVN. > >> No need to do anything if you update via SVN. > >> > >> Best Regards, > >> Jürgen > >> > >> > >> On 6/30/24 18:55,enz...@gmx.com wrote: > >>> Hi, > >>> > >>> is this apl-1.9.tar.gz just a tar.gz of the current svn or something > >>> labelled as a reak 'stable' release? > >>> > >>> since i assume you will be doing 'releases' from now on (?) - maybe > >>> calling it apl-2.0 would have been a better version number to start this > >>> new release scheme with rather then apl-1.9? > >>> > >>> a suggestion - add something to the configure summary to make note what > >>> the configure was for - libapl or python3/lib_gnu_apl etc > >>> like you are doing with apl_POSTGRES: > >>> apl_APL: [yes/no] > >>> apl_LIBAPL: [yes/no] > >>> apl_PYTHON: [yes/np] > >>> > >>> configure --with-python -> your Makefile.am is 'hardcoded' for > >>> '-I/usr/include/python3.6m -I/usr/include/python3.8' > >>> i didn't see any information for compiling with different python versions > >>> and installation locations (for Python.h) that would require using > >>> CPPFLAGS for different installation locations and newer python versions > >>> configure CPPFLAGS='-I/usr/local/include/python3.10' ...... for my > >>> particular python3.10 installation > >>> > >>> > >>> > >>> On Sun, 30 Jun 2024 13:41:38 +0200 > >>> Dr. Jürgen Sauermann<m...@xn--jrgen-sauermann-zvb.de> wrote: > >>> > >>>> Hi, > >>>> > >>>> I am happy to announce that *GNU APL 1.9* has been released. > >>>> > >>>> GNU APL is a free implementation of the ISO standard 13751 aka. > >>>> "Programming Language APL, Extended". > >>>> > >>>> The 1.9 release contains: > >>>> > >>>> * Bug fixes > >>>> > >>>> > >>>> Have fun! > >>>> > >>>> Dr. Jürgen Sauermann > >>>> Author and Maintainer of GNU APL > >>>> > >>>> > >>>> P.S. Some redundant distribution formats of GNU APL (RMPs, windows) > >>>> are no longer supported. The best way of using GNU APL is to fetch it > >>>> from > >>>> the savannah SVN and GIT archives (seehttps://www.gnu.org/software/apl > >>>> ). > >>>> These archives are, unlike the less frequent GNU APL releases, always > >>>> up-to-date and in sync with the ongoing GNU APL development.
