GNU Guile 2.9.4 Released [beta]

GNU Guile 2.9.4 Released [beta]

[Andy Wingo]

We are pleased to announce GNU Guile release 2.9.4.  This is the fourth
pre-release of what will eventually become the 3.0 release series.

Compared to the current stable series (2.2.x), the future Guile 3.0 adds
support for just-in-time native code generation, speeding up all Guile
programs.  See the NEWS extract at the end of the mail for full details.

Compared to the previous prerelease (2.9.3), Guile 2.9.4 adds support
for more unboxed floating-point operations, enables inlining of
top-level definitions, improves compilation of `letrec*' and internal
definitions, and allows mixed internal definitions and expressions in
body contexts (e.g. in a `let').

We encourage you to test this release and provide feedback to
guile-devel@gnu.org, and to file bugs by sending mail to
bug-guile@gnu.org.

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.9.4 can be installed in parallel with Guile 2.2.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:
  http://alpha.gnu.org/gnu/guile/guile-2.9.4.tar.lz   (10MB)
  http://alpha.gnu.org/gnu/guile/guile-2.9.4.tar.xz   (12MB)
  http://alpha.gnu.org/gnu/guile/guile-2.9.4.tar.gz   (21MB)

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

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

Here are the SHA256 checksums:

  e2da91bf20ab7b82ec6913dd9adcf64885f232f2242cdcdc7e612ead10ccf4fa  guile-2.9.4.tar.lz
  17ecf3c09c9784526c6f27955bf9a74a2adf6f7f16e20b00e9cedf0871dc34d6  guile-2.9.4.tar.xz
  4b495513866c52b2ce70997711cd3263914e946200c3541b79ccb82ccca69b9c  guile-2.9.4.tar.gz

[*] 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.9.4.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 4FD4D288D445934E0A14F9A5A8803732E4436885

and rerun the 'gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.69
  Automake 1.16.1
  Libtool 2.4.6
  Gnulib v0.1-1157-gb03f418
  Makeinfo 6.5


Changes in alpha 2.9.4 (since alpha 2.9.3):

* Notable changes

** Improved compilation of many floating-point primitives

Heavy floating-point computations that use `sqrt', `abs', `floor',
`ceiling', `sin', `cos', `tan', `asin', `acos', and `atan' will be
faster, as the compiler can unbox inexact rationals (flonums) in more
cases.

** Improved compilation of internal `define'

Internal definitions -- like the `define' in `(let () (define x 10)
...)' -- are now compiled more optimally, using the algorithm from
Ghuloum and Dybvig's "Fixing Letrec (reloaded)" paper.  This change
makes internal `define' just as efficient as `let', `let*', `letrec',
and similar.

** Interleaved internal definitions and expressions allowed

It used to be that internal definitions had to precede all expressions
in their bodies.  This restriction has been relaxed.  If an expression
precedes an internal definition, it is treated as if it were a
definition of an unreferenced variable.  For example, the expression
`(foo)' transforms to the equivalent of `(define _ (begin (foo) #f))',
if it precedes other definitions.

This change improves the readability of Guile programs, as it used to be
that program indentation tended to increase needlessly to allow nested
`let' and `letrec' to re-establish definition contexts after initial
expressions, for example for type-checks on procedure arguments.

** Optimization of top-level bindings within a compilation unit

At optimization level 2 and above, Guile's compiler is now allowed to
inline top-level definitions within a compilation unit.  See
"Declarative Modules" in the manual, for full details.  This change can
improve the performance of programs with many small top-level
definitions by quite a bit!


Cumulative changes in the alpha 2.9.x series (since the stable 2.2 series):

* Notable changes

** Just-in-time code generation

Guile programs now run up to 4 times faster, relative to Guile 2.2,
thanks to just-in-time (JIT) native code generation.  Notably, this
brings the performance of "eval" as written in Scheme back to the level
of "eval" written in C, as in the days of Guile 1.8.

See "Just-In-Time Native Code" in the manual, for more information.  JIT
compilation will be enabled automatically and transparently.  To disable
JIT compilation, configure Guile with `--enable-jit=no' or
`--disable-jit'.  The default is `--enable-jit=auto', which enables the
JIT if it is available.  See `./configure --help' for more.

JIT compilation is enabled by default on x86-64, i686, ARMv7, and
AArch64 targets.

** Lower-level bytecode

Relative to the virtual machine in Guile 2.2, Guile's VM instruction set
is now more low-level.  This allows it to express more advanced
optimizations, for example type check elision or integer
devirtualization, and makes the task of JIT code generation easier.

Note that this change can mean that for a given function, the
corresponding number of instructions in Guile 3.0 may be higher than
Guile 2.2, which can lead to slowdowns when the function is interpreted.
We hope that JIT compilation more than makes up for this slight
slowdown.

** By default, GOOPS classes are not redefinable

It used to be that all GOOPS classes were redefinable, at least in
theory.  This facility was supported by an indirection in all "struct"
instances, even though only a subset of structs would need redefinition.
We wanted to remove this indirection, in order to speed up Guile
records, allow immutable Guile records to eventually be described by
classes, and allow for some optimizations in core GOOPS classes that
shouldn't be redefined anyway.

Thus in GOOPS now there are classes that are redefinable and classes
that aren't.  By default, classes created with GOOPS are not
redefinable.  To make a class redefinable, it should be an instance of
`<redefinable-class>'.  See "Redefining a Class" in the manual for more
information.

* New deprecations

** scm_t_uint8, etc deprecated in favor of C99 stdint.h

It used to be that Guile defined its own `scm_t_uint8' because C99
`uint8_t' wasn't widely enough available.  Now Guile finally made the
change to use C99 types, both internally and in Guile's public headers.

Note that this also applies to SCM_T_UINT8_MAX, SCM_T_INT8_MIN, for intN
and uintN for N in 8, 16, 32, and 64.  Guile also now uses ptrdiff_t
instead of scm_t_ptrdiff, and similarly for intmax_t, uintmax_t,
intptr_t, and uintptr_t.

* Incompatible changes

** All deprecated code removed

All code deprecated in Guile 2.2 has been removed.  See older NEWS, and
check that your programs can compile without linker warnings and run
without runtime warnings.  See "Deprecation" in the manual.

In particular, the function `scm_generalized_vector_get_handle' which
was deprecated in 2.0.9 but remained in 2.2, has now finally been
removed. As a replacement, use `scm_array_get_handle' to get a handle
and `scm_array_handle_rank' to check the rank.

** Remove "self" field from vtables and "redefined" field from classes

These fields were used as part of the machinery for class redefinition
and is no longer needed.

** VM hook manipulation simplified

The low-level mechanism to instrument a running virtual machine for
debugging and tracing has been simplified.  See "VM Hooks" in the
manual, for more.

* Changes to the distribution

** New effective version

The "effective version" of Guile is now 3.0, which allows parallel
installation with other effective versions (for example, the older Guile
2.2).  See "Parallel Installations" in the manual for full details.
Notably, the `pkg-config' file is now `guile-3.0'.

Re: GNU Guile 2.9.4 Released [beta]

[Thomas Morley]

Am So., 25. Aug. 2019 um 22:22 Uhr schrieb Andy Wingo <wingo@pobox.com>:
>
> We are pleased to announce GNU Guile release 2.9.4.  This is the fourth
> pre-release of what will eventually become the 3.0 release series.

> We encourage you to test this release and provide feedback to
> guile-devel@gnu.org, and to file bugs by sending mail to
> bug-guile@gnu.org.

Hi,

I did in my guile-git-repository:

git fetch
git pull -r
git checkout v2.9.4
git checkout -b guile-2.9.4
make clean
sh autogen.sh
./configure
make
sudo make install

All went well, but then doing:
~$ guile
returns:
guile: error while loading shared libraries: libguile-3.0.so.0: cannot
open shared object file: No such file or directory

But
~$ locate libguile-3.0.so.0
returns:
/home/hermann/guile-3.0/libguile/.libs/libguile-3.0.so.0
/home/hermann/guile-3.0/libguile/.libs/libguile-3.0.so.0.0.0

Am I doing something wrong?

Cheers,
  Harm

Re: GNU Guile 2.9.4 Released [beta]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]

On Mon, Aug 26, 2019 at 06:39:02PM +0200, Thomas Morley wrote:
> Am So., 25. Aug. 2019 um 22:22 Uhr schrieb Andy Wingo <wingo@pobox.com>:
> >
> > We are pleased to announce GNU Guile release 2.9.4.  This is the fourth
> > pre-release of what will eventually become the 3.0 release series.
> 
> > We encourage you to test this release and provide feedback to
> > guile-devel@gnu.org, and to file bugs by sending mail to
> > bug-guile@gnu.org.
> 
> Hi,
> 
> I did in my guile-git-repository:
> 
> git fetch
> git pull -r
> git checkout v2.9.4
> git checkout -b guile-2.9.4
> make clean
> sh autogen.sh
> ./configure
> make
> sudo make install
> 
> All went well, but then doing:
> ~$ guile
> returns:
> guile: error while loading shared libraries: libguile-3.0.so.0: cannot
> open shared object file: No such file or directory
> 
> But
> ~$ locate libguile-3.0.so.0
> returns:
> /home/hermann/guile-3.0/libguile/.libs/libguile-3.0.so.0
> /home/hermann/guile-3.0/libguile/.libs/libguile-3.0.so.0.0.0

Hm. After having done "sudo make install" above, I'd expect libguile
to land in /usr/local/lib somewhere: go look there.

 - Are you starting the "right" guile? (probably)
   What does "which guile" say?
 - What does "/usr/bin/ldd $(which guile) say?

Perhaps you have to add /usr/local/lib to /etc/ld.so.conf (or some
file below /etc/ld.so.conf.d) and run ldconfig.

HTH
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: GNU Guile 2.9.4 Released [beta]

[Thomas Morley]

Am Mo., 26. Aug. 2019 um 19:10 Uhr schrieb <tomas@tuxteam.de>:
>
> On Mon, Aug 26, 2019 at 06:39:02PM +0200, Thomas Morley wrote:
> > Am So., 25. Aug. 2019 um 22:22 Uhr schrieb Andy Wingo <wingo@pobox.com>:
> > >
> > > We are pleased to announce GNU Guile release 2.9.4.  This is the fourth
> > > pre-release of what will eventually become the 3.0 release series.
> >
> > > We encourage you to test this release and provide feedback to
> > > guile-devel@gnu.org, and to file bugs by sending mail to
> > > bug-guile@gnu.org.
> >
> > Hi,
> >
> > I did in my guile-git-repository:
> >
> > git fetch
> > git pull -r
> > git checkout v2.9.4
> > git checkout -b guile-2.9.4
> > make clean
> > sh autogen.sh
> > ./configure
> > make
> > sudo make install
> >
> > All went well, but then doing:
> > ~$ guile
> > returns:
> > guile: error while loading shared libraries: libguile-3.0.so.0: cannot
> > open shared object file: No such file or directory
> >
> > But
> > ~$ locate libguile-3.0.so.0
> > returns:
> > /home/hermann/guile-3.0/libguile/.libs/libguile-3.0.so.0
> > /home/hermann/guile-3.0/libguile/.libs/libguile-3.0.so.0.0.0
>
> Hm. After having done "sudo make install" above, I'd expect libguile
> to land in /usr/local/lib somewhere: go look there.
>
>  - Are you starting the "right" guile? (probably)
>    What does "which guile" say?
>  - What does "/usr/bin/ldd $(which guile) say?
>
> Perhaps you have to add /usr/local/lib to /etc/ld.so.conf (or some
> file below /etc/ld.so.conf.d) and run ldconfig.
>
> HTH
> -- tomás

Hi tomás,

thanks for your hints.
I've got it work by running nothing else than
sudo ldconfig

But I wonder, shouldn't it work out of the box with 'sudo make install' ?

Thanks,
  Harm

Re: GNU Guile 2.9.4 Released [beta]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

On Mon, Aug 26, 2019 at 08:13:45PM +0200, Thomas Morley wrote:

[...ldconfig...]

> Hi tomás,
> 
> thanks for your hints.
> I've got it work by running nothing else than
> sudo ldconfig
> 
> But I wonder, shouldn't it work out of the box with 'sudo make install' ?

As far as I know it should be libtool's job, yes. But I might be wrong.

For me, it worked out of the box, but it's not the first installation
I do.

For someone more "in the know", perhaps your autotools versions might be
of interest.

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: GNU Guile 2.9.4 Released [beta]

[Mark H Weaver]

Hi Thomas,

Thomas Morley <thomasmorley65@gmail.com> writes:

> Am Mo., 26. Aug. 2019 um 19:10 Uhr schrieb <tomas@tuxteam.de>:
>>
>> Perhaps you have to add /usr/local/lib to /etc/ld.so.conf (or some
>> file below /etc/ld.so.conf.d) and run ldconfig.
>>
>> HTH
>> -- tomás
>
> Hi tomás,
>
> thanks for your hints.
> I've got it work by running nothing else than
> sudo ldconfig
>
> But I wonder, shouldn't it work out of the box with 'sudo make install' ?

Running 'ldconfig' is not always appropriate, and therefore the vast
majority of programs do *not* run 'ldconfig' in "make install".  Whether
it is appropriate depends on several factors, including which OS and
distro you're using, which prefix you're installing to, whether you're
building a distro package that will actually be installed at a later
time, and which of several available mechanisms you have chosen to use
to allow programs to find their shared libraries.

For example, it's *never* appropriate to run 'ldconfig' on NixOS or Guix
systems, nor when building a Debian package or similar where the actual
installation will happen later, nor when installing into a directory
that's not listed in /etc/ld.so.conf (or /etc/ld.so.conf.d), nor when
running "make install" as non-root.

In theory we could try to make a guess, but there's no reliable way for
the build system to know whether it is appropriate or not, and in
practice it is usually done as a separate step in most modern systems.

     Regards,
       Mark

Re: GNU Guile 2.9.4 Released [beta]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 767 bytes --]

On Mon, Aug 26, 2019 at 03:12:47PM -0400, Mark H Weaver wrote:
> Hi Thomas,
> 
> Thomas Morley <thomasmorley65@gmail.com> writes:

[...]

> > But I wonder, shouldn't it work out of the box with 'sudo make install' ?
> 
> Running 'ldconfig' is not always appropriate, and therefore the vast
> majority of programs do *not* run 'ldconfig' in "make install" [...]

OK, that makes sense. I take my post back :-)

It was anyway based on a dim memory.

[...]

> In theory we could try to make a guess, but there's no reliable way for
> the build system to know whether it is appropriate or not, and in
> practice it is usually done as a separate step in most modern systems.

I think "making a guess" doesn't sound very attractive...

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: GNU Guile 2.9.4 Released [beta]

[Thomas Morley]

Am Mo., 26. Aug. 2019 um 21:13 Uhr schrieb Mark H Weaver <mhw@netris.org>:
>
> Hi Thomas,
>
> Thomas Morley <thomasmorley65@gmail.com> writes:
>
> > Am Mo., 26. Aug. 2019 um 19:10 Uhr schrieb <tomas@tuxteam.de>:
> >>
> >> Perhaps you have to add /usr/local/lib to /etc/ld.so.conf (or some
> >> file below /etc/ld.so.conf.d) and run ldconfig.
> >>
> >> HTH
> >> -- tomás
> >
> > Hi tomás,
> >
> > thanks for your hints.
> > I've got it work by running nothing else than
> > sudo ldconfig
> >
> > But I wonder, shouldn't it work out of the box with 'sudo make install' ?
>
> Running 'ldconfig' is not always appropriate, and therefore the vast
> majority of programs do *not* run 'ldconfig' in "make install".  Whether
> it is appropriate depends on several factors, including which OS and
> distro you're using, which prefix you're installing to, whether you're
> building a distro package that will actually be installed at a later
> time, and which of several available mechanisms you have chosen to use
> to allow programs to find their shared libraries.
>
> For example, it's *never* appropriate to run 'ldconfig' on NixOS or Guix
> systems, nor when building a Debian package or similar where the actual
> installation will happen later, nor when installing into a directory
> that's not listed in /etc/ld.so.conf (or /etc/ld.so.conf.d), nor when
> running "make install" as non-root.
>
> In theory we could try to make a guess, but there's no reliable way for
> the build system to know whether it is appropriate or not, and in
> practice it is usually done as a separate step in most modern systems.
>
>      Regards,
>        Mark

Hi Mark,

many thanks for your explanations.
You may remember from here:
https://lists.gnu.org/archive/html/guile-user/2019-08/msg00016.html
that I'm used to switch guile-versions pretty frequently.

For every guile-version so far 'sudo make install' worked out of the
box (apart from the problem discussed in the linked thread), thus I
was surprised it didn't today.

Thanks,
  Harm

Re: GNU Guile 2.9.4 Released [beta]

[Matt Wette]

On 8/25/19 1:21 PM, Andy Wingo wrote:
> We are pleased to announce GNU Guile release 2.9.4. This is the fourth
> pre-release of what will eventually become the 3.0 release series.
>
macOS 10.14.6:
wrote `system/vm/frame.go'
   BOOTSTRAP GUILEC system/vm/linker.go
/bin/sh: line 1: 79336 Abort trap: 6 GUILE_AUTO_COMPILE=0 
../meta/build-env guild compile --target="x86_64-apple-darwin18.7.0" -O1 
-Oresolve-primitives -L "/Users/mwette/proj/guile/guile-2.9.4/module" -L 
"/Users/mwette/proj/guile/guile-2.9.4/guile-readline" -o 
"system/vm/linker.go" "../module/system/vm/linker.scm"
make[2]: *** [system/vm/linker.go] Error 134
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I don't (yet) have time to hunt this down right now.  Building w/ 
up-to-date macports dep's.