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> <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> >> <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 >> >> >> >> >> >> >> >> > > >
