Then I would suggest leaving a heads-up on the GNU APL home page (in the installing section) explaining how to get around the bug, for people like me :)
Cheers, Louis > On 04 Sep 2016, at 11:21, 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >
