Re: GNU Guile 3.0.3 released

[Ludovic Courtès]

Hello,

Andy Wingo  skribis:

> On Tue 23 Jun 2020 11:36, Chris Vine  writes:

[...]

>>> I was hesitant about the SONAME: the ABI jump was unnecessary unless in
>>> ‘--disable-deprecated’ builds.  I erred on the side of cautiousness:
>>> 
>>>   
>>> https://git.savannah.gnu.org/cgit/guile.git/commit/?id=5d052c87bd8f0fd894e67f0bebd4fa6f6160d83c
>>
>> Hi,
>>
>> Ah right.  There must have been two SO breaks between guile-3.0.2 and
>> guile-3.0.3.
>>
>> It's a nuisance having SO bumps on micro releases and I wonder if that
>> could be included in the announcement so that you don't first notice it
>> when stuff fails to run?
>
> I think I agree with Chris.  The intention is certainly to have a stable
> ABI within a stable series, so 3.0.3 should have the same CURRENT.
>
> It's certainly correct that a --disable-deprecated 3.0.3 build has a
> different ABI than 3.0.2, and if that were what we were looking at, we
> would indeed need the CURRENT version bump; but I think the premise is
> wrong: we do *not* have a stable ABI in --disable-deprecated builds, and
> we never have.  Otherwise we wouldn't ever be able to deprecate anything
> within a stable series.

Following our discussion on IRC, I agree with restoring CURRENT and will
push a 3.0.4 in that direction.

Apologies for the annoyance!

Ludo’.

Re: GNU Guile 3.0.3 released

[Andy Wingo]

On Tue 23 Jun 2020 11:36, Chris Vine  writes:

> On Tue, 23 Jun 2020 10:05:51 +0200
> Ludovic Courtès  wrote:
>> Hi Chris,
>> 
>> Chris Vine  skribis:
>> 
>> > On Sun, 21 Jun 2020 23:04:03 +0200
>> > Ludovic Courtès  wrote:
>> >> We are delighted to announce GNU Guile release 3.0.3, the third bug-fix
>> >> release of the new 3.0 stable series.  This release represents 170
>> >> commits by 17 people since version 3.0.2.  See the NEWS excerpt that
>> >> follows for full details.
>> > [snip]
>> >
>> > This has a libguile so ABI jump from libguile-3.0.so.1 to
>> > libguile-3.0.so.3, which breaks my binaries linked to libguile.  Is that
>> > normal for a micro update in the stable release series and if so can
>> > there be some warning in the announcement?
>> 
>> Yes, it means you need to relink those binaries.
>> 
>> I was hesitant about the SONAME: the ABI jump was unnecessary unless in
>> ‘--disable-deprecated’ builds.  I erred on the side of cautiousness:
>> 
>>   
>> https://git.savannah.gnu.org/cgit/guile.git/commit/?id=5d052c87bd8f0fd894e67f0bebd4fa6f6160d83c
>
> Hi,
>
> Ah right.  There must have been two SO breaks between guile-3.0.2 and
> guile-3.0.3.
>
> It's a nuisance having SO bumps on micro releases and I wonder if that
> could be included in the announcement so that you don't first notice it
> when stuff fails to run?

I think I agree with Chris.  The intention is certainly to have a stable
ABI within a stable series, so 3.0.3 should have the same CURRENT.

It's certainly correct that a --disable-deprecated 3.0.3 build has a
different ABI than 3.0.2, and if that were what we were looking at, we
would indeed need the CURRENT version bump; but I think the premise is
wrong: we do *not* have a stable ABI in --disable-deprecated builds, and
we never have.  Otherwise we wouldn't ever be able to deprecate anything
within a stable series.

WDYT about a quick 3.0.4 that restores the CURRENT ?

Cheers,

Andy

Re: GNU Guile 3.0.3 released

[Chris Vine]

On Sun, 21 Jun 2020 23:04:03 +0200
Ludovic Courtès  wrote:
> We are delighted to announce GNU Guile release 3.0.3, the third bug-fix
> release of the new 3.0 stable series.  This release represents 170
> commits by 17 people since version 3.0.2.  See the NEWS excerpt that
> follows for full details.
[snip]

This has a libguile so ABI jump from libguile-3.0.so.1 to
libguile-3.0.so.3, which breaks my binaries linked to libguile.  Is that
normal for a micro update in the stable release series and if so can
there be some warning in the announcement?

Re: GNU Guile 3.0.3 released

[Jérémy Korwin-Zmijowski]

Hey,

Thank you to all contributors behind the work !

Jérémy

GNU Guile 3.0.3 released

[Ludovic Courtès]

We are delighted to announce GNU Guile release 3.0.3, the third bug-fix
release of the new 3.0 stable series.  This release represents 170
commits by 17 people since version 3.0.2.  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.3 (since 3.0.2)

* New interfaces and functionality

** New baseline compiler

Guile's CPS-based compiler generates good code, but it takes time and
memory to do so.  For users that prioritize speed of compilation over
speed of generated code, Guile now has a new baseline compiler that goes
directly from the high-level Tree-IL to bytecode, skipping CPS and all
of its optimizations.  This compiler is used for `guild compile -O0',
and generally runs around ten times as fast as the CPS compiler.

*** New VM intrinsics to support baseline compiler

See "Intrinsic Call Instructions" in the manual.

*** Compiler support for warning and lowering passes
*** Compiler support for choosing different compilation orders

See "Compiler Tower" in the manual.  The new per-language "compiler
chooser" facility can choose different compilers based on optimization
level.

*** Better support for specifying optimization and warning levels

The procedural compilation interfaces (`compile', `compile-file', and so
on) now have #:optimization-level and #:warning-level keyword arguments,
which default to corresponding `default-optimization-level' and
`default-warning-level' parameters.  You can still specify warning and
optimization passes manually, but we think most users will find the
higher-level interfaces more robust to use.

** Faster Guile build from source

Guile now uses the baseline compiler for its bootstrap, when building
the first Scheme compiler.  Because the baseline compiler runs faster
and includes less code than the CPS compiler, Guile takes less time to
build.

** New 'pipeline' procedure in (ice-9 popen)

The 'pipeline' procedure provides a simple way to spawn command pipeline
as one would do in a shell.

** Refreshed bitvector facility

See "Bit Vectors" in the manual, for more on all of these.

*** New bitvector-count, bitvector-count-bits, bitvector-position
procedures

These replace the wonky "bit-count", "bit-count*", and "bit-position"
procedures.

*** New bitvector-bit-set?, bitvector-bit-clear? procedures

These replace bitvector-ref.  The reason to migrate is that it's an
opportunity be more efficient in 3.0 (because the new procedures only
work on true bitvectors, and not generic bit arrays), easier to read (no
need for 'not' when checking for false bits), and more consistent with
other bitvector procedures.

*** New bitvector-set-bit!, bitvector-clear-bit! procedures

These replace bitvector-set!, for similar reasons as the bitvector-ref
replacement above.

*** New bitvector-set-all-bits!, bitvector-clear-all-bits! procedures

These replace bitvector-fill!.

*** New bitvector-flip-all-bits! procedure

This replaces bit-invert!.

*** New bitvector-set-bits!, bitvector-clear-bits! procedures

These replace the wonky "bit-set*!" procedure.

* Bug fixes

** statprof reports the names of primitives

Previously statprof would show strings like "anon #x1234" for primitives
written in C.

** Compiler reduces 'equal?' when passed a character literal

The compiler now properly reduces expressions such as (equal? c #\x) to
(eq? c #\x).  This was not the case in 3.0.2, which could lead to slower
code, especially in 'match' expressions with many clauses with with
character literals.

** JIT bugs on ARMv7 have been fixed
   (,