bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU APL 1.9 Released


From: enztec
Subject: Re: GNU APL 1.9 Released
Date: Tue, 9 Jul 2024 11:50:15 -0600

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]