[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Guile 2.9.8 Released [beta]

From: Stefan Israelsson Tampe
Subject: Re: GNU Guile 2.9.8 Released [beta]
Date: Tue, 7 Jan 2020 21:00:00 +0100


Great, but loading an extension like:

(catch #t
  (lambda ()
    (throw #t)
    (load-extension "libguile-persist" "persist_init") (pk 1))
  (lambda x
    (let ((file
           (%search-load-path "src/.libs/")))
       (catch #t
         (lambda ()
           (load-extension file "persist_init"))
         (lambda x
            "libguile-persist is not loadable!")))
        "libguile-persist is not present, did you forget to make it?")))))

And then have  line like

(pk 5 serialize-vm-ra)

Loading this module prints
(5 #f)

Worked in releases before.

Although loading the extension in the shell shows that serialize-vm-ra is
bound to a function.

On Thu, Jan 2, 2020 at 2:37 PM Andy Wingo <address@hidden> wrote:

> We are pleased to announce GNU Guile release 2.9.8.  This is the eighth
> and possibly final 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.7), Guile 2.9.8 fixes a bug in
> libguile that caused writes to unmapped memory in some circumstances.
> This problem manifested itself as a failure of Guile to compile itself
> on some systems, notably Ubuntu 18.04 on x86-64.  It also fixes a couple
> warnings related to SRFI-35.
> The current plan is to make a 3.0.0 final release on 17 January 2020.
> We may need another prerelease in the interim.  It's a good time to test
> the prereleases to make sure they work on your platform.  Please send
> any build reports (success or failure) to address@hidden, along
> with platform details.  You can file a bug by sending mail to
> address@hidden.
> The Guile web page is located at, 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.8 can be installed in parallel with Guile 2.2.x; see
> .
> A more detailed NEWS summary follows these details on how to get the
> Guile sources.
> Here are the compressed sources:
>   (10MB)
>   (12MB)
>   (21MB)
> Here are the GPG detached signatures[*]:
> Use a mirror for higher download bandwidth:
> Here are the SHA256 checksums:
>   3ce11e9dca0f475fa944729d99f33c379fe8962e729bd21a99470249624c71d7
> guile-2.9.8.tar.lz
>   4a8cf663b8bfd435168935c74a8ec434328ffad16230322c64f0ac567dda2c26
> guile-2.9.8.tar.xz
>   31c3d458ff9342db130e27c8d82d2a33912da92845e5ee431b6a125971a823d2
> guile-2.9.8.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.8.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 --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
> An extract from NEWS follows.
> Changes in alpha 2.9.8 (since alpha 2.9.7):
> * Bug fixes
> ** Fix bug in which abort_to_prompt used an invalid stack pointer
> This bug manifested itself as a bootstrap compile error on some systems,
> notably Ubuntu 18.04 on x86-64, and was due to failing to recalculate a
> local variable after a possible stack relocation.
> ** SRFI-35 does a #:re-export-and-replace on `&error'
> ** SRFI-35 avoids compiler warnings for multiply-defined condition types
> Changes in alpha 2.9.x (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.
> ** 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.
> ** Record unification
> Guile used to have a number of implementations of structured data types
> in the form of "records": a core facility, SRFI-9 (records), SRFI-35
> (condition types -- a form of records) and R6RS records.  These
> facilities were not compatible, as they all were built in different
> ways.  This had the unfortunate corollary that SRFI-35 conditions were
> not compatible with R6RS conditions.  To fix this problem, we have now
> added the union of functionality from all of these record types into
> core records: single-inheritance subtyping, mutable and immutable
> fields, and so on.  See "Records" in the manual, for full details.
> R6RS records, SRFI-9 records, and the SRFI-35 and R6RS exception types
> have been accordingly "rebased" on top of core records.
> ** Reimplementation of exceptions
> Since Guile's origins 25 years ago, `throw' and `catch' have been the
> primary exception-handling primitives.  However these primitives have
> two problems.  One is that it's hard to handle exceptions in a
> structured way using `catch'.  Few people remember what the
> corresponding `key' and `args' are that an exception handler would see
> in response to a call to `error', for example.  In practice, this
> results in more generic catch-all exception handling than one might
> like.
> The other problem is that `throw', `catch', and especially
> `with-throw-handler' are quite unlike what the rest of the Scheme world
> uses.  R6RS and R7RS, for example, have mostly converged on
> SRFI-34-style `with-exception-handler' and `raise' primitives, and
> encourage the use of SRFI-35-style structured exception objects to
> describe the error.  Guile's R6RS layer incorporates an adapter between
> `throw'/`catch' and structured exception handling, but it didn't apply
> to SRFI-34/SRFI-35, and we would have to duplicate it for R7RS.
> In light of these considerations, Guile has now changed to make
> `with-exception-handler' and `raise-exception' its primitives for
> exception handling and defined a hierarchy of R6RS-style exception types
> in its core.  SRFI-34/35, R6RS, and the exception-handling components of
> SRFI-18 (threads) have been re-implemented in terms of this core
> functionality.  There is also a a compatibility layer that makes it so
> that exceptions originating in `throw' can be handled by
> `with-exception-hander', and vice-versa for `raise-exception' and
> `catch'.
> Generally speaking, users will see no difference.  The one significant
> difference is that users of SRFI-34 will see more exceptions flowing
> through their `with-exception-handler'/`guard' forms, because whereas
> before they would only see exceptions thrown by SRFI-34, now they will
> see exceptions thrown by R6RS, R7RS, or indeed `throw'.
> Guile's situation is transitional.  Most exceptions are still signalled
> via `throw'.  These will probably migrate over time to
> `raise-exception', while preserving compatibility of course.
> See "Exceptions" in the manual, for full details on the new API.
> ** 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!
> At optimization level 3 and above, Guile will assume that any top-level
> binding in a declarative compilation unit that isn't exported from a
> module can be completely inlined into its uses.  (Prior to this change,
> -O3 was the same as -O2.)  Note that with this new
> `seal-private-bindings' pass, private declarative bindings are no longer
> available for access from the first-class module reflection API.  The
> optimizations afforded by this pass can be useful when you need a speed
> boost, but having them enabled at optimization level 3 means they are
> not on by default, as they change Guile's behavior in ways that users
> might not expect.
> ** 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.
> ** Define top-level bindings for aux syntax: `else', `=>', `...', `_'
> These auxiliary syntax definitions are specified to be defined in the
> R6RS and the R7RS.  They were previously unbound, even in the R6RS
> modules.  This change is not anticipated to cause any incompatibility
> with existing Guile code, and improves things for R6RS and R7RS users.
> ** Conventional gettext alias is now `G_'
> Related to the last point, since the "Fix literal matching for
> module-bound literals" change in the 2.2 series, it was no longer
> possible to use the conventional `_' binding as an alias for `gettext',
> because a local `_' definition would prevent `_' from being recognized
> as auxiliary syntax for `match', `syntax-rules', and similar.  The new
> recommended conventional alias for `gettext' is `G_'.
> ** Add --r6rs command-line option
> The new `install-r6rs!' procedure adapts Guile's defaults to be more
> R6RS-compatible.  This procedure is called if the user passes `--r6rs'
> as a command-line argument.  See "R6RS Incompatibilities" in the manual,
> for full details.
> ** Add support for R7RS
> Thanks to Göran Weinholt and OKUMURA Yuki, Guile now implements the R7RS
> modules.  As the R7RS library syntax is a subset of R6RS, to use R7RS
> you just `(import (scheme base))' and off you go.  As with R6RS also,
> there are some small lexical incompatibilities regarding hex escapes;
> see "R6RS Support" in the manual, for full details.
> Also as with R6RS, there is an `install-r7rs!' procedure and a `--r7rs'
> command-line option.
> ** Add #:re-export-and-replace argument to `define-module'
> This new keyword specifies a set of bindings to re-export, but also
> marks them as intended to replace core bindings.  See "Creating Guile
> Modules" in the manual, for full details.
> Note to make this change, we had to change the way replacement flags are
> stored, to being associated with modules instead of individual variable
> objects.  This means that users who #:re-export an imported binding that
> was already marked as #:replace by another module will now see warnings,
> as they need to use #:re-export-and-replace instead.
> ** `iota' in core and SRFI-1 `iota' are the same
> Previously, `iota' in core would not accept start and step arguments and
> would return an empty list for negative count. Now there is only one
> `iota' function with the extended semantics of SRFI-1.  Note that as an
> incompatible change, core `iota' no longer accepts a negative count.
> * 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.
> ** The two-argument form of `record-constructor'
> Calling `record-constructor' with two arguments (the record type and a
> list of field names) is deprecated.  Instead, call with just one
> argument, and provide a wrapper around that constructor if needed.
> * 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', and there are new
> `guile-3' and `guile-3.0' features for `cond-expand'.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]