GNU Guile 3.0.2 released

[Ludovic Courtès]

We are delighted to announce GNU Guile release 3.0.2, the second bug-fix
release of the new 3.0 stable series.  This release represents 22
commits by 8 people since version 3.0.1.  See the NEWS excerpt that
follows for full 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, packaged
for use in a wide variety of environments.  In addition to implementing
the R5RS, R6RS, and R7RS Scheme standards, Guile includes full access to
POSIX system calls, networking support, multiple threads, dynamic
linking, a foreign function call interface, powerful string processing,
and HTTP client and server implementations.

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 3.0 can be installed in parallel with Guile 2.2.x; see
http://www.gnu.org/software/guile/manual/html_node/Parallel-Installations.html.

 *  *  *

Changes in 3.0.2 (since 3.0.1)

* New interfaces and functionality

** New (srfi srfi-171) module

This module implements "tranducers" as specified in
.
Thanks to Linus Björnstam for this new API!

** SRFI-14 character data set upgraded to Unicode 13.0.0

* Bug fixes

** Fix heap corruption when allocating structs
   ()

This bug would cause random crashes; users are invited to upgrade.
Thanks to rr () for being instrumental in
finding this bug!

** Fix race condition between 'abort-to-prompt' and stack marking
   ()

This bug could occasionally cause crashes in multi-threaded Guile
programs using delimited continuations or exceptions.

** Ensure weak sets are occasionally vacuumed
   ()

Previously, weak sets, which are used internally for interned symbols
and for ports with SCM_PORT_TYPE_NEEDS_CLOSE_ON_GC, could grow seemingly
indefinitely without being vacuumed.

** Interpret dynamic library name as literal file name first
   ()

Until now, 'dynamic-link' would always append an extension, such as
".so", to the user-provided file names.  Now, 'dynamic-link' first tries
the file name literally, and only then falls back to adding the OS
shared library file name extension.

This allows users to refer to "libsomething.so.1.2.3" instead of
"libsomething.so", the latter being usually provided by "-dev" packages
of GNU/Linux distributions, unlike the former.

**  includes  again

This fixes an omission in Guile 3.0.

** Fix fixpoint computation in compute-significant-bits
   ()

** Fix compilation '--without-threads'
   ()

* New deprecations

** 'tmpnam' is now deprecated

The 'tmpnam' function in the C library has been deprecated for years due
to security concerns; the Scheme procedure 'tmpnam' is now deprecated as
well, in favor of 'mkstemp!'.  In addition, a new '--disable-tmpnam'
option has been added to 'configure' for users who would like to disable
it right away.

 *  *  *

Here are the compressed sources:
  https://ftp.gnu.org/gnu/guile/guile-3.0.2.tar.gz   (21MB)
  https://ftp.gnu.org/gnu/guile/guile-3.0.2.tar.lz   (11MB)
  https://ftp.gnu.org/gnu/guile/guile-3.0.2.tar.xz   (13MB)

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

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

Here are the SHA256 checksums:

  04485e759b2aec44e33cdd06ece28bbb859c1dbef73e8aeac02e4e7ca2fe0e57  
guile-3.0.2.tar.gz
  1d8330d4f0b284d216beef35670b8d8471984e7b2b32a5f2fd3cb10c88751c59  
guile-3.0.2.tar.lz
  53c47d320533c80a3145adbd83e14bbe107c0441c18a8b214ff20849b28a9f8a  
guile-3.0.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-3.0.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 pool.sks-keyservers.net \
 

Re: Replace ltdl with GLib's GModule

[Eli Zaretskii]

> From: Ludovic Courtès 
> Date: Fri, 27 Mar 2020 13:01:38 +0100
> 
> I’m very much tired of “file not found” :-), but I don’t think Guile
> should depend on GLib, which is quite big.

FWIW, I agree.

> I think we should either fix ltdl (probably less work than porting Guile
> to GModule, but also less exciting) or have a very basic wrapper around
> dlopen instead of using ltdl (I think Andy had made experiments in that
> direction.)

If you drop ltdl, the MinGW port of Guile will be broken, as dlopen
there is not guaranteed to exist (it exists in one flavor of MinGW,
but not in the other, which is the most popular one, AFAIK).

So my recommendation would be to fix ltdl.

Re: Replace ltdl with GLib's GModule

[Ludovic Courtès]

Hello!

Mike Gran  skribis:

> In a fit of pique, I pushed a new branch of Guile to the repo
> called wip-replace-ltdl-with-gmodule.  It replaces the dynamic linking
> library libltdl from libtool with the analagous library GModule
> from GLib.  It was remarkably easy, and, after a cursory test
> I was surprised to find that it seems to be working.
>
> GModule itself is a standalone library, but, I think it depends
> on GLib.  It might be possible to remove that dependency without
> much difficulty, but unfortunately, then you would be left with
> another library to maintain.

Fun!

I’m very much tired of “file not found” :-), but I don’t think Guile
should depend on GLib, which is quite big.

I think we should either fix ltdl (probably less work than porting Guile
to GModule, but also less exciting) or have a very basic wrapper around
dlopen instead of using ltdl (I think Andy had made experiments in that
direction.)

Thanks,
Ludo’.