GNU Guile 2.9.8 Released [beta]

GNU Guile 2.9.8 Released [beta]

[Andy Wingo]

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 guile-devel@gnu.org, along
with platform details.  You can file a bug 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.8 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.8.tar.lz   (10MB)
  http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.xz   (12MB)
  http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.gz   (21MB)

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

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

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 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

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

\f
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'.

Re: GNU Guile 2.9.8 Released [beta]

[Matt Wette]

On 1/2/20 5:36 AM, Andy Wingo 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 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.
>

make and make check verified to work on Ubuntu 18.08 / x86_64

Re: GNU Guile 2.9.8 Released [beta]

[Nala Ginrut]

When I was trying to compile Artanis, the configure threw an error:
----------------------------
checking for Guile version >= 3.0... configure: error: Guile 3.0 required,
but 2.9.8 found
----------------------------

Here's what I put in configure.ac:
GUILE_PKG(2.2 2.3 2.9 3.0)

My question is "what's the correct config here"?

Best regards.



On Thu, Jan 2, 2020 at 9:37 PM Andy Wingo <wingo@pobox.com> 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 guile-devel@gnu.org, along
> with platform details.  You can file a bug 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.8 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.8.tar.lz   (10MB)
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.xz   (12MB)
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.gz   (21MB)
>
> Here are the GPG detached signatures[*]:
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.lz.sig
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.xz.sig
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.gz.sig
>
> Use a mirror for higher download bandwidth:
>   http://www.gnu.org/order/ftp.html
>
> 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 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
>
> 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'.
>
>

Re: GNU Guile 2.9.8 Released [beta]

[tomas]

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

On Fri, Jan 03, 2020 at 01:34:59PM +0800, Nala Ginrut wrote:
> When I was trying to compile Artanis, the configure threw an error:
> ----------------------------
> checking for Guile version >= 3.0... configure: error: Guile 3.0 required,
> but 2.9.8 found
> ----------------------------
> 
> Here's what I put in configure.ac:
> GUILE_PKG(2.2 2.3 2.9 3.0)
> 
> My question is "what's the correct config here"?

Hm. I think I had that with nyacc too. This worked for me:

  GUILE_PKG([3.0])
  GUILE_PROGS([2.9.5])

I think this is due to our currently apocalyptic [1] situation:

  tomas@trotzki:~/src/guile/nyacc$ guile
  GNU Guile 2.9.5
  [...]
  
  Enter `,help' for help.
  scheme@(guile-user)> (version)
  $1 = "2.9.5"
  scheme@(guile-user)> (effective-version)
  $2 = "3.0"

(replace 2.9.5 for 2.9.8 as appropriate).

Cheers
[1] Although apocalyptic has often a negative connotation, I'm using
   it here in its more original sense [2], i.e. full of gleeful
   expectation :-)

[2] https://en.wiktionary.org/wiki/apocalyptic

-- tomás

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

Re: GNU Guile 2.9.8 Released [beta]

[Andy Wingo]

On Fri 03 Jan 2020 06:34, Nala Ginrut <nalaginrut@gmail.com> writes:

> When I was trying to compile Artanis, the configure threw an error:
> ----------------------------
> checking for Guile version >= 3.0... configure: error: Guile 3.0 required, but 2.9.8 found
> ----------------------------
>
> Here's what I put in configure.ac:
> GUILE_PKG(2.2 2.3 2.9 3.0)
>
> My question is "what's the correct config here"?

There was a bug in guile.m4 from a few years ago doesn't do the right
thing for major version changes.  I think you need to update guile.m4
from git, then do:

GUILE_PKG([2.2 3.0])

Also note that it's not meaningful to put in alpha releases to GUILE_PKG
-- 2.9.7's effective version is 3.0.

FWIW I would encourage doing GUILE_PKG([3.0 2.2]) instead, as it's
generally the right thing to default to newer Guile release series.

Cheers,

Andy

Re: GNU Guile 2.9.8 Released [beta]

[Stefan Israelsson Tampe]

Bump!

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/libguile-persist.so")))
      (if
       file
       (catch #t
         (lambda ()
           (load-extension file "persist_init"))
         (lambda x
           (warn
            "libguile-persist is not loadable!")))
       (warn
        "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 <wingo@pobox.com> 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 guile-devel@gnu.org, along
> with platform details.  You can file a bug 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.8 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.8.tar.lz   (10MB)
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.xz   (12MB)
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.gz   (21MB)
>
> Here are the GPG detached signatures[*]:
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.lz.sig
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.xz.sig
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.gz.sig
>
> Use a mirror for higher download bandwidth:
>   http://www.gnu.org/order/ftp.html
>
> 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 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
>
> 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'.
>
>

Re: GNU Guile 2.9.8 Released [beta]

[Andy Wingo]

On Tue 07 Jan 2020 21:00, Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:

> Bump!
>
> 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/libguile-persist.so")))
>       (if 
>        file
>        (catch #t
>          (lambda ()          
>            (load-extension file "persist_init"))
>          (lambda x
>            (warn
>             "libguile-persist is not loadable!")))
>        (warn 
>         "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.

Surely this test case can be shortened?  All the load-extension bits
appear to not be necessary, right?

Andy

Re: GNU Guile 2.9.8 Released [beta]

[Nala Ginrut]

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

When I was trying to compile Artanis with Guile-2.9.8, it throw error like
this:
-------------------------------------------------------------------------------------------
WARNING: (artanis utils): imported module (rnrs) overrides core binding
`record-accessor'
Backtrace:
In ice-9/psyntax.scm:
   285:10 19 (parse _ (("placeholder" placeholder)) (()) _ c&e (eval) …)
In ice-9/eval.scm:
   293:34 18 (_ #<module (#{ g189}#) 5624d6ebb320>)
In ice-9/boot-9.scm:
   3366:4 17 (define-module* _ #:filename _ #:pure _ #:version _ # _ …)
  3379:24 16 (_)
   222:29 15 (map1 (((artanis utils)) ((artanis config)) ((# #)) # …))
   222:29 14 (map1 (((artanis config)) ((artanis irregex)) ((# …)) …))
   222:29 13 (map1 (((artanis irregex)) ((artanis server #)) ((…)) …))
   222:17 12 (map1 (((artanis server server-context)) ((artanis …)) …))
  3283:17 11 (resolve-interface (artanis server server-context) # _ # …)
In ice-9/threads.scm:
    390:8 10 (_ _)
In ice-9/boot-9.scm:
  3209:13  9 (_)
In ice-9/threads.scm:
    390:8  8 (_ _)
In ice-9/boot-9.scm:
  3493:20  7 (_)
   2792:4  6 (save-module-excursion #<procedure 5624d6abe0f0 at ice-…>)
  3513:26  5 (_)
In unknown file:
           4 (primitive-load-path "artanis/server/server-context" #<…>)
In ice-9/eval.scm:
   626:19  3 (_ #<directory (artanis server server-context) 5624d6b3…>)
    155:9  2 (_ #<directory (artanis server server-context) 5624d6b3…>)
In ice-9/boot-9.scm:
  1153:19  1 (_ _ _ _ _ _ _)
  1655:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1655:16: In procedure raise-exception:
Wrong number of arguments to #<procedure 5624d66ee4a0 at
ice-9/boot-9.scm:1153:19 (a b c d e f)>
--------------------------------------------------------------------------------------------------------------------

Any hint that I can figure out whait's incompatible?

Thanks!



On Wed, Jan 8, 2020 at 5:43 AM Andy Wingo <wingo@pobox.com> wrote:

> On Tue 07 Jan 2020 21:00, Stefan Israelsson Tampe <stefan.itampe@gmail.com>
> writes:
>
> > Bump!
> >
> > 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/libguile-persist.so")))
> >       (if
> >        file
> >        (catch #t
> >          (lambda ()
> >            (load-extension file "persist_init"))
> >          (lambda x
> >            (warn
> >             "libguile-persist is not loadable!")))
> >        (warn
> >         "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.
>
> Surely this test case can be shortened?  All the load-extension bits
> appear to not be necessary, right?
>
> Andy
>
>

[-- Attachment #2: Type: text/html, Size: 3935 bytes --]

Re: GNU Guile 2.9.8 Released [beta]

[Stefan Israelsson Tampe]

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

I can't make a simple case out of this. But the gist is that we have a
module c

(define-module (c)
  #:export (fail))

(define fail (cons 'fail '()))

Then in module b:

(define-module (b)
  #:use-module (c)
  #:export (f))

(define-syntax-rule (kif it p x y)
  (let ((it p))
    (if (eq? it fail)
y
x)))

(define (f x)
  (kif it (x) it x))

Module b is too simple and this compiles, I have a more advanced module and
uses of the tag fail. Now this module
compiles when we have the definition of fail in the same module but
separating it out to module c lead to the fopllowing
stack trace:
Backtrace:
In system/base/compile.scm:
  155:11 19 (_ #<closed: file 5620dba602a0>)
  224:14 18 (read-and-compile _ #:from _ #:to _ #:env _ #:opts _)
   175:2 17 (compile _ #:from _ #:to _ #:env _ #:opts _)
  183:32 16 (compile-fold _ _ _ (#:to-file? #t #:warnings (# # # …)))
In language/cps/compile-bytecode.scm:
  699:12 15 (compile-bytecode _ #<directory (oop pf-objects) 5620d…> …)
In language/cps/closure-conversion.scm:
   885:7 14 (convert-closures _)
In language/cps/intmap.scm:
   519:5 13 (visit-branch #(#(#(#<intset 0-18,20-22,24-29…> …) …) …) …)
   519:5 12 (visit-branch #(#(#<intset 0-18,20-22,24-29,32-3…> …) …) …)
   519:5 11 (visit-branch #(#<intset 0-18,20-22,24-29,32-36,38,…> …) …)
In language/cps/intset.scm:
   470:5 10 (visit-branch #(#(#(#(1064828927 3623737183 …) …) …) …) …)
   470:5  9 (visit-branch #(#(#(1064828927 3623737183 # # # …) …) …) …)
   470:5  8 (visit-branch #(#(3047188480 218316806 1799356468 …) …) …)
   470:5  7 (visit-branch #(213200 #f 1073741824 4294287363 # # # …) …)
   470:5  6 (visit-branch 4093640703 _ 2688 _)
In language/cps/closure-conversion.scm:
  749:15  5 (_ 2705 _)
  771:22  4 (lp #<intmap 0-18,20-22,24-29,32-36,38,40-42,44,46-48,…> …)
  771:22  3 (lp #<intmap 0-18,20-22,24-29,32-36,38,40-42,44,46-48,…> …)
  771:22  2 (lp #<intmap 0-18,20-22,24-29,32-36,38,40-42,44,46-48,…> …)
  610:11  1 (allocate-closure _ _ _ _ _ 1)
In ice-9/boot-9.scm:
 1655:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1655:16: In procedure raise-exception:
unexpected well-known nullary, unary, or binary closure
Makefile:1295: recipe for target 'oop/pf-objects.go' failed
make: *** [oop/pf-objects.go] Error 1








On Thu, Jan 2, 2020 at 2:37 PM Andy Wingo <wingo@pobox.com> 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 guile-devel@gnu.org, along
> with platform details.  You can file a bug 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.8 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.8.tar.lz   (10MB)
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.xz   (12MB)
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.gz   (21MB)
>
> Here are the GPG detached signatures[*]:
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.lz.sig
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.xz.sig
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.gz.sig
>
> Use a mirror for higher download bandwidth:
>   http://www.gnu.org/order/ftp.html
>
> 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 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
>
> 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'.
>
>

[-- Attachment #2: Type: text/html, Size: 22609 bytes --]

Re: GNU Guile 2.9.8 Released [beta]

[Andy Wingo]

On Thu 09 Jan 2020 22:14, Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:

> In language/cps/closure-conversion.scm: 
>   749:15  5 (_ 2705 _) 
>   771:22  4 (lp #<intmap 0-18,20-22,24-29,32-36,38,40-42,44,46-48,…> …) 
>   771:22  3 (lp #<intmap 0-18,20-22,24-29,32-36,38,40-42,44,46-48,…> …) 
>   771:22  2 (lp #<intmap 0-18,20-22,24-29,32-36,38,40-42,44,46-48,…> …) 
>   610:11  1 (allocate-closure _ _ _ _ _ 1) 

Nice bug!  I wish I had a test case :)  Can you try the following patch
and see if it fixes the issue for you?

Cheers,

Andy

diff --git a/module/language/cps/closure-conversion.scm b/module/language/cps/closure-conversion.scm
index 1452212f0..17a81f674 100644
--- a/module/language/cps/closure-conversion.scm
+++ b/module/language/cps/closure-conversion.scm
@@ -1,6 +1,6 @@
 ;;; Continuation-passing style (CPS) intermediate language (IL)
 
-;; Copyright (C) 2013-2019 Free Software Foundation, Inc.
+;; Copyright (C) 2013-2020 Free Software Foundation, Inc.
 
 ;;;; This library is free software; you can redistribute it and/or
 ;;;; modify it under the terms of the GNU Lesser General Public
@@ -596,6 +596,17 @@ term."
              ($continue ktag0 src
                ($primcall 'allocate-words/immediate `(closure . ,(+ nfree 2))
                           ())))))
+        (#(#t 0)
+         (with-cps cps
+           (build-term ($continue k src ($const #f)))))
+        (#(#t 1)
+         ;; A well-known closure of one free variable is replaced
+         ;; at each use with the free variable itself, so we don't
+         ;; need a binding at all; and yet, the continuation
+         ;; expects one value, so give it something.  DCE should
+         ;; clean up later.
+         (with-cps cps
+           (build-term ($continue k src ($const #f)))))
         (#(#t 2)
          ;; Well-known closure with two free variables; the closure is a
          ;; pair.
@@ -666,17 +677,6 @@ bound to @var{var}, and continue to @var{k}."
           (#(#f 0)
            (with-cps cps
              (build-term ($continue k src ($const-fun kfun)))))
-          (#(#t 0)
-           (with-cps cps
-             (build-term ($continue k src ($const #f)))))
-          (#(#t 1)
-           ;; A well-known closure of one free variable is replaced
-           ;; at each use with the free variable itself, so we don't
-           ;; need a binding at all; and yet, the continuation
-           ;; expects one value, so give it something.  DCE should
-           ;; clean up later.
-           (with-cps cps
-             (build-term ($continue k src ($const #f)))))
           (#(well-known? nfree)
            ;; A bit of a mess, but beta conversion should remove the
            ;; final $values if possible.

Re: GNU Guile 2.9.8 Released [beta]

[Andy Wingo]

On Wed 08 Jan 2020 15:22, Nala Ginrut <nalaginrut@gmail.com> writes:

> In unknown file:
>            4 (primitive-load-path "artanis/server/server-context" #<…>)
> In ice-9/eval.scm:
>    626:19  3 (_ #<directory (artanis server server-context) 5624d6b3…>)
>     155:9  2 (_ #<directory (artanis server server-context) 5624d6b3…>)
> In ice-9/boot-9.scm:
>   1153:19  1 (_ _ _ _ _ _ _)
>   1655:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1655:16: In procedure raise-exception:
> Wrong number of arguments to #<procedure 5624d66ee4a0 at ice-9/boot-9.scm:1153:19 (a b c d e f)>
> --------------------------------------------------------------------------------------------------------------------
>
> Any hint that I can figure out whait's incompatible?

Gosh we need to improve this info.  Anyway the procedure at
boot-9.scm:1153:19 is a record constructor, for a record with 6 fields.
Apparently somewhere in (artanis server server-context) is calling it
with the wrong number of arguments.  What do you use for records?  Do
you have your own abstraction or do you use R6RS records or something?
Perhaps something in artanis relied on the way that R6RS records used to
implement single inheritance, as a chain of objects instead of a flat
record.  Or perhaps the adaptations to R6RS records in Guile introduced
a bug.  I am interested to know the answer :)

Andy

Re: GNU Guile 2.9.8 Released [beta]

[Stefan Israelsson Tampe]

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

I can confirm that this patch solves the issue

On Sat, Jan 11, 2020 at 11:33 AM Andy Wingo <wingo@pobox.com> wrote:

> On Wed 08 Jan 2020 15:22, Nala Ginrut <nalaginrut@gmail.com> writes:
>
> > In unknown file:
> >            4 (primitive-load-path "artanis/server/server-context" #<…>)
> > In ice-9/eval.scm:
> >    626:19  3 (_ #<directory (artanis server server-context) 5624d6b3…>)
> >     155:9  2 (_ #<directory (artanis server server-context) 5624d6b3…>)
> > In ice-9/boot-9.scm:
> >   1153:19  1 (_ _ _ _ _ _ _)
> >   1655:16  0 (raise-exception _ #:continuable? _)
> >
> > ice-9/boot-9.scm:1655:16: In procedure raise-exception:
> > Wrong number of arguments to #<procedure 5624d66ee4a0 at
> ice-9/boot-9.scm:1153:19 (a b c d e f)>
> >
> --------------------------------------------------------------------------------------------------------------------
> >
> > Any hint that I can figure out whait's incompatible?
>
> Gosh we need to improve this info.  Anyway the procedure at
> boot-9.scm:1153:19 is a record constructor, for a record with 6 fields.
> Apparently somewhere in (artanis server server-context) is calling it
> with the wrong number of arguments.  What do you use for records?  Do
> you have your own abstraction or do you use R6RS records or something?
> Perhaps something in artanis relied on the way that R6RS records used to
> implement single inheritance, as a chain of objects instead of a flat
> record.  Or perhaps the adaptations to R6RS records in Guile introduced
> a bug.  I am interested to know the answer :)
>
> Andy
>
>

[-- Attachment #2: Type: text/html, Size: 2097 bytes --]

Re: GNU Guile 2.9.8 Released [beta]

[Nala Ginrut]

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

Hi Wingo!
Here're update:
1. 2.9.9 didn't fix this issue

2. I imported r6rs record-type in (artanis utils), and this module was
imported in almost every artanis modules.
I do use r6rs specific record API to introspect the internal things for
debugging in Artanis.
And I imported r6rs define-record-type in server-context.scm
I guess there're some name conflicting.



On Sat, Jan 11, 2020 at 6:33 PM Andy Wingo <wingo@pobox.com> wrote:

> On Wed 08 Jan 2020 15:22, Nala Ginrut <nalaginrut@gmail.com> writes:
>
> > In unknown file:
> >            4 (primitive-load-path "artanis/server/server-context" #<…>)
> > In ice-9/eval.scm:
> >    626:19  3 (_ #<directory (artanis server server-context) 5624d6b3…>)
> >     155:9  2 (_ #<directory (artanis server server-context) 5624d6b3…>)
> > In ice-9/boot-9.scm:
> >   1153:19  1 (_ _ _ _ _ _ _)
> >   1655:16  0 (raise-exception _ #:continuable? _)
> >
> > ice-9/boot-9.scm:1655:16: In procedure raise-exception:
> > Wrong number of arguments to #<procedure 5624d66ee4a0 at
> ice-9/boot-9.scm:1153:19 (a b c d e f)>
> >
> --------------------------------------------------------------------------------------------------------------------
> >
> > Any hint that I can figure out whait's incompatible?
>
> Gosh we need to improve this info.  Anyway the procedure at
> boot-9.scm:1153:19 is a record constructor, for a record with 6 fields.
> Apparently somewhere in (artanis server server-context) is calling it
> with the wrong number of arguments.  What do you use for records?  Do
> you have your own abstraction or do you use R6RS records or something?
> Perhaps something in artanis relied on the way that R6RS records used to
> implement single inheritance, as a chain of objects instead of a flat
> record.  Or perhaps the adaptations to R6RS records in Guile introduced
> a bug.  I am interested to know the answer :)
>
> Andy
>

[-- Attachment #2: Type: text/html, Size: 2540 bytes --]

Re: GNU Guile 2.9.8 Released [beta]

[Nala Ginrut]

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

Just a report, the same compiling error existing in Guile-3.0.0.

Best regards.


On Tue, Jan 14, 2020 at 4:49 PM Nala Ginrut <nalaginrut@gmail.com> wrote:

> Hi Wingo!
> Here're update:
> 1. 2.9.9 didn't fix this issue
>
> 2. I imported r6rs record-type in (artanis utils), and this module was
> imported in almost every artanis modules.
> I do use r6rs specific record API to introspect the internal things for
> debugging in Artanis.
> And I imported r6rs define-record-type in server-context.scm
> I guess there're some name conflicting.
>
>
>
> On Sat, Jan 11, 2020 at 6:33 PM Andy Wingo <wingo@pobox.com> wrote:
>
>> On Wed 08 Jan 2020 15:22, Nala Ginrut <nalaginrut@gmail.com> writes:
>>
>> > In unknown file:
>> >            4 (primitive-load-path "artanis/server/server-context" #<…>)
>> > In ice-9/eval.scm:
>> >    626:19  3 (_ #<directory (artanis server server-context) 5624d6b3…>)
>> >     155:9  2 (_ #<directory (artanis server server-context) 5624d6b3…>)
>> > In ice-9/boot-9.scm:
>> >   1153:19  1 (_ _ _ _ _ _ _)
>> >   1655:16  0 (raise-exception _ #:continuable? _)
>> >
>> > ice-9/boot-9.scm:1655:16: In procedure raise-exception:
>> > Wrong number of arguments to #<procedure 5624d66ee4a0 at
>> ice-9/boot-9.scm:1153:19 (a b c d e f)>
>> >
>> --------------------------------------------------------------------------------------------------------------------
>> >
>> > Any hint that I can figure out whait's incompatible?
>>
>> Gosh we need to improve this info.  Anyway the procedure at
>> boot-9.scm:1153:19 is a record constructor, for a record with 6 fields.
>> Apparently somewhere in (artanis server server-context) is calling it
>> with the wrong number of arguments.  What do you use for records?  Do
>> you have your own abstraction or do you use R6RS records or something?
>> Perhaps something in artanis relied on the way that R6RS records used to
>> implement single inheritance, as a chain of objects instead of a flat
>> record.  Or perhaps the adaptations to R6RS records in Guile introduced
>> a bug.  I am interested to know the answer :)
>>
>> Andy
>>
>

[-- Attachment #2: Type: text/html, Size: 3042 bytes --]

Re: GNU Guile 2.9.8 Released [beta]

[Nala Ginrut]

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

@Andy Wingo <wingo@pobox.com>
It's my mistake to call an incompatible constructor after I updated the
interfaces. I think Guile-3 made more strict checking because this mistake
wasn't caught before 2.9.

Now folks may use docker to try Artanis on Guile-3

docker pull registry.gitlab.com/nalaginrut/artanis:latest

Best regards.



On Sun, Jan 19, 2020 at 3:43 AM Nala Ginrut <nalaginrut@gmail.com> wrote:

> Just a report, the same compiling error existing in Guile-3.0.0.
>
> Best regards.
>
>
> On Tue, Jan 14, 2020 at 4:49 PM Nala Ginrut <nalaginrut@gmail.com> wrote:
>
>> Hi Wingo!
>> Here're update:
>> 1. 2.9.9 didn't fix this issue
>>
>> 2. I imported r6rs record-type in (artanis utils), and this module was
>> imported in almost every artanis modules.
>> I do use r6rs specific record API to introspect the internal things for
>> debugging in Artanis.
>> And I imported r6rs define-record-type in server-context.scm
>> I guess there're some name conflicting.
>>
>>
>>
>> On Sat, Jan 11, 2020 at 6:33 PM Andy Wingo <wingo@pobox.com> wrote:
>>
>>> On Wed 08 Jan 2020 15:22, Nala Ginrut <nalaginrut@gmail.com> writes:
>>>
>>> > In unknown file:
>>> >            4 (primitive-load-path "artanis/server/server-context" #<…>)
>>> > In ice-9/eval.scm:
>>> >    626:19  3 (_ #<directory (artanis server server-context) 5624d6b3…>)
>>> >     155:9  2 (_ #<directory (artanis server server-context) 5624d6b3…>)
>>> > In ice-9/boot-9.scm:
>>> >   1153:19  1 (_ _ _ _ _ _ _)
>>> >   1655:16  0 (raise-exception _ #:continuable? _)
>>> >
>>> > ice-9/boot-9.scm:1655:16: In procedure raise-exception:
>>> > Wrong number of arguments to #<procedure 5624d66ee4a0 at
>>> ice-9/boot-9.scm:1153:19 (a b c d e f)>
>>> >
>>> --------------------------------------------------------------------------------------------------------------------
>>> >
>>> > Any hint that I can figure out whait's incompatible?
>>>
>>> Gosh we need to improve this info.  Anyway the procedure at
>>> boot-9.scm:1153:19 is a record constructor, for a record with 6 fields.
>>> Apparently somewhere in (artanis server server-context) is calling it
>>> with the wrong number of arguments.  What do you use for records?  Do
>>> you have your own abstraction or do you use R6RS records or something?
>>> Perhaps something in artanis relied on the way that R6RS records used to
>>> implement single inheritance, as a chain of objects instead of a flat
>>> record.  Or perhaps the adaptations to R6RS records in Guile introduced
>>> a bug.  I am interested to know the answer :)
>>>
>>> Andy
>>>
>>

[-- Attachment #2: Type: text/html, Size: 4009 bytes --]