Re: [Axiom-developer] [Maxima] GCL 2.6.8 and 2.6.9 are released

[Henry Baker]

Thanks very much to you & the GCL team!

Q: What about maximum _bind stack_ size on Windows & other platforms?

I recently ran up against the size of this "bind stack", and was told that
its size was compiled in.

Here's how to fix stack overflow problems in SBCL, but it doesn't work for GCL:
-----
I found an obscure Cygwin utility called 'peflags' that can be used to change 
the amount of stack for _any_ Windows executable -- not just Cygwin exectables.

Thus, I was able to change the stack size for SBCL Lisp with the following 
command in the appropriate directory under 'Program Files':

   Query the current stack-reserve setting

peflags --stack-reserve sbcl.exe
sbcl.exe: stack reserve size    : 2097152 (0x200000) bytes

   Provide a new stack-reserve setting

peflags --stack-reserve=0x1000000 sbcl.exe
sbcl.exe: stack reserve size    : 16777216 (0x1000000) bytes

Note that sbcl.exe is a relatively small program which loads the main sbcl.core 
image.  Nevertheless, sbcl.exe sets the amount of stack for the whole program.

'peflags' can also adjust other settings, as well, including heap size, etc.

I have no idea if 'peflags' will work correctly on 64-bit applications, though.
-----

At 08:48 AM 8/27/2013, Camm Maguire wrote:
>Greetings!  The GCL team is happy to announce a pair of stable releases at
>
>ftp://ftp.gnu.org/gnu/gcl/gcl_2.6.8.tar.gz
>and
>ftp://ftp.gnu.org/gnu/gcl/gcl_2.6.9.tar.gz
>
>Please also see the homepage and release notes at
>
>http://www.gnu.org/software/gcl.
>
>The 2.6.8 release represents several years worth of fixes and
>enhancements, notably a great extension of GCL's native object file
>relocation support.  
>
>2.6.9 is released concurrently as it contains a number of structural
>improvements which, while passing all our tests, may cause issues for
>some people.  These improvements are chiefly a two word cons, immediate
>fixnum support, word sized fixnums (64bits on 64bit machines), and a
>'dynamic maxpage' implementation, which removes all compile time limits
>to the heap size and auxiliary typing and marking tables.  2.6.9 will
>attempt to manage the heap given the apparent constraints of the running
>system, with the goal of eliminating allocation failures and handling
>out of memory conditions in advance with a modicum of grace.  As this
>involves a runtime startup probe of brk, which has varying degrees of
>significance in different operating systems, one might still experience
>overallocation of memory (notably on hurd).  In such cases, 
>
>gcl -eval '(si::set-log-maxpage-bound x)'
>
>will limit the heap to 2^x bytes as a workaround.
>
>All gcl, maxima, acl2, axiom, and hol88 builds and self tests pass for
>the following platforms, with noted exceptions(*) itemized below:
>
>debian: amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64
>kfreebsd-i386 mips mipsel powerpc s390 s390x sparc
>
>debian-ports: alpha hppa m68k powerpcspe ppc64 sh4 sparc64 x32
>
>macosx, windows
>
>*exceptions
>
>1) all systems use native object relocation by default now but ia64 and
>ppc64, which use dlopen.  Thus there is a typical limit of 1024 files
>that can be loaded, and the current acl2 build exceeds this limit.  As
>this bound is runtime configurable with root access, this is not an
>insurmountable obstacle.
>
>2) kfreebsd-i386 systems do not appear to allow one to brk more than
>500M of memory, and the acl2 certification process needs 1Gb.  A
>solution here is as yet unknown but may be forthcoming shortly.
>
>3) windows builds have been performed on win95.  There is an as yet
>unidentified runtime error running the 2.6.9 images on win7.  More
>information here will be forthcoming shortly.
>
>Windows installers can be found at ftp://ftp.gnu.org/gnu/gcl.
>
>4) macosx builds have been tested on snow leopard.  More recent versions
>appear to have a linker bug which prevents configure from detecting the
>provided profil() routine.  A workaround here should be to 
>
>echo "#undef NO_PROFILE >>h/config.h" 
>
>after configure and before make.
>
>GCL has moved to the git version control system.  The 2.6.8 and 2.6.9
>branches and tags are identical in cvs and git.  Henceforward,
>modifications will be made to git only.  As of the present writing, git
>contains a merge of experimental into master, and a port of most 2.6.x
>improvements into master.  This will form the basis of a 2.7.0 release
>sometime in the future.
>
>For those unfamiliar with git:
>
>git clone git://git.sv.gnu.org/gcl.git
>cd gcl
>git checkout master, or git checkout Version_2_6_9, etc.
>cd gcl
>./configure && make
>
>git can of course provide much more.  I'm currently using Egg, an emacs
>interface to git, with increasing success.  Merging, logging, bisecting,
>branching, and uploading appear much simpler.  I recommend this tool to
>would-be gcl contributors.
>
>Feedback as always most welcome!
>
>Take care,
>-- 
>Camm Maguire                                        address@hidden
>==========================================================================
>"The earth is but one country, and mankind its citizens."  --  Baha'u'llah