Re: [Bug-apl] compile error location of malloc.h

[Juergen Sauermann]

Hi, following Blake's proposal, I have stored ftp://ftp.gnu.org/gnu/apl/apl-1.6a.tar.gz onto the GNU FTP server. I suppose there is no point in creating all the different distribution formats since the problem shows only on Macs. Apart from that, SVN is the preferred method of keeping GNU APL up-to-date. /// Jürgen On 09/04/2016 06:54 PM, Blake McBride wrote: Given the popularity of Macs, might I suggest a 1.6a release? Blake On Sun, Sep 4, 2016 at 4:21 AM, Juergen Sauermann <juergen.sauerm...@t-online.de> wrote: Hi Louis, it is of course unfortunate that this bug slipped in just before the 1.6 release was created. But it seems to affect only one platform and is simple to correct manually. Therefore I believe it is more appropriate to handle it like any other bug rather than triggering a new release. /// Jürgen On 09/02/2016 08:48 PM, Louis de Forcrand wrote: I’m sorry to say that this bug is (or was last time I checked) in release 1.6. As it makes it more complicated to compile it on OS X maybe it would be better to fix release 1.6 for people new to GNU APL? Of course it might also be better to wait a little while and include some other fixes in order to make the update worth the effort. Cheers, Louis On 31 Aug 2016, at 03:35, Blake McBride <blake1...@gmail.com> wrote: Here is a +1 for keeping it as straight C as possible. Blake On Tue, Aug 30, 2016 at 4:17 AM, Juergen Sauermann <juergen.sauerm...@t-online.de> wrote: Hi Xiao-Yong, in principle you are right. However I have avoided to use the C++ counterparts of the standard C include files so far  because some of them produce compile errors like this: /usr/include/c++/4.8/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options. and I was afraid that this would negatively impact the portability of GNU APL without giving an advantage. /// Jürgen On 08/29/2016 11:21 PM, Xiao-Yong Jin wrote: There is nothing wrong using <stdlib.h>, but in C++ the standard way is #include<cstdlib> and call std::malloc and its friends. On Aug 29, 2016, at 4:43 AM, Juergen Sauermann <juergen.sauerm...@t-online.de> wrote: Hi, thanks, fixed in SVN 794. I went for <stdlib.h> because that is what the malloc manpage says. Currently <stdlib.h> is aleady #included by Common.hh but that may change. Therefore I believe that it is cleaner to #include it again. /// Jürgen On 08/29/2016 07:21 AM, Elias Mårtenson wrote: They are, but if they are not found in the local directory, they are also searched for in the system directories. That said, in this case using the angle brackets is the correct thing to use. On 29 August 2016 at 13:08, Christian Robert <christian.rob...@polymtl.ca> wrote: that should read: #include <malloc.h> or better #include <stdlib.h> things in double quotes are searched in local directory by default and not in system. Xtian. On 2016-08-28 23:42, Xiao-Yong Jin wrote: LApack.cc:21:20: fatal error: malloc.h: No such file or directory #include "malloc.h" ^ compilation terminated. Under OS X, it’s in /usr/include/malloc/malloc.h Is it actually needed? The code compiles fine without the #include. Best, Xiao-Yong