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]