GNU Guile 2.0.10 released

GNU Guile 2.0.10 released

[Ludovic Courtès]

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

We are pleased to announce GNU Guile release 2.0.10, the next maintenance
release for the 2.0.x stable series.

This release contains 253 commits by 11 people over 11 months.

The Guile web page is located at http://gnu.org/software/guile/ .

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 and
a large subset of R6RS, 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 suitable for stand-alone applications.  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.

========================================================================
Here are the compressed sources:
  ftp://ftp.gnu.org/gnu/guile/guile-2.0.10.tar.gz   (7.2MB)
  ftp://ftp.gnu.org/gnu/guile/guile-2.0.10.tar.xz   (4.5MB)

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

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

Here are the MD5 and SHA1 checksums:

74c583b173075cc576f9e7abcf394f90  guile-2.0.10.tar.gz
70e9d9100d84159720fe46b27210812b  guile-2.0.10.tar.xz
784839fa8b925e3c4be75017e2dd65f4e9920a7b  guile-2.0.10.tar.gz
5c1a9e61d796932ac6b924fd931dce29f043bfbb  guile-2.0.10.tar.xz

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify guile-2.0.10.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 EA52ECF4

and rerun the 'gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.69
  Automake 1.14
  Libtool 2.4.2
  Makeinfo 5.2
  Gnulib v0.1-92-g546ff82


========================================================================
This release provides new interfaces, many bug fixes, and performance
improvements.  Here are the highlights, taken from the `NEWS' file:

  Changes in 2.0.10 (since 2.0.9):

  * Notable changes

  ** New GDB extension to support Guile

  Guile now comes with an extension for GDB 7.8 or later (unreleased at
  the time of writing) that simplifies debugging of C code that uses
  Guile.  See "GDB Support" in the manual.

  ** Improved integration between R6RS and native Guile exceptions

  R6RS exception handlers, established using 'with-exception-handler' or
  'guard', are now able to catch native Guile exceptions, which are
  automatically converted into appropriate R6RS condition objects.

  ** Support for HTTP proxies

  Guile's built-in web client now honors the 'http_proxy' environment
  variable, as well as the new 'current-http-proxy' parameter.  See
  "Web Client" in the manual for details.

  ** Lexical syntax improvements

  *** Support |...| symbol notation.

  Guile's core reader and printer now support the R7RS |...| notation
  for writing symbols with arbitrary characters, as a more portable and
  attractive alternative to Guile's native #{...}# notation.  To enable
  this notation by default, put one or both of the following in your
  ~/.guile:

    (read-enable  'r7rs-symbols)
    (print-enable 'r7rs-symbols)

  *** Support '#true' and '#false' notation for booleans.

  The booleans '#t' and '#f' may now be written as '#true' and '#false'
  for improved readability, per R7RS.

  *** Recognize '#\escape' character name.

  The escape character '#\esc' may now be written as '#\escape', per R7RS.

  *** Accept "\|" in string literals.

  The pipe character may now be preceded by a backslash, per R7RS.

  ** Custom binary input ports now support 'setvbuf'.

  Until now, ports returned by 'make-custom-binary-input-port' were always
  full-buffered.  Now, their buffering mode can be changed using 'setvbuf'.

  ** SRFI-4 predicates and length accessors no longer accept arrays.

  Given that the SRFI-4 accessors don't work for arrays, the fact that the
  predicates and length accessors returned true for arrays was a bug.

  ** GUILE_PROGS now supports specifying a minimum required version.

  The 'GUILE_PROGS' autoconf macro in guile.m4 now allows an optional
  argument to specify a minimum required Guile version.  By default, it
  requires Guile >= 2.0.  A micro version can also be specified, e.g.:
  GUILE_PROGS([2.0.10])

  ** Error reporting improvements

  *** Improved run-time error reporting in (ice-9 match).

  If no pattern matches in a 'match' form, the datum that failed to match
  is printed along with the location of the failed 'match' invocation.

  *** Print the faulty object upon invalid-keyword errors.
  *** Improved error reporting of procedures defined by define-inlinable.
  *** Improved error reporting for misplaced ellipses in macro definitions.
  *** Improved error checking in 'define-public' and 'module-add!'.
  *** Improved error when 'include' form with relative path is not in a file.

  ** Speed improvements

  *** 'scm_c_read' on ISO-8859-1 (e.g. binary) unbuffered ports is faster.
  *** New inline asm for VM fixnum multiply, for faster overflow checking.
  *** New inline asm for VM fixnum operations on ARM and 32-bit x86.
  *** 'positive?' and 'negative?' are now compiled to VM primitives.
  *** Numerical comparisons with more than 2 arguments are compiled to VM code.
  *** Several R6RS bitwise operators have been optimized.

  ** Miscellaneous

  *** Web: 'content-disposition' headers are now supported.
  *** Web: 'uri-encode' hexadecimal percent-encoding is now uppercase.
  *** Size argument to 'make-doubly-weak-hash-table' is now optional.
  *** Timeout for 'unlock-mutex' and SRFI-18 'mutex-unlock!' may now be #f.

  ** Gnulib update

  Guile's copy of Gnulib was updated to v0.1-92-g546ff82.  The following
  modules were imported from Gnulib: copysign, fsync, isfinite, link,
  lstat, mkdir, mkstemp, readlink, rename, rmdir, and unistd.

  * New interfaces

  ** Cooperative REPL servers

  This new facility supports REPLs that run at specified times within an
  existing thread, for example in programs utilizing an event loop or in
  single-threaded programs.  This allows for safe access and mutation of
  a program's data structures from the REPL without concern for thread
  synchronization.  See "Cooperative REPL Servers" in the manual for
  details.

  ** SRFI-43 (Vector Library)

  Guile now includes SRFI-43, a comprehensive library of vector operations
  analogous to the SRFI-1 list library.  See "SRFI-43" in the manual for
  details.

  ** SRFI-64 (A Scheme API for test suites)

  Guile now includes SRFI-64, a flexible framework for creating test
  suites.  The reference implementation of SRFI-64 has also been updated
  to fully support earlier versions of Guile.

  ** SRFI-111 (Boxes)

  See "SRFI-111" in the manual.

  ** 'define-values'

  See "Binding multiple return values" in the manual.

  ** Custom ellipsis identifiers using 'with-ellipsis' or SRFI-46.

  Guile now allows macro definitions to use identifiers other than '...'
  as the ellipsis.  This is convenient when writing macros that generate
  macro definitions.  The desired ellipsis identifier can be given as the
  first operand to 'syntax-rules', as specified in SRFI-46 and R7RS, or by
  using the new 'with-ellipsis' special form in procedural macros.  With
  this addition, Guile now fully supports SRFI-46.

  See "Specifying a Custom Ellipsis Identifier" and "Custom Ellipsis
  Identifiers for syntax-case Macros" in the manual for details.

  ** R7RS 'syntax-error'

  Guile now supports 'syntax-error', as specified by R7RS, allowing for
  improved compile-time error reporting from 'syntax-rules' macros.  See
  "Reporting Syntax Errors in Macros" in the manual for details.

  ** New procedures to convert association lists into hash tables

  Guile now includes the convenience procedures 'alist->hash-table',
  'alist->hashq-table', 'alist->hashv-table', and 'alist->hashx-table'.
  See "Hash Table Reference" in the manual.

  ** New predicates: 'exact-integer?' and 'scm_is_exact_integer'

  See "Integers" in the manual.

  ** 'weak-vector-length', 'weak-vector-ref', and 'weak-vector-set!'

  These should now be used to access weak vectors, instead of
  'vector-length', 'vector-ref', and 'vector-set!'.

  * Manual updates

  ** Improve docs for 'eval-when'.

  Each 'eval-when' condition is now explained in detail, including
  'expand' which was previously undocumented.  (expand load eval) is now
  the recommended set of conditions, instead of (compile load eval).
  See "Eval When" in the manual, for details.

  ** Update the section on SMOBs and memory management.

  See "Defining New Types (Smobs)" in the manual.

  ** Fixes

  *** GOOPS: #:dsupers is the init keyword for the dsupers slot.
  *** 'unfold-right' takes a tail, not a tail generator.
  *** Clarify that 'append!' and 'reverse!' might not mutate.
  *** Fix doc that incorrectly claimed (integer? +inf.0) => #t.
      (http://bugs.gnu.org/16356)
  *** Document that we support SRFI-62 (S-expression comments).
  *** Document that we support SRFI-87 (=> in case clauses).
  *** Document 'equal?' in the list of R6RS incompatibilities.
  *** Remove outdated documentation of LTDL_LIBRARY_PATH.
  *** Fix 'weak-vector?' doc: Weak hash tables are not weak vectors.
  *** Fix 'my-or' examples to use let-bound variable.
      (http://bugs.gnu.org/14203)

  * New deprecations

  ** General 'uniform-vector' interface

  This interface lacked both generality and specificity.  The general
  replacements are 'array-length', 'array-ref', and friends on the scheme
  side, and the array handle interface on the C side.  On the specific
  side of things, there are the specific bytevector, SRFI-4, and bitvector
  interfaces.

  ** Use of the vector interface on arrays
  ** 'vector-length', 'vector-ref', and 'vector-set!' on weak vectors
  ** 'vector-length', 'vector-ref', and 'vector-set!' as primitive-generics

  Making the vector interface operate only on a single representation will
  allow future versions of Guile to compile loops involving vectors to
  more efficient native code.

  ** 'htons', 'htonl', 'ntohs', 'ntohl'

  These procedures, like their C counterpart, were used to convert numbers
  to/from network byte order, typically in conjunction with the
  now-deprecated uniform vector API.

  This functionality is now covered by the bytevector and binary I/O APIs.
  See "Interpreting Bytevector Contents as Integers" in the manual.

  ** 'gc-live-object-stats'

  It hasn't worked in the whole 2.0 series.  There is no replacement,
  unfortunately.

  ** 'scm_c_program_source'

  This internal VM function was not meant to be public.  Use
  'scm_procedure_source' instead.

  * Build fixes

  ** Fix build with Clang 3.4.

  ** MinGW build fixes
  *** Do not add $(EXEEXT) to guild or guile-tools.
  *** tests: Use double quotes around shell arguments, for Windows.
  *** tests: Don't rely on $TMPDIR and /tmp on Windows.
  *** tests: Skip FFI tests that use `qsort' when it's not accessible.
  *** tests: Remove symlink only when it exists.
  *** tests: Don't rely on `scm_call_2' being visible.

  ** Fix computation of LIBLOBJS so dependencies work properly.
     (http://bugs.gnu.org/14193)

  * Bug fixes

  ** Web: Fix web client with methods other than GET.
     (http://bugs.gnu.org/15908)
  ** Web: Add Content-Length header for empty bodies.
  ** Web: Accept "UTC" as the zone offset in date headers.
     (http://bugs.gnu.org/14128)
  ** Web: Don't throw if a response is longer than its Content-Length says.
  ** Web: Write out HTTP Basic auth headers correctly.
     (http://bugs.gnu.org/14370)
  ** Web: Always print a path component in 'write-request-line'.
  ** Fix 'define-public' from (ice-9 curried-definitions).
  ** psyntax: toplevel variable definitions discard previous syntactic binding.
     (http://bugs.gnu.org/11988)
  ** Fix thread-unsafe lazy initializations.
  ** Make (ice-9 popen) thread-safe.
     (http://bugs.gnu.org/15683)
  ** Make guardians thread-safe.
  ** Make regexp_exec thread-safe.
     (http://bugs.gnu.org/14404)
  ** vm: Gracefully handle stack overflows.
     (http://bugs.gnu.org/15065)
  ** Fix 'rationalize'.
     (http://bugs.gnu.org/14905)
  ** Fix inline asm for VM fixnum operations on x32.
  ** Fix 'SCM_SYSCALL' to really swallow EINTR.
  ** Hide EINTR returns from 'accept'.
  ** SRFI-19: Update the table of leap seconds.
  ** Add missing files to the test-suite Makefile.
  ** Make sure 'ftw' allows directory traversal when running as root.
  ** Fix 'hash-for-each' for weak hash tables.
  ** SRFI-18: Export 'current-thread'.
     (http://bugs.gnu.org/16890)
  ** Fix inlining of tail list to apply.
     (http://bugs.gnu.org/15533)
  ** Fix bug in remqueue in threads.c when removing last element.
  ** Fix build when '>>' on negative integers is not arithmetic.
  ** Fix 'bitwise-bit-count' for negative arguments.
     (http://bugs.gnu.org/14864)
  ** Fix VM 'ash' for right shifts by large amounts.
     (http://bugs.gnu.org/14864)
  ** Fix rounding in scm_i_divide2double for negative arguments.
  ** Avoid lossy conversion from inum to double in numerical comparisons.
  ** Fix numerical comparison of fractions to infinities.
  ** Allow fl+ and fl* to accept zero arguments.
     (http://bugs.gnu.org/14869)
  ** flonum? returns false for complex number objects.
     (http://bugs.gnu.org/14866)
  ** flfinite? applied to a NaN returns false.
     (http://bugs.gnu.org/14868)
  ** Flonum operations always return flonums.
     (http://bugs.gnu.org/14871)
  ** min and max: NaNs beat infinities, per R6RS errata.
     (http://bugs.gnu.org/14865)
  ** Fix 'fxbit-count' for negative arguments.
  ** 'gcd' and 'lcm' support inexact integer arguments.
     (http://bugs.gnu.org/14870)
  ** Fix R6RS 'fixnum-width'.
     (http://bugs.gnu.org/14879)
  ** tests: Use shell constructs that /bin/sh on Solaris 10 can understand.
     (http://bugs.gnu.org/14042)
  ** Fix display of symbols containing backslashes.
     (http://bugs.gnu.org/15033)
  ** Fix truncated-print for uniform vectors.
  ** Define `AF_UNIX' only when Unix-domain sockets are supported.
  ** Decompiler: fix handling of empty 'case-lambda' expressions.
  ** Fix handling of signed zeroes and infinities in 'numerator' and 'denominator'.
  ** dereference-pointer: check for null pointer.
  ** Optimizer: Numerical comparisons are not negatable, for correct NaN handling.
  ** Compiler: Evaluate '-' and '/' in left-to-right order.
     (for more robust floating-point arithmetic)
  ** snarf.h: Declare static const function name vars as SCM_UNUSED.
  ** chars.c: Remove duplicate 'const' specifiers.
  ** Modify SCM_UNPACK type check to avoid warnings in clang.
  ** Arrange so that 'file-encoding' does not truncate the encoding name.
     (http://bugs.gnu.org/16463)
  ** Improve error checking in bytevector->uint-list and bytevector->sint-list.
     (http://bugs.gnu.org/15100)
  ** Fix (ash -1 SCM_I_FIXNUM_BIT-1) to return a fixnum instead of a bignum.
  ** i18n: Fix null pointer dereference when locale info is missing.
  ** Fix 'string-copy!' to work properly with overlapping src/dest.
  ** Fix hashing of vectors to run in bounded time.
  ** 'port-position' works on CBIPs that do not support 'set-port-position!'.
  ** Custom binary input ports sanity-check the return value of 'read!'.
  ** bdw-gc.h: Check SCM_USE_PTHREAD_THREADS using #if not #ifdef.
  ** REPL Server: Don't establish a SIGINT handler.
  ** REPL Server: Redirect warnings to client socket.
  ** REPL Server: Improve robustness of 'stop-server-and-clients!'.
  ** Add srfi-16, srfi-30, srfi-46, srfi-62, srfi-87 to %cond-expand-features.
  ** Fix trap handlers to handle applicable structs.
     (http://bugs.gnu.org/15691)
  ** Fix optional end argument in `uniform-vector-read!'.
     (http://bugs.gnu.org/15370)
  ** Fix brainfuck->scheme compiler.
  ** texinfo: Fix newline preservation in @example with lines beginning with @

  ** C standards conformance improvements

  Improvements and bug fixes were made to the C part of Guile's run-time
  support (libguile).

  *** Don't use the identifier 'noreturn'.
      (http://bugs.gnu.org/15798)
  *** Rewrite SCM_I_INUM to avoid unspecified behavior when not using GNU C.
  *** Improve fallback implemention of SCM_SRS to avoid unspecified behavior.
  *** SRFI-60: Reimplement 'rotate-bit-field' on inums to be more portable.
  *** Improve compliance with C standards regarding signed integer shifts.
  *** Avoid signed overflow in random.c.
  *** VM: Avoid signed overflows in 'add1' and 'sub1'.
  *** VM: Avoid overflow in ASM_ADD when the result is most-positive-fixnum.
  *** read: Avoid signed integer overflow in 'read_decimal_integer'.

========================================================================
The following people contributed to this release:

     2  Aleix Conchillo Flaque
     1  Alexandru Cojocaru
    21  Andy Wingo
     1  Arne Babenhauserheide
     1  Chris K. Jester-Young
     1  David Kastrup
     3  David Thompson
     7  Ian Price
    44  Ludovic Courtès
   170  Mark H Weaver
     2  Tom Tromey

You can follow Guile development in the Git repository and on the Guile
mailing lists.  Guile builds from the `master' branch of Git have
version number 2.1.x.

Guile versions with an odd middle number, e.g., 2.1.*, are unstable
development versions.  Even middle numbers indicate stable versions.
This has been the case since the 1.3.* series.

Please report bugs to `bug-guile@gnu.org'.  We also welcome reports of
successful builds, which can be sent to the same email address.


Ludovic, on behalf of the Guile team.

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

Re: GNU Guile 2.0.10 released

[Andy Wingo]

Thanks to all the new contributors on this one, and thanks especially to
Mark!

Andy
-- 
http://wingolog.org/

Re: GNU Guile 2.0.10 released

[Panicz Maciej Godek]

Delightful to hear that. Thanks a lot for the work!

However, when I'm trying to build it under mingw, I get the following error:

../lib/.libs/libgnu.a(mkstemp.o): In function `mkstemp':
c:\dev\guile-2.0.10\lib/mkstemp.c:48: multiple definition of `mkstemp'
.libs/libguile_2.0_la-mkstemp.o:c:\dev\guile-2.0.10\libguile/mkstemp.c:68:
first defined here

(and indeed, the function is defined twice, once in
libguile/mkstemp.c, and the second time in lib/mkstemp.c)

Any clues how to fix it?

(I am using latest mingw with gc-7.2e configured with --enable-threads=posix)

Re: GNU Guile 2.0.10 released

[Ludovic Courtès]

Panicz Maciej Godek <godek.maciek@gmail.com> skribis:

> Delightful to hear that. Thanks a lot for the work!
>
> However, when I'm trying to build it under mingw, I get the following error:
>
> ../lib/.libs/libgnu.a(mkstemp.o): In function `mkstemp':
> c:\dev\guile-2.0.10\lib/mkstemp.c:48: multiple definition of `mkstemp'
> .libs/libguile_2.0_la-mkstemp.o:c:\dev\guile-2.0.10\libguile/mkstemp.c:68:
> first defined here
>
> (and indeed, the function is defined twice, once in
> libguile/mkstemp.c, and the second time in lib/mkstemp.c)

Oops, indeed.

Could you edit libguile/Makefile.am (or libguile/Makefile.in, if
Automake isn’t installed), and remove occurrences of mkstemp.c in there?

Let us know if it solves the problem.

Thanks,
Ludo’.

Re: GNU Guile 2.0.10 released

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Panicz Maciej Godek <godek.maciek@gmail.com> skribis:
>
>> Delightful to hear that. Thanks a lot for the work!
>>
>> However, when I'm trying to build it under mingw, I get the following error:
>>
>> ../lib/.libs/libgnu.a(mkstemp.o): In function `mkstemp':
>> c:\dev\guile-2.0.10\lib/mkstemp.c:48: multiple definition of `mkstemp'
>> .libs/libguile_2.0_la-mkstemp.o:c:\dev\guile-2.0.10\libguile/mkstemp.c:68:
>> first defined here
>>
>> (and indeed, the function is defined twice, once in
>> libguile/mkstemp.c, and the second time in lib/mkstemp.c)
>
> Oops, indeed.
>
> Could you edit libguile/Makefile.am (or libguile/Makefile.in, if
> Automake isn’t installed), and remove occurrences of mkstemp.c in there?
>
> Let us know if it solves the problem.

Interesting.  Madsy and I both built Guile (950a966, very close to
2.0.10) successfully using MinGW without running into this problem.
I wonder why we didn't hit this.

     Mark

Re: GNU Guile 2.0.10 released

[Panicz Maciej Godek]

2014-03-19 14:50 GMT+01:00 Ludovic Courtès <ludo@gnu.org>:

> Could you edit libguile/Makefile.am (or libguile/Makefile.in, if
> Automake isn't installed), and remove occurrences of mkstemp.c in there?
>
> Let us know if it solves the problem.

I did remove the only reference to mkstemp.c that appeared in the
Makefile.am, then run autoreconf and configure, but it turned out that
there were still some dependencies on libguile_2.0_la-mkstemp.o in the
generated libguile/Makefile. After removing those, I went through that
part of compilation, but the process stalled on the GEN
guile-procedures.texi.

Furthermore, after pressing C-c, I had some "permission denied" error.
(I don't know if that's the original, but after repeating the process
with some modifications it didn't even get to the "GEN", but at the
stage of CCLD libguile-2.0.la it produces:
..../mingw/bin/ld.exe: cannot open output file
.libs/libguile-2.0.22.dll: Permission denied)

BTW I had to run configure with
ac_cv_func__set_invalid_parameter_handler=no
because otherwise I had a "_set_invalid_parameter_handler could not be
located in the dynamic link library msvcrt.dll" error popup.

Re: GNU Guile 2.0.10 released

[Ludovic Courtès]

Panicz Maciej Godek <godek.maciek@gmail.com> skribis:

> 2014-03-19 14:50 GMT+01:00 Ludovic Courtès <ludo@gnu.org>:
>
>> Could you edit libguile/Makefile.am (or libguile/Makefile.in, if
>> Automake isn't installed), and remove occurrences of mkstemp.c in there?
>>
>> Let us know if it solves the problem.
>
> I did remove the only reference to mkstemp.c that appeared in the
> Makefile.am, then run autoreconf and configure, but it turned out that
> there were still some dependencies on libguile_2.0_la-mkstemp.o in the
> generated libguile/Makefile. After removing those, I went through that
> part of compilation, but the process stalled on the GEN
> guile-procedures.texi.

OK.  How long did you wait?  That part can take a bit of time (I’d say
30s to 1mn maybe) because it runs the yet-to-be-compiled Guile.

> Furthermore, after pressing C-c, I had some "permission denied" error.
> (I don't know if that's the original, but after repeating the process
> with some modifications it didn't even get to the "GEN", but at the
> stage of CCLD libguile-2.0.la it produces:
> ..../mingw/bin/ld.exe: cannot open output file
> .libs/libguile-2.0.22.dll: Permission denied)

It looks like a setup issue on the machine, no?

> BTW I had to run configure with
> ac_cv_func__set_invalid_parameter_handler=no
> because otherwise I had a "_set_invalid_parameter_handler could not be
> located in the dynamic link library msvcrt.dll" error popup.

Hmm, do you know what that means?  This actually comes from Gnulib’s
‘msvc-inval’ module, so it would be great if you could provide a
detailed report at bug-gnulib@gnu.org.

Thanks!

Ludo’.

Re: GNU Guile 2.0.10 released

[Panicz Maciej Godek]

2014-03-20 9:04 GMT+01:00 Ludovic Courtès <ludo@gnu.org>:
> Panicz Maciej Godek <godek.maciek@gmail.com> skribis:
[...]
>> I did remove the only reference to mkstemp.c that appeared in the
>> Makefile.am, then run autoreconf and configure, but it turned out that
>> there were still some dependencies on libguile_2.0_la-mkstemp.o in the
>> generated libguile/Makefile. After removing those, I went through that
>> part of compilation, but the process stalled on the GEN
>> guile-procedures.texi.
>
> OK.  How long did you wait?  That part can take a bit of time (I'd say
> 30s to 1mn maybe) because it runs the yet-to-be-compiled Guile.

I decided to run the whole process once again, and GEN
guile-procedures.texi has been running for almost an hour now, and it
clearly uses no CPU.

I had a "process hacker" tool installed, and it allows me to do some
introspection (although I understand very little). There are two
threads running in the "youngest" guile.exe (#2820), the first one
with start address
guile.exe+0x1570
and the second with
msvcrt.dll!endthreadex+0x3a

When I inspect the first thread, I get:

0, ntkrnlpa.exe!KiDeliverApc+0xb3
1, ntkrnlpa.exe!ZwYieldExecution+0x19ae
2, ntkrnlpa.exe!NtWaitForSingleObject+0x38c
3, ntkrnlpa.exe!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb14
4, ntdll.dll!KiFastSystemCallRet
5, kernel32.dll!WaitForMultipleObjects+0x18
6, pthreadGC2.dll!pthreadCancelableTimedWait+0x4b
7, pthreadGC2.dll!sem_timedwait+0x16f
8, 0x79a50

The inspection of the second thread shows:

0, ntkrnlpa.exe!KiDeliverApc+0xb3
1, ntkrnlpa.exe!ZwYieldExecution+0x19ae
2, ntkrnlpa.exe!NtWaitForSingleObject+0x9a
3, ntkrnlpa.exe!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb14
4, ntdll.dll!KiFastSystemCallRet
5, ntdll.dll!RtlEnterCriticalSection+0x46
6, ntdll.dll!KiUserApcDispatcher+0x7

When I use the "analyze > wait" option on the first thread, I get:
Thread is waiting (alertable, wait all) for:
Handle 0x79a50 (Semaphore): (unnamed object)
Handle 0x7b4 (Event): (unnamed object)

The same "analyze > wait" on the second thread results with a popup
which explains that "the thread doesn't appear to be waiting".

The analyzed process occupies 71,55MB and is a child process of
another guile.exe process (#2120), which uses 308kB and consists of
one thread, whose "wait analysis" shows:
Thread is waiting (alertable) for:
Handle 0x7c0 (Process): guile.exe (2820)
[no surprise]

It looks like it has something to do with the multithreaded bdw-gc, so
I'm sending a copy of this letter to bdwgc@lists.opendylan.org with a
mention that I'm using gc-7.2e configured with --enable-threads=posix
(on mingw, of course), perhaps they might know what's going on.

>> Furthermore, after pressing C-c, I had some "permission denied" error.
>> (I don't know if that's the original, but after repeating the process
>> with some modifications it didn't even get to the "GEN", but at the
>> stage of CCLD libguile-2.0.la it produces:
>> ..../mingw/bin/ld.exe: cannot open output file
>> .libs/libguile-2.0.22.dll: Permission denied)
>
> It looks like a setup issue on the machine, no?

It turned out that C-c didn't kill the process, but apparently it
detached it from the terminal, and it had been occupying the resource
all that time.

>> BTW I had to run configure with
>> ac_cv_func__set_invalid_parameter_handler=no
>> because otherwise I had a "_set_invalid_parameter_handler could not be
>> located in the dynamic link library msvcrt.dll" error popup.
>
> Hmm, do you know what that means?  This actually comes from Gnulib's
> 'msvc-inval' module, so it would be great if you could provide a
> detailed report at bug-gnulib@gnu.org.

I have found that solution here:
http://mingw.5.n7.nabble.com/Building-gettext-from-source-using-GCC-4-7-2-td32229.html
but I really don't know what it means, and I think I'd have to examine
that in more detail before daring to send a bug report, since the
issue seems to be known.

Thank you,
M.

Re: GNU Guile 2.0.10 released

[Eli Zaretskii]

> Date: Thu, 20 Mar 2014 11:34:53 +0100
> From: Panicz Maciej Godek <godek.maciek@gmail.com>
> Cc: bdwgc@lists.opendylan.org, "guile-user@gnu.org" <guile-user@gnu.org>
> 
> >> I did remove the only reference to mkstemp.c that appeared in the
> >> Makefile.am, then run autoreconf and configure, but it turned out that
> >> there were still some dependencies on libguile_2.0_la-mkstemp.o in the
> >> generated libguile/Makefile. After removing those, I went through that
> >> part of compilation, but the process stalled on the GEN
> >> guile-procedures.texi.
> >
> > OK.  How long did you wait?  That part can take a bit of time (I'd say
> > 30s to 1mn maybe) because it runs the yet-to-be-compiled Guile.
> 
> I decided to run the whole process once again, and GEN
> guile-procedures.texi has been running for almost an hour now, and it
> clearly uses no CPU.
> 
> I had a "process hacker" tool installed, and it allows me to do some
> introspection (although I understand very little). There are two
> threads running in the "youngest" guile.exe (#2820), the first one
> with start address
> guile.exe+0x1570
> and the second with
> msvcrt.dll!endthreadex+0x3a
> 
> When I inspect the first thread, I get:
> 
> 0, ntkrnlpa.exe!KiDeliverApc+0xb3
> 1, ntkrnlpa.exe!ZwYieldExecution+0x19ae
> 2, ntkrnlpa.exe!NtWaitForSingleObject+0x38c
> 3, ntkrnlpa.exe!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb14
> 4, ntdll.dll!KiFastSystemCallRet
> 5, kernel32.dll!WaitForMultipleObjects+0x18
> 6, pthreadGC2.dll!pthreadCancelableTimedWait+0x4b
> 7, pthreadGC2.dll!sem_timedwait+0x16f
> 8, 0x79a50
> 
> The inspection of the second thread shows:
> 
> 0, ntkrnlpa.exe!KiDeliverApc+0xb3
> 1, ntkrnlpa.exe!ZwYieldExecution+0x19ae
> 2, ntkrnlpa.exe!NtWaitForSingleObject+0x9a
> 3, ntkrnlpa.exe!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb14
> 4, ntdll.dll!KiFastSystemCallRet
> 5, ntdll.dll!RtlEnterCriticalSection+0x46
> 6, ntdll.dll!KiUserApcDispatcher+0x7
> 
> When I use the "analyze > wait" option on the first thread, I get:
> Thread is waiting (alertable, wait all) for:
> Handle 0x79a50 (Semaphore): (unnamed object)
> Handle 0x7b4 (Event): (unnamed object)

Isn't this the same problem I reported last year, starting here:

  http://lists.gnu.org/archive/html/guile-user/2013-06/msg00022.html

I suggest to configure Guile --without-threads, and see if that
resolves the issue.

Re: [Gc] GNU Guile 2.0.10 released

[Panicz Maciej Godek]

2014-03-26 19:24 GMT+01:00 Eli Zaretskii <eliz-mXXj517/zsQ@public.gmane.org>:
>> I had a "process hacker" tool installed, and it allows me to do some
>> introspection (although I understand very little). [...]
>
> Isn't this the same problem I reported last year, starting here:
>
>   http://lists.gnu.org/archive/html/guile-user/2013-06/msg00022.html
>
> I suggest to configure Guile --without-threads, and see if that
> resolves the issue.

I suspect that it is. But I wanted to rebuild my SLAYER framework for
Windows and make a new release with Guile 2.0.10 and threads enabled
-- because then it would make more sense to distribute it.

I wish I knew a way to find out whether the problem is on Guile's or
GC's or mingw's or pthreads-win32's side.

Some guys who had similar problem (i.e. their process also stopped at
"ntdll!KiUserApcDispatcher+0x7") suggest that it is a busy resource:
http://stackoverflow.com/questions/2214465/debugging-the-dreaded-application-has-failed-to-initialize-error

So now, instead of just compiling --without-threads, I'd like to
somehow get the threaded version working, even it takes much more time
and more digging.

Re: GNU Guile 2.0.10 released

[Mike Gran]

On Wednesday, March 26, 2014 11:45 AM, Panicz Maciej Godek <godek.maciek@gmail.com> wrote:

2014-03-26 19:24 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:
>
>>> I had a "process hacker" tool installed, and it allows me to do some
>>> introspection (although I understand very little). [...]
>>
>> Isn't this the same problem I reported last year, starting here:
>>
>>  http://lists.gnu.org/archive/html/guile-user/2013-06/msg00022.html
>>
>> I suggest to configure Guile --without-threads, and see if that
>> resolves the issue.
>


Tangentially related...


The Guile build uses the in-tree Guile executable in
the GEN guile-procedure.texi step.  Backed when I hacked on Guile,
failing at that step was pretty common if the executable is less
than 100%.  But a version of Guile that isn't correct enough
to pass that step may still be functional enough to run much
of 'make check'.

Thus, I often found it useful hand edit the Makefile to strip out the
document generation steps so that the build would continue as far as
possible.

-Mike

Re: GNU Guile 2.0.10 released

[Eli Zaretskii]

> Date: Wed, 26 Mar 2014 19:44:53 +0100
> From: Panicz Maciej Godek <godek.maciek@gmail.com>
> Cc: Ludovic Courtès <ludo@gnu.org>, 
> 	bdwgc@lists.opendylan.org, "guile-user@gnu.org" <guile-user@gnu.org>
> 
> 2014-03-26 19:24 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:
> >> I had a "process hacker" tool installed, and it allows me to do some
> >> introspection (although I understand very little). [...]
> >
> > Isn't this the same problem I reported last year, starting here:
> >
> >   http://lists.gnu.org/archive/html/guile-user/2013-06/msg00022.html
> >
> > I suggest to configure Guile --without-threads, and see if that
> > resolves the issue.
> 
> I suspect that it is. But I wanted to rebuild my SLAYER framework for
> Windows and make a new release with Guile 2.0.10 and threads enabled
> -- because then it would make more sense to distribute it.

I know what you mean.  I also hate it when programs lose features when
ported.

> I wish I knew a way to find out whether the problem is on Guile's or
> GC's or mingw's or pthreads-win32's side.

Indeed.  At the time, no one here was able to help me locate the
problem.

> Some guys who had similar problem (i.e. their process also stopped at
> "ntdll!KiUserApcDispatcher+0x7") suggest that it is a busy resource:
> http://stackoverflow.com/questions/2214465/debugging-the-dreaded-application-has-failed-to-initialize-error

Last June I reported many details about the hang, you might find there
something about this stuff.  See, for example, these messages:

  http://lists.gnu.org/archive/html/guile-user/2013-06/msg00030.html
  http://lists.gnu.org/archive/html/guile-user/2013-06/msg00076.html
  http://lists.gnu.org/archive/html/guile-user/2013-06/msg00079.html

The last one leads to this:

  http://lists.gnu.org/archive/html/guile-devel/2011-06/msg00034.html

> So now, instead of just compiling --without-threads, I'd like to
> somehow get the threaded version working, even it takes much more time
> and more digging.

It would be wonderful if you succeed in solving this.  Mark told me
that someone succeeded in building MinGW Guile with pthreads, and he
built pthreads himself.  So maybe you should try that, among other
things.

Thanks.

Re: GNU Guile 2.0.10 released

[Eli Zaretskii]

> Date: Wed, 26 Mar 2014 12:02:21 -0700 (PDT)
> From: Mike Gran <spk121@yahoo.com>
> Cc: Ludovic Courtès <ludo@gnu.org>,
>   "guile-user@gnu.org" <guile-user@gnu.org>
> 
> The Guile build uses the in-tree Guile executable in
> the GEN guile-procedure.texi step.  Backed when I hacked on Guile,
> failing at that step was pretty common if the executable is less
> than 100%.  But a version of Guile that isn't correct enough
> to pass that step may still be functional enough to run much
> of 'make check'.
> 
> Thus, I often found it useful hand edit the Makefile to strip out the
> document generation steps so that the build would continue as far as
> possible.

Well, I'm sure we all tried this route here and there.  Sure enough,
back last year, I tried that as well -- but to no avail.  Guile would
get stuck during the next step, when compiling the *.scm files.  See
http://lists.gnu.org/archive/html/bug-guile/2013-05/msg00006.html for
more details.

Thanks.

Re: [Gc] GNU Guile 2.0.10 released

[Panicz Maciej Godek]

2014-03-26 20:22 GMT+01:00 Eli Zaretskii <eliz-mXXj517/zsQ@public.gmane.org>:
[...]
> Last June I reported many details about the hang, you might find there
> something about this stuff.  See, for example, these messages:
>
>   http://lists.gnu.org/archive/html/guile-user/2013-06/msg00030.html
>   http://lists.gnu.org/archive/html/guile-user/2013-06/msg00076.html
>   http://lists.gnu.org/archive/html/guile-user/2013-06/msg00079.html
>
> The last one leads to this:
>
>   http://lists.gnu.org/archive/html/guile-devel/2011-06/msg00034.html
>
>> So now, instead of just compiling --without-threads, I'd like to
>> somehow get the threaded version working, even it takes much more time
>> and more digging.
>
> It would be wonderful if you succeed in solving this.  Mark told me
> that someone succeeded in building MinGW Guile with pthreads, and he
> built pthreads himself.  So maybe you should try that, among other
> things.

Thanks for the hints and support.
I will dive into this issue next week and keep you informed how's the progress.

Re: GNU Guile 2.0.10 released

[Ludovic Courtès]

Mike Gran <spk121@yahoo.com> skribis:

> The Guile build uses the in-tree Guile executable in
> the GEN guile-procedure.texi step.  Backed when I hacked on Guile,
> failing at that step was pretty common if the executable is less
> than 100%.  But a version of Guile that isn't correct enough
> to pass that step may still be functional enough to run much
> of 'make check'.

Hmm I think when generating guile-procedures.texi fails, then it’s
really a bad sign and a good reason to stop and report the failure.

Ludo’.

Re: GNU Guile 2.0.10 released

[Mark H Weaver]

Eli Zaretskii <eliz@gnu.org> writes:
> Mark told me that someone succeeded in building MinGW Guile with
> pthreads, and he built pthreads himself.

Someone reported having done so, but that turned out to be false.  At
this point, I'm not aware of anyone who has built a working threaded
Guile for MinGW.

     Mark