Re: sparse vector 'without' returns ⍬ with sufficiently large vector

[Dr . Jürgen Sauermann]

  
  
Hi,
  
  thank you  all  for your clarifications. Fixed in SVN 1275.

Jürgen


On 4/30/20 11:47 PM, Rowan Cannaday
  wrote:


  
  Sorry for the late reply. I was out venturing for
groceries, which has turned into a significantly more stressful
task than anticipated it would.


Thanks to responders who have provided simpler
  demonstrations of the effect.


- Rowan
  
  
  
On Thu, Apr 30, 2020, 3:30 PM
  Kacper Gutowski  wrote:

On Thu, Apr
  30, 2020 at 11:17:20PM +0400, Ala'a Mohammad wrote:
  >I suspect It has something to do with Zero value.
  >
  >Kacper example also produce output when Zero is replaced
  with other 
  >values.
  
  Zero isn't stricly needed to reproduce: (61⍴10) ~ 60⍴¯10
  I didn't try to properly debug it, but the bug is in 
  Bif_F12_WITHOUT::large_eval_AB which is used for A~B 
  when 3600<(⍴A)×⍴B.
  
  -k
  

  


  

Re: sparse vector 'without' returns ⍬ with sufficiently large vector

[Kacper Gutowski]

On Fri, May 01, 2020 at 03:08:16PM +0200, Dr. Jürgen Sauermann wrote:
> Fixed in SVN 1275.

With g++ 9.3.0, it fails to build tripping on a warning:

g++ -DHAVE_CONFIG_H -I. -I..-Wall -I sql -Werror -rdynamic -g -O2 -MT 
apl-Bif_F12_FORMAT.o -MD -MP -MF .deps/apl-Bif_F12_FORMAT.Tpo -c -o 
apl-Bif_F12_FORMAT.o `test -f 'Bif_F12_FORMAT.cc' || echo './'`Bif_F12_FORMAT.cc
In file included from PrintBuffer.hh:30,
 from Cell.hh:30,
 from CharCell.hh:24,
 from Value.hh:24,
 from NamedObject.hh:25,
 from Function.hh:27,
 from PrimitiveFunction.hh:27,
 from Bif_F12_FORMAT.hh:26,
 from Bif_F12_FORMAT.cc:25:
Shape.hh: In member function ‘virtual Token Bif_F12_FORMAT::eval_B(Value_P)’:
Shape.hh:133:18: error: ‘shape_Z.Shape::rho[]’ may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
  133 | if (rho[r])   { volume /= rho[r];  rho[r] = sh;  volume *= 
rho[r]; }
  | ~^
Shape.hh: In member function ‘Value_P 
Bif_F12_FORMAT::format_by_specification(Value_P, Value_P)’:
Shape.hh:133:18: error: ‘shape_Z.Shape::rho[]’ may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
  133 | if (rho[r])   { volume /= rho[r];  rho[r] = sh;  volume *= 
rho[r]; }
  | ~^
cc1plus: all warnings being treated as errors

-k

Error building APL

[Blake McBride]

Greetings,

Trying to build GNU APL rev 1275 on my 64-bit Linux box I get:

[...]
mv -f .deps/apl-Bif_OPER2_RANK.Tpo .deps/apl-Bif_OPER2_RANK.Po
g++ -DHAVE_CONFIG_H -I. -I..-Wall -I sql -Werror -I/usr/include
-I/usr/include/postgresql   -rdynamic -g -O2 -MT apl-Bif_OPER1_REDUCE.o -MD
-MP -MF .deps/apl-Bif_OPER1_REDUCE.Tpo -c -o apl-Bif_OPER1_REDUCE.o `test
-f 'Bif_OPER1_REDUCE.cc' || echo './'`Bif_OPER1_REDUCE.cc
In file included from PrintBuffer.hh:30:0,
 from Cell.hh:30,
 from CharCell.hh:24,
 from Value.hh:24,
 from NamedObject.hh:25,
 from Function.hh:27,
 from PrimitiveFunction.hh:27,
 from PrimitiveOperator.hh:24,
 from Bif_OPER1_REDUCE.hh:24,
 from Bif_OPER1_REDUCE.cc:23:
Shape.hh: In member function ‘Token Bif_REDUCE::reduce_n_wise(Value_P,
Token&, Value_P, uAxis)’:
Shape.hh:133:18: error: ‘shape_Z.Shape::rho[axis]’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
 if (rho[r])   { volume /= rho[r];  rho[r] = sh;  volume *= rho[r];
}
 ~^
Shape.hh:109:41: error: ‘shape_Z.Shape::rho[axis]’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
{ Assert(r < rho_rho);   return rho[r]; }
 ^
Shape.hh: In member function ‘Token Bif_REDUCE::replicate(Value_P, Value_P,
uAxis)’:
Shape.hh:133:18: error: ‘shape_Z.Shape::rho[axis]’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
 if (rho[r])   { volume /= rho[r];  rho[r] = sh;  volume *= rho[r];
}
 ~^
cc1plus: all warnings being treated as errors
Makefile:3234: recipe for target 'apl-Bif_OPER1_REDUCE.o' failed
make[3]: *** [apl-Bif_OPER1_REDUCE.o] Error 1
make[3]: Leaving directory '/home/blake/Backup/apl/src'
Makefile:4584: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/blake/Backup/apl/src'
Makefile:522: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/blake/Backup/apl'
Makefile:409: recipe for target 'all' failed
make: *** [all] Error 2

Re: Error building APL

[Dr . Jürgen Sauermann]

  
  
Hi everybody,
  
  it seems like gcc/g++ continues to generate bogus warnings at a
  rate that makes it difficult to
  keep up with. For that reason I have written a README-11-bogus-compiler-warnings
  which
  explains how to deal with this. SVN 1276.
  
  Maybe somebody would like to report this as a compiler error.
  Strictly speaking it is not
  because the warning itself says "maybe", but IMHO it should not
  occur under -Wall
  but only under -Wextra.

Best Regards,
Jürgen


On 5/1/20 4:06 PM, Blake McBride wrote:


  
  Greetings,


Trying to build GNU APL rev 1275 on my 64-bit Linux box I
  get:


[...]
mv -f .deps/apl-Bif_OPER2_RANK.Tpo
  .deps/apl-Bif_OPER2_RANK.Po
  g++ -DHAVE_CONFIG_H -I. -I..    -Wall -I sql -Werror
  -I/usr/include -I/usr/include/postgresql   -rdynamic -g -O2
  -MT apl-Bif_OPER1_REDUCE.o -MD -MP -MF
  .deps/apl-Bif_OPER1_REDUCE.Tpo -c -o apl-Bif_OPER1_REDUCE.o
  `test -f 'Bif_OPER1_REDUCE.cc' || echo
  './'`Bif_OPER1_REDUCE.cc
  In file included from PrintBuffer.hh:30:0,
                   from Cell.hh:30,
                   from CharCell.hh:24,
                   from Value.hh:24,
                   from NamedObject.hh:25,
                   from Function.hh:27,
                   from PrimitiveFunction.hh:27,
                   from PrimitiveOperator.hh:24,
                   from Bif_OPER1_REDUCE.hh:24,
                   from Bif_OPER1_REDUCE.cc:23:
  Shape.hh: In member function ‘Token
  Bif_REDUCE::reduce_n_wise(Value_P, Token&, Value_P,
  uAxis)’:
  Shape.hh:133:18: error: ‘shape_Z.Shape::rho[axis]’ may be used
  uninitialized in this function [-Werror=maybe-uninitialized]
           if (rho[r])   { volume /= rho[r];  rho[r] = sh;
   volume *= rho[r]; }
               ~^
  Shape.hh:109:41: error: ‘shape_Z.Shape::rho[axis]’ may be used
  uninitialized in this function [-Werror=maybe-uninitialized]
      { Assert(r < rho_rho);   return rho[r]; }
                                           ^
  Shape.hh: In member function ‘Token
  Bif_REDUCE::replicate(Value_P, Value_P, uAxis)’:
  Shape.hh:133:18: error: ‘shape_Z.Shape::rho[axis]’ may be used
  uninitialized in this function [-Werror=maybe-uninitialized]
           if (rho[r])   { volume /= rho[r];  rho[r] = sh;
   volume *= rho[r]; }
               ~^
  cc1plus: all warnings being treated as errors
  Makefile:3234: recipe for target 'apl-Bif_OPER1_REDUCE.o'
  failed
  make[3]: *** [apl-Bif_OPER1_REDUCE.o] Error 1
  make[3]: Leaving directory '/home/blake/Backup/apl/src'
  Makefile:4584: recipe for target 'all-recursive' failed
  make[2]: *** [all-recursive] Error 1
  make[2]: Leaving directory '/home/blake/Backup/apl/src'
  Makefile:522: recipe for target 'all-recursive' failed
  make[1]: *** [all-recursive] Error 1
  make[1]: Leaving directory '/home/blake/Backup/apl'
  Makefile:409: recipe for target 'all' failed
  make: *** [all] Error 2



  


  

Re: Error building APL

[Blake McBride]

Or, as a solution I've used in the past, don't kill the build on a
warning.  Just issue the warning and keep going.  This is the default
behavior of make.  Errors are errors that should be fixed.  Warnings are
things the compiler points out that you may want to look into.  It isn't
saying they're wrong.

I think it is often the case that making a few tweaks to minimize warnings
is good.  However, as you've noted, trying to eliminate every warning is
more than a fulltime job.

Thanks!

Blake


On Fri, May 1, 2020 at 9:43 AM Dr. Jürgen Sauermann <
mail@jürgen-sauermann.de> wrote:

> Hi everybody,
>
> it seems like gcc/g++ continues to generate bogus warnings at a rate that
> makes it difficult to
> keep up with. For that reason I have written a
> *README-11-bogus-compiler-warnings* which
> explains how to deal with this. *SVN 1276*.
>
> Maybe somebody would like to report this as a compiler error. Strictly
> speaking it is not
> because the warning itself says "maybe", but IMHO it should not occur
> under *-Wall*
> but only under *-Wextra*.
>
> Best Regards,
> Jürgen
>
>
> On 5/1/20 4:06 PM, Blake McBride wrote:
>
> Greetings,
>
> Trying to build GNU APL rev 1275 on my 64-bit Linux box I get:
>
> [...]
> mv -f .deps/apl-Bif_OPER2_RANK.Tpo .deps/apl-Bif_OPER2_RANK.Po
> g++ -DHAVE_CONFIG_H -I. -I..-Wall -I sql -Werror -I/usr/include
> -I/usr/include/postgresql   -rdynamic -g -O2 -MT apl-Bif_OPER1_REDUCE.o -MD
> -MP -MF .deps/apl-Bif_OPER1_REDUCE.Tpo -c -o apl-Bif_OPER1_REDUCE.o `test
> -f 'Bif_OPER1_REDUCE.cc' || echo './'`Bif_OPER1_REDUCE.cc
> In file included from PrintBuffer.hh:30:0,
>  from Cell.hh:30,
>  from CharCell.hh:24,
>  from Value.hh:24,
>  from NamedObject.hh:25,
>  from Function.hh:27,
>  from PrimitiveFunction.hh:27,
>  from PrimitiveOperator.hh:24,
>  from Bif_OPER1_REDUCE.hh:24,
>  from Bif_OPER1_REDUCE.cc:23:
> Shape.hh: In member function ‘Token Bif_REDUCE::reduce_n_wise(Value_P,
> Token&, Value_P, uAxis)’:
> Shape.hh:133:18: error: ‘shape_Z.Shape::rho[axis]’ may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
>  if (rho[r])   { volume /= rho[r];  rho[r] = sh;  volume *=
> rho[r]; }
>  ~^
> Shape.hh:109:41: error: ‘shape_Z.Shape::rho[axis]’ may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
> { Assert(r < rho_rho);   return rho[r]; }
>  ^
> Shape.hh: In member function ‘Token Bif_REDUCE::replicate(Value_P,
> Value_P, uAxis)’:
> Shape.hh:133:18: error: ‘shape_Z.Shape::rho[axis]’ may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
>  if (rho[r])   { volume /= rho[r];  rho[r] = sh;  volume *=
> rho[r]; }
>  ~^
> cc1plus: all warnings being treated as errors
> Makefile:3234: recipe for target 'apl-Bif_OPER1_REDUCE.o' failed
> make[3]: *** [apl-Bif_OPER1_REDUCE.o] Error 1
> make[3]: Leaving directory '/home/blake/Backup/apl/src'
> Makefile:4584: recipe for target 'all-recursive' failed
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory '/home/blake/Backup/apl/src'
> Makefile:522: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/home/blake/Backup/apl'
> Makefile:409: recipe for target 'all' failed
> make: *** [all] Error 2
>
>
>

Re: Error building APL

[Dr . Jürgen Sauermann]

Hi Blake,

this is kind of a dilemma. On the one hand I have the ambition that the
build should be as clean as
possible. In the majority of cases the warnings point at something that
needs to be improved. Many
reports come from platforms that I do not posses, or from a compiler
version that I do not use (like in
the example below). On the other hand the number of bogus compiler
warnings has increased
significantly in the last few years and the warnings get increasingly
stupid (e.g. -Wmisleading-indentation)

The idea of *README-11-bogus-compiler-warnings* was to give the user an
idea of how to fix
a build that is broken by a new bogus compiler warning so that I can
prioritize the fix of the warning
a little down without loosing the reports about the warnings.

Best Regards,
Jürgen


On 5/1/20 4:59 PM, Blake McBride wrote:
> Or, as a solution I've used in the past, don't kill the build on a
> warning.  Just issue the warning and keep going.  This is the default
> behavior of make.  Errors are errors that should be fixed.  Warnings
> are things the compiler points out that you may want to look into.  It
> isn't saying they're wrong.
>
> I think it is often the case that making a few tweaks to minimize
> warnings is good.  However, as you've noted, trying to eliminate every
> warning is more than a fulltime job.
>
> Thanks!
>
> Blake
>
>
> On Fri, May 1, 2020 at 9:43 AM Dr. Jürgen Sauermann
> mailto:mail@j%C3%BCrgen-sauermann.de>> wrote:
>
> Hi everybody,
>
> it seems like gcc/g++ continues to generate bogus warnings at a
> rate that makes it difficult to
> keep up with. For that reason I have written a
> *README-11-bogus-compiler-warnings* which
> explains how to deal with this. *SVN 1276*.
>
> Maybe somebody would like to report this as a compiler error.
> Strictly speaking it is not
> because the warning itself says "maybe", but IMHO it should not
> occur under *-Wall*
> but only under *-Wextra*.
>
> Best Regards,
> Jürgen
>
>
> On 5/1/20 4:06 PM, Blake McBride wrote:
>> Greetings,
>>
>> Trying to build GNU APL rev 1275 on my 64-bit Linux box I get:
>>
>> [...]
>> mv -f .deps/apl-Bif_OPER2_RANK.Tpo .deps/apl-Bif_OPER2_RANK.Po
>> g++ -DHAVE_CONFIG_H -I. -I..    -Wall -I sql -Werror
>> -I/usr/include -I/usr/include/postgresql   -rdynamic -g -O2 -MT
>> apl-Bif_OPER1_REDUCE.o -MD -MP -MF .deps/apl-Bif_OPER1_REDUCE.Tpo
>> -c -o apl-Bif_OPER1_REDUCE.o `test -f 'Bif_OPER1_REDUCE.cc' ||
>> echo './'`Bif_OPER1_REDUCE.cc
>> In file included from PrintBuffer.hh:30:0,
>>                  from Cell.hh:30,
>>                  from CharCell.hh:24,
>>                  from Value.hh:24,
>>                  from NamedObject.hh:25,
>>                  from Function.hh:27,
>>                  from PrimitiveFunction.hh:27,
>>                  from PrimitiveOperator.hh:24,
>>                  from Bif_OPER1_REDUCE.hh:24,
>>                  from Bif_OPER1_REDUCE.cc:23:
>> Shape.hh: In member function ‘Token
>> Bif_REDUCE::reduce_n_wise(Value_P, Token&, Value_P, uAxis)’:
>> Shape.hh:133:18: error: ‘shape_Z.Shape::rho[axis]’ may be used
>> uninitialized in this function [-Werror=maybe-uninitialized]
>>          if (rho[r])   { volume /= rho[r];  rho[r] = sh;  volume
>> *= rho[r]; }
>>              ~^
>> Shape.hh:109:41: error: ‘shape_Z.Shape::rho[axis]’ may be used
>> uninitialized in this function [-Werror=maybe-uninitialized]
>>     { Assert(r < rho_rho);   return rho[r]; }
>>                                          ^
>> Shape.hh: In member function ‘Token
>> Bif_REDUCE::replicate(Value_P, Value_P, uAxis)’:
>> Shape.hh:133:18: error: ‘shape_Z.Shape::rho[axis]’ may be used
>> uninitialized in this function [-Werror=maybe-uninitialized]
>>          if (rho[r])   { volume /= rho[r];  rho[r] = sh;  volume
>> *= rho[r]; }
>>              ~^
>> cc1plus: all warnings being treated as errors
>> Makefile:3234: recipe for target 'apl-Bif_OPER1_REDUCE.o' failed
>> make[3]: *** [apl-Bif_OPER1_REDUCE.o] Error 1
>> make[3]: Leaving directory '/home/blake/Backup/apl/src'
>> Makefile:4584: recipe for target 'all-recursive' failed
>> make[2]: *** [all-recursive] Error 1
>> make[2]: Leaving directory '/home/blake/Backup/apl/src'
>> Makefile:522: recipe for target 'all-recursive' failed
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory '/home/blake/Backup/apl'
>> Makefile:409: recipe for target 'all' failed
>> make: *** [all] Error 2
>>
>

APL X11 font recommendation

[Alexander Shendi (Web.DE)]

Hi all,

I am now shopping for an APL font to use with X11R7 on NetBSD 9. I have already 
tried the stuff from APL385.com. The procedure was as follows:
1. Copy the font files into /usr/pkg/share/fonts/X11/TTF/.
2. Execute "/usr/X11R7/bin/mkfontscale"
3. Execute "/usr/X11R7/bin/mkfontdir"
4. Execute "xset +fp /usr/pkg/share/fonts/X11/TTF"
5. Execute "xset fp rehash"
6. Check with xlsfonts that the APL fonts are available.
7. Set the locale to UTF-8 by setting LC_ALL and LANG to "en_US. UTF-8". 

If there is anything wrong with this, please let me know. 

I do have the fonts available, but the end result look horrible and does not 
display all APL chars. 

So I either need another font or I am doing something wrong. 

TIA. It is appreciated. 

Best Regards, 
-- Alexander 

--
You have zero privacy anyway. Get over it.

Scott McNealy 1999

Re: APL X11 font recommendation

[Brian Callahan]

I can't speak for NetBSD, but on OpenBSD, when you install GNU APL from 
OpenBSD packages, you automatically install an additional package of 
Apl333.ttf and Apl385.ttf. This works fine, and has the added benefit of 
letting OpenBSD set up the fonts for you, so you can immediately be on 
your way to using GNU APL without any extra setup.


If you're familiar with pkgsrc, you might consider adding the fonts 
there and let pkgsrc take care of all the setup for you and everyone 
else who may come to APL via pkgsrc.


~Brian

On 2020-05-01 1:04 PM, Alexander Shendi (Web.DE) wrote:

Hi all,

I am now shopping for an APL font to use with X11R7 on NetBSD 9. I 
have already tried the stuff from APL385.com. The procedure was as 
follows:

1. Copy the font files into /usr/pkg/share/fonts/X11/TTF/.
2. Execute "/usr/X11R7/bin/mkfontscale"
3. Execute "/usr/X11R7/bin/mkfontdir"
4. Execute "xset +fp /usr/pkg/share/fonts/X11/TTF"
5. Execute "xset fp rehash"
6. Check with xlsfonts that the APL fonts are available.
7. Set the locale to UTF-8 by setting LC_ALL and LANG to "en_US. UTF-8".

If there is anything wrong with this, please let me know.

I do have the fonts available, but the end result look horrible and 
does not display all APL chars.


So I either need another font or I am doing something wrong.

TIA. It is appreciated.

Best Regards,
-- Alexander

--
You have zero privacy anyway. Get over it.

Scott McNealy 1999 

Re: Error building APL

[Blake McBride]

Hi Jürgen,

Being the author of a portable, C-based Object-Oriented Extension to the C
language (https://github.com/blakemcbride/Dynace) and the Kiss Web
Development Framework (https://kissweb.org/), I sympathize with you.  In
fact, I would guess that I've spent nearly as much time with build systems
and portability issues as I have on the systems themselves.  With respect
to Dynace, I had the same goals - build with no warnings.  In the end,
however, I found it impossible.  I gave up, did what I could but ignored
the ones that were BS.

I think it is very important that GNU APL build without investigation
(looking at README-11-bogus-compiler-warnings).  If GNU APL doesn't build
out-of-the-box, most first-time users will give up and remove it.  For this
reason, I think allowing the build to proceed is very important.
README-11-bogus-compiler-warnings can be used to explain the warnings and
ways of eliminating them by lowering the warning level of the compiler.
Meanwhile, when *you* build, you can pay close attention to the warnings to
be sure you're not doing anything wrong.  Having the build fail and forcing
a new user to investigate the issue is a sure way to lose new users.

Just some opinions.

Thanks!

Blake


On Fri, May 1, 2020 at 10:52 AM Dr. Jürgen Sauermann <
mail@jürgen-sauermann.de> wrote:

> Hi Blake,
>
> this is kind of a dilemma. On the one hand I have the ambition that the
> build should be as clean as
> possible. In the majority of cases the warnings point at something that
> needs to be improved. Many
> reports come from platforms that I do not posses, or from a compiler
> version that I do not use (like in
> the example below). On the other hand the number of bogus compiler
> warnings has increased
> significantly in the last few years and the warnings get increasingly
> stupid (e.g. -Wmisleading-indentation)
>
> The idea of *README-11-bogus-compiler-warnings* was to give the user an
> idea of how to fix
> a build that is broken by a new bogus compiler warning so that I can
> prioritize the fix of the warning
> a little down without loosing the reports about the warnings.
>
> Best Regards,
> Jürgen
>
>
> On 5/1/20 4:59 PM, Blake McBride wrote:
> > Or, as a solution I've used in the past, don't kill the build on a
> > warning.  Just issue the warning and keep going.  This is the default
> > behavior of make.  Errors are errors that should be fixed.  Warnings
> > are things the compiler points out that you may want to look into.  It
> > isn't saying they're wrong.
> >
> > I think it is often the case that making a few tweaks to minimize
> > warnings is good.  However, as you've noted, trying to eliminate every
> > warning is more than a fulltime job.
> >
> > Thanks!
> >
> > Blake
> >
> >
> > On Fri, May 1, 2020 at 9:43 AM Dr. Jürgen Sauermann
> > mailto:mail@j%C3%BCrgen-sauermann.de>> wrote:
> >
> > Hi everybody,
> >
> > it seems like gcc/g++ continues to generate bogus warnings at a
> > rate that makes it difficult to
> > keep up with. For that reason I have written a
> > *README-11-bogus-compiler-warnings* which
> > explains how to deal with this. *SVN 1276*.
> >
> > Maybe somebody would like to report this as a compiler error.
> > Strictly speaking it is not
> > because the warning itself says "maybe", but IMHO it should not
> > occur under *-Wall*
> > but only under *-Wextra*.
> >
> > Best Regards,
> > Jürgen
> >
> >
> > On 5/1/20 4:06 PM, Blake McBride wrote:
> >> Greetings,
> >>
> >> Trying to build GNU APL rev 1275 on my 64-bit Linux box I get:
> >>
> >> [...]
> >> mv -f .deps/apl-Bif_OPER2_RANK.Tpo .deps/apl-Bif_OPER2_RANK.Po
> >> g++ -DHAVE_CONFIG_H -I. -I..-Wall -I sql -Werror
> >> -I/usr/include -I/usr/include/postgresql   -rdynamic -g -O2 -MT
> >> apl-Bif_OPER1_REDUCE.o -MD -MP -MF .deps/apl-Bif_OPER1_REDUCE.Tpo
> >> -c -o apl-Bif_OPER1_REDUCE.o `test -f 'Bif_OPER1_REDUCE.cc' ||
> >> echo './'`Bif_OPER1_REDUCE.cc
> >> In file included from PrintBuffer.hh:30:0,
> >>  from Cell.hh:30,
> >>  from CharCell.hh:24,
> >>  from Value.hh:24,
> >>  from NamedObject.hh:25,
> >>  from Function.hh:27,
> >>  from PrimitiveFunction.hh:27,
> >>  from PrimitiveOperator.hh:24,
> >>  from Bif_OPER1_REDUCE.hh:24,
> >>  from Bif_OPER1_REDUCE.cc:23:
> >> Shape.hh: In member function ‘Token
> >> Bif_REDUCE::reduce_n_wise(Value_P, Token&, Value_P, uAxis)’:
> >> Shape.hh:133:18: error: ‘shape_Z.Shape::rho[axis]’ may be used
> >> uninitialized in this function [-Werror=maybe-uninitialized]
> >>  if (rho[r])   { volume /= rho[r];  rho[r] = sh;  volume
> >> *= rho[r]; }
> >>  ~^
> >> Shape.hh:109:41: error: ‘shape_Z.Shape::rho[axis]’ may be used
> >> uninitialized in this

Re: APL X11 font recommendation

[carl hansen]

On Fri, May 1, 2020 at 10:04 AM Alexander Shendi (Web.DE)
 wrote:
>
> Hi all,
>
> I am now shopping for an APL font to use with X11R7 on NetBSD 9. I have 
> already tried the stuff from APL385.com.

try FreeMono in
https://www.gnu.org/software/freefont/
or
https://ftp.gnu.org/gnu/unifont/unifont-13.0.02/Unifont-APL8x16-13.0.02.psf.gz
Let us know your experiences.

Re: Error building APL

[Peter Teeson]

Is there a place for using CMAKE?  
Abstracting the global aspects?
Or alternatively just no longer supporting older releases of OS’ and Compilers?

Just musing.

Peter


> On May 1, 2020, at 1:48 PM, Blake McBride  wrote:
> 
> Hi Jürgen,
> 
> Being the author of a portable, C-based Object-Oriented Extension to the C 
> language (https://github.com/blakemcbride/Dynace 
> ) and the Kiss Web Development 
> Framework (https://kissweb.org/ ), I sympathize with 
> you.  In fact, I would guess that I've spent nearly as much time with build 
> systems and portability issues as I have on the systems themselves.  With 
> respect to Dynace, I had the same goals - build with no warnings.  In the 
> end, however, I found it impossible.  I gave up, did what I could but ignored 
> the ones that were BS.
> 
> I think it is very important that GNU APL build without investigation 
> (looking at README-11-bogus-compiler-warnings).  If GNU APL doesn't build 
> out-of-the-box, most first-time users will give up and remove it.  For this 
> reason, I think allowing the build to proceed is very important.  
> README-11-bogus-compiler-warnings can be used to explain the warnings and 
> ways of eliminating them by lowering the warning level of the compiler.  
> Meanwhile, when *you* build, you can pay close attention to the warnings to 
> be sure you're not doing anything wrong.  Having the build fail and forcing a 
> new user to investigate the issue is a sure way to lose new users.
> 
> Just some opinions.
> 
> Thanks!
> 
> Blake
> 
> 
> On Fri, May 1, 2020 at 10:52 AM Dr. Jürgen Sauermann 
> mailto:mail@j%C3%BCrgen-sauermann.de>> wrote:
> Hi Blake,
> 
> this is kind of a dilemma. On the one hand I have the ambition that the
> build should be as clean as
> possible. In the majority of cases the warnings point at something that
> needs to be improved. Many
> reports come from platforms that I do not posses, or from a compiler
> version that I do not use (like in
> the example below). On the other hand the number of bogus compiler
> warnings has increased
> significantly in the last few years and the warnings get increasingly
> stupid (e.g. -Wmisleading-indentation)
> 
> The idea of *README-11-bogus-compiler-warnings* was to give the user an
> idea of how to fix
> a build that is broken by a new bogus compiler warning so that I can
> prioritize the fix of the warning
> a little down without loosing the reports about the warnings.
> 
> Best Regards,
> Jürgen
> 
> 
> On 5/1/20 4:59 PM, Blake McBride wrote:
> > Or, as a solution I've used in the past, don't kill the build on a
> > warning.  Just issue the warning and keep going.  This is the default
> > behavior of make.  Errors are errors that should be fixed.  Warnings
> > are things the compiler points out that you may want to look into.  It
> > isn't saying they're wrong.
> >
> > I think it is often the case that making a few tweaks to minimize
> > warnings is good.  However, as you've noted, trying to eliminate every
> > warning is more than a fulltime job.
> >
> > Thanks!
> >
> > Blake
> >
> >
> > On Fri, May 1, 2020 at 9:43 AM Dr. Jürgen Sauermann
> > mailto:mail@j%C3%BCrgen-sauermann.de> 
> > %C3%BCrgen-sauermann.de 
> > >> wrote:
> >
> > Hi everybody,
> >
> > it seems like gcc/g++ continues to generate bogus warnings at a
> > rate that makes it difficult to
> > keep up with. For that reason I have written a
> > *README-11-bogus-compiler-warnings* which
> > explains how to deal with this. *SVN 1276*.
> >
> > Maybe somebody would like to report this as a compiler error.
> > Strictly speaking it is not
> > because the warning itself says "maybe", but IMHO it should not
> > occur under *-Wall*
> > but only under *-Wextra*.
> >
> > Best Regards,
> > Jürgen
> >
> >
> > On 5/1/20 4:06 PM, Blake McBride wrote:
> >> Greetings,
> >>
> >> Trying to build GNU APL rev 1275 on my 64-bit Linux box I get:
> >>
> >> [...]
> >> mv -f .deps/apl-Bif_OPER2_RANK.Tpo .deps/apl-Bif_OPER2_RANK.Po
> >> g++ -DHAVE_CONFIG_H -I. -I..-Wall -I sql -Werror
> >> -I/usr/include -I/usr/include/postgresql   -rdynamic -g -O2 -MT
> >> apl-Bif_OPER1_REDUCE.o -MD -MP -MF .deps/apl-Bif_OPER1_REDUCE.Tpo
> >> -c -o apl-Bif_OPER1_REDUCE.o `test -f 'Bif_OPER1_REDUCE.cc' ||
> >> echo './'`Bif_OPER1_REDUCE.cc
> >> In file included from PrintBuffer.hh:30:0,
> >>  from Cell.hh:30,
> >>  from CharCell.hh:24,
> >>  from Value.hh:24,
> >>  from NamedObject.hh:25,
> >>  from Function.hh:27,
> >>  from PrimitiveFunction.hh:27,
> >>  from PrimitiveOperator.hh:24,
> >>  from Bif_OPER1_REDUCE.hh:24,
> >>  from Bif_OPER1_REDUCE.cc:23:
> >> S

Re: Error building APL

[Dr . Jürgen Sauermann]

  
  
Hi Peter,
  
  my experience with cmake is rather bad. I once wanted to install a
  rather
  trivial source package whose build was based on cmake. It turned
  out that installing cmake itself was rather awkward and took far
  longer
  than the package that I originally aimed at. This was, of course,
  before
  apt and friends so you had to manage cmake's dependencies manually
  (and recursively).
  
  With GNU APL I wanted to save the user's that trouble. The beauty
  of
  ./configure is that it works without installing the autotools.
  
  Best Regards,
  Jürgen
  

On 5/1/20 8:28 PM, Peter Teeson wrote:


  
  Is there a place
for using CMAKE?  
  Abstracting the
global aspects?
  Or alternatively
just no longer supporting older releases of OS’ and Compilers?
  
  
  Just musing.
  
  
  Peter
  
  
  

  
On May 1, 2020, at 1:48 PM, Blake McBride 
  wrote:


  
Hi Jürgen,
  
  
  Being the author of a portable, C-based
Object-Oriented Extension to the C language (https://github.com/blakemcbride/Dynace)
and the Kiss Web Development Framework (https://kissweb.org/),
I sympathize with you.  In fact, I would guess that
I've spent nearly as much time with build systems
and portability issues as I have on the systems
themselves.  With respect to Dynace, I had the same
goals - build with no warnings.  In the end,
however, I found it impossible.  I gave up, did what
I could but ignored the ones that were BS.
  
  
  I think it is very important that GNU
APL build without investigation (looking at
README-11-bogus-compiler-warnings).  If GNU APL
doesn't build out-of-the-box, most first-time users
will give up and remove it.  For this reason, I
think allowing the build to proceed is very
important.  README-11-bogus-compiler-warnings can be
used to explain the warnings and ways of eliminating
them by lowering the warning level of the compiler. 
Meanwhile, when *you* build, you can pay close
attention to the warnings to be sure you're not
doing anything wrong.  Having the build fail and
forcing a new user to investigate the issue is a
sure way to lose new users.
  
  
  Just some opinions.
  
  
  Thanks!
  
  
  Blake
  
  



  On Fri, May 1, 2020
at 10:52 AM Dr. Jürgen Sauermann 
wrote:
  
  Hi Blake,

this is kind of a dilemma. On the one hand I have
the ambition that the
build should be as clean as
possible. In the majority of cases the warnings
point at something that
needs to be improved. Many
reports come from platforms that I do not posses, or
from a compiler
version that I do not use (like in
the example below). On the other hand the number of
bogus compiler
warnings has increased
significantly in the last few years and the warnings
get increasingly
stupid (e.g. -Wmisleading-indentation)

The idea of *README-11-bogus-compiler-warnings* was
to give the user an
idea of how to fix
a build that is broken by a new bogus compiler
warning so that I can
prioritize the fix of the warning
a little down without loosing the reports about the
warnings.

Best Regards,
Jürgen


On 5/1/20 4:59 PM, Blake McBride wrote:
> Or, as a solution I've used in the past, don't
kill the build on a
> warning.  Just issue the war

Re: Error building APL

[Rowan Cannaday]

What about excluding certain "error on warning" flags, except when
compiling in developer mode?

For example, make `CXXFLAGS=-Werror=maybe-uninitialized ./configure` the
default and force an error when configuring with `DEVELOP_WANTED=yes`.

- Rowan

On Fri, May 1, 2020 at 6:41 PM Dr. Jürgen Sauermann <
mail@jürgen-sauermann.de> wrote:

> Hi Peter,
>
> my experience with cmake is rather bad. I once wanted to install a rather
> trivial source package whose build was based on cmake. It turned
> out that installing cmake itself was rather awkward and took far longer
> than the package that I originally aimed at. This was, of course, before
> apt and friends so you had to manage cmake's dependencies manually
> (and recursively).
>
> With GNU APL I wanted to save the user's that trouble. The beauty of
> ./configure is that it works without installing the autotools.
>
> Best Regards,
> Jürgen
>
>
> On 5/1/20 8:28 PM, Peter Teeson wrote:
>
> Is there a place for using CMAKE?
> Abstracting the global aspects?
> Or alternatively just no longer supporting older releases of OS’ and
> Compilers?
>
> Just musing.
>
> Peter
>
>
> On May 1, 2020, at 1:48 PM, Blake McBride  wrote:
>
> Hi Jürgen,
>
> Being the author of a portable, C-based Object-Oriented Extension to the C
> language (https://github.com/blakemcbride/Dynace) and the Kiss Web
> Development Framework (https://kissweb.org/), I sympathize with you.  In
> fact, I would guess that I've spent nearly as much time with build systems
> and portability issues as I have on the systems themselves.  With respect
> to Dynace, I had the same goals - build with no warnings.  In the end,
> however, I found it impossible.  I gave up, did what I could but ignored
> the ones that were BS.
>
> I think it is very important that GNU APL build without investigation
> (looking at README-11-bogus-compiler-warnings).  If GNU APL doesn't build
> out-of-the-box, most first-time users will give up and remove it.  For this
> reason, I think allowing the build to proceed is very important.
> README-11-bogus-compiler-warnings can be used to explain the warnings and
> ways of eliminating them by lowering the warning level of the compiler.
> Meanwhile, when *you* build, you can pay close attention to the warnings to
> be sure you're not doing anything wrong.  Having the build fail and forcing
> a new user to investigate the issue is a sure way to lose new users.
>
> Just some opinions.
>
> Thanks!
>
> Blake
>
>
> On Fri, May 1, 2020 at 10:52 AM Dr. Jürgen Sauermann <
> mail@jürgen-sauermann.de> wrote:
>
>> Hi Blake,
>>
>> this is kind of a dilemma. On the one hand I have the ambition that the
>> build should be as clean as
>> possible. In the majority of cases the warnings point at something that
>> needs to be improved. Many
>> reports come from platforms that I do not posses, or from a compiler
>> version that I do not use (like in
>> the example below). On the other hand the number of bogus compiler
>> warnings has increased
>> significantly in the last few years and the warnings get increasingly
>> stupid (e.g. -Wmisleading-indentation)
>>
>> The idea of *README-11-bogus-compiler-warnings* was to give the user an
>> idea of how to fix
>> a build that is broken by a new bogus compiler warning so that I can
>> prioritize the fix of the warning
>> a little down without loosing the reports about the warnings.
>>
>> Best Regards,
>> Jürgen
>>
>>
>> On 5/1/20 4:59 PM, Blake McBride wrote:
>> > Or, as a solution I've used in the past, don't kill the build on a
>> > warning.  Just issue the warning and keep going.  This is the default
>> > behavior of make.  Errors are errors that should be fixed.  Warnings
>> > are things the compiler points out that you may want to look into.  It
>> > isn't saying they're wrong.
>> >
>> > I think it is often the case that making a few tweaks to minimize
>> > warnings is good.  However, as you've noted, trying to eliminate every
>> > warning is more than a fulltime job.
>> >
>> > Thanks!
>> >
>> > Blake
>> >
>> >
>> > On Fri, May 1, 2020 at 9:43 AM Dr. Jürgen Sauermann
>> > mailto:mail@j%C3%BCrgen-sauermann.de>>
>> wrote:
>> >
>> > Hi everybody,
>> >
>> > it seems like gcc/g++ continues to generate bogus warnings at a
>> > rate that makes it difficult to
>> > keep up with. For that reason I have written a
>> > *README-11-bogus-compiler-warnings* which
>> > explains how to deal with this. *SVN 1276*.
>> >
>> > Maybe somebody would like to report this as a compiler error.
>> > Strictly speaking it is not
>> > because the warning itself says "maybe", but IMHO it should not
>> > occur under *-Wall*
>> > but only under *-Wextra*.
>> >
>> > Best Regards,
>> > Jürgen
>> >
>> >
>> > On 5/1/20 4:06 PM, Blake McBride wrote:
>> >> Greetings,
>> >>
>> >> Trying to build GNU APL rev 1275 on my 64-bit Linux box I get:
>> >>
>> >> [...]
>> >> mv -f .deps/apl-Bif_OPER2_RANK.Tpo .deps/apl-Bif_OPER2_RANK.Po

Re: Error building APL

[Christian Robert]

Had to use this to compile on Fedora 32 with gcc 10.0.1

CXXFLAGS="-Wno-maybe-uninitialized -Wno-class-memaccess" ./configure

Xtian.


On 2020-05-01 14:41, Dr. Jürgen Sauermann wrote:

Hi Peter,

my experience with cmake is rather bad. I once wanted to install a rather
trivial source package whose build was based on cmake. It turned
out that installing cmake itself was rather awkward and took far longer
than the package that I originally aimed at. This was, of course, before
apt and friends so you had to manage cmake's dependencies manually
(and recursively).

With GNU APL I wanted to save the user's that trouble. The beauty of
./configure is that it works without installing the autotools.

Best Regards,
Jürgen


On 5/1/20 8:28 PM, Peter Teeson wrote:

Is there a place for using CMAKE?
Abstracting the global aspects?
Or alternatively just no longer supporting older releases of OS’ and Compilers?

Just musing.

Peter



On May 1, 2020, at 1:48 PM, Blake McBride mailto:blake1...@gmail.com>> wrote:

Hi Jürgen,

Being the author of a portable, C-based Object-Oriented Extension to the C 
language (https://github.com/blakemcbride/Dynace) and the Kiss Web Development 
Framework (https://kissweb.org/), I sympathize with you.  In fact, I would 
guess that I've spent nearly as much time with build systems and portability 
issues as I have on the systems themselves.  With respect to Dynace, I had the 
same goals - build with no warnings.  In the end, however, I found it 
impossible.  I gave up, did what I could but ignored the ones that were BS.

I think it is very important that GNU APL build without investigation (looking 
at README-11-bogus-compiler-warnings).  If GNU APL doesn't build 
out-of-the-box, most first-time users will give up and remove it.  For this 
reason, I think allowing the build to proceed is very important.  
README-11-bogus-compiler-warnings can be used to explain the warnings and ways 
of eliminating them by lowering the warning level of the compiler. Meanwhile, 
when *you* build, you can pay close attention to the warnings to be sure you're 
not doing anything wrong.  Having the build fail and forcing a new user to 
investigate the issue is a sure way to lose new users.

Just some opinions.

Thanks!

Blake


On Fri, May 1, 2020 at 10:52 AM Dr. Jürgen Sauermann mailto:mail@j%C3%BCrgen-sauermann.de>> wrote:

Hi Blake,

this is kind of a dilemma. On the one hand I have the ambition that the
build should be as clean as
possible. In the majority of cases the warnings point at something that
needs to be improved. Many
reports come from platforms that I do not posses, or from a compiler
version that I do not use (like in
the example below). On the other hand the number of bogus compiler
warnings has increased
significantly in the last few years and the warnings get increasingly
stupid (e.g. -Wmisleading-indentation)

The idea of *README-11-bogus-compiler-warnings* was to give the user an
idea of how to fix
a build that is broken by a new bogus compiler warning so that I can
prioritize the fix of the warning
a little down without loosing the reports about the warnings.

Best Regards,
Jürgen


On 5/1/20 4:59 PM, Blake McBride wrote:
> Or, as a solution I've used in the past, don't kill the build on a
> warning.  Just issue the warning and keep going.  This is the default
> behavior of make.  Errors are errors that should be fixed.  Warnings
> are things the compiler points out that you may want to look into.  It
> isn't saying they're wrong.
>
> I think it is often the case that making a few tweaks to minimize
> warnings is good.  However, as you've noted, trying to eliminate every
> warning is more than a fulltime job.
>
> Thanks!
>
> Blake
>
>
> On Fri, May 1, 2020 at 9:43 AM Dr. Jürgen Sauermann
> mailto:mail@j%C3%BCrgen-sauermann.de> %C3%BCrgen-sauermann.de >> wrote:
>
>     Hi everybody,
>
>     it seems like gcc/g++ continues to generate bogus warnings at a
>     rate that makes it difficult to
>     keep up with. For that reason I have written a
>     *README-11-bogus-compiler-warnings* which
>     explains how to deal with this. *SVN 1276*.
>
>     Maybe somebody would like to report this as a compiler error.
>     Strictly speaking it is not
>     because the warning itself says "maybe", but IMHO it should not
>     occur under *-Wall*
>     but only under *-Wextra*.
>
>     Best Regards,
>     Jürgen
>
>
>     On 5/1/20 4:06 PM, Blake McBride wrote:
>>     Greetings,
>>
>>     Trying to build GNU APL rev 1275 on my 64-bit Linux box I get:
>>
>>     [...]
>>     mv -f .deps/apl-Bif_OPER2_RANK.Tpo .deps/apl-Bif_OPER2_RANK.Po
>>     g++ -DHAVE_CONFIG_H -I. -I..    -Wall -I sql -Werror
>>

[Bug c++/94905] Bogus warning -Werror=maybe-uninitialized

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94905

--- Comment #1 from Marc Glisse  ---
Several of us asked, and it was rejected. Your next step is to provide a
self-contained testcase (preprocessed sources?). You may also want to check if
it still warns in gcc-10.

-- 
You are receiving this mail because:
You reported the bug.