|
| From: | Dr . Jürgen Sauermann |
| Subject: | Re: GNU APL 1.9 Released |
| Date: | Wed, 10 Jul 2024 12:28:58 +0200 |
| User-agent: | Mozilla Thunderbird |
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 <mail@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, enztec@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<mail@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,enztec@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<mail@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.
| [Prev in Thread] | Current Thread | [Next in Thread] |