Re: GNU APL 1.9 Released

[enztec]

that is the definition of a very unhelpfull sparse summary  not something 
usefull

the point of a 'summary' is to make it easy to identify problems etc not to 
force someone to scroll/search through a large output message for the problem

On Wed, 3 Jul 2024 12:16:15 +0200
Dr. Jürgen Sauermann <mail@xn--jrgen-sauermann-zvb.de> wrote:

> Hi,
>
> the nature of a summary is to omit the details.
>
> In addition to the number of missing header files (at the end of the output)
> you get the information which header files are missing further up in the
> output.
> In your example below:
>
> checking for fftw3.h... (cached) no
>
>   IOW: the count displayed at the end is simply the number of header
> file that have failed.
>
> Best Regards,
> Jürgen
>
>
> On 7/1/24 19:41, enztec@gmx.com wrote:
> > Hi
> >
> > i have another suggestion for the configure summary
> >
> > in the configure output i get
> > checking for fftw3.h... (cached) no
> >     └──── will affect: ⎕FFT
> > disabled by: --with-pcre=no
> >     └──── will affect: ⎕RE
> > checking for GTK... no - (explicitly disabled by user)
> >     └──── may affect: ⎕PLOT, will affect ⎕PNG
> >
> > in the configure summary i get
> >   apl_missing_headers:         1
> >
> > i assume this is referring to the missing fftw3
> > why not list what header(s) the apl_missing_headers is referring to in 
> > addition to the number
> >
> > 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 (see https://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.
>