Greetings! If anyone has comments on the following release notes I'd be
appreciative!
=============================================================================
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-1">
</head>
<body style="width: 1000px;">
<br>
<br>
<div align="center"><font size="+2"><b>GCL 2.7.0 RELEASE NOTES<br>
</b></font></div>
<font size="+2"><br>
</font>
<p>
Greetings! The GCL team is happy to announce the release of version
2.7.0, the culmination of many years of work and a major development
in the evolution of GCL. Please see http://www.gnu.org/software/gcl for
downloading information.</p>
Of note:
<p> The GNU build system has been installed.</p>
<p>
The git repository hosts the sources at the maintainer-clean
level, plus some packaging files for various systems. When
building from a git checkout, you should not need autotools, but
you may need to touch the following files in order, as git does
not preserve timestamps: aclocal.m4 configure.in configure
Makefile.am Makefile.in.
<p>
When building from the distributed tarball this will never be
necessary. Furthermore, as is customary this tarball will
include in addition pre-built documentation, so the user will
not need texinfo unless building the optional standard targets
dvi, pdf, and html.
</p>
<p>
The check target will run the ansi-tests and some timing
benchmarks.
</p>
<p>
The dist target will recreate the distribution tarball, and
distcheck will test it.
</p>
<p>
Parallel builds are supported, but you should note that GCL will
work in available system memory be default, and if multiple
processes do not coordinate allocation, the effects could be
negative. The environment variables GCL_MEM_MULTIPLE and
GCL_MEM_BOUND can limit the memory each process sees, and
GCL_MULTIPROCESS_MEMORY_POOL will instruct multiple processes to
manage the memory collectively. These variables and more are
documented in the info pages.
</p>
<p>
Configure enable/disable options for gprof, xgcl, and gcltk will
govern whether these features are built and installed.
</p>
<p>
All known ANSI issues have been resolved, as reflected in the
testsuite run via 'make check'. Both traditional and ANSI images are
built and installed. The ANSI image is selected by {prefix}/bin/gcl
if the environment variable GCL_ANSI is set to any value.
</p>
<p>
This has required some backward non-compatible changes in all
images, most notably that functions are no longer lists
describing the source. One can typically upgrade code
generating old `(lambda ...) functions with the simple
modification (eval `(lambda ...)).
</p>
<p>
GCL functions carry a lot of extra information by default, including
the call signature, the assumed signatures of fast-link callees, the
compressed-string version of the source, and the file from which it
was loaded. This enables some useful features:
<ul>
<li>All functions not referencing static data (i.e. closures,
load-time-value) can be inlined regardless of the (declaim
(inline)) status at function definition. The static data
limitation will hopefully be removed in the future.</li>
<li>GCL fully implements 'function-lambda-expression, usefully
abbreviated with 'si::fle.</li>
<li>GCL provides a utility 'si::do-recomp to identify signature
conflicts and recompile the original source files. The older
utility using optional .fn files to generate a sys-proclaims.lisp is
still supported, but is trumped by the signature information
accompanying the function itself. The old system tried to handle
this on a per-file basis, which was limited as the produced
signatures implicitly depended on signatures in other files. The new
system analyzes all conflicts at once, iterating until consistency
is achieved.</li>
<li>Self-explanatory functions 'si::file and
'si::signature.</li>
<li>GCL provides 'compiler::interpret to reverse 'compile.</li>
<li>Functions 'compile and 'compiler::interpret are idempotent
and can be invoked multiple times.</li>
<li>Heavy use of automatic inlining is used by the compiler.</li>
</ul>
</p>
<p> Limited profiling is available in all images, when supported,
by adding the :prof-p t arguments to compile-file. The
corresponding 'compiler::*default-prof-p* can make this the
default in any image. Only functions thus compiled will appear in
the output of (si::gprof-start)(...)(si::gprof-quit). To profile
all of GCL, the profiling images can be run by setting the
GCL_PROF environment variable to any value before invoking
{prefix}/bin/gcl. The startup banner will let you know which
image you are running.
</p>
<p> On many systems, notably x86_64, the standard code produced by
gcc (the 'medium model') must lie within the first 2Gb of memory.
The variabe 'si::*code-block-reserve* can allocate space for this
early on if needed, for example before running a large job on a
machine with many Gb of available memory. On startup all images
come with an extra 30Mb of space in this variable. Usage is
documented in the info pages.
</p>
<p>
If the heap has grown too large and there is no longer any space
below 2Gb, code can be compiled and loaded for the 'large'
memory model at about a 10% performance penalty. The options
:large-memory-model t to compile-file, or the corresponding
'compiler::*default-large-memory-model-p*, can control this
behaviour. At the moment this support is limited to x86_64
systems.
</p>
<p>
The function 'compiler::watch can take any variable or function
name in addition to several special symbols to trace the
compiler's logic. Some useful special symbols are
'compiler::type-inference, 'compiler::branch-elimination,
'compiler::inline, and 'compiler::tail-recursion. The function
'compiler::unwatch turns off tracing on the supplied arguments,
or universally with no arguments.
</p>
<p> The type system has been completely redesigned around
bit-vectors. The functions 'si::cmp-norm-tp and
'si::cmp-unnorm-tp may be of interest.
</p>
<p> The variable 'compiler::*annotate* if set will place comments
in the generated C file illustrating the inlining. The variable
'compiler::*disassemble-objdump* governs whether assembly
accompanies the C source output of disassemble.
</p>
<p> The variable 'si::*fast-link-warnings* can let you know if
calls to your function cannot be fast linked. All calls
regardless of signatures should proceed correctly, albeit possibly
slowly in case of signature mismatches.</p>
<p> The demo functions 'xgcl-demo and 'gcl-tk-demo have been
updated.</p>
<br>
</body>
</html>
=============================================================================
--
Camm Maguire [email protected]
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
