[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GNU Guile 2.1.3 released [beta]
GNU Guile 2.1.3 released [beta]
Sun, 19 Jun 2016 11:31:48 +0200
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
We are pleased to announce GNU Guile release 2.1.3.
Guile 2.1.3 is the third 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
Besides bug fixes, this release has a complete overhaul of the port
implementation. 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.3 can be installed in parallel with Guile 2.0.x; see
A more detailed NEWS summary follows these details on how to get the
Here are the compressed sources:
Here are the GPG detached signatures[*]:
Use a mirror for higher download bandwidth:
Here are the SHA256 checksums:
[*] 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.3.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:
Changes in 2.1.3 (changes since the 2.1.2 alpha release):
* Notable changes
** Complete overhaul of port internals
Guile's ports have been completely overhauled to allow Guile developers
and eventually Guile users to write low-level input and output routines
in Scheme. The new internals will eventually allow for user-space
tasklets or green threads that suspend to a scheduler when they would
cause blocking I/O, allowing users to write straightforward network
services that parse their input and send their output as if it were
blocking, while under the hood Guile can multiplex many active
connections at once.
At the same time, this change makes Guile's ports implementation much
more maintainable, rationalizing the many legacy port internals and
making sure that the abstractions between the user, Guile's core ports
facility, and the port implementations result in a system that is as
performant and expressive as possible.
The interface to the user has no significant change, neither on the C
side nor on the Scheme side. However this refactoring has changed the
interface to the port implementor in an incompatible way. See
"Incompatible changes" below for full details.
** All ports are now buffered, can be targets of `setvbuf'
See "Buffering" in the manual, for more. A port with a buffer size of 1
is equivalent to an unbuffered port. Ports may set their default buffer
sizes, and some ports (for example soft ports) are unbuffered by default
for historical reasons.
** Support for non-blocking I/O
See "Non-Blocking I/O" in the manual, for more.
** Removal of port locks
As part of the 2.2 series, we introduced recursive locks on each port,
and arranged to lock them to avoid crashes but also to serialize I/O in
some ways. This turned out to be a mistake: the port lock does not
necessarily correspond to a program's desired atomic unit of I/O, so
correct programs would likely have to have their own locking. At the
same time the port buffering refactoring made it possible for us to
avoid the crashes that led to the introduction of locking, but without
locks. For that reason we have removed port locks, and removed the
"_unlocked" port API variants that were introduced in 2.1.0.
* New interfaces
** `TCP_NODELAY' and `TCP_CORK' socket options, if provided by the system
** `scm_c_put_latin1_chars', `scm_c_put_utf32_chars'
Use these instead of `scm_lfwrite'. See the new "Using Ports from C"
section of the manual, for more.
* New deprecations
** `_IONBF', `_IOLBF', and `_IOFBF'
Instead, use the symbol values `none', `line', or `block', respectively,
as arguments to the `setvbuf' function.
* Incompatible changes
** Decoding errors do not advance the read pointer before erroring
When the user sets a port's conversion strategy to "error", indicating
that Guile should throw an error if it tries to read from a port whose
incoming bytes are not valid for the port's encoding, it used to be that
Guile would advance the read pointer past the bad bytes, and then throw
an error. This would allow the following `read-char' invocation to
proceed after the bad bytes. This behavior is incompatible with the
final R6RS standard, and besides contravenes the user's intention to
raise an error on bad input. Guile now raises an error without
advancing the read pointer. To skip over a bad encoding, set the port
conversion strategy to "substitute" and read a substitute character.
** Decoding errors with `substitute' strategy return U+FFFD
It used to be that decoding errors with the `substitute' conversion
strategy would replace the bad bytes with a `?' character. This has
been changed to use the standard U+FFFD REPLACEMENT CHARACTER, in
accordance with the Unicode recommendations.
** API to define new port types from C has changed
See the newly expanded "I/O Extensions" in the manual, for full details.
*** Remove `scm_set_port_mark'
Port mark functions have not been called since the switch to the BDW
*** Remove `scm_set_port_equalp'
Likewise port equal functions weren't being called. Given that ports
have their own internal buffers, it doesn't make sense to hook them into
*** Remove `scm_set_port_free'
It used to be that if an open port became unreachable, a special "free"
function would be called instead of the "close" function. Now that the
BDW-GC collector allows us to run arbitrary code in finalizers, we can
simplify to just call "close" on the port and remove the separate free
functions. Note that hooking into the garbage collector has some
overhead. For that reason Guile exposes a new interface,
`scm_set_port_needs_close_on_gc', allowing port implementations to
indicate to Guile whether they need closing on GC or not.
*** Remove `scm_set_port_end_input', `scm_set_port_flush'
As buffering is handled by Guile itself, these functions which were to
manage an implementation-side buffer are no longer needed.
*** Change prototype of `scm_make_port_type'
The `read' (renamed from `fill_input') and `write' functions now operate
on bytevectors. Also the `mode_bits' argument now inplicitly includes
SCM_OPN, so you don't need to include these.
*** Change prototype of port `close' function
The port close function now returns void.
*** Port and port type data structures are now opaque
Port type implementations should now use API to access port state.
However, since the change to handle port buffering centrally, port type
implementations rarely need to access unrelated port state.
*** Port types are now `scm_t_port_type*', not a tc16 value
`scm_make_port_type' now returns an opaque pointer, not a tc16.
Relatedly, the limitation that there only be 256 port types has been
- GNU Guile 2.1.3 released [beta],
Andy Wingo <=