guile-sources
[Top][All Lists]
Advanced

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

GNU Guile 2.1.2 released [beta]


From: Andy Wingo
Subject: GNU Guile 2.1.2 released [beta]
Date: Wed, 03 Feb 2016 17:08:12 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

We are pleased to announce GNU Guile release 2.1.2.

Guile 2.1.2 is the second pre-release in what will eventually become the
2.2 release series.  We encourage you to test this release and provide
feedback to address@hidden

This release focuses on speed; your programs will run even faster on
Guile 2.1.2 than under 2.1.1.  See the full NEWS below, for details.

The Guile web page is located at http://gnu.org/software/guile/, and
among other things, it contains a copy of the Guile manual and pointers
to more resources.

Guile is an implementation of the Scheme programming language, with
support for many SRFIs, packaged for use in a wide variety of
environments.  In addition to implementing the R5RS Scheme standard,
Guile includes a module system, full access to POSIX system calls,
networking support, multiple threads, dynamic linking, a foreign
function call interface, and powerful string processing.

Guile can run interactively, as a script interpreter, and as a Scheme
compiler to VM bytecode.  It is also packaged as a library so that
applications can easily incorporate a complete Scheme interpreter/VM.
An application can use Guile as an extension language, a clean and
powerful configuration language, or as multi-purpose "glue" to connect
primitives provided by the application.  It is easy to call Scheme code
>From C code and vice versa.  Applications can add new functions, data
types, control structures, and even syntax to Guile, to create a
domain-specific language tailored to the task at hand.

Guile 2.1.2 can be installed in parallel with Guile 2.0.x; see
http://www.gnu.org/software/guile/manual/html_node/Parallel-Installations.html.

A more detailed NEWS summary follows these details on how to get the
Guile sources.

Here are the compressed sources:
  https://alpha.gnu.org/gnu/guile/guile-2.1.2.tar.gz   (17MB)
  https://alpha.gnu.org/gnu/guile/guile-2.1.2.tar.xz   (11MB)

Here are the GPG detached signatures[*]:
  https://alpha.gnu.org/gnu/guile/guile-2.1.2.tar.gz.sig
  https://alpha.gnu.org/gnu/guile/guile-2.1.2.tar.xz.sig

Use a mirror for higher download bandwidth:
  http://www.gnu.org/order/ftp.html

Here are the SHA256 checksums:

016a30dec897227d379fa9137b6cda184ea4eb2745a8e3e5f762777e56d43e99  
guile-2.1.2.tar.gz
2cd5244d78132b217bdf1cb8ac40baec3271027985846de92c5212b0c70c275d  
guile-2.1.2.tar.xz

[*] 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 guile-2.1.2.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys 8812F8F2

and rerun the 'gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.69
  Automake 1.15
  Libtool 2.4.6
  Gnulib v0.1-92-g546ff82
  Makeinfo 6.0


Changes in 2.1.2 (changes since the 2.1.1 alpha release):

* Notable changes

** Unboxed arithmetic

It used to be that Guile's numbers were always boxed with a tag
indicating their type.  Small integers could sometimes represent their
tag and value in one word; these are the fixnums.  Other kinds of
numbers would be allocated on the heap.

Guile can now unbox arithmetic on exact integers (values in the signed
and unsigned 64-bit integer range) and inexact reals (floating-point
numbers).  Access to bytevectors are always unboxed, and some arithmetic
can be unboxed as well.  Unboxing eliminates run-time allocation for
numbers and removes run-time polymorphic dispatch, providing a
significant speedup.

** Faster build times

Building Guile from a tarball can now take advantage of a "prebuilt/"
tree of prebuilt .go files.  These compiled files are created when a
tarball is made, and are used to speed up the build for users of
official releases.

These pre-built binaries are not necessary, however: they are not stored
in revision control and can always be re-created from the source, given
that Guile can bootstrap itself from its minimal bootstrap C
interpreter.  If you do not want to depend on these pre-built binaries,
you can "make -C prebuilt clean" before building.

If Guile doesn't pre-build binaries for your architecture and you would
like support for your architecture, see prebuilt/Makefile.am for more
information on how to add support.

** Better backtraces

Guile's backtraces do a better job at finding the function name, and
they also do a better job printing function arguments whose values are
unavailable.

** Add "tree" display mode for statprof.

See the newly updated "Statprof" section of the manual, for more.

** Many small compiler and VM improvements

The user-visible change is that Guile is faster, for many small reasons.
See the commit log for detailed changes.

Note that until the stable 2.2.0 release is made, we will not make any
efforts towards binary compatibility among 2.1.x releases.  Compiled
Scheme files from older pre-releases in the Guile 2.1.x series are not
loadable by the Guile 2.1.2 pre-release.

** Better handling of GUILE_LOAD_COMPILED_PATH

It used to be that Guile would stop at the first .go file it found in
the GUILE_LOAD_COMPILED_PATH.  If that file turned out to be out of
date, then no .go file would be loaded.  Now Guile will continue to
search the path for a file which is both present and up-to-date, with
respect to the .scm file.

** Fix build when threads are disabled
** Fix cross-compilation of .go files

* New deprecations

** `with-statprof' macro deprecated

Use the `statprof' procedure instead.

* Incompatible changes

** Remove `frame-procedure'

Several optimizations in Guile make `frame-procedure' an interface that
we can no longer support.  For background, `frame-procedure' used to
return the value at slot 0 in a frame, which usually corresponds to the
SCM value of the procedure being applied.  However it could be that this
slot is re-used for some other value, because the closure was not needed
in the function.  Such a re-use might even be for an untagged value, in
which case treating slot 0 as a SCM value is quite dangerous.  It's also
possible that so-called "well-known" closures (closures whose callers
are all known) are optimized in such a way that slot 0 is not a
procedure but some optimized representation of the procedure's free
variables.  Instead, developers building debugging tools that would like
access to `frame-procedure' are invited to look at the source for the
`(system vm frame)' module for alternate interfaces, including the new
`frame-procedure-name'.

** Remove `,procedure' REPL command

Not all procedures have values, so it doesn't make sense to expose this
interface to the user.  Instead, the `,locals' REPL command will include
the callee, if it is live.

** Remove `frame-local-ref', `frame-local-set!', `frame-num-locals'

These procedures reference values in a frame on the stack.  Since we now
have unboxed values of different kinds, it is now necessary to specify
the type when reference locals, and once this incompatible change needs
to be made, we might as well make these interfaces private.  See
"Frames' in the manual, for more information on the replacements for
these low-level interfaces.



reply via email to

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