gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gcl-2.6.13 released [stable]


From: Camm Maguire
Subject: Re: gcl-2.6.13 released [stable]
Date: Wed, 21 Dec 2022 12:23:14 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Greetings, and thanks so much for your feedback!

My strong guess is that you are using gcc-12.  There is a known bug
therein preventing gcl from using it until fixed.  I anticipate this
won't take too long, so have not put any configure checks etc. in the
way.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023756

Please let me know if problems persist with gcc <= 11.  You should be
able to do CC=gcc-11 ./configure .... when building gcl and that will
take care of it.

Take care,

Raymond Toy <toy.raymond@gmail.com> writes:

> On Tue, Dec 20, 2022 at 10:58 AM Camm Maguire 
> <camm@transcendence.maguirefamily.org> wrote:
>
>  Greetings!  The GCL team is happy to announce the release of version
>  2.6.13, the latest achievement in the 'stable' (as opposed to
>  'development') series.  Please see http://www.gnu.org/software/gcl for
>  downloading information.
>
>  This release consolidates several years of work on GCL internals,
>  performance and ansi compliance.
>
> I got the release from git and built it without problems.  Built maxima too, 
> but I get memory corruption errors and a fatal segfault runnint the 
> testsuite.  I'm using the current maxima HEAD, not your cleanup banch. (Which 
> looks really nice, BTW.)
>
>  Garbage collection has been overhauled and significantly accelerated.
>  Contiguous block handling is now as fast as or perhaps faster than
>  relblock handling, leading to the now implemented promotion of relblock
>  data to contiguous after a surviving a number of gc calls.  Relblock is
>  only written once during gc.  Heap allocation is fully dynamic at
>  runtime and controllable with environment variables without
>  recompilation.  While SGC is supported, it is found in practice to be
>  less useful with modern large memory cores and is off by default.  </p>
>
>  GCC on several platforms defaults to code which must lie within a common
>  2Gb space, now an issue with heaps routinely larger than this.  Error
>  protection for code address overflow is in place on most machines.  The
>  variable si::*code-block-reserve* can be set to a static array of
>  element type 'character to preallocate a code block early within an
>  acceptable range.  On amd64, compile-file takes a :large-memory-model-p
>  keyword (with compiler::*default-large-memory-model-p*) to compile
>  somewhat slower code which can be loaded at an arbitrary address.
>
>  The COMMON-LISP package is fixed to the ansi standard.  A CLTL1-COMPAT
>  package is defined to support earlier applications, and is used in
>  non-ansi builds.
>
>  GCL can optionally manage a single heap load across multiple processes
>  via the GCL_MULTIPROCESS_MEMORY_POOL environment variable.  GCL can
>  compile gprof profiling code in non-profiling images using the :prof-p
>  keyword to compile, causing '(si::gprof-start)(...)(si::gprof-quit)' to
>  only report calls to such code.  GCL supports riscv4, and 64bit cygwin
>  on Windows in addition to the previous 21 architectures.  GCL has
>  extensive support for hardware floating point exception handling via the
>  #'si::break-on-floating-point-exceptions function, taking the floating
>  point errors as keyword arguments.
>
>  Several ANSI compliance errors have been fixed, most particularly in
>  pathnames and restarts.  Hashtables have been accelerated, supporting
>  caching, static allocation, and 'equalp tests.
>
>  Circle detection and handling has been greatly accelerated, using the gc
>  marking algorithm for a copy-less implementation.
>
>  The compiler no longer writes data files reordering
>  "package-operations", changing the data file format to one loadable on
>  object file initialization.
>
>  Floating point reading and writing has been made more precise.  Inf/nan
>  handling matches IEEE specifications.
>
>  Here are the compressed sources and a GPG detached signature:
>    https://www.gnu.org/software/gcl//gcl-2.6.13.tar.gz
>    https://www.gnu.org/software/gcl//gcl-2.6.13.tar.gz.sig
>
>  Use a mirror for higher download bandwidth:
>    https://www.gnu.org/order/ftp.html
>
>  Here are the SHA1 and SHA256 checksums:
>
>  15b99ce0a0274ea1487866593d1262b0ce0051fa  gcl-2.6.13.tar.gz
>  8OnPPf67vS3iJo9GC49W/ItKGRRBs2IAF+RLJcmssY4  gcl-2.6.13.tar.gz
>
>  The SHA256 checksum is base64 encoded, instead of the
>  hexadecimal encoding that most checksum tools default to.
>
>  Use a .sig file to verify that the corresponding file (without the
>  .sig suffix) is intact.  First, be sure to download both the .sig file
>  and the corresponding tarball.  Then, run a command like this:
>
>    gpg --verify gcl-2.6.13.tar.gz.sig
>
>  The signature should match the fingerprint of the following key:
>
>    pub   dsa1024 2002-08-23 [SCA]
>          F1B0 68F9 933A AC36 2A30  A795 7331 B5C0 57F0 45DC
>    uid           [ unknown] Camm Maguire <camm@debian.org>
>    uid           [ unknown] Camm Maguire <camm@enhanced.com>
>
>  If that command fails because you don't have the required public key,
>  or that public key has expired, try the following commands to retrieve
>  or refresh it, and then rerun the 'gpg --verify' command.
>
>    gpg --recv-keys F1B068F9933AAC362A30A7957331B5C057F045DC
>
>  As a last resort to find the key, you can try the official GNU
>  keyring:
>
>    wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
>    gpg --keyring gnu-keyring.gpg --verify gcl-2.6.13.tar.gz.sig
>  -- 
>  Camm Maguire                                        camm@maguirefamily.org
>  ==========================================================================
>  "The earth is but one country, and mankind its citizens."  --  Baha'u'llah

-- 
Camm Maguire                                        camm@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



reply via email to

[Prev in Thread] Current Thread [Next in Thread]