bug#57507: Regular expression matching depends on locale encoding

[dsmich]

Also remember that Guile uses the system C library regex routines. And
is using C strings, not Guile strings.

(sorry for top post, too tired to fight with this web editor)

-Dale

-From: "Jean Abou Samra" 
To: 57...@debbugs.gnu.org
Cc: 
Sent: Wednesday August 31 2022 12:55:13PM
Subject: bug#57507: Regular expression matching depends on locale
encoding

 Regular expressions do funky things with Unicode if a
non-Unicode-aware
 locale is set. Yet, they're purely string operations, so I don't
think
 it's expected that they depend on the locale encoding.

 $ LC_ALL=C guile3.0
 GNU Guile 3.0.7
 Copyright (C) 1995-2021 Free Software Foundation, Inc.

 Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
 This program is free software, and you are welcome to redistribute it
 under certain conditions; type `,show c' for details.

 Enter `,help' for help.
 scheme@(guile-user)> (use-modules (ice-9 regex))
 scheme@(guile-user)> (match:substring (string-match "u203f" "u3091"))
 ice-9/boot-9.scm:1685:16: In procedure raise-exception:
 In procedure make-regexp: Invalid preceding regular expression

 Entering a new prompt. Type `,bt' for a backtrace or `,q' to
continue.
 scheme@(guile-user) [1]> ,q
 scheme@(guile-user)> (match:substring (string-match "[u203f]"
"u3091"))
 $1 = "u3091"
 scheme@(guile-user)>

bug#53201: string->uri-reference rejects domain names with final ‘.’

[dsmich]

New patch. Now with 3 test cases!

-Dale


From f4eece6395e75197030bff42a583e847e5a34e15 Mon Sep 17 00:00:00 2001
From: "Dale P. Smith" 
Date: Thu, 27 Jan 2022 19:20:57 -0500
Subject: [PATCH] Allow trailing "." in urls

bug #53201
---
 module/web/uri.scm| 17 ++---
 test-suite/tests/web-uri.test | 10 ++
 2 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/module/web/uri.scm b/module/web/uri.scm
index 8e0b9bee7..8c5c0d6f0 100644
--- a/module/web/uri.scm
+++ b/module/web/uri.scm
@@ -206,13 +206,16 @@ for ‘build-uri’ except there is no scheme."
((regexp-exec ipv6-regexp host)
 (false-if-exception (inet-pton AF_INET6 host)))
(else
-(let lp ((start 0))
-  (let ((end (string-index host #\. start)))
-(if end
-(and (regexp-exec domain-label-regexp
-  (substring host start end))
- (lp (1+ end)))
-(regexp-exec top-label-regexp host start)))
+(let ((last (1- (string-length host
+  (let lp ((start 0))
+(let ((end (string-index host #\. start)))
+  (if (and end (< end last))
+  (and (regexp-exec domain-label-regexp
+(substring host start end))
+   (lp (1+ end)))
+  (if end
+  (regexp-exec top-label-regexp (substring host start end))
+  (regexp-exec top-label-regexp host start)
 
 (define userinfo-pat
   (string-append "[" letters digits "_.!~*'();:&=+$,-]+"))
diff --git a/test-suite/tests/web-uri.test b/test-suite/tests/web-uri.test
index 95fd82f16..e9fb766f0 100644
--- a/test-suite/tests/web-uri.test
+++ b/test-suite/tests/web-uri.test
@@ -367,6 +367,16 @@
   (pass-if "//bad.host.1"
 (not (string->uri-reference "//bad.host.1")))
 
+  (pass-if "//bad.host.1."
+(not (string->uri-reference "//bad.host.1.")))
+
+  (pass-if "//bad.host.."
+(not (string->uri-reference "//bad.host..")))
+
+  (pass-if "//1.good.host."
+(uri=? (string->uri-reference "//1.good.host.")
+   #:host "1.good.host." #:path ""))
+
   (pass-if "http://1.good.host;
 (uri=? (string->uri-reference "http://1.good.host;)
#:scheme 'http #:host "1.good.host" #:path ""))
-- 
2.30.2

bug#53201: string->uri-reference rejects domain names with final ‘.’

[dsmich]

Probably not the best fix. Seems to work. Includes a few tests.

-Dale

diff --git a/module/web/uri.scm b/module/web/uri.scm
index 8e0b9bee7..d6758fcc6 100644
--- a/module/web/uri.scm
+++ b/module/web/uri.scm
@@ -212,7 +212,9 @@ for ‘build-uri’ except there is no scheme."
 (and (regexp-exec domain-label-regexp
 (substring host start end))
 (lp (1+ end)))
- (regexp-exec top-label-regexp host start)))
+ (if (< start (string-length host))
+ (regexp-exec top-label-regexp host start)
+ #t)))

 (define userinfo-pat
 (string-append "[" letters digits "_.!~*'();:&=+$,-]+"))
diff --git a/test-suite/tests/web-uri.test
b/test-suite/tests/web-uri.test
index 95fd82f16..c49142d48 100644
--- a/test-suite/tests/web-uri.test
+++ b/test-suite/tests/web-uri.test
@@ -367,6 +367,9 @@
 (pass-if "//bad.host.1"
 (not (string->uri-reference "//bad.host.1")))

+ (pass-if "//bad.host.."
+ (not (string->uri-reference "//bad.host..")))
+
 (pass-if "http://1.good.host;
 (uri=? (string->uri-reference "http://1.good.host;)
 #:scheme 'http #:host "1.good.host" #:path ""))
@@ -375,6 +378,10 @@
 (uri=? (string->uri-reference "//1.good.host")
 #:host "1.good.host" #:path ""))

+ (pass-if "//1.good.host."
+ (uri=? (string->uri-reference "//1.good.host.")
+ #:host "1.good.host." #:path ""))
+
 (when (memq 'socket *features*)
 (pass-if "http://192.0.2.1;
 (uri=? (string->uri-reference "http://192.0.2.1;)

bug#48765: `member` from (scheme base) returns empty list instead of #f when item is not found

[dsmich]

In git main it appears to work but with a warning:

$ guile --r7rs
GNU Guile 3.0.7.13-c1fd55-dirty
...

scheme@(guile-user)> (import (scheme base))
scheme@(guile-user)> (member 'a '(b))
WARNING: (guile-user): imported module (scheme base) overrides core
binding `member'
$1 = #f
scheme@(guile-user)> (member 'a '(b a))
$2 = (a)

-Dale

-From: "Arvydas Silanskas" 
To: 48...@debbugs.gnu.org
Cc: 
Sent: Monday May 31 2021 5:10:12PM
Subject: bug#48765: `member` from (scheme base) returns empty list
instead of #f when item is not found

 Default `member` works fine:

 $ guile
 > (member 'a '(b)) $1 = #f

 However, using scheme base it returns empty list 
 $ guile --r7rs
 > (import (scheme base))
 > (member 'a '(b))
 $1 = () 
 Other functions (memq, memv) seem to work fine.
 I am using version 3.0.5 as distributed by debian bullseye

bug#48480: [a-Z] is not a valid regex range in 3.0.7

[dsmich]

This *is* the error returned by the underlying C library. For example:

#include 
#include 
#include 

int main() {
 char buf[128] = {0};
 regex_t rx = {0};
 int status = regcomp(, "[a-Z]", REG_EXTENDED);
 size_t ret = regerror(status, , buf, sizeof buf);
 printf("status: %d, ret: %d, buf: [%s]n", status, ret, buf);
 return 0;
}

gcc -o rx rx.c && ./rx
status: 11, ret: 18, buf: [Invalid range end]

--Dale

bug#44371: Missing 'get-bytevector-some!' in Guile 2.2

[dsmich]

You have 2.2.4. It was added in 2.2.5.

From the NEWS file:

Changes in 2.2.5 (since 2.2.4):

** New 'get-bytevector-some!' I/O primitive.

-Dale

-From: "Roel Janssen" 
To: 44...@debbugs.gnu.org
Cc: 
Sent: Sunday November 1 2020 9:42:07AM
Subject: bug#44371: Missing 'get-bytevector-some!' in Guile 2.2

Dear Guix,

 I installed guile-2.2 on Debian 10.6 and I seem to missing the "get-
 bytevector-some!" procedure from "(ice-9 binary-ports)":

 --
 # guile
 GNU Guile 2.2.4
 Copyright (C) 1995-2017 Free Software Foundation, Inc.

 Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
 This program is free software, and you are welcome to redistribute it
 under certain conditions; type `,show c' for details.

 Enter `,help' for help.
 scheme@(guile-user)> ,use (ice-9 binary-ports)
 scheme@(guile-user)> get-bytevector-some!
 ;;; : warning: possibly unbound variable `get-
 bytevector-some!'
 ERROR: In procedure module-lookup: Unbound variable: get-bytevector-
 some!

 Entering a new prompt. Type `,bt' for a backtrace or `,q' to
 continue.
 scheme@(guile-user) [1]> ,q
 scheme@(guile-user)> get-bytevector-some
 $1 = #
 --

 Kind regards,
 Roel Janssen

bug#40737: Segfault in arm gcc7, thumb2 builroot, with arm patch

[dsmich]

close 40737 v3.0.3

bug#41981: Reference Manual on Vtables: Missing Information on Permission "h"

[dsmich]

Is is documented in the docstring:

scheme@(guile-user)> ,d make-struct-layout
- Scheme Procedure: make-struct-layout fields
 Return a new structure layout object.

 FIELDS must be a string made up of pairs of characters strung
 together. The first character of each pair describes a field type,
 the second a field protection. Allowed types are 'p' for
 GC-protected Scheme data, 'u' for unprotected binary data. Allowed
 protections are 'w' for normal fields or 'h' for hidden fields.

 Hidden fields are writable, but they will not consume an
 initializer arg passed to `make-struct'. They are useful to add
 slots to a struct in a way that preserves backward-compatibility
 with existing calls to `make-struct', especially for derived
 vtables.

bug#40737: Segfault in arm gcc7, thumb2 builroot, with arm patch

[dsmich]

Here is the start of a case to go in tests/movi.c:

#include "test.h"

// Should really test all of the cases seen in
// arm-cpu.c: encode_thumb_immediate()

/*    abcdefgh */
/*  abcdefgh  abcdefgh */
/* abcdefgh  abcdefgh  */
/* abcdefgh abcdefgh abcdefgh abcdefgh */
/* 1bcdefgh

bug#40737: Segfault in arm gcc7, thumb2 builroot, with arm patch

[dsmich]

From: "Ludovic Courtès" 
> dsm...@roadrunner.com skribis:
 > > In the test-suite/standalone dir:
 > > while GUILE_JIT_THRESHOLD=0 make TESTS=test-language check-TESTS;
> 
> OK.
 > 
 > On IRC you mentioned that this does not happen with
GUILE_JIT_THRESHOLD=-1, right?
 >

That is correct.

-Dale

bug#40737: Segfault in arm gcc7, thumb2 builroot, with arm patch

[dsmich]

I'm still seeing segfaults on rasbian on an rpi3. Have not tried
buildroot yet.

That patch *did* fix a boatload of errors on arm, but this segfault is
an unrelated problem I think. Only happens on arm though.

Here is a way to reproduce:

In the test-suite/standalone dir:
while GUILE_JIT_THRESHOLD=0 make TESTS=test-language check-TESTS; do
:;done

And then:
../../meta/uninstalled-env ../../libtool --mode=execute gdb
../../libguile/guile core

Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x76f505cc in scm_is_string (x=0x0) at strings.h:293
293 return SCM_HAS_TYP7 (x, scm_tc7_string);
[Current thread is 1 (Thread 0x76fe6010 (LWP 21616))]
(gdb) bt
#0 0x76f505cc in scm_is_string (x=0x0) at strings.h:293
#1 scm_string_to_symbol (string=0x0) at symbols.c:361
#2 0x722df4cc in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)

-From: "Ludovic Courtès" 
To: dsm...@roadrunner.com
Cc: 40...@debbugs.gnu.org
Sent: Wednesday June 17 2020 6:36:34PM
Subject: Re: bug#40737: Segfault in arm gcc7, thumb2 builroot, with
arm patch

Hi Dale,

 dsm...@roadrunner.com skribis:

 > Here is a backtrace of running guile on a builtroot constructed
 system
 > for rpi3.
 > Thumb2 instructions: BR2_ARM_INSTRUCTIONS_THUMB2=y
 > Gcc 7.5: BR2_GCC_VERSION="7.5.0"
 > Glibc.
 >
 > Uses the patch from
 >

bug#40792: .dir-locals.el has unbalanced parens

[dsmich]

Two too many right parens on line 44 in .dir-locals.el, causing the
file to be unbalanced.

Looks like this happened in this commit:
7ed92f0a9 * Add syntax-parameterize indentation to .dir-locals.el.

-Dale

bug#40737: Even more info

[dsmich]

And with threshold set to 0:

# GUILE_JIT_THRESHOLD=0 guile
Pre-boot error; key: misc-error, args: (#f "parent is not a exception
type ~S" (#) #f)Aborted (core dumped)

Program terminated with signal SIGABRT, Aborted.
#0 0x76acd6b6 in ?? ()
[Current thread is 1 (LWP 515)]
(gdb) thread apply all backtrace

Thread 4 (LWP 518):
#0 0x76e5f674 in __libc_do_syscall () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread.so.0
#1 0x76e5a99e in pthread_cond_wait@@GLIBC_2.4 () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread.so.0
#2 0x76e837aa in GC_wait_marker () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgc.so.1
#3 0x76e83ab0 in GC_help_marker () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgc.so.1
#4 0x76e83b26 in GC_mark_thread () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgc.so.1
#5 0x76e55bb0 in start_thread () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread.so.0
#6 0x76b4b0ec in ?? () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)

Thread 3 (LWP 516):
#0 0x76e5f674 in __libc_do_syscall () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread.so.0
#1 0x76e5a99e in pthread_cond_wait@@GLIBC_2.4 () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread.so.0
#2 0x76e837aa in GC_wait_marker () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgc.so.1
#3 0x76e83ab0 in GC_help_marker () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgc.so.1
#4 0x76e83b26 in GC_mark_thread () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgc.so.1
#5 0x76e55bb0 in start_thread () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread.so.0
#6 0x76b4b0ec in ?? () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)

Thread 2 (LWP 517):
#0 0x76e5f674 in __libc_do_syscall () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread.so.0
#1 0x76e5a99e in pthread_cond_wait@@GLIBC_2.4 () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread.so.0
#2 0x76e837aa in GC_wait_marker () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgc.so.1
#3 0x76e83ab0 in GC_help_marker () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgc.so.1
#4 0x76e83b26 in GC_mark_thread () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgc.so.1
#5 0x76e55bb0 in start_thread () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread.so.0
#6 0x76b4b0ec in ?? () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)

Thread 1 (LWP 515):
#0 0x76acd6b6 in __libc_do_syscall () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libc.so.6
#1 0x76adbc70 in raise () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libc.so.6
#2 0x76adc73e in abort () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libc.so.6
#3 0x76f45ce8 in scm_throw (key=0x76fb92b0, key@entry=0x0,
args=0x76a57360) at throw.c:264
#4 0x76f0b97e in throw_ (args=, key=0x0) at intrinsics.c:352
#5 throw_with_value (val=, key_subr_and_message=) at intrinsics.c:367
#6 0x74f473da in ?? ()
--Type  for more, q to quit, c to continue without paging--c
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)
(gdb) info reg
r0 0x0 0
r1 0x7ef92688 2130257544
r2 0x0 0
r3 0x8 8
r4 0x0 0
r5 0x7ef92688 2130257544
r6 0x76a57360 1990554464
r7 0xaf 175
r8 0x75207308 1965060872
r9 0x75207208 1965060616
r10 0x4 4
r11 0x76f82000 1995972608
r12 0xaf 175
sp 0x7ef92680 0x7ef92680
lr 0x76adbc71 1991097457
pc 0x76acd6b6 0x76acd6b6 
cpsr 0x30 48
fpscr 0x0 0
(gdb) disassem /r 0x76acd6b6,+8
Dump of assembler code from 0x76acd6b6 to 0x76acd6be:
=> 0x76acd6b6 : 80 bd pop {r7, pc}
 0x76acd6b8 : 03 4b ldr r3, [pc, #12] ; (0x76acd6c8 )
 0x76acd6ba : 1d ee 70 0f mrc 15, 0, r0, cr13, cr0, {3}
End of assembler dump.
(gdb) 

bug#40737: Even more info

[dsmich]

Also forgot to mention this is guile 3.0.2.

It doesn't fail all the time.

When run with GUILE_JIT_THRESHOLD=-1 , there are never any problems.

With GUILE_JIT_THRESHOLD=0 , it always fails, but I'm not sure it's in
the same place.

-Dale

bug#40737: Forgot command output

[dsmich]

# ulimit -c unlimited
# guile
Backtrace:
Exception thrown while printing backtrace:
Unrecognized keyword: #:exports

Segmentation fault (core dumped)

-Dale

bug#40737: Segfault in arm gcc7, thumb2 builroot, with arm patch

[dsmich]

Here is a backtrace of running guile on a builtroot constructed system
for rpi3.
Thumb2 instructions: BR2_ARM_INSTRUCTIONS_THUMB2=y
Gcc 7.5: BR2_GCC_VERSION="7.5.0"
Glibc.

Uses the patch from
https://gitlab.com/wingo/lightening/-/merge_requests/3

I hope this makes it through the mail client ok. 

-Dale

Core was generated by `guile'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x76ee6f12 in ?? ()
[Current thread is 1 (LWP 507)]
(gdb) thread apply all backtrace

Thread 5 (LWP 508):
#0 0x76e59674 in __libc_do_syscall () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread.so.0
#1 0x76e5499e in pthread_cond_wait@@GLIBC_2.4 () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread.so.0
#2 0x76e7d7aa in GC_wait_marker () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgc.so.1
#3 0x76e7dab0 in GC_help_marker () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgc.so.1
#4 0x76e7db26 in GC_mark_thread () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgc.so.1
#5 0x76e4fbb0 in start_thread () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread.so.0
#6 0x76b450ec in ?? () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)

Thread 4 (LWP 510):
#0 0x76e59674 in __libc_do_syscall () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread.so.0
#1 0x76e5499e in pthread_cond_wait@@GLIBC_2.4 () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread.so.0
#2 0x76e7d7aa in GC_wait_marker () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgc.so.1
#3 0x76e7dab0 in GC_help_marker () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgc.so.1
#4 0x76e7db26 in GC_mark_thread () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgc.so.1
#5 0x76e4fbb0 in start_thread () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread.so.0
#6 0x76b450ec in ?? () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)

Thread 3 (LWP 511):
#0 0x76e59674 in __libc_do_syscall () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread.so.0
#1 0x76e57720 in read () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread.so.0
#2 0x76ef8aee in read_finalization_pipe_data (data=0x74c1f95c) at
finalizers.c:205
#3 0x76e7cea8 in GC_do_blocking_inner () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgc.so.1
#4 0x76e7b068 in GC_with_callee_saves_pushed () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgc.so.1
#5 0x76e7b094 in GC_do_blocking () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgc.so.1
#6 0x76f3f10c in scm_without_guile (func=0x76ef8add , data=0x74c1f95c)
at threads.c:706
#7 0x76ef8d7a in finalization_thread_proc (unused=) at
finalizers.c:218
#8 0x76eef876 in c_body (d=0x74c1fe1c) at continuations.c:430
#9 0x76f4298e in vm_debug_engine (thread=0x76a46c00) at
vm-engine.c:972
#10 0x76f47b9c in scm_call_n (proc=0x7521dc70,
argv=argv@entry=0x74c1fbc0, nargs=nargs@entry=2) at vm.c:1608
#11 0x76ef22c4 in scm_call_2 (proc=, arg1=, arg2=) at eval.c:503
#12 0x76ef31a2 in scm_c_with_exception_handler (type=type@entry=0x404,
handler=0x76f3f9b9 , handler_data=handler_data@entry=0x74c1fda8, 
 thunk=0x76f3fa7d , thunk_data=thunk_data@entry=0x74c1fda8) at
exceptions.c:170
#13 0x76f3fbd4 in scm_c_catch (tag=tag@entry=0x404,
body=body@entry=0x76eef86d , body_data=body_data@entry=0x74c1fe1c, 
 handler=handler@entry=0x76eefa1d ,
handler_data=handler_data@entry=0x74c1fe1c, 
 pre_unwind_handler=pre_unwind_handler@entry=0x76eef8fb ,
pre_unwind_handler_data=pre_unwind_handler_data@entry=0x751fc300) at
throw.c:168
--Type  for more, q to quit, c to continue without paging--c
#14 0x76eefba2 in scm_i_with_continuation_barrier (body=0x76eef86d ,
body_data=body_data@entry=0x74c1fe1c, handler=0x76eefa1d ,
handler_data=handler_data@entry=0x74c1fe1c,
pre_unwind_handler=0x76eef8fb , pre_unwind_handler_data=0x751fc300) at
continuations.c:368
#15 0x76eefc06 in scm_c_with_continuation_barrier (func=, data=) at
continuations.c:464
#16 0x76f3edd4 in with_guile (base=0x74c1fe4c, data=0x74c1fe64) at
threads.c:645
#17 0x76e78e98 in GC_call_with_stack_base () from
/home/dales/br/rpi/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgc.so.1
#18 0x76f3f0cc in scm_i_with_guile (dynamic_state=, data=, func=) at
threads.c:688
#19 scm_with_guile (func=, data=) at threads.c:694
#20 0x76e4fbb0 in start_thread () from

bug#39118: Segfault while building on 64-bit Cygwin

[dsmich]

Pretty sure that the missing readline symbol is because the macos
readline is being used/found instead of GNU readline.

-Dale

-From: "John Cowan" 
To: "Ludovic Courtès"
Cc: 39...@debbugs.gnu.org, guile-de...@gnu.org
Sent: Friday January 24 2020 9:36:59AM
Subject: bug#39118: Segfault while building on 64-bit Cygwin

Both Cygwin and MacOS crash in pretty much the same way. By disabling
the JIT, I was able to get the Cygwin build to run to completion. On
MacOS with --disable-jit, however, I am now getting an entirely new
failure:
 CC readline.lo
readline.c:432:7: warning: implicitly declaring library function
'strncmp' with type 'int (const char *, const char *,
 unsigned long)' [-Wimplicit-function-declaration]
 if (strncmp (rl_get_keymap_name (rl_get_keymap ()), "vi", 2))
 ^
readline.c:432:7: note: include the header  or explicitly provide a
declaration for 'strncmp'
readline.c:432:16: warning: implicit declaration of function
'rl_get_keymap_name' is invalid in C99
 [-Wimplicit-function-declaration]
 if (strncmp (rl_get_keymap_name (rl_get_keymap ()), "vi", 2))
 ^
readline.c:432:16: warning: incompatible integer to pointer conversion
passing 'int' to parameter of type 'const char *'
 [-Wint-conversion]
 if (strncmp (rl_get_keymap_name (rl_get_keymap ()), "vi", 2))
 ^
3 warnings generated.
 CCLD guile-readline.la [1]
Undefined symbols for architecture x86_64:
 "_rl_get_keymap_name", referenced from:
 _scm_init_readline in readline.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)

On Thu, Jan 23, 2020 at 3:35 PM Ludovic Courtès  wrote:
Hi,

 John Cowan  skribis:

 > Thanks. Unfortunately, the standard recipe for making core dumps on
Mac

 This bug report is about Cygwin, not macOS, right? :-)

 Ludo’.
  

Links:
--
[1] http://guile-readline.la
[2] mailto:l...@gnu.org
[3] mailto:co...@ccil.org

bug#26476: Help for C primitives not found

[dsmich]

So.  (help cons) is no longer working for me with 2.2.

The output of

 echo '(help cons)' | strace guile

shows

stat("/usr/local/share/guile/guile-procedures.txt", 0x7ffd5f923330) = -1 ENOENT 
(No such file or directory)
stat("/usr/local/share/guile/site/2.2/guile-procedures.txt", 0x7ffd5f923330) = 
-1 ENOENT (No such file or directory)
stat("./guile-procedures.txt", 0x7ffd5f923330) = -1 ENOENT (No such file or 
directory)
write(1, "No documentation found for:\n", 28No documentation found for:
) = 28
write(1, "(srfi srfi-1): cons\n", 20(srfi srfi-1): cons
)   = 20

guile was compiled from the 2.2 release tarball using default configure options.

The file actually lives at

$ ls -l /usr/local/share/guile/2.2/guile-procedures.txt 
-rw-r--r-- 1 root staff 306615 Apr 13 07:20 
/usr/local/share/guile/2.2/guile-procedures.txt


This is on Debian Jessie, amd84

-Dale

bug#26123: guile-2.2.0: AI_ADDRCONFIG

[dsmich]

 Thomas Klausner  wrote: 
> 
>   SNARF  net_db.doc
> net_db.c:468:***Missing or erroneous `#define FUNC_NAME s_AI_ADDRCONFIG);'
> net_db.c:488:***Missing or erroneous #undef for AI_ADDRCONFIG);:
> 
> Compilation continues even though this looks like an error.

Yeah,  while annoying, this is harmless.

The proper fix in my opinion is to limit the regular expression on line 28 in 
libguile/guile-func-name-check to only match function definition macros.  
Currently, it matches other macros that define things other than functions, and 
so erroneously looks for a function body.

For example, adding a space like /^SCM_DEFINE / would probably be appropriate.  
However, that would prevent it from matching any other function defining 
macros, if they exist.

-Dale
 

bug#24909: Recent async changes in master cause segfault

[dsmich]

Looks like 3f23688 fixes it.

-Dale

bug#24909: Recent async changes in master cause segfault

[dsmich]

The test-suite/standalone/test-guild-compile test is segfaulting.  Git 
bisecting between the 2.1.4 release and HEAD shows

# first bad commit: [c957ec7ab0f0a028910dc737e12191f7bdc1ca93] Use atomics for 
async interrupts

gcc --version
gcc (Debian 4.9.2-10) 4.9.2

uname -mr
3.16.0-4-amd64 x86_64

A pretty much up-to-date Debian Jessie system.


Collecting a core dump and displaying all backtraces is:

(gdb) thr apply all bt

Thread 3 (Thread 0x7fb574b2f740 (LWP 12971)):
#0  0x7fb573bff893 in select () at ../sysdeps/unix/syscall-template.S:81
#1  0x7fb5746d1e6b in do_std_select (args=0x7fffcf4c8de0) at threads.c:1752
#2  0x7fb5738d1ba3 in GC_do_blocking_inner (data=, 
context=) at pthread_support.c:1141
#3  0x7fb5738d32be in GC_with_callee_saves_pushed (fn=, 
arg=) at mach_dep.c:273
#4  0x7fb5738cb69c in GC_do_blocking (fn=, 
fn@entry=0x7fb5746d1e50 , client_data=, 
client_data@entry=0x7fffcf4c8de0)
at misc.c:1657
#5  0x7fb5746d292a in scm_without_guile (func=0x7fb5746d1e50 
, data=0x7fffcf4c8de0) at threads.c:848
#6  0x7fb5746d2ab5 in scm_std_select (nfds=4, nfds@entry=0, 
readfds=0x7fffcf4c8e10, readfds@entry=0x0, writefds=writefds@entry=0x0, 
exceptfds=exceptfds@entry=0x0, 
timeout=timeout@entry=0x7fffcf4c8ed0) at threads.c:1796
#7  0x7fb5746d33e3 in scm_std_sleep (secs=) at threads.c:1912
#8  0x7fb5746b3940 in scm_sleep (i=) at scmsigs.c:636
#9  0x7fb5746e0a26 in vm_regular_engine (thread=0x4, vp=0xd78d80, 
registers=0x0, resume=260) at vm-engine.c:832
#10 0x7fb5746e64f6 in scm_call_n (proc=0x7fb574b5a030, 
argv=argv@entry=0x7fffcf4c90f8, nargs=nargs@entry=1) at vm.c:1248
#11 0x7fb574668ac7 in scm_primitive_eval (exp=exp@entry=0xe6c870) at 
eval.c:654
#12 0x7fb574668b23 in scm_eval (exp=0xe6c870, 
module_or_state=module_or_state@entry=0xd8c750) at eval.c:688
#13 0x7fb5746b448d in scm_shell (argc=9, argv=0x7fffcf4c9728) at 
script.c:454
#14 0x7fb57467f85d in invoke_main_func (body_data=0x7fffcf4c95d0) at 
init.c:339
#15 0x7fb5746627ea in c_body (d=0x7fffcf4c9510) at continuations.c:429
#16 0x7fb5746e0a26 in vm_regular_engine (thread=0x4, vp=0xd78d80, 
registers=0x0, resume=2) at vm-engine.c:832
#17 0x7fb5746e64f6 in scm_call_n (proc=0xdca4a0, proc@entry=0xd4ced0, 
argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1248
#18 0x7fb5746679f9 in scm_call_0 (proc=proc@entry=0xd4ced0) at eval.c:473
#19 0x7fb5746d3ea7 in catch (tag=tag@entry=0x404, thunk=0xdca4a0, 
handler=0x7fb574662ac0 , pre_unwind_handler=0xdca3e0) at throw.c:135
#20 0x7fb5746d42d5 in scm_catch_with_pre_unwind_handler 
(key=key@entry=0x404, thunk=, handler=, 
pre_unwind_handler=)
at throw.c:249
#21 0x7fb5746d438f in scm_c_catch (tag=tag@entry=0x404, 
body=body@entry=0x7fb5746627e0 , 
body_data=body_data@entry=0x7fffcf4c9510, 
handler=handler@entry=0x7fb574662ac0 , 
handler_data=handler_data@entry=0x7fffcf4c9510, 
pre_unwind_handler=pre_unwind_handler@entry=0x7fb574662920 
, pre_unwind_handler_data=0xdd3bc0) at throw.c:370
#22 0x7fb574662e20 in scm_i_with_continuation_barrier 
(body=body@entry=0x7fb5746627e0 , 
body_data=body_data@entry=0x7fffcf4c9510, 
handler=handler@entry=0x7fb574662ac0 , 
handler_data=handler_data@entry=0x7fffcf4c9510, 
pre_unwind_handler=pre_unwind_handler@entry=0x7fb574662920 
, pre_unwind_handler_data=0xdd3bc0) at continuations.c:367
#23 0x7fb574662eb5 in scm_c_with_continuation_barrier (func=, data=) at continuations.c:463
#24 0x7fb5746d248c in with_guile_and_parent (base=0x7fffcf4c9570, 
data=0x7fffcf4c95a0) at threads.c:786
#25 0x7fb5738cb6ca in GC_call_with_stack_base (fn=0xfdfe, 
fn@entry=0x7fb5746d2440 , arg=0x7fffcf4c8e10, 
arg@entry=0x7fffcf4c95a0)
at misc.c:1553
#26 0x7fb5746d28b8 in scm_i_with_guile_and_parent (parent=, 
data=data@entry=0x7fffcf4c95a0, func=func@entry=0x7fb57467f840 
)
at threads.c:829
#27 scm_with_guile (func=func@entry=0x7fb57467f840 , 
data=data@entry=0x7fffcf4c95d0) at threads.c:835
#28 0x7fb57467f9f2 in scm_boot_guile (argc=argc@entry=9, 
argv=argv@entry=0x7fffcf4c9728, main_func=main_func@entry=0x400a50 
, closure=closure@entry=0x0)
at init.c:322
#29 0x004008f0 in main (argc=9, argv=0x7fffcf4c9728) at guile.c:101

Thread 2 (Thread 0x7fb572588700 (LWP 12986)):
#0  0x7fb573ed7add in read () at ../sysdeps/unix/syscall-template.S:81
#1  0x7fb574670ef7 in read_finalization_pipe_data (data=0x7fb572587a80) at 
finalizers.c:199
#2  0x7fb5738d1ba3 in GC_do_blocking_inner (data=, 
context=) at pthread_support.c:1141
#3  0x7fb5738d32be in GC_with_callee_saves_pushed (fn=, 
arg=) at mach_dep.c:273
#4  0x7fb5738cb69c in GC_do_blocking (fn=, 
fn@entry=0x7fb574670ee0 , client_data=, 
client_data@entry=0x7fb572587a80) at misc.c:1657
#5  0x7fb5746d292a in scm_without_guile (func=0x7fb574670ee0 
, data=0x7fb572587a80) at threads.c:848
#6  0x7fb574671307 in finalization_thread_proc (unused=) at 

bug#20423: goops - inheritance of slot options

[dsmich]

 David Pirotte  wrote: 
> Hi Andy,
> 
> > For what it's worth this is a part of GOOPS's design AFAIU: all slot
> > definitions are unique.  Two slots named S declared on classes A and B
> > are distinct, even if A is a superclass of B.
> 
> Well, as I explained in the original report, the only specification we have 
> is CLOS:
> Stklos, upon which Guile GOOPS is based, clearly state in its manual, among 
> the
> first paragraphs, that it implements the CLOS protocol [a subset]: there is no
> 'redesign' anywhere in Stlkos [it just lacks :before and :after methods 
> AFAICT].
> 
> AFAICT, there is no Guile 'official' document stating clearly, neither in the
> manual, that GOOPS authors decided to redesign this part of the protocol and 
> why...
> is there?

Way way back, goops was a separate project from guile.   This TODO file has 
some info on where Mikael was planning on going with it:

http://cvs.savannah.gnu.org/viewvc/guile/guile-oops/TODO?revision=1.19=guile=markup

-Dale

bug#17502: R6RS `library' form must have exports before imports

[dsmich]

 Taylan Ulrich Bayirli/Kammer taylanbayi...@gmail.com wrote: 
 The R6RS `library' form requires the (export ...) list to appear
 before the (import ...) list.  I'm not sure if this itself is a bug;
 R6RS consistently uses that order, doesn't mention the order to be
 irrelevant, and seems to me to imply that it's indeed mandatory.  I
 didn't check for what other R6RS implementations do though.

From http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-10.html#node_sec_7.1 :

A library definition must have the following form:

(library library name
  (export export spec ...)

  (import import spec ...)

  library body)

Seems unambiguous to me.

-Dale

bug#15221: provide a mechanism to activate readline systemwide

[dsmich]

 Arne Babenhauserheide (IMK) arne.babenhauserhe...@kit.edu wrote: 
 Hi,
 
 Not having readline at the guile interpreter from the get-go in a GNU
 environment was a quite scarring experience for me, so it would be great
 to have a way to enable readline by default.
 
 init.scm could provide that, but:
 
 wingo it seems to search the load path for init.scm
 wingo before loading anything else
 wingo tricky though, apparently that happens even before loading boot-9
 
 Ideally there should be either a compileflag or a systemwide config file
 to enable readline support in the whole system. If it is a compile-flag
 it might be useful to not make it default, because developers why
 develop proprietary applications could then by accident compile a
 program with activated readline support.
 
 If such a flag existed, most GNU/Linux distributions could simply
 activate it for guile itself (as long as they do not ship unfree scripts
 using guile which depend on readline support — those scripts would
 violate the GPL, but they would not work at all without readline
 support, so this dependency should be pretty clear).

Sometimes readline gets in the way, for example, when using guile with emacs.

If it was enabled by default, then there also must be an option to disable it 
when not needed.

The main reason readline is not enabled by default (IIRC), is the license 
differences between readline and guile. (GPL and LGPL)

-Dale

bug#14749: rtl.test failure in master

[dsmich]

 dsm...@roadrunner.com wrote: 
 
  dsm...@roadrunner.com wrote: 
  
   dsm...@roadrunner.com wrote: 
   I'm seeing this make check error from rtl.test on master:
   
   ERROR: rtl.test: load-constant: #\37200 - arguments: ((misc-error #f ~A 
   (make-long-immediate unavailable for this target) #f))
   
   The failing line is:
   (integer-char 16000)
  
  I did a bisect and it says this started with commit 
 
 Forget this noise.  rtl.test fails here since the inclusion of rtl.test.

$ git describe
v2.1.0-1093-g5270bb5

Passes make check on 32bit with no problems.  Yey!

-Dale

bug#14749: rtl.test failure in master

[dsmich]

 dsm...@roadrunner.com wrote: 
 
  dsm...@roadrunner.com wrote: 
  I'm seeing this make check error from rtl.test on master:
  
  ERROR: rtl.test: load-constant: #\37200 - arguments: ((misc-error #f ~A 
  (make-long-immediate unavailable for this target) #f))
  
  The failing line is:
  (integer-char 16000)
 
 I did a bisect and it says this started with commit 

Forget this noise.  rtl.test fails here since the inclusion of rtl.test.

-Dale

bug#14749: rtl.test failure in master

[dsmich]

I'm seeing this make check error from rtl.test on master:

ERROR: rtl.test: load-constant: #\37200 - arguments: ((misc-error #f ~A 
(make-long-immediate unavailable for this target) #f))

The failing line is:
(integer-char 16000)

Out of curiosity, I added these lines:
   #\λ
   (integer-char 955)

I chose the lambda char as it works fine within a string a few line further 
into the test.

Those lines produce these errors:
ERROR: rtl.test: load-constant: #\1673 - arguments: ((misc-error #f ~A 
(make-long-immediate unavailable for this target) #f))
ERROR: rtl.test: load-constant: #\1673 - arguments: ((misc-error #f ~A 
(make-long-immediate unavailable for this target) #f))

I don't how 16000 relates to #\37200 or how 955 or #\λ to #\1673 .

Could it be that this is a 32 bit machine?

$ git describe
v2.1.0-1017-g98eaef1


-Dale

bug#14749: rtl.test failure in master

[dsmich]

 dsm...@roadrunner.com wrote: 
 I'm seeing this make check error from rtl.test on master:
 
 ERROR: rtl.test: load-constant: #\37200 - arguments: ((misc-error #f ~A 
 (make-long-immediate unavailable for this target) #f))
 
 The failing line is:
 (integer-char 16000)

I did a bisect and it says this started with commit 

e6450062a19bf5d0072d117b69be95c2641c23ab is the first bad commit
commit e6450062a19bf5d0072d117b69be95c2641c23ab
Author: Andy Wingo wi...@pobox.com
Date:   Sun Jun 16 15:02:34 2013 +0200

Reduce call-with-values to let for singly-valued producers


-Dale

bug#13095: http-get: Throw to key `bad-response' with args `(EOF while reading response body: ...)'

[dsmich]

 Ludovic Courtès l...@gnu.org wrote: 
 Thien-Thi Nguyen t...@gnuvola.org skribis:
 
  HTTP 1.0 is close by default, but HTTP 1.1 is keep open by default,
  if i recall correctly.  Does that have anything to do w/ this bug?
 
 Note sure, because both http://citylan.dl.sourceforge.net (the example
 that fails) and http://ftp.gnu.org (one that works even with the
 ‘shutdown’ call) are HTTP 1.1:
 
 --8---cut here---start-8---
 scheme@(guile-user) (use-modules (web client)(web uri)(rnrs io ports))
 scheme@(guile-user) (define resp (http-get (string-uri 
 http://citylan.dl.sourceforge.net/project/libusb/libusb-1.0/libusb-1.0.9/libusb-1.0.9.tar.bz2;)))
 scheme@(guile-user) resp
 $1 = #response version: (1 . 1) code: 200 reason-phrase: OK headers: 
 ((server . nginx/1.0.12) (date . #date nanosecond: 0 second: 25 minute: 35 
 hour: 23 day: 8 month: 12 year: 2012 zone-offset: 0) (content-type 
 application/octet-stream) (content-length . 421971) (last-modified . #date 
 nanosecond: 0 second: 58 minute: 47 hour: 6 day: 20 month: 4 year: 2012 
 zone-offset: 0) (connection close) (accept-ranges bytes)) port: #closed: 
 file 0
 scheme@(guile-user) (define resp* (http-get (string-uri 
 http://ftp.gnu.org/gnu/hello/hello-2.8.tar.gz;)))
 scheme@(guile-user) resp*
 $2 = #response version: (1 . 1) code: 200 reason-phrase: OK headers: 
 ((date . #date nanosecond: 0 second: 59 minute: 35 hour: 23 day: 8 month: 12 
 year: 2012 zone-offset: 0) (server . Apache/2.2.14 (Trisquel GNU/Linux)) 
 (last-modified . #date nanosecond: 0 second: 47 minute: 55 hour: 17 day: 20 
 month: 4 year: 2012 zone-offset: 0) (etag 4648b4-aa48b-4be1fff866200 . #t) 
 (accept-ranges bytes) (content-length . 697483) (connection close) 
 (content-type application/x-gzip)) port: #closed: file 0
 --8---cut here---end---8---

Hmm..  The failing site is running on nginx/1.0.12 while the working site is 
Apache/2.2.14.

-Dale

bug#11872: stable-2.0 build breaks at v2.0.5-225-g005de2e

[dsmich]

 Ludovic Courtès l...@gnu.org wrote: 
 Hi Dale,
 
 dsm...@roadrunner.com skribis:
 
  Building stable-2.0 stared breaking for me at commit 
  005de2e8273853e155c21767b1c8bdb4f3f3ca53
 
 [...]
 
  In file included from striconveh.c:30:
  unistr.h: In function 'u8_check':
  unistr.h:71: error: expected declaration specifiers before 
  '_UC_ATTRIBUTE_PURE'
  unistr.h:77: error: expected '=', ',', ';', 'asm' or '__attribute__' before 
  '_UC_ATTRIBUTE_PURE'
 
 Could you try “make distclean  rm -rf autom4te.cache config.cache 
 autoreconf -vfi”, etc. and confirm that it solves the problem?

That didn't help.  git clean -dxf and rebuilding from there didn't help.

Turns out I had and older libunistring installed from source.  Removing that 
and installing the libunistring-dev package (wheezy/sid) allows the build to 
finish with no errors including make check.

Thanks!

bug#10488: guile-config deprecation?

[dsmich]

 Andy Wingo wi...@pobox.com wrote: 
 On Thu 12 Jan 2012 19:42, Mike Gran spk...@yahoo.com writes:
 
  There's a bit of confusion on the guile-config deprecation.
 
 Indeed.
 
  NEWS says that guile-config will be deprecated
 
 This reflects what I would like to happen, but I share your concern that
 we not create a situation in which guile-config will just disappear
 with no equally powerful, documented replacement in place.  Hence the
 slowness of this transition.  Thanks for bringing it up.
 
  meta/guile-config.in says it has been deprecated
 
 I changed the text to will be deprecated.  It's somewhat
 weasel-worded, I guess.
 
  meta/guile.m4's GUILE_PROGS rule will error guile-config required
  but not found
 
 Uf, this is a can of worms.  I hacked on this a bit this morning, and
 came up with the following.  What do you think?

How about adding something for extensiondir ?

-Dale

bug#10336: Holidays vs. release

[dsmich]

 Andy Wingo wi...@pobox.com wrote: 
 Hi Ludovic,
 
 I pushed a couple patches that should help this bug out, though for some
 reason I wasn't able to reproduce the issue before.  I wonder why.
 
 On Wed 25 Jan 2012 17:10, l...@gnu.org (Ludovic Courtès) writes:
 
  So I looked into it, and there’s at least one thing wrong: the test must
  be compiled with #:partial-eval? #f, otherwise the ‘let’ vanishes, which
  defeats the test.
 
 Indeed.  I think I fixed that now.
 
  Second thing, it suffices to insert a function call like
  ((lambda (x) #f) #f) just before calls to ‘gc’ to solve the problem.
 
 Strange.  Another thing was that the function was a constant, not a
 closure, so it wasn't going to be collectable in the first place.
 
 Can you retry the test now, Dale?

Sure.  v2.0.3-190-gf5e772b still has the same failure.

-Dale

bug#10336: Holidays vs. release

[dsmich]

 dsm...@roadrunner.com wrote: 
 
  Ludovic Courtès l...@gnu.org wrote: 
  Hello Guilers!
  
  I initially thought it would be great to push a 2.0.4 tarball by the end
  of the year, but since I’ll be on holidays starting from tomorrow until
  Jan. 3rd, I won’t be able to make it.  Sorry about that!
 
 I'm still getting that one failure in make check.  Something about gc a 
 lexicals?  (Sorry I'm not at that machine.)  Probably would be a good idea to 
 tune that up before release anyway.
 
 I'll post details when I can.

I'm on a 32bit Debian intel system.  libgc is 7.2alpha4

git describe is
v2.0.3-82-ga2c6601

The single failure running make check is

Running gc.test
FAIL: gc.test: gc: Lexical vars are collectable


-Dale

Re: quote oddity

[dsmich]

 Bill Schottstaedt b...@ccrma.stanford.edu wrote: 
 Does this strike you guys as kind of odd?
 
 guile ((lambda (s c) (s c)) quote #f)
 c
 guile ((lambda (q) (let ((x 1)) (q x))) quote)
 x
 
 I can't decide what I think.

Well, quote is syntax.  You can't pass it around like a function.  Guile 2.0 
fixes that:

scheme@(guile-user) ((lambda (s c) (s c)) quote #f) 
While compiling expression:
ERROR: Syntax error:
unknown location: quote: bad syntax in form quote


scheme@(guile-user) ((lambda (q) (let ((x 1)) (q x))) quote)
While compiling expression:
ERROR: Syntax error:
unknown location: quote: bad syntax in form quote


-Dale

(no subject)

[dsmich]

With guile at v2.0.0-134-g38c50a9, I'm getting a couple of failures in 
threads.test on my single core Debian Squeeze machine:

FAIL: threads.test: lock-mutex: timed locking succeeds if mutex unlocked within 
timeout
FAIL: threads.test: mutex-ownership: mutex with owner not retained (bug #27450)

Running just the threads.test *sometimes* works.  One in six runs or so.

-Dale

Re: Stable 2.0 and popen.test on Debian Squeeze

[dsmich]

 Mark H Weaver m...@netris.org wrote: 
 
 Does the attached patch fix your problems with popen.test on Squeeze?

Indeed it does.   Very much thanks!


dsmith@stumpy:~/src/guile$ ./check-guile popen.test
Testing /home/dsmith/src/guile/meta/guile ... popen.test
with GUILE_LOAD_PATH=/home/dsmith/src/guile/test-suite
Running popen.test

Totals for this test run:
passes: 15
failures:   0
unexpected passes:  0
expected failures:  0
unresolved test cases:  0
untested test cases:0
unsupported test cases: 0
errors: 0


-Dale

Re: Stable 2.0 and popen.test on Debian Squeeze

[dsmich]

 Mark H Weaver m...@netris.org wrote: 
 
 Does the attached patch fix your problems with popen.test on Squeeze?

Indeed it does.   Very much thanks!


dsmith@stumpy:~/src/guile$ ./check-guile popen.test
Testing /home/dsmith/src/guile/meta/guile ... popen.test
with GUILE_LOAD_PATH=/home/dsmith/src/guile/test-suite
Running popen.test

Totals for this test run:
passes: 15
failures:   0
unexpected passes:  0
expected failures:  0
unresolved test cases:  0
untested test cases:0
unsupported test cases: 0
errors: 0


-Dale

Re: Stable 2.0 and popen.test on Debian Squeeze

[dsmich]

 Mark H Weaver m...@netris.org wrote: 
 Andy Wingo wi...@pobox.com writes:
  The difference seems to be the difference between:
 
dash -c 'exec 1/dev/null; echo closed 12; exec 2/dev/null; read'
 
  and
 
bash -c 'exec 1/dev/null; echo closed 12; exec 2/dev/null; read'
 
  Dash prints closed and exits immediately with error code 2.  Bash
  prints closed and waits for input from the read.
 
  Are we relying on non-portable shell behavior here?
 
 In dash, read requires at least one argument: the name of the variable
 in which to put the string.  You don't see the error message because
 stderr has been redirected to /dev/null.  In bash, the REPLY variable is
 used by default.  So the read above ought to be changed to
 read REPLY.

On my Debian Squeeze system:


dsmith@stumpy:~/src/guile$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Mar  1 20:26 /bin/sh - dash


dsmith@stumpy:~/src/guile$ git diff
diff --git a/test-suite/tests/popen.test b/test-suite/tests/popen.test
index 6300c3b..9604c9c 100644
--- a/test-suite/tests/popen.test
+++ b/test-suite/tests/popen.test
@@ -104,7 +104,7 @@
 (with-input-from-port (car p2c)
   (lambda ()
 (open-input-pipe
- exec 1/dev/null; echo closed 12; exec 
2/dev/null; read)))
+ exec 1/dev/null; echo closed 12; exec 
2/dev/null; read REPLY)))
   (close-port (cdr c2p))   ;; write side
   (let ((result (eof-object? (read-char port
(display hello!\n (cdr p2c))



dsmith@stumpy:~/src/guile$ ./check-guile popen.test
Testing /home/dsmith/src/guile/meta/guile ... popen.test
with GUILE_LOAD_PATH=/home/dsmith/src/guile/test-suite
Running popen.test
FAIL: popen.test: open-output-pipe: no duplicate

Totals for this test run:
passes: 14
failures:   1
unexpected passes:  0
expected failures:  0
unresolved test cases:  0
untested test cases:0
unsupported test cases: 0
errors: 0



-Dale

Re: git guile hangs in fluids.test

[dsmich]

 Ludovic Courtès l...@gnu.org wrote: 
 Hello!
 
 l...@gnu.org (Ludovic Courtès) writes:
 
  l...@gnu.org (Ludovic Courtès) writes:
 
  dsm...@roadrunner.com writes:
 
  Thread 1 (Thread 0x404f92f0 (LWP 14857)):
  #0  0x4001e424 in __kernel_vsyscall ()
  #1  0x4046c285 in sem_wait@@GLIBC_2.1 () at 
  ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/sem_wait.S:80
  #2  0x40168018 in GC_stop_world () at pthread_stop_world.c:426
 
  The other thread should have call sem_post() to release this one.  Can
  you print the value of ‘GC_suspend_ack_sem’?
 
  For the record we’ve been having this problem on Hydra[*] for a couple
  of weeks and I can reproduce it using an i686 build and personality.
 
http://hydra.nixos.org/build/863871
 
  It happens while running ./check-guile, somewhere in between
  futures.test and gc.test (when the latter calls ‘scm_gc’ for the first
  time), which sounds like a race condition making libgc think there are
  more threads than in actuality.
 
 After further investigation, it turns out to be due to the lack of
 pthread_exit interception in both 7.1 and 7.2alpha4, which is fixed in
 current CVS:

Yes!  I can confirm that fluids.test and threads.test (which was also hanging) 
no longer hangs.

I am getting a failure now in popen.test however.  More details to come.

Now if they can only get a release out!  And if it can advance beyond Debian 
Experimantal!

Thanks!
  -Dale

Re: r6rs-ports.test is failing

[dsmich]

 Andy Wingo wi...@pobox.com wrote: 
 On Wed 01 Dec 2010 23:28, dsm...@roadrunner.com writes:
 
  The r6rs-ports.test is failing for me on a Debian Lenny 64bit system.
 
  $ git describe
  release_1-9-13-107-ga0ad8ad
 
  $ ./check-guile r6rs-ports.test
  Testing /home/dsmith/src/guile/meta/guile ... r6rs-ports.test
  with GUILE_LOAD_PATH=/home/dsmith/src/guile/test-suite
  Running r6rs-ports.test
  UNRESOLVED: r6rs-ports.test: 7.2.11 Binary Output: put-bytevector [2 args]
  UNRESOLVED: r6rs-ports.test: 7.2.11 Binary Output: put-bytevector [3 args]
  UNRESOLVED: r6rs-ports.test: 7.2.11 Binary Output: put-bytevector [4 args]
  ERROR: r6rs-ports.test: 8.2.6  Input and output ports: transcoded-port 
  [error handling mode = replace] - arguments: ((encoding-error 
  scm_from_stringn input locale conversion error 84 UTF-8 UTF-32 
  #vu8(255 1 2 3 103 110 117)))
 
 I gather that this is still an issue, but that this code is being
 rewritten; can you please ping us if this bug is still present next
 weekend?

Yes, it's still an issue as of release_1-9-14-85-gbc03d89 .

I'll let you know how things are next week.

Thanks for looking at this!

-Dale

Re: r6rs-ports.test is failing

[dsmich]

 Ludovic Courtès l...@gnu.org wrote: 
 Hi!
 
 Sorry for the late reply.

No problem!

 Can you try this?
 
   (define p (open-bytevector-input-port #vu8(255 1 2 3 103 110 117)))
   (set-port-conversion-strategy! p 'substitute)
   (get-line p)
 
 Here on x86_64-linux-gnu, with libunistring 0.9.3, it returns a
 7-character string ending in “gnu”.

scheme@(guile-user) (use-modules (rnrs))
scheme@(guile-user) (define p (open-bytevector-input-port #vu8(255 1 2 3 103 
110 117)))
scheme@(guile-user) (set-port-conversion-strategy! p 'substitute)
scheme@(guile-user) (get-line p)
$1 = �\x01\x02\x03gnu
scheme@(guile-user) (version)
$2 = 1.9.13.176-3df53


That does look like a 7 char string ending in gnu.

-Dale

Re: r6rs-ports.test is failing

[dsmich]

 Ludovic Courtès l...@gnu.org wrote: 
 And this?
 
 (let* ((t  (make-transcoder (utf-8-codec) (native-eol-style)
 (error-handling-mode replace)))
(b  (open-bytevector-input-port #vu8(255 1 2 3 103 110 117)))
(tp (transcoded-port b t)))
   (port-conversion-strategy tp))


$2 = substitute


-Dale

r6rs-ports.test is failing

[dsmich]

The r6rs-ports.test is failing for me on a Debian Lenny 64bit system.

$ git describe
release_1-9-13-107-ga0ad8ad

$ ./check-guile r6rs-ports.test
Testing /home/dsmith/src/guile/meta/guile ... r6rs-ports.test
with GUILE_LOAD_PATH=/home/dsmith/src/guile/test-suite
Running r6rs-ports.test
UNRESOLVED: r6rs-ports.test: 7.2.11 Binary Output: put-bytevector [2 args]
UNRESOLVED: r6rs-ports.test: 7.2.11 Binary Output: put-bytevector [3 args]
UNRESOLVED: r6rs-ports.test: 7.2.11 Binary Output: put-bytevector [4 args]
ERROR: r6rs-ports.test: 8.2.6  Input and output ports: transcoded-port [error 
handling mode = replace] - arguments: ((encoding-error scm_from_stringn 
input locale conversion error 84 UTF-8 UTF-32 #vu8(255 1 2 3 103 110 
117)))

Totals for this test run:
passes: 36
failures:   0
unexpected passes:  0
expected failures:  0
unresolved test cases:  3
untested test cases:0
unsupported test cases: 0
errors: 1


$ env | grep -E '(LANG|LC)'
LANG=en_US.UTF-8
GDM_LANG=en_US.UTF-8


$ locale
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_ALL=

git guile hangs in fluids.test

[dsmich]

Recently, git guile has been consistently hanging in fluids.test.  Cpu usage 
drops to 0.  This is on a single core machine running a fairly up-to-date 
Debian Testing.

$ gcc --version
gcc (Debian 4.4.2-9) 4.4.3 20100108 (prerelease)

$ git describe
release_1-9-9-23-g6128f34

Here is a gdb backtrace connected to the hung process:

(gdb) bt
#0  0x4001e424 in __kernel_vsyscall ()
#1  0x4046c285 in sem_wait@@GLIBC_2.1 () at 
../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/sem_wait.S:80
#2  0x40168018 in GC_stop_world () at pthread_stop_world.c:426
#3  0x40157b1e in GC_stopped_mark (stop_func=0x40156f40 GC_never_stop_func) 
at alloc.c:474
#4  0x40157df9 in GC_try_to_collect_inner (stop_func=0x40156f40 
GC_never_stop_func) at alloc.c:362
#5  0x40158194 in GC_try_to_collect (stop_func=0x40156f40 GC_never_stop_func) 
at alloc.c:762
#6  0x40158270 in GC_gcollect () at alloc.c:774
#7  0x40076277 in scm_i_gc (what=0x4010efee fluids) at gc.c:401
#8  0x40070d43 in new_fluid () at fluids.c:132
#9  scm_make_fluid () at fluids.c:180
#10 0x400f24a7 in vm_debug_engine (vm=0x9b2b590, program=0x9b6f910, 
argv=0xbfa168d0, nargs=1) at vm-i-system.c:853
#11 0x400e163a in scm_c_vm_run (vm=0x9b2b590, program=0x9b6f910, 
argv=0xbfa168d0, nargs=1) at vm.c:518
#12 0x4006e9c7 in scm_primitive_eval (exp=0x9fe2de0) at eval.c:859
#13 0x4008dac3 in scm_primitive_load (filename=0x9e62990) at load.c:125
#14 0x400f249c in vm_debug_engine (vm=0x9b2b590, program=0x9c3ac48, 
argv=0xbfa16a24, nargs=1) at vm-i-system.c:856
#15 0x400e163a in scm_c_vm_run (vm=0x9b2b590, program=0x9c3ac48, 
argv=0xbfa16a24, nargs=1) at vm.c:518
#16 0x4006d945 in scm_call_1 (proc=0x9c3ac48, arg1=0x9c4d1d0) at eval.c:574
#17 0x4006ee0e in scm_for_each (proc=0x9c3ac48, arg1=0x9c532a0, args=0x304) at 
eval.c:802
#18 0x400f2517 in vm_debug_engine (vm=0x9b2b590, program=0x9b6f910, 
argv=0xbfa16b90, nargs=1) at vm-i-system.c:862
#19 0x400e163a in scm_c_vm_run (vm=0x9b2b590, program=0x9b6f910, 
argv=0xbfa16b90, nargs=1) at vm.c:518
#20 0x4006e9c7 in scm_primitive_eval (exp=0x9c2a048) at eval.c:859
#21 0x4006ea41 in scm_eval (exp=0x9c2a048, module_or_state=0x9aca738) at 
eval.c:893
#22 0x400b83e5 in scm_shell (argc=10, argv=0xbfa17014) at script.c:762
#23 0x40086a36 in invoke_main_func (body_data=0xbfa16f50) at init.c:381
#24 0x40065622 in c_body (d=0xbfa16ea4) at continuations.c:475
#25 0x400ddfd2 in apply_catch_closure (clo=0x0, args=0x304) at throw.c:147
#26 0x400f189f in vm_debug_engine (vm=0x9b2b590, program=0x9ac4858, 
argv=0xbfa16d80, nargs=4) at vm-i-system.c:924
#27 0x400e163a in scm_c_vm_run (vm=0x9b2b590, program=0x9ac4858, 
argv=0xbfa16d80, nargs=4) at vm.c:518
#28 0x4006d85d in scm_call_4 (proc=0x9ac4858, arg1=0x404, arg2=0x9bf6d00, 
arg3=0x9bf6cf0, arg4=0x9bf6ce0)
at eval.c:595
#29 0x400de9b2 in scm_catch_with_pre_unwind_handler (key=0x404, 
thunk=0x9bf6d00, handler=0x9bf6cf0, 
pre_unwind_handler=0x9bf6ce0) at throw.c:87
#30 0x400dea82 in scm_c_catch (tag=0x404, body=0x40065610 c_body, 
body_data=0xbfa16ea4, 
handler=0x40065630 c_handler, handler_data=0xbfa16ea4, 
pre_unwind_handler=0x400de340 scm_handle_by_message_noexit, 
pre_unwind_handler_data=0x0) at throw.c:214
#31 0x400658eb in scm_i_with_continuation_barrier (body=0x40065610 c_body, 
body_data=0xbfa16ea4, 
handler=0x40065630 c_handler, handler_data=0xbfa16ea4, 
pre_unwind_handler=0x400de340 scm_handle_by_message_noexit, 
pre_unwind_handler_data=0x0) at continuations.c:452
#32 0x400659c3 in scm_c_with_continuation_barrier (func=0x400869f0 
invoke_main_func, data=0xbfa16f50)
at continuations.c:493
#33 0x400ddbac in scm_i_with_guile_and_parent (func=0x400869f0 
invoke_main_func, data=0xbfa16f50, parent=0x0)
at threads.c:734
#34 0x400ddcce in scm_with_guile (func=0x400869f0 invoke_main_func, 
data=0xbfa16f50) at threads.c:713
#35 0x400869cf in scm_boot_guile (argc=10, argv=0xbfa17014, main_func=0x8048860 
inner_main, closure=0x0)
at init.c:364
#36 0x0804885b in main (argc=10, argv=0xbfa17014) at guile.c:70
(gdb) 


-Dale

Re: git guile hangs in fluids.test

[dsmich]

 dsm...@roadrunner.com wrote: 
 Recently, git guile has been consistently hanging in fluids.test.  Cpu usage 
 drops to 0.  This is on a single core machine running a fairly up-to-date 
 Debian Testing.
 
 Here is a gdb backtrace connected to the hung process:

After 10 make check runs, fluids.test hung 6 times, and threads.test hung 4.  
Here is a bactracce from a hung threads.test:

(gdb) bt
#0  0x4001e424 in __kernel_vsyscall ()
#1  0x4046c285 in sem_wait@@GLIBC_2.1 () at 
../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/sem_wait.S:80
#2  0x40168018 in GC_stop_world () at pthread_stop_world.c:426
#3  0x40157b1e in GC_stopped_mark (stop_func=0x40156f40 GC_never_stop_func) 
at alloc.c:474
#4  0x40157df9 in GC_try_to_collect_inner (stop_func=0x40156f40 
GC_never_stop_func) at alloc.c:362
#5  0x40158194 in GC_try_to_collect (stop_func=0x40156f40 GC_never_stop_func) 
at alloc.c:762
#6  0x40158270 in GC_gcollect () at alloc.c:774
#7  0x40076277 in scm_i_gc (what=0x401150a0 call) at gc.c:401
#8  0x400762b3 in scm_gc () at gc.c:384
#9  0x400f24a7 in vm_debug_engine (vm=0x8c83590, program=0x8cc7910, 
argv=0xbfecf110, nargs=1) at vm-i-system.c:853
#10 0x400e163a in scm_c_vm_run (vm=0x8c83590, program=0x8cc7910, 
argv=0xbfecf110, nargs=1) at vm.c:518
#11 0x4006e9c7 in scm_primitive_eval (exp=0xa8a3f98) at eval.c:859
#12 0x4008dac3 in scm_primitive_load (filename=0x995b370) at load.c:125
#13 0x400f249c in vm_debug_engine (vm=0x8c83590, program=0x8d93d80, 
argv=0xbfecf264, nargs=1) at vm-i-system.c:856
#14 0x400e163a in scm_c_vm_run (vm=0x8c83590, program=0x8d93d80, 
argv=0xbfecf264, nargs=1) at vm.c:518
#15 0x4006d945 in scm_call_1 (proc=0x8d93d80, arg1=0x8cd4220) at eval.c:574
#16 0x4006ee0e in scm_for_each (proc=0x8d93d80, arg1=0x8dac8c0, args=0x304) at 
eval.c:802
#17 0x400f2517 in vm_debug_engine (vm=0x8c83590, program=0x8cc7910, 
argv=0xbfecf3d0, nargs=1) at vm-i-system.c:862
#18 0x400e163a in scm_c_vm_run (vm=0x8c83590, program=0x8cc7910, 
argv=0xbfecf3d0, nargs=1) at vm.c:518
#19 0x4006e9c7 in scm_primitive_eval (exp=0x8d83048) at eval.c:859
#20 0x4006ea41 in scm_eval (exp=0x8d83048, module_or_state=0x8c22738) at 
eval.c:893
#21 0x400b83e5 in scm_shell (argc=10, argv=0xbfecf854) at script.c:762
#22 0x40086a36 in invoke_main_func (body_data=0xbfecf790) at init.c:381
#23 0x40065622 in c_body (d=0xbfecf6e4) at continuations.c:475
#24 0x400ddfd2 in apply_catch_closure (clo=0x0, args=0x304) at throw.c:147
#25 0x400f189f in vm_debug_engine (vm=0x8c83590, program=0x8c1c858, 
argv=0xbfecf5c0, nargs=4) at vm-i-system.c:924
#26 0x400e163a in scm_c_vm_run (vm=0x8c83590, program=0x8c1c858, 
argv=0xbfecf5c0, nargs=4) at vm.c:518
#27 0x4006d85d in scm_call_4 (proc=0x8c1c858, arg1=0x404, arg2=0x8d516d0, 
arg3=0x8d516c0, arg4=0x8d516b0)
at eval.c:595
#28 0x400de9b2 in scm_catch_with_pre_unwind_handler (key=0x404, 
thunk=0x8d516d0, handler=0x8d516c0, 
pre_unwind_handler=0x8d516b0) at throw.c:87
#29 0x400dea82 in scm_c_catch (tag=0x404, body=0x40065610 c_body, 
body_data=0xbfecf6e4, 
handler=0x40065630 c_handler, handler_data=0xbfecf6e4, 
pre_unwind_handler=0x400de340 scm_handle_by_message_noexit, 
pre_unwind_handler_data=0x0) at throw.c:214
#30 0x400658eb in scm_i_with_continuation_barrier (body=0x40065610 c_body, 
body_data=0xbfecf6e4, 
handler=0x40065630 c_handler, handler_data=0xbfecf6e4, 
pre_unwind_handler=0x400de340 scm_handle_by_message_noexit, 
pre_unwind_handler_data=0x0) at continuations.c:452
#31 0x400659c3 in scm_c_with_continuation_barrier (func=0x400869f0 
invoke_main_func, data=0xbfecf790)
at continuations.c:493
#32 0x400ddbac in scm_i_with_guile_and_parent (func=0x400869f0 
invoke_main_func, data=0xbfecf790, parent=0x0)
at threads.c:734
#33 0x400ddcce in scm_with_guile (func=0x400869f0 invoke_main_func, 
data=0xbfecf790) at threads.c:713
#34 0x400869cf in scm_boot_guile (argc=10, argv=0xbfecf854, main_func=0x8048860 
inner_main, closure=0x0)
at init.c:364
#35 0x0804885b in main (argc=10, argv=0xbfecf854) at guile.c:70
(gdb)

-Dale

Re: git guile hangs in fluids.test

[dsmich]

 Ludovic Courtès l...@gnu.org wrote: 
 Hi Dale,
 
 dsm...@roadrunner.com writes:
 
  Recently, git guile has been consistently hanging in fluids.test.  Cpu
  usage drops to 0.  This is on a single core machine running a fairly
  up-to-date Debian Testing.
 
 What does ./build-aux/config.guess say?


$ ./build-aux/config.guess 
i686-pc-linux-gnu

And as raeburn suggested:

(gdb) thread apply all bt

Thread 2 (Thread 0x40c1cb70 (LWP 15152)):
#0  0x4001e424 in __kernel_vsyscall ()
#1  0x4033cd47 in do_sigsuspend (set=0x40170320) at 
../sysdeps/unix/sysv/linux/sigsuspend.c:63
#2  *__GI___sigsuspend (set=0x40170320) at 
../sysdeps/unix/sysv/linux/sigsuspend.c:78
#3  0x4016822b in GC_suspend_handler_inner (sig_arg=0x1e Address 0x1e out of 
bounds, context=0x40c1b99c)
at pthread_stop_world.c:207
#4  0x401682b5 in GC_suspend_handler (sig=30, info=0x40c1b91c, 
context=0x40c1b99c) at pthread_stop_world.c:142
#5  signal handler called
#6  0x4001e422 in __kernel_vsyscall ()
#7  0x403d23cb in read () from /lib/i686/cmov/libc.so.6
#8  0x400b6f82 in signal_delivery_thread (data=0x0) at scmsigs.c:164
#9  0x400ddfd2 in apply_catch_closure (clo=0x1, args=0x304) at throw.c:147
#10 0x400f189f in vm_debug_engine (vm=0x93a8ee0, program=0x91ea858, 
argv=0x40c1bec4, nargs=3) at vm-i-system.c:924
#11 0x400e163a in scm_c_vm_run (vm=0x93a8ee0, program=0x91ea858, 
argv=0x40c1bec4, nargs=3) at vm.c:518
#12 0x4006d8b7 in scm_call_3 (proc=0x91ea858, arg1=0x404, arg2=0x9618310, 
arg3=0x96182f0) at eval.c:588
#13 0x400de908 in scm_catch (key=0x404, thunk=0x9618310, handler=0x96182f0) at 
throw.c:74
#14 0x400dea16 in scm_catch_with_pre_unwind_handler (key=0x404, 
thunk=0x9618310, handler=0x96182f0, 
pre_unwind_handler=0x904) at throw.c:82
#15 0x400dea82 in scm_c_catch (tag=0x404, body=0x400b6f20 
signal_delivery_thread, body_data=0x0, 
handler=0x400de3c0 scm_handle_by_message, handler_data=0x4011b344, 
pre_unwind_handler=0, 
pre_unwind_handler_data=0x0) at throw.c:214
#16 0x400dead9 in scm_internal_catch (tag=0x404, body=0x400b6f20 
signal_delivery_thread, body_data=0x0, 
handler=0x400de3c0 scm_handle_by_message, handler_data=0x4011b344) at 
throw.c:223
#17 0x400dd2fb in really_spawn (d=0x40a1b16c) at threads.c:922
#18 0x40065622 in c_body (d=0x40c1c2a4) at continuations.c:475
#19 0x400ddfd2 in apply_catch_closure (clo=0x1, args=0x304) at throw.c:147
#20 0x400f189f in vm_debug_engine (vm=0x93a8ee0, program=0x91ea858, 
argv=0x40c1c180, nargs=4) at vm-i-system.c:924
#21 0x400e163a in scm_c_vm_run (vm=0x93a8ee0, program=0x91ea858, 
argv=0x40c1c180, nargs=4) at vm.c:518
#22 0x4006d85d in scm_call_4 (proc=0x91ea858, arg1=0x404, arg2=0x9618cc0, 
arg3=0x9618cb0, arg4=0x9618c70)
at eval.c:595
#23 0x400de9b2 in scm_catch_with_pre_unwind_handler (key=0x404, 
thunk=0x9618cc0, handler=0x9618cb0, 
pre_unwind_handler=0x9618c70) at throw.c:87
#24 0x400dea82 in scm_c_catch (tag=0x404, body=0x40065610 c_body, 
body_data=0x40c1c2a4, 
handler=0x40065630 c_handler, handler_data=0x40c1c2a4, 
pre_unwind_handler=0x400de340 scm_handle_by_message_noexit, 
pre_unwind_handler_data=0x0) at throw.c:214
#25 0x400658eb in scm_i_with_continuation_barrier (body=0x40065610 c_body, 
body_data=0x40c1c2a4, 
handler=0x40065630 c_handler, handler_data=0x40c1c2a4, 
pre_unwind_handler=0x400de340 scm_handle_by_message_noexit, 
pre_unwind_handler_data=0x0) at continuations.c:452
#26 0x400659c3 in scm_c_with_continuation_barrier (func=0x400dd260 
really_spawn, data=0x40a1b16c)
at continuations.c:493
#27 0x400ddbac in scm_i_with_guile_and_parent (func=0x400dd260 really_spawn, 
data=0x40a1b16c, parent=0x93a8fe8)
at threads.c:734
#28 0x400ddc3f in spawn_thread (d=0x40a1b16c) at threads.c:934
#29 0x40166e48 in GC_inner_start_routine (sb=0x40c1c380, arg=0x99cdfe0) at 
pthread_support.c:1073
#30 0x4016121c in GC_call_with_stack_base (fn=0x40166da0 
GC_inner_start_routine, arg=0x99cdfe0) at misc.c:1165
#31 0x40166cd7 in GC_start_routine (arg=0x99cdfe0) at pthread_support.c:1104
#32 0x40466585 in start_thread (arg=0x40c1cb70) at pthread_create.c:300
#33 0x403e129e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Thread 1 (Thread 0x404f92f0 (LWP 14857)):
#0  0x4001e424 in __kernel_vsyscall ()
#1  0x4046c285 in sem_wait@@GLIBC_2.1 () at 
../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/sem_wait.S:80
#2  0x40168018 in GC_stop_world () at pthread_stop_world.c:426
#3  0x40157b1e in GC_stopped_mark (stop_func=0x40156f40 GC_never_stop_func) 
at alloc.c:474
#4  0x40157df9 in GC_try_to_collect_inner (stop_func=0x40156f40 
GC_never_stop_func) at alloc.c:362
#5  0x40158194 in GC_try_to_collect (stop_func=0x40156f40 GC_never_stop_func) 
at alloc.c:762
---Type return to continue, or q return to quit---
#6  0x40158270 in GC_gcollect () at alloc.c:774
#7  0x40076277 in scm_i_gc (what=0x4010efee fluids) at gc.c:401
#8  0x40070d43 in new_fluid () at fluids.c:132
#9  scm_make_fluid () at fluids.c:180
#10 0x400f24a7 in vm_debug_engine 

Re: undefined __rl_init_argument on Mac OS 10.4

[dsmich]

Howdy Aziz,

 Abdulaziz Ghuloum aghul...@gmail.com wrote: 
 Hello,
 
 I tried building guile 1.9 today and the build fails due to undefined  
 __rl_init_argument.  This appears to be defined in line 96 of guile- 
 readline/readline.c and used only once in like 125 of the same file.   
 Commenting out both lines makes the build proceed, but I don't know  
 how bad this is.  There are also a bunch of warnings about redefined  
 bindings.  A summary of the failed build log is below.

That's because the Apple reimplementation of readline is incomplete.  The 
preferred solution is to install gnu readline.

On the other hand, I did basically the same as you when I built Guile on my mac 
mini.  Never had a problem with it.

-Dale

Re: [bug #24554] Pthreads and Stack overflow in guile (reopen bug 20814?) (guile 1.8.5)

[dsmich]

 Kannan Vijayan [EMAIL PROTECTED] wrote: 
 
 Follow-up Comment #2, bug #24554 (project guile):
 
 I have confirmed that the bug is not really a bug.  The debian changelog
 indicates that the --with-threads option was turned off with one of the 1.8.0
 releases of guile due to a bug.  It doesn't seem to have been turned back on
 since then.

I would imagine that --with-threads will not be turned back on until a 1.10.x 
(or 2.0.0 ?) release of Guile.

My limited understanding of the situation (possibly incorrect):  Using 
--without-threads changes the sizes of some data structures (I'm guessing they 
are smaller, with some pthreads stuff #ifdef'ed out), so that code compiled for 
one way will segfault when linked with code compiled for the other way.

As far as just releasing new packages --with-threads, It's just not possible to 
go back an recompile all the currently existing packages on already existing 
systems.

-Dale

Re: bug in read?

[dsmich]

 Andy Wingo [EMAIL PROTECTED] wrote: 
 Hi,
 
 Since it's a week later now and no one's answered:
 
 On Mon 17 Sep 2007 23:49, Luigi Semenzato [EMAIL PROTECTED] writes:
 
  Is this a reader bug?  Hash marks following
  an integer are interpreted as zeros, and the
  number is converted to real.
 
  guile (read)
  44###
  44000.0
  guile
 
  If this is expected, section 5.5.2.6 (Read Syntax for Numerical Data)
  should mention it.

This is the syntax for inexact numbers.  See r5rs sections 6.2.4 and 7.1.1

-Dale



___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile