Re: Compiling Guile on Solaris 10 11/06 x86 edition
[EMAIL PROTECTED] writes: FAIL: time.test: strftime: C99 %z format: EST+5 Hmm. You could step through that EST+5 test to see what comes out. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Compiling Guile on Solaris 10 11/06 x86 edition
Alan Pae [EMAIL PROTECTED] writes: with 1.8.2, if I hide complex.h (mv complex.h complex.h.temp) then it compiles find, You may also be able to pretend complex double doesn't exist with ./configure ac_cv_type_complex_double=no but SWIG does not load. Don't know anything about that. How do I test for cexp() and friends? Configure checks for clog10, which is supposed to be representative of all the complex funcs, you can look in config.log or in config.h to see if it was noticed. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: guile-1.8.1 (static-only build) 'gmake check' 2 of 9 tests failed
[EMAIL PROTECTED] writes: After the many modifications reported, the build of guile-1.8.1 (with --enable-static --disable-shared) is successful on Solaris2.6, but some 'gmake check' tests fail (see below). Thanks. Might there be a problem when a static-only build is done, or that the tests themselves don't expect a static-only build? Or both :). ERROR: In procedure dynamic-link: ERROR: file: libguile-srfi-srfi-1-v-3, message: ld.so.1: guile: fatal: libguile-srfi-srfi-1-v-3.a: open failed: No such file or directory FAIL: test-require-extension That might be supposed to work. I think there's some hairy stuff in libtool where you tell it about the modules you might dynamic link, and in a static build it compiles them in and fakes up success loading them. I guess nobody's tried a static build. ERROR: In procedure dynamic-link: ERROR: file: libtest-asmobs, message: ld.so.1: guile: fatal: libtest-asmobs.a: open failed: No such file or directory FAIL: test-asmobs Yes, that test probably can't work in a static-only build. It should exit 77 to skip, or have an automake conditional around it. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: sleep 999 after tests
Marijn Schouten (hkBst) [EMAIL PROTECTED] writes: This test depends on networking being enabled. Does it? It's a pipe, not a socket. So how about making it 30 seconds? No, but something that made the two processes watch more closely what each other is doing would be fine. (I suppose the child process ought to be killed+waited explicitly too.) As I said though, if it's blocking for 999 then you're looking at a bug, maybe in guile, maybe in the test. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: crash and test failures with 1.8.1
[belated followup]
Dan McMahill [EMAIL PROTECTED] writes:
Running numbers.test
FAIL: numbers.test: max: big / real: (= big*5 (max big*5 -inf.0))
Thanks, that was a bug in the test (I believe the code is/was ok).
Running r4rs.test
[1] Segmentation fault ${dir}${tst}
FAIL: check-guile
Don't know anything about that.
1) Is there a more or less simple way to step through the tests in an
interactive mode where I can get to the failures in numbers.test to
really see what values are involved and causing the failure?
Not really, but the tests are supposed to be relatively straightforward
so you can pick out the values and try them.
2) Is there a simple way to get the r4rs.test to run in the debugger
so I can either track this down myself or provide some more useful
feedback?
Slightly painful. The last time I had to do that I changed the last
line of the generated pre-inst-guile script from
exec $GUILE $@
to
exec /my/build/dir/libtool gdb --args $GUILE $@
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Re: guile-1.8.1 build fails at libguile/stime.c on Solaris2.6
[belated followup] [EMAIL PROTECTED] writes: Workaround: in that file, for that platform, insert #define _REENTRANT //(or #define __EXTENSIONS__) Thanks, I added that in the cvs. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: warnings during compilation of guile-1.8.2 and FAIL: check-guile
Storbeck, Frank [EMAIL PROTECTED] writes: 1. == quote === threads.c:525: warning: missing braces around initializer That's supposed to be covered by SCM_NEED_BRACES_ON_PTHREAD_ONCE_INIT which is tested by configure (see config.log) and set in libguile/scmconfig.h, if you'd like to check if that test got the right answer, and put it through. (I believe the braces solaris demands are contrary to the posix standard -- not that that helps anyone wanting it to work :-) ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: warnings during compilation of guile-1.8.2 and FAIL: check-guile
Storbeck, Frank [EMAIL PROTECTED] writes: 2. filesys.c: In function 'scm_readdir': filesys.c:916: warning: implicit declaration of function 'readdir64_r' We had another report that you have to define _REENTRANT to get gmtime_r. Is it the same for readdir64_r? (If so I'll chuck that in filesys.c. Assuming of course readdir64_r does exist and is meant to be used ...) ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: warnings during compilation of guile-1.8.2 and FAIL: check-guile
Storbeck, Frank [EMAIL PROTECTED] writes: 3. FAIL: posix.test: putenv: removing FAIL: posix.test: setenv: removing FAIL: posix.test: unsetenv: something FAIL: posix.test: unsetenv: empty Sounds like a bug. I guess each one is about not being able to remove a variable from the environment. I think they all end up going down scm_putenv() in libguile/posix.c, and it ought to be using unsetenv() to remove. Is unsetenv() available on solaris? The fallback code if it's not is most likely wrong (it's some DOS nonsense). ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Bug on Guile Make
Simon Butcher [EMAIL PROTECTED] writes: numbers.c: In function 'xisinf': numbers.c:147: warning: implicit declaration of function 'isinf' I think we went 12 rounds with that recently. I think it was slackness in the configure test, letting gcc do constant folding instead of actually probing for the func. You should be able to edit the generated config.h to turn off HAVE_ISINF. numbers.c: In function 'scm_log': numbers.c:6022: error: '_Complex_I' undeclared (first use in this function) That may be new. The test for using complex double is whether that type exists. I'd have thought complex.h (which your config.h says exists) supplied _Complex_I. Is there another name or something? ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: guile-1.8.1 fails test on x86 when regex or networking is disabled
Marijn Schouten (hkBst) [EMAIL PROTECTED] writes: guile-1.8.1 fails test on x86 when regex or networking is disabled Do you actually not have those things? There's no interest in disabling things just for the sake of disabling. Without regex should run (I think I fixed a bug about getting to the repl recently). The test suite might not be fully conditionalized. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: guile-1.8.1 fails test on amd64
Marijn Schouten (hkBst) [EMAIL PROTECTED] writes: ERROR: Value too large for defined data type PASS: gmtime: (in another thread after error 9223372036854775807) Hmm. Thanks. I think the change below should do the trick, if you'd like to try it. Note that I have built guile without thread support. Are you sure? Those tests are meant for threads, and it looks like (provided? 'threads) passed. (Run ./pre-inst-guile and try that if you want to check.) --- time.test.~1.6.2.4.~ 2006-09-23 10:05:29.0 +1000 +++ time.test 2007-01-25 08:56:05.0 +1100 @@ -34,7 +34,7 @@ (alarm 5) (false-if-exception (gmtime t)) - (join-thread (begin-thread (catch 'out-of-range + (join-thread (begin-thread (catch #f (lambda () (gmtime t)) (lambda args #f (alarm 0) ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: guile-1.8.1 fails test on amd64
Marijn Schouten (hkBst) [EMAIL PROTECTED] writes: test-conversion.c: In function ‘test_1’: test-conversion.c:32: warning: format ‘%Ld’ expects type ‘long long int’, but argument 4 has type ‘scm_t_intmax’ Rob's looking at that I think. FAIL: numbers.test: max: big / real: (= big*5 (max big*5 -inf.0)) FAIL: numbers.test: max: real / big: (= big*5 (max -inf.0 big*5)) FAIL: numbers.test: min: big / real: (= big*5 (min big*5 +inf.0)) FAIL: numbers.test: min: real / big: (= big*5 (min +inf.0 big*5)) FAIL: numbers.test: max: big / real: (= big*5 (max big*5 -inf.0)) FAIL: numbers.test: max: real / big: (= big*5 (max -inf.0 big*5)) FAIL: numbers.test: min: big / real: (= big*5 (min big*5 +inf.0)) FAIL: numbers.test: min: real / big: (= big*5 (min +inf.0 big*5)) Thanks, I think I fixed that (dodgy test). ERROR: srfi-14.test: Latin-1 (8-bit charset): char-set:punctuation (membership) - arguments: ((unbound-variable #f Unbound variable: ~S (thrown) #f)) Another dodgy test. FAIL: srfi-60.test: copy-bit: (eqv? -1 (copy-bit 62 -1 #t)) An actual bug, should be fixed now (and also fixed in the debian packaged version now I think). In thread: ERROR: In procedure gmtime: ERROR: Value too large for defined data type Can you tell where that comes from? That might be a new one. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: stack overflow equal? values
[EMAIL PROTECTED] (Ludovic Courtès) writes: I propose the following simple fix. Ok to apply? Yep, looks good. After I posted I wondered if the values struct is an actual s or if there's some strange extra I couldn't spot. Testing eq avoids worrying about that. Dunno why values are a struct and not a smob cell. Actually, `scm_i_struct_equalp ()' should also compare the tail elements (when there are tail elements), Yes. but their semantics are a little fuzzy to me. In particular, I don't understand why the size of the tail array can be specified in both `make-vtable-vtable' and `make-struct': What does that mean? Which one should really be taken into account? Dunno :). It seems that the code is a bit unclear on this too: guile (define v (make-vtable-vtable pr 0)) guile (define s (make-struct v 123)) guile (struct-ref s 10) Segmentation fault A segv is a bug, obviously, whichever way it's actually meant to be. (Looks like the API is so complex that few people actually bothered to use it to its full extents. ;-)) The records level is friendlier I guess. For a long time I couldn't understand what vtable meant, I still don't think I quite do. Maybe the docs should be tweaked, to help show what structs are typically meant to be. --- orig/test-suite/tests/structs.test +++ mod/test-suite/tests/structs.test @@ -82,12 +82,18 @@ (set-owner! ball Bill) (string=? (owner ball) Bill))) - (pass-if equal? You can make a with-test-prefix group if you like. An exercise of an actual values too will be good, maybe in eval.test. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: stack overflow equal? values
Marco Maggi [EMAIL PROTECTED] writes: guile (equal? (values 1 2) (values 1 2)) ERROR: Stack overflow Thanks, looks like a bug introduced by recursing into structs in equal?. I guess scm_i_struct_equalp should check and ignore a field type s ... ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Bug with macros in SCM and Guile
Aubrey Jaffer [EMAIL PROTECTED] writes: | From: Marc Feeley [EMAIL PROTECTED] | Date: Wed, 29 Nov 2006 15:58:57 -0500 | | For SCM it seems that a macro call is normally expanded when an | expression is encountered in a top-down traversal of the code, but | not always. For example, in the function bar2 below the macro call | to foo is expanded when bar2 is *called*, and at that point a new | definition of the macro foo has been introduced. I thought that was the idea for defmacro, to expand when it runs, and in fact to re-expand every time it's run. A little wasteful, but it's emulating lisp style (or is it just emacs-lisp style) in that isn't it? ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: [Patch] Some fixes for the MinGW port
Cesar Strauss [EMAIL PROTECTED] writes: Not to mention the common use of spaces within paths, like c:\Program Files. It is a recipe for trouble ;-) . Yes. I think autoconf/automake/libtool had trouble with those for a while, let alone what slackness an actual package might have. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: [Patch] Some fixes for the MinGW port
(Delayed by mail snafu ...) Cesar Strauss [EMAIL PROTECTED] writes: -extern SCM scm_create_hook (const char* name, int n_args); +SCM_API SCM scm_create_hook (const char* name, int n_args); -extern SCM scm_major_version (void); -extern SCM scm_minor_version (void); -extern SCM scm_micro_version (void); -extern SCM scm_effective_version (void); -extern SCM scm_version (void); -extern void scm_init_version (void); +SCM_API SCM scm_major_version (void); +SCM_API SCM scm_minor_version (void); +SCM_API SCM scm_micro_version (void); +SCM_API SCM scm_effective_version (void); +SCM_API SCM scm_version (void); Thanks, I made that change. +SCM_API void scm_init_version (void); Not sure if that's meant to be public, it's probably used only within libguile. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: [Patch] Some fixes for the MinGW port
Cesar Strauss [EMAIL PROTECTED] writes: The attached patch addresses the following issues on MinGW, when building the CVS HEAD version of guile: Actually, portability things are being tackled first in the 1.8 branch, then merged into the head periodically. There's some mingw pthread fixes there which haven't made it to the head yet for instance, if you'd like to give them a try. -# define LC_MESSAGES_MASK(1 LC_MESSAGES) +# ifdef LC_MESSAGES /* undefined on mingw */ +# define LC_MESSAGES_MASK (1 LC_MESSAGES) +# else +# define LC_MESSAGES_MASK 0 +# endif I'll leave that for Ludovic to contemplate, I think he said he'll change it to use just the base LC bits, not an extra set of mask values. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: [Patch] Some fixes for the MinGW port
Cesar Strauss [EMAIL PROTECTED] writes:
- The colon, when used as a delimiter in a sed command, conflicts with
paths that include a drive letter (e.g. 'c:/mingw/bin').
- -e s:@-bindir-@:${bindir}: \
+ -e 's|@-bindir-@|${bindir}|' \
Thanks. Though I think the best advice concerning drive letters is
don't do that :-).
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Re: [Patch] Some fixes for the MinGW port
Cesar Strauss [EMAIL PROTECTED] writes: + ;; SIGBUS is not present on mingw + (if (defined? 'SIGBUS) + `((,SIGBUS . Bad memory access (bus error))) + '())) Thanks, I made a similar change. I don't know why it's never shown up before, maybe noone ever got to the repl on mingw before! ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: procedure-documentation does not work for procedures which exported from module
[EMAIL PROTECTED] writes: It this a bug in Guile? Or I'm wrong and I should write such code in other way? It looks right, and it works for me with the same debian guile (on i386). You don't have a different version of your module lurking in the search path? You can put a print in %load-hook (see the manual) to check that. You can also try (procedure-source any-string) to see if it's what you expect. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: [Patch] --with-threads on MinGW
I made the sigmask change. That should be all of what you reported, thanks. But you could give it a run when you get a chance, I'm not sure if that signal delivery thread will do the right thing. I'm guessing it'll be harmless but useless. It might be better to go with the null threads code. The test suite doesn't really exercise signals, you might have to make your own program with some raises or alarms. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: MinGW/autoconf
Nils Durner [EMAIL PROTECTED] writes: It aborts after the warning and mingw.org doesn't provide a newer autoconf. I was sure I'd wrestled it before and it was merely annoying but harmless. In any event normally I don't think there's any virtue in working with old developer tools, but in this case we can modernize configure.in to get around it. I checked in the changes below. * configure.in (-lm): No need to suppress libm on mingw, it's not needed because it's empty, but including it does no harm. (-lm): Look for cos instead of main, since cos and friends are the purpose of looking for libm. (winsock etc): Test $host = *-*-mingw* rather than $MINGW32, autoconf regards the latter as obsolete. (AC_MINGW32): Remove test, $MINGW32 now unused. (uint32_t): Look at HAVE_NETDB_H rather than hard-coding __MINGW32__ in the test program. The only bit to maybe wonder about is the -lm detection. I'm pretty sure AC_CHECK_LIB gets the right answer on its own, but I also know libtool has had an AC_CHECK_LIBM doing some hard-coded suppressing of -lm for beos, mingw, cygwin and darwin. --- configure.in.~1.268.2.25.~ 2006-12-15 10:15:59.0 +1100 +++ configure.in 2006-12-22 20:21:14.0 +1100 @@ -55,7 +55,6 @@ dnl Some more checks for Win32 AC_CYGWIN -AC_MINGW32 AC_LIBTOOL_WIN32_DLL AC_PROG_INSTALL @@ -561,9 +560,11 @@ AC_TYPE_SIGNAL AC_TYPE_MODE_T -if test $MINGW32 = no; then - AC_CHECK_LIB(m, main) -fi +# On mingw -lm is empty, so this test is unnecessary, but it's +# harmless so we don't hard-code to suppress it. +# +AC_CHECK_LIB(m, cos) + AC_CHECK_FUNCS(gethostbyname) if test $ac_cv_func_gethostbyname = no; then AC_CHECK_LIB(nsl, gethostbyname) @@ -578,7 +579,8 @@ dnl Check for Winsock and other functionality on Win32 (*not* CygWin) dnl EXTRA_DEFS= -if test $MINGW32 = yes ; then +case $host in + *-*-mingw*) AC_CHECK_HEADER(winsock2.h, [AC_DEFINE([HAVE_WINSOCK2_H], 1, [Define if you have the winsock2.h header file.])]) AC_CHECK_LIB(ws2_32, main) @@ -592,7 +594,8 @@ AC_DEFINE(USE_DLL_IMPORT, 1, [Define if you need additional CPP macros on Win32 platforms.]) fi -fi +;; +esac AC_SUBST(EXTRA_DEFS) # Reasons for testing: @@ -798,7 +801,7 @@ #if HAVE_STDINT_H #include stdint.h #endif - #ifndef __MINGW32__ + #ifndef HAVE_NETDB_H #include netdb.h #endif], [uint32_t a;], ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: [Patch] --with-threads on MinGW
Nils Durner [EMAIL PROTECTED] writes: However, pthread.h has to be included somewhere to have timespec declared. Otherwise, building fails with threads.c: In function `scm_timed_wait_condition_variable': threads.c:1264: error: storage size of 'waittime' isn't known It should come from pthread-threads.h, which is included by threads.h for SCM_USE_PTHREAD_THREADS. Can you check if that happens. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: [Patch] --with-threads on MinGW
Nils Durner [EMAIL PROTECTED] writes: Yes, as said before, the concept of signals is unknown under Windows. Oops, ok, there's a local notion through raise(), but nothing that you want a separate running thread for. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: contents of empty shared array
SZAVAI Gyula [EMAIL PROTECTED] writes:
(let ((a (make-shared-array #() (lambda x #f) 0 2)))
(array-contents a))
== #f
I suppose an empty shared array ought to be considered contiguous.
--- orig/libguile/unif.c2006-11-30 10:25:50.101433600 +0100
+++ mod/libguile/unif.c 2006-11-30 13:03:16.24432 +0100
@@ -900,6 +900,7 @@
{
SCM_I_ARRAY_V (ra) = make_typed_vector (scm_array_type (ra), 0);
scm_array_handle_release (old_handle);
+ SCM_SET_ARRAY_CONTIGUOUS_FLAG (ra);
return ra;
Is that meant to be confined to the SCM_I_ARRAY_V case (per below)?
One of the lurking array experts will have to say ...
--- unif.c.~1.192.2.6.~ 2006-12-13 09:38:49.0 +1100
+++ unif.c 2006-12-14 09:09:33.0 +1100
@@ -901,7 +901,10 @@
if (1 == SCM_I_ARRAY_NDIM (ra))
ra = make_typed_vector (scm_array_type (ra), 0);
else
+{
SCM_I_ARRAY_V (ra) = make_typed_vector (scm_array_type (ra), 0);
+SCM_SET_ARRAY_CONTIGUOUS_FLAG (ra);
+}
scm_array_handle_release (old_handle);
return ra;
}
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Re: [Patch] --with-threads on MinGW
Nils Durner [EMAIL PROTECTED] writes: The only timespec declaration on Win32 is the one in pthread.h, (Taking bits one at a time so I don't get confused.) I checked in the change below to hopefully detect. My debian mingw cross doesn't have pthread.h at all, so I can't actually test it. --- configure.in.~1.268.2.23.~ 2006-12-03 10:19:27.0 +1100 +++ configure.in 2006-12-14 10:10:18.0 +1100 @@ -622,10 +622,12 @@ # Reasons for testing: # netdb.h - not in mingw # sys/param.h - not in mingw +# pthread.h - only available with pthreads. ACX_PTHREAD doesn't +# check this specifically, we need it for the timespec test below. # sethostname - the function itself check because it's not in mingw, # the DECL is checked because Solaris 10 doens't have in any header # -AC_CHECK_HEADERS(crypt.h netdb.h sys/param.h sys/resource.h sys/file.h) +AC_CHECK_HEADERS(crypt.h netdb.h pthread.h sys/param.h sys/resource.h sys/file.h) AC_CHECK_FUNCS(chroot flock getlogin cuserid getpriority setpriority getpass sethostname gethostname) AC_CHECK_DECLS([sethostname]) @@ -1034,17 +1036,22 @@ fi +# On mingw, struct timespec is in pthread.h. +# AC_MSG_CHECKING(for struct timespec) AC_CACHE_VAL(scm_cv_struct_timespec, AC_TRY_COMPILE([ -#include time.h], +#include time.h +#if HAVE_PTHREAD_H +#include pthread.h +#endif], [struct timespec t; t.tv_nsec = 100], scm_cv_struct_timespec=yes, scm_cv_struct_timespec=no)) AC_MSG_RESULT($scm_cv_struct_timespec) if test $scm_cv_struct_timespec = yes; then AC_DEFINE(HAVE_STRUCT_TIMESPEC, 1, -[Define this if your system defines struct timespec via time.h.]) +[Define this if your system defines struct timespec via either time.h or pthread.h.]) fi # ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: [Patch] --with-threads on MinGW
Nils Durner [EMAIL PROTECTED] writes: Pthreads-win32 defines pthread_t as struct. I made the change below to go via a union to pick out some info. Does it look about right? Maybe there's an easier way to pick out the bytes ... --- configure.in.~1.268.2.23.~ 2006-12-03 10:19:27.0 +1100 +++ configure.in 2006-12-14 10:10:18.0 +1100 @@ -622,10 +622,12 @@ # Reasons for testing: # netdb.h - not in mingw # sys/param.h - not in mingw +# pthread.h - only available with pthreads. ACX_PTHREAD doesn't +# check this specifically, we need it for the timespec test below. # sethostname - the function itself check because it's not in mingw, # the DECL is checked because Solaris 10 doens't have in any header # -AC_CHECK_HEADERS(crypt.h netdb.h sys/param.h sys/resource.h sys/file.h) +AC_CHECK_HEADERS(crypt.h netdb.h pthread.h sys/param.h sys/resource.h sys/file.h) AC_CHECK_FUNCS(chroot flock getlogin cuserid getpriority setpriority getpass sethostname gethostname) AC_CHECK_DECLS([sethostname]) @@ -1034,17 +1036,22 @@ fi +# On mingw, struct timespec is in pthread.h. +# AC_MSG_CHECKING(for struct timespec) AC_CACHE_VAL(scm_cv_struct_timespec, AC_TRY_COMPILE([ -#include time.h], +#include time.h +#if HAVE_PTHREAD_H +#include pthread.h +#endif], [struct timespec t; t.tv_nsec = 100], scm_cv_struct_timespec=yes, scm_cv_struct_timespec=no)) AC_MSG_RESULT($scm_cv_struct_timespec) if test $scm_cv_struct_timespec = yes; then AC_DEFINE(HAVE_STRUCT_TIMESPEC, 1, -[Define this if your system defines struct timespec via time.h.]) +[Define this if your system defines struct timespec via either time.h or pthread.h.]) fi # ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: [Patch] --with-threads on MinGW
I wrote:
I made the change below
Oops, too much cut and paste. Actual change is:
Index: threads.c
===
RCS file: /cvsroot/guile/guile/guile-core/libguile/threads.c,v
retrieving revision 1.84.2.5
retrieving revision 1.84.2.6
diff -u -r1.84.2.5 -r1.84.2.6
--- threads.c 25 Jul 2006 00:09:30 - 1.84.2.5
+++ threads.c 13 Dec 2006 23:55:51 - 1.84.2.6
@@ -141,9 +141,32 @@
static int
thread_print (SCM exp, SCM port, scm_print_state *pstate SCM_UNUSED)
{
+ /* On a Gnu system pthread_t is an unsigned long, but on mingw it's a
+ struct. A cast like (unsigned long) t-pthread is a syntax error in
+ the struct case, hence we go via a union, and extract according to the
+ size of pthread_t. */
+ union {
+pthread_t p;
+unsigned short us;
+unsigned int ui;
+unsigned long ul;
+scm_t_uintmax um;
+ } u;
scm_i_thread *t = SCM_I_THREAD_DATA (exp);
+ scm_i_pthread_t p = t-pthread;
+ scm_t_uintmax id;
+ u.p = p;
+ if (sizeof (p) == sizeof (unsigned short))
+id = u.us;
+ else if (sizeof (p) == sizeof (unsigned int))
+id = u.ui;
+ else if (sizeof (p) == sizeof (unsigned long))
+id = u.ul;
+ else
+id = u.um;
+
scm_puts (#thread , port);
- scm_uintprint ((size_t)t-pthread, 10, port);
+ scm_uintprint (id, 10, port);
scm_puts ( (, port);
scm_uintprint ((scm_t_bits)t, 16, port);
scm_puts (), port);
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Re: [Patch] --with-threads on MinGW
Nils Durner [EMAIL PROTECTED] writes:
static SCM
signal_delivery_thread (void *data)
{
- sigset_t all_sigs;
int n, sig;
char sigbyte;
+#ifndef __MINGW32__
+ sigset_t all_sigs;
+
sigfillset (all_sigs);
scm_i_pthread_sigmask (SIG_SETMASK, all_sigs, NULL);
+#endif
Are you sure about that? Does it mean the signal delivery thread
doesn't catch any signals?
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Re: [Patch] --with-threads on MinGW
Nils Durner [EMAIL PROTECTED] writes:
pthread_attr_getstack() exists, but pthread_getattr_np() doesn't.
How about the change below (untested), to keep out of the hair of the
_np bits.
That getattr_np is confusing. Is the right way to create an attr
object with pthread_attr_init, use it for pthread_create, then use it
again later with pthread_attr_getstack if you want to ask something?
If that could be passed down through the levels of guile inits it'd
get rid of a non-portable call.
--- threads.c.~1.84.2.6.~ 2006-12-14 10:52:15.0 +1100
+++ threads.c 2006-12-14 11:36:37.0 +1100
@@ -629,7 +629,16 @@
}
}
-#endif /* HAVE_PTHREAD_ATTR_GETSTACK HAVE_PTHREAD_GETATTR_NP */
+#elif defined (__MINGW32__)
+/* In mingw the basic scm_get_stack_base can be used in any thread. */
+#define HAVE_GET_THREAD_STACK_BASE
+static SCM_STACKITEM *
+get_thread_stack_base ()
+{
+ return scm_get_stack_base ();
+}
+
+#endif /* pthread methods of get_thread_stack_base */
#else /* !SCM_USE_PTHREAD_THREADS */
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Re: generic * and 0
Mikael Djurfeldt [EMAIL PROTECTED] writes: Good idea. I made the change. Because of paragraph 6.2.2, a program cannot expect to get the result 0.0, and it seems like a strength of the implementation to provide the additional piece of information that the result is indeed *exactly* 0. If you wanted an argument the other way, returning a flonum zero could give negative zero for say (* 0 -1.0). But I'd favour exactness, since the result is certainly exactly zero. (Not entirely sure that the common zero is a good idea, but I tend to think so.) I suppose it's a question of whether * should do that, or leave it up to the application. The only case I can think of where a common zero may not be good is with matrices, where (* 0 matrix) = matrix could preserve the dimensions of the input matrix in the output matrix. Those dimensions could be used later (* matrix matrix), to signal an error if the dimensions were incompatible. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: generic * and 0
While nosing around nearby stuff I noticed
(* 0 1.0) = 0
(* 0 1+1i) = 0
but
(* 1.0 0) = 0.0
(* 1+1i 0) = 0.0
which seems a bit inconsistent. R5RS Exactness reads like either
exact or inexact is permitted, but I imagine it ought to be the same
whichever way around you write the args. I think I'll change the
latter two to exact 0.
--- numbers.c.~1.135.2.22.~ 2006-03-20 08:48:19.0 +1100
+++ numbers.c 2006-12-03 15:59:32.0 +1100
@@ -3632,6 +3632,9 @@
}
} else if (SCM_REALP (x)) {
if (SCM_INUMP (y)) {
+ /* inexact*exact0 is exact 0, per R5RS Exactness section */
+ if (SCM_EQ_P (y, SCM_INUM0))
+return y;
return scm_make_real (SCM_INUM (y) * SCM_REAL_VALUE (x));
} else if (SCM_BIGP (y)) {
return scm_make_real (scm_i_big2dbl (y) * SCM_REAL_VALUE (x));
@@ -3645,6 +3648,9 @@
}
} else if (SCM_COMPLEXP (x)) {
if (SCM_INUMP (y)) {
+ /* inexact*exact0 is exact 0, per R5RS Exactness section */
+ if (SCM_EQ_P (y, SCM_INUM0))
+return y;
return scm_make_complex (SCM_INUM (y) * SCM_COMPLEX_REAL (x),
SCM_INUM (y) * SCM_COMPLEX_IMAG (x));
} else if (SCM_BIGP (y)) {
--- numbers.c.~1.281.2.7.~ 2006-09-27 11:34:11.0 +1000
+++ numbers.c 2006-12-03 16:08:52.0 +1100
@@ -4492,7 +4492,12 @@
else if (SCM_REALP (x))
{
if (SCM_I_INUMP (y))
- return scm_from_double (SCM_I_INUM (y) * SCM_REAL_VALUE (x));
+{
+ /* inexact*exact0 is exact 0, per R5RS Exactness section */
+ if (scm_is_eq (y, SCM_INUM0))
+return y;
+ return scm_from_double (SCM_I_INUM (y) * SCM_REAL_VALUE (x));
+}
else if (SCM_BIGP (y))
{
double result = mpz_get_d (SCM_I_BIG_MPZ (y)) * SCM_REAL_VALUE (x);
@@ -4512,8 +4517,13 @@
else if (SCM_COMPLEXP (x))
{
if (SCM_I_INUMP (y))
- return scm_c_make_rectangular (SCM_I_INUM (y) * SCM_COMPLEX_REAL (x),
-SCM_I_INUM (y) * SCM_COMPLEX_IMAG (x));
+{
+ /* inexact*exact0 is exact 0, per R5RS Exactness section */
+ if (scm_is_eq (y, SCM_INUM0))
+return y;
+ return scm_c_make_rectangular (SCM_I_INUM (y) * SCM_COMPLEX_REAL (x),
+ SCM_I_INUM (y) * SCM_COMPLEX_IMAG
(x));
+}
else if (SCM_BIGP (y))
{
double z = mpz_get_d (SCM_I_BIG_MPZ (y));
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Re: [Patch] --with-threads on MinGW
Nils Durner [EMAIL PROTECTED] writes: the attached patch fixes building on MinGW with --with-threads=pthreads Looks good in principle, but some bits ought to be in a more autoconfy style. -#ifdef HAVE_STRUCT_TIMESPEC +#if HAVE_STRUCT_TIMESPEC || SCM_I_GSC_USE_PTHREAD_THREADS pf (typedef struct timespec scm_t_timespec;\n); Does the detection of struct timespec go wrong somehow? +#ifndef __MINGW32__ + sigset_t all_sigs; + sigfillset (all_sigs); scm_i_pthread_sigmask (SIG_SETMASK, all_sigs, NULL); +#endif I think I'd rather either conditionalize on the existance of pthread_sigmask, or perhaps make some dummy sigset stuff if it doesn't exist. +#ifndef __MINGW32__ + t-pthread, +#else + t-pthread.p, +#endif What does that do? #if SCM_USE_PTHREAD_THREADS /* pthread_getattr_np not available on MacOS X and Solaris 10. */ -#if HAVE_PTHREAD_ATTR_GETSTACK HAVE_PTHREAD_GETATTR_NP +#if (HAVE_PTHREAD_ATTR_GETSTACK HAVE_PTHREAD_GETATTR_NP) || __MINGW32__ Remind us what's wrong with the getstack detection ... ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: guile-1.8.1 tarball missing config.rpath
Ralf Wildenhues [EMAIL PROTECTED] writes: * Neil Jerram wrote on Fri, Nov 17, 2006 at 03:19:43PM CET: 2. Make sure that whoever prepares the release has Automake 1.10; then automake --add-missing will install config.rpath as a side effect of the AM_GNU_GETTEXT declaration in configure.in. I made that change, by bumping the required version in the top-level Makefile.am. Not quite right. automake will complain, but it will take gettextize or autopoint to actually install config.rpath. Every time I've run gettextize it's modified or added more stuff than I wanted it to :-(. In particular for guile we don't have translated messages internally yet, hence no po directory. You could also just copy it from /usr/share/gettext (or whereever gettext happens to be installed on your system). Yes, that'd be the go. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: generic * and 0
SZAVAI Gyula [EMAIL PROTECTED] writes:
(use-modules (oop goops))
(define-class c ())
(define-method (* a (b c)) #t)
(* 0 (make c))
== 0
Thanks, that's a bug.
- switch (xx)
- {
-case 0: return x; break;
-case 1: return y; break;
- }
-
Though that's not the fix (it breaks 0 * bignum, and changes 0 * real
and complex).
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Re: bounds of 1-dimensional empty arrays
[EMAIL PROTECTED] (Ludovic Courtès) writes: BTW, it would be helpful if you could provide a ChangeLog entry or a short sentence explaining the fix you propose. (Copyright assignment will be needed for more than about 15 lines cumulative ... which often makes just a pointer to the offending part easier than an actual patch.) ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: vector-list
Szavai Gyula [EMAIL PROTECTED] writes: (let ((b (make-shared-array #(1) (lambda (x) '(0)) 2))) Thanks, though I'm not sure that's supposed to work. I suspect you're not meant to make parts of the old array appear in more than one place in the new array. Perhaps Marius can say what the intention is. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: generic * and 0
Mikael Djurfeldt [EMAIL PROTECTED] writes: If you want to use an operator which is common for numbers and c:s, why don't you want to use a common zero? If you don't, the behavior of the operator will be inconsistent. For multiply by 0, I can sort of think of cases when the return type shouldn't be a fixnum. If you're doing 0 times a certain size matrix, then you probably want a matrix full of zeros to come back. Does that sound right? For multiply by 1, I can't actually think of any time you wouldn't want to get back the object unchanged. But perhaps if a class has a notion of multiply, but not multiply by scalar then you'd like it to be overridable so it can be banned. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: configure doesn't check for clog and csqrt
[EMAIL PROTECTED] (Ludovic Courtès) writes: Han-Wen Nienhuys [EMAIL PROTECTED] writes: Apparently, in GUILE-1.8.1 configure doesn't check for clog and csqrt(). This leads to problems on Freebsd 4.1, as the libc there doesn't support both functions. Does it provide them in some other library, like `-lm'? (There's a test, it assumes there presence of complex double means the complex funcs exist ...) ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Win32/MinGW port
Nils Durner [EMAIL PROTECTED] writes: As there are no signals on Win32, I *think* it is okay to just ifndef MINGW the code. That might be worth trying. (But not with ifdef mingw, rather a test for missing funcs or features. There's already been mingw-specific conditionals that became bogus because missing bits have since been added to the system.) #include fcntl.h #define pipe(f) _pipe(f, 1000, _O_BINARY) Yep, we've got that in another file. It might be worth sticking in _scm.h to get it everywhere. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Win32/MinGW port
Nils Durner [EMAIL PROTECTED] writes: Yes, but some functions are not supported by pthreads-w32. How bad are the missing bits? Should configure reject it because there's no pthread_sigmask, or is there something the code can do to cope? ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: guile-1.8.0 configure error
Weinstein, Jay P [EMAIL PROTECTED] writes: It can't find pthread libs in /usr/lib. See config.log Looks like -pthread succeeded. Did something not work? ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Win32/MinGW port
Nils Durner [EMAIL PROTECTED] writes: scmsigs.c:157: warning: implicit declaration of function `pthread_sigmask' Does it have pthreads? Did you ask for them, or did configure wrongly decide to use them? ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Copyright years on the Guile Web page
Yoni Rabkin Katzenell [EMAIL PROTECTED] writes: The years 2003, 2004 and 2006 are missing from the list. Thanks, I added 2006 to changed pages. (A year only gets added when there's an actual change.) ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: (apply make-vector '(1 2 3))
The case of no args was also not caught (passed through to the 2o
func). I made this change,
* eval.c (SCM_APPLY): For scm_tc7_subr_2o, throw wrong-num-args on 0
arguments or 3 or more arguments. Previously 0 called proc with
SCM_UNDEFINED, and 3 or more silently used just the first 2.
--- eval.c.~1.405.2.5.~ 2006-07-21 10:22:22.0 +1000
+++ eval.c 2006-10-02 12:18:26.0 +1000
@@ -4849,7 +4849,16 @@
switch (SCM_TYP7 (proc))
{
case scm_tc7_subr_2o:
- args = scm_is_null (args) ? SCM_UNDEFINED : SCM_CAR (args);
+ if (SCM_UNBNDP (arg1))
+ scm_wrong_num_args (proc);
+ if (scm_is_null (args))
+args = SCM_UNDEFINED;
+ else
+{
+ if (! scm_is_null (SCM_CDR (args)))
+scm_wrong_num_args (proc);
+ args = SCM_CAR (args);
+}
RETURN (SCM_SUBRF (proc) (arg1, args));
case scm_tc7_subr_2:
if (scm_is_null (args) || !scm_is_null (SCM_CDR (args)))
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Bug in libguile/scmsigs.c Guile 1.8.0
Mark Detrick [EMAIL PROTECTED] writes:
scmsigs.c: In function 'ensure_signal_delivery_thread':
scmsigs.c:191: warning: missing braces around initializer
scmsigs.c:191: warning: (near initialization for
'once.__pthread_once_pad')
Thanks, that's some non-posix conformance in solaris. We've got a
workaround in the cvs for the next release. You can add braces to
SCM_I_PTHREAD_ONCE_INIT in pthread-threads.h. The line
#define SCM_I_PTHREAD_ONCE_INIT PTHREAD_ONCE_INIT
becomes
#define SCM_I_PTHREAD_ONCE_INIT { PTHREAD_ONCE_INIT }
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Re: MinGW port
Ken Raeburn [EMAIL PROTECTED] writes: Is the execv declaration (in some header file) part of mingw, or Windows? Looks like mingw process.h. But I've got an idea the const * const * is a long-standing MSDOS-ism, presumably carried forward into that horribly bloated overlay manager thing they added, I forget what it's called ... doors, holes, flywire screen ... ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: (apply make-vector '(1 2 3))
Marius Vollmer [EMAIL PROTECTED] writes: This doesn't happen for Scheme functions, probably only for (certain types of) primitives. Slackness in the scm_tc7_subr_2o case of scm_apply perhaps (looking only at null or not null for the list of args). ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Minor documentation layout flaws
percy tiglao [EMAIL PROTECTED] writes: Type (backtrace) to get more information or (debug) to enter the debugger. This doesn't go off the page; but it nearly does. It wraps in info too. But this is obviously the output of guile. It's free-form though, not something you have to type, or should expect to see exactly, so it doesn't matter too much. Should I just add a newline between the and debugger? Sounds fine, I made that change. I also fixed two spots in the format function showing 1x2 3x4 5x6, which I think I introduced. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: MinGW port
Neil Jerram [EMAIL PROTECTED] writes: do you understand exactly what the Win32/MinGW compiler is complaining about? The function takes const char * const * but the actual parameter is char **. I've never understood why that should provoke a complaint. Const is a promise by the func that it won't modify the contents (of either the array or the contained strings) so surely it's acceptable to pass something that is allowed to be modified, isn't it? In any case, __MINGW32__ conditionals are pretty horrible, I'd much prefer to see guile not force -Werror on unsuspecting users. Or not do it on mingw at least. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Minor documentation layout flaws
percy tiglao [EMAIL PROTECTED] writes: overfull hboxes If tex would report them in a form that you could step through it'd be possible to fix the worst ones. call-with-current-continuation on it. But the word was so big; that it pushed the parameters off the page. Thanks, I reformatted a bit. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: [bug #17344] Problem compiling guile 1.8.0
Pierre [EMAIL PROTECTED] writes: gcc -s -O3 -march=i686 -Wall -Wmissing-prototypes -Werror -o .libs/guile .libs/guileS.o -pthread guile-guile.o -Wl,--export-dynamic ./.libs/libguile.so /usr/local/lib/libgmp.so -lcrypt -lm /usr/local/lib/libltdl.so guile-guile.o: In function `main': guile.c:(.text+0x2f): undefined reference to `lt__PROGRAM__LTX_preloaded_symbols' What system is this? You could try delete the following two lines from libguile/guile.c, they're not needed on a gnu system. extern const lt_dlsymlist lt_preloaded_symbols[]; lt_dlpreload_default (lt_preloaded_symbols); Dunno why the symbol is lt__PROGRAM__LTX_preloaded_symbols though. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: CVS-060720 compilation failure on Solaris 10, patch
Claes Wallin [EMAIL PROTECTED] writes:
+#ifdef __sun__
+/* workaround for broken Solaris 10 headers */
+#define SCM_I_PTHREAD_ONCE_INIT { PTHREAD_ONCE_INIT }
+#else /* !__sun__ */
+#define SCM_I_PTHREAD_ONCE_INIT PTHREAD_ONCE_INIT
+#endif /* !__sun__ */
Grr. Contrary to what posix says I think :-(.
http://www.opengroup.org/onlinepubs/95399/functions/pthread_once.html
I might make a configure test to see which style should be used, you'd
imagine sun will fix their bugs eventually.
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Re: CVS-060720 compilation failure on Solaris 10, patch
Claes Wallin [EMAIL PROTECTED] writes:
-std=gnu99 worked, or changing those asm() to __asm().
__asm__ would be fine if it helped. There's a mixture of asm and
__asm__ at the moment.
isinf is contained in an '#ifdef _STD_C99' section.
Hmm ...
* Updated HAVE_ALLOCA_H blocks in libguile/eval.c libguile/filesys.c
* Check for HAVE_PTHREAD_GETATTR_NP in libguile/threads.c
* Tests using scm_boot_guile instead of scm_init_guile
* string.h in libguile/threads.c
* { PTHREAD_ONCE_INIT } in libguile/threads-pthreads.h
* Check for HAVE_DECL_SETHOSTNAME libguile/posix.c
Thanks, all applied, except ONCE_INIT which is in progress ...
* Addition of version.texi in doc/ref/ and doc/tutorial/
Don't know what you mean there. If you're building from the cvs you
may need ./configure --enable-maintainer-mode.
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Re: CVS-060720 compilation failure on Mac OS X 10.4, patch (dirfd)
Claes Wallin [EMAIL PROTECTED] writes: * test-suite/tests/dirfd.test: Since dirfd is used by readdir on platforms that have it, this test does an opendir and two consecutive readdirs, expecting . and ... Not sure if this works on non-posix platforms. Yep, not sure about . and .., though I remember most unixy stuff on DOS systems synthesising them in the bad old days. There's an existing test in filesys.test when expects the root directory / to be non-empty; it at least exercises the opendir/readdir/closedir sequence. Perhaps a test that created a long-named temporary file (in the builddir) would be an idea. But might have to communicate the NAME_MAX (or equivalent) size to the scheme level to do that effectively. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: CVS-060720 compilation failure on Solaris 10, patch
Claes Wallin [EMAIL PROTECTED] writes: Nope, 'grep -r sethostname /usr/include' yields two hits, both are comments. Beaut, I made the change. You might check if the man page says a header, sometimes sub-includes are buried in bizarre places (ie. outside /usr/include). ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: CVS-060720 compilation failure on Solaris 10, patch
Claes Wallin [EMAIL PROTECTED] writes: It seems that isinf is c99, and that earlier gcc:s supported it in isoc as a GNU extension. If we're using c99, why not specify it? What good things will be turned off? Every time I've had the misfortune to experiment with standards-modes on headers or whatever it's been painful. I think _POSIX_SOURCE losing all GNU extras was the most recent bad bit in guile. Is isinf missed on solaris? Is there another way to ask for it? ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: CVS-060720 compilation failure on Mac OS X 10.4, patch (dirfd)
Claes Wallin [EMAIL PROTECTED] writes: On Mac OS X 10.4 dirfd is a macro, not a function. Thanks. Is that true on solaris too? I'm guessing it is. Replace AC_CHECK_FUNCS([dirfd]) with gl_FUNC_DIRFD. I think I'll make the test #ifndef dirfd instead. Is gl_FUNC_DIRFD an actual documented function? ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: CVS-060720 compilation failure on Solaris 10, patch
Claes Wallin [EMAIL PROTECTED] writes: Declare sethostname on __sun__. +#ifdef __sun__ +int sethostname(char *name, int namelen); +#endif Thanks, but I don't really want to hard-code __sun__. Is that prototype in some other header? If not AC_CHECK_DECL will be the way to go. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: CVS-060720 compilation failure on Solaris 10, patch
Claes Wallin [EMAIL PROTECTED] writes: Demand C99 for math functions. Which ones are missed otherwise? +AC_PROG_CC_C99 I'm worried that will turn off good things in gcc. I'd much rather leave the compiler in the default mode, or whatever mode the user has asked for with CFLAGS. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: CVS-060720 compilation failure on Solaris 10, patch
Claes Wallin [EMAIL PROTECTED] writes: * libguile/threads.c: include string.h (FD_ZERO on Solaris needs this) Thanks, I made that change. +#if HAVE_STRING_H defined(__sun__)/* On Solaris 10, FD_ZERO uses memset */ ... but without __sun__. That header is friendly, no need to restrict its use. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: CVS-060720 compilation failure on Solaris 10, patch
[EMAIL PROTECTED] (Ludovic Courtès) writes: the `#ifdef's changed a bit in the Autoconf manual (see [0]), so perhaps we should update them accordingly. Sounds good, done. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: 1.8.0: C++-style cast
[EMAIL PROTECTED] (Ludovic Courtès) writes: PS to Kevin: Can you eventually merge into HEAD your recent fixes in 1.8? Yep. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: CVS FIXED, but probably lacking (Re: Compilation failure on Mac OS X 10.4, socklen_t needs sys/socket.h)
Claes Wallin [EMAIL PROTECTED] writes: SunOS 4 Does anything else work there? :-) It's diabolically old isn't it? ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: 1.8.0: C++-style cast
Mike Gran [EMAIL PROTECTED] writes: In guile-core-1.8-20060711, in libguile/numbers.c, in guile_ieee_init(), a C++ style cast is used instead of a C-style cast. Also, a declaration block occurs in a code block. These bend the rules of old-school ANSI C. - guile_Inf = (*(X_CAST(double *, DINFINITY))); + guile_Inf = (*((double *) (DINFINITY))); ... I don't think it's c++. I'm guessing X_CAST is an OSF macro. Dunno if it does anything good. John Eaton contributed that, maybe he can say (Cc'ed). ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: 1.8.0: The ?: operator used in an lvalue context
Mike Gran [EMAIL PROTECTED] writes: This gets flagged as an error by the AIX xlc compiler. It might be cleaner to change it into an if/else. Yep, thanks, I made that change. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: 1.8.0: $ in makefile w/o an implicit rule
Mike Gran [EMAIL PROTECTED] writes: In guile-core-1.8-20060705, in libguile/Makefile, the target for version.h: version.h.in uses the macro $ when there isn't an implicit rule defined. This doesn't work in OpenBSD and AIX make. Thanks. The autoconf manual notes that too in fact. You could change the line sed $ [EMAIL PROTECTED] to sed version.h.in $.tmp perhaps. I changed $ to $(srcdir)/version.h.in, which I think is the right place to find that file. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: parallel make fails for guile 1.8
Neil Jerram [EMAIL PROTECTED] writes: I think that means it can be certainly be removed from BUILT_SOURCES. Beaut, I did that. It probably doesn't need to be built automatically at all; a developer can do make guile.texi when they need it. Sticking it in nodist_noinst_DATA = guile.texi seems to work to get it built under make all, if you still want it. If normal users don't need it then maybe it should be restricted to if ENABLE_MAINTAINER_MODE though. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: compile problems
Ryan VanderBijl [EMAIL PROTECTED] writes: 1. configure couldn't find ltdl library, nor header file. You need to install libtool (or the ltdl part of it). Guile no longer comes with an out-of-date version :). 2. read.c:332 s_vector declared but not used warning, when configured with --disable-elisp. Thanks. Easily fixed by some ifdefs. Or not forcing -Werror on unsuspecting users :-(. 3. throw.c:495 scm_handle_by_message control reaches end of non-void function. Thanks. Not sure what the correct behavior should be, perhaps it should 'return SCM_BOOL_F;' like the function scm_handle_by_message_noexit? It doesn't return so it doesn't matter. I guess exit or pthread_exit isn't marked as noreturn. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: parallel make fails for guile 1.8
Neil Jerram [EMAIL PROTECTED] writes: I would guess this means that the Makefile is failing to work out that the libguile .c files depend on scmconfig.h, Yep. I added scmconfig.h to the .x and .doc files dependencies, because they run cpp. For the .o files depending on scmconfig.h, I don't think there's a good way to express that with automake. The magic dependency tracking might be supposed to do it, but I find that too painful. BUILT_SOURCES (where scmconfig.h already is) is usually the easiest way to get stuff done before building main .o files etc. In our case its defeated because guile.texi is in BUILT_SOURCES too, and it depends on the main guile target, so that starts on the .o files for libguile (under a parallel make). But is guile.texi actually used for anything? ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Does not find header files or libraries under /usr/local
[EMAIL PROTECTED] (Ludovic Courtès) writes: Often, `configure' scripts provide a `--with-PACKAGE-prefix' option (or `--with-PACKAGE-includes', or `--with-PACKAGE-libs') so that one can specify where to look fo a particular package. Though that's contrary to the gnu standards. Getting a path from somewhere is fine, even good, but --with is not the place for it. http://www.gnu.org/prep/standards/html_node/Configuration.html Do not use a --with option to specify the file name to use to find certain files. That is outside the scope of what --with options are for. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Guile 1.8.0 make check fails
Hector Herrera [EMAIL PROTECTED] writes: Running numbers.test FAIL: numbers.test: number-string: (or (string=? (number-string 11.3 12) B.4) (string=? (number-string 11.3 12) B.409)) Thanks, I saw that too and was about to disable it. The conversions are not so exact that the test can be relied on, not in its current form. [some other tests] They're just warnings, or bits still in progress. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: configure cannot test when cross-compiling should be ok
The Senator [EMAIL PROTECTED] writes:
checking for restartable system calls... configure: error: cannot run
test program while cross compiling
You should be able to force it with
./configure ac_cv_sys_restartable_syscalls=yes
or no if that's the right answer, I don't know how system calls and
signals interact on mingw.
--- configure-old-with-errors 2006-05-13 20:19:06.0 +1200
+++ configure 2006-05-15 02:44:35.0 +1200
@@ -37596,7 +37596,7 @@
See \`config.log' for more details. 5
echo $as_me: error: cannot run test program while cross compiling
See \`config.log' for more details. 2;}
- { (exit 1); exit 1; }; }
+ }
That's probably not what you want.
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Re: 'Segmentation fault' in example program
Frithjof [EMAIL PROTECTED] writes: Is my system just not set up correctly or is this a bug in Guile or one in the example? A bug in the example. If you don't have a HOSTNAME variable then getenv returns NULL, and scm_str2string can't cope with NULL. I'll change the manual. Thanks. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Bug in make-shared-array.
Marius Vollmer [EMAIL PROTECTED] writes: This behavior might or might not be a feature, but if you really want it, it is probably better to use array-contents explicitely. Yep, that should be an error. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: bug in eqv?
Aubrey Jaffer [EMAIL PROTECTED] writes: SRFI-77 is the most preliminary of proposals, and guaranteed to be withdrawn. Yep. Seems to me the idea of base r5rs is reasonably clear (not crystal clear, but near enough) that eqv? is the same as = on numbers. Keeps the heirarchy of comparisons clean too. -- library procedure: equal? obj1 obj2 `Equal?' recursively compares the contents of pairs, vectors, and strings, applying `eqv?' on other objects such as numbers and symbols. A rule of thumb is that objects are generally `equal?' if they print the same. `Equal?' may fail to terminate if its arguments are circular data structures. If -0.0 and 0.0 print differently, then there is no support for (equal? -0.0 0.0) == #t. I would read it that equal? is supposed to be the same as eqv? on numbers, and the bit about printing is only an aid to understanding the recursion (and not a terribly helpful one really). ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: bug in eqv?
Aubrey Jaffer [EMAIL PROTECTED] writes: Because (= 0.0 -0.0) is #t, (eqv? 0.0 -0.0) must be #t. Ah dear, thanks. Bit too much creativity with the nans and infs. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: guile and readline-5.1
Charles Ballard [EMAIL PROTECTED] writes: (any chance of an AC_ARG_WITH readline prefix in the configure) Probably not. But ripping out the old rl_cleanup_after_signal compatibility bit would be a possibility. If that would either then work straight away with editline, or would fail in some cleaner way. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: guile and readline-5.1
Charles Ballard [EMAIL PROTECTED] writes: I downloaded 5.1 from the gnu site, which resolved all bar one of the issues. _rl_init_argument seems to have been replaced by _rl_reset_argument. Looks like the code in question in guile is designed as a fallback for ancient realine 2.1 and 2.2, and shouldn't be getting used at all with readline 5.1. Please see whether configure has detected rl_cleanup_after_signal(), and put -DHAVE_RL_CLEANUP_AFTER_SIGNAL=1 into DEFS in the generated Makefile. The stuff in config.log should give a hint what went wrong if that function wasn't detected, post the relevant part if so. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: pedantic stuff: C++ comments in 1.8.0
Mike Gran [EMAIL PROTECTED] writes: There are some C++-style comments in 1.8.0. Thanks, I applied that fix. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Bug in make-shared-array.
Steve Juranich [EMAIL PROTECTED] writes: Are there any workarounds for this? There's something evil happening, I can't tell what it is. Marius was the last to give the array bits a prod, he might be able to say. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: string comparison vs. char comparison
[EMAIL PROTECTED] writes: guile (string? s ß) #f guile (char? #\s #\ß) #t Ah dear. Thanks. The string funcs are signed, the char funcs are unsigned. I think they used to be both unsigned. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
[bug #15747] guile 1.6.7 is missing hash-for-each function
Update of bug #15747 (project guile): Status:None = In Progress Open/Closed:Open = Closed ___ Follow-up Comment #1: There's no hash-for-each in Guile 1.6, but it's going to be in 1.8. You can use hash-fold in 1.6. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15747 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
[bug #14925] Non-portable binary compilations on linux
Update of bug #14925 (project guile): Status:None = Need Info Open/Closed:Open = Closed ___ Follow-up Comment #1: We think __libc_stack_end is portable enough, we think it's upwardly compatible between glibc versions, which should be enough. Incidentally, it must be very difficult doing binary compilations on linux, I wasn't aware the kernel came with a compiler or shell or tools. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14925 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: guile-1.6: fails to configure within the MinGW environment
Peter Nobis [EMAIL PROTECTED] writes: ./configure --host=i586-mingw32msvc checking for restartable system calls... configure: error: cannot run test program while cross compiling Are you actually cross compiling, or just trying to force the CPU-OS tuple? ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: [bug #14925] Non-portable binary compilations on linux
Neil Jerram [EMAIL PROTECTED] writes: - Can you be more precise about how __libc_stack_end is non-portable? (Is it just a matter of having a recent enough glibc?) My guess would be __libc_stack_end is portable enough, in the sense of being upward compatible between glibc versions. Maybe the OP was moving to an older one. - What do you mean statically linking from the share directory? I can't tell what that means either. Moved directories or something. Unlikely to be a good thing. But I don't see any way, either in this mail or in the bug report on savannah, to contact the submitter ... Unless the submitter is lurking here we'll have to close it as unable to be actioned, not aware of such a problem ... ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: guile-1.6.7 make problem
josh kurlander [EMAIL PROTECTED] writes: guile.c: In function main: guile.c:91: error: array type has incomplete element type guile.c:91: warning: unused variable lt_preloaded_symbols gcc 4 has become stricter about structs not yet defined. I think you can comment out the two lines extern const scm_lt_dlsymlist lt_preloaded_symbols[]; scm_lt_dlpreload_default (lt_preloaded_symbols); I'm pretty sure they don't do anything on a normal gnu/linux system. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: SLIB 3a2 does not work with Guile 1.6.4
Alan Grover [EMAIL PROTECTED] writes: * The guile.init file (provided in SLIB) has a bug: Please report slib bugs to slib (Aubrey Jaffer). ERROR: Unbound variable: with-load-pathname I think I struck that once when I had the debian packaged slib installed as well as another newer copy. You might like to check it's hitting the right files. Incidentally, the (ice-9 slib) module which comes with guile probably doesn't work with the latest slib, running up guile.init as described in the slib docs is the way to go. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Bug list hard to find
Alan Grover [EMAIL PROTECTED] writes: There does not appear to be any link from the http://www.gnu.org/software/guile site to the bug-list. I don't think there actually is an actively maintained bug list. * There appears to be a bug-list feature in Savannah for the project, but which isn't used (?). It copies through to bug-guile, for whoever wants to takeup something. A few people have submitted bugs anonymously though, which makes it hard to get feedback, so mailing bug-guile directly is probably best. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: using guile's readline module
Gene Pavlovsky [EMAIL PROTECTED] writes: guile (readline-set! bounce-parens 50) unnamed port: In expression (readline-options-interface (append # #)): unnamed port: Unbound variable: readline-options-interface ABORT: (unbound-variable) Fixed in the cvs, only waiting for the 1.6.8 release. (readline-options-interface needs to be exported from guile-readline/ice-9/readline.scm for use by the macros.) ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: SRFI-17 generates re-export warnings
Alan Grover [EMAIL PROTECTED] writes: The (srfi srfi-17) module uses 'export' instead of 're-export', and thus generates warnings. You (I think it was you) already reported that, fixed in the cvs. + :re-export ( I'm pretty sure that makes you export the core versions instead of the new definitions, which is not what's wanted. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Unclear documentation: Options and Config, set! and enable/disable
Alan Grover [EMAIL PROTECTED] writes: It isn't clear from the documentation how to use the User Level Options Interfaces (chapter Configuration, Features and Runtime Options). Alas, yes. Apparently, all of the group-set! are macros, and interpret the first argument as a symbol. Perhaps this was an attempt to make this interface appear analogous to set!, despite the option-symbols not being defined/bound. An example of a macro only serving to obscure :(. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: typos from guile/guile-core/ref/
hyperdivision [EMAIL PROTECTED] writes: various typos from chapter 4 that i've unveiled so far... directory guile/guile-core/ of the current CVS. Thanks, I made those changes, except for the autoconf/aclocal which I changed to a pxref. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Segfault using call/cc on ia64 (and possibly others)
Andreas Rottmann [EMAIL PROTECTED] writes: Segfaults in the G-Wrap testsuite[0] seem to indicate that this might be a problem on alpha, Your one-liner seems ok for me on alpha. Propose something for the test suite in any case. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: FAIL: unif.test: make-shared-array: shared of shared
Neil Jerram [EMAIL PROTECTED] writes: FAIL: unif.test: make-shared-array: shared of shared Any ideas? There's something wrong with making a shared array from another shared array. The base is or isn't offset or something. I don't normally add tests that will immediately fail, but this one is a bit obscure and might otherwise be forgotten. (It's a real bug though, it breaks my charting program.) ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Problem diving complex numbers
Jean Crepeau [EMAIL PROTECTED] writes:
There appears to be a bug in the 1.6.x releases of guile which wasn't
there in the 1.4.1 (and probably other versions before).
Yep, but those versions are prone to overflow when re or im is above
sqrt(DBL_MAX).
Simply doing
(/ 0-1i)
will result in #.##.#i
Thanks. Looks like nobody ever divided by -i before :). I think it's
meant to be like:
--- numbers.c.~1.135.2.20.~ 2005-02-21 09:50:34.0 +1100
+++ numbers.c 2005-04-29 14:19:10.535828592 +1000
@@ -3738,7 +3738,7 @@
} else if (SCM_COMPLEXP (x)) {
double r = SCM_COMPLEX_REAL (x);
double i = SCM_COMPLEX_IMAG (x);
- if (r = i) {
+ if (fabs(r) = fabs(i)) {
double t = r / i;
double d = i * (1.0 + t * t);
return scm_make_complex (t / d, -1.0 / d);
@@ -3782,7 +3782,7 @@
{
double r = SCM_COMPLEX_REAL (y);
double i = SCM_COMPLEX_IMAG (y);
- if (r = i) {
+if (fabs(r) = fabs(i)) {
double t = r / i;
double d = i * (1.0 + t * t);
return scm_make_complex ((a * t) / d, -a / d);
@@ -3873,7 +3873,7 @@
} else if (SCM_COMPLEXP (y)) {
double ry = SCM_COMPLEX_REAL (y);
double iy = SCM_COMPLEX_IMAG (y);
- if (ry = iy) {
+ if (fabs(ry) = fabs(iy)) {
double t = ry / iy;
double d = iy * (1.0 + t * t);
return scm_make_complex ((rx * t + ix) / d, (ix * t - rx) / d);
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Re: srfi-17 generates deprecated warnings
Alan Grover [EMAIL PROTECTED] writes: + :re-export (setter)) I think that has to be an export at the end, since it's a redefinition of a core procedure. +(export + ;; redefined standard procedures + car cdr caar cadr cdar cddr caaar caadr cadar caddr cdaar + cdadr cddar cdddr cr caaadr caadar caaddr cadaar cadadr + caddar cadddr cdaaar cdaadr cdadar cdaddr cddaar cddadr + cdddar cr string-ref vector-ref) Thanks, I made that change. ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Problem compiling tests for guile 1.7.1
Pierre [EMAIL PROTECTED] writes: fail: scm_from_double (nan) == +nan.0 FAIL: test-conversion See if you can trace through with gdb to see where it fails, ie. if one of the operands is not a nan, or if the comparison has gone wrong. A build with CFLAGS=-g will make source lines work properly, but might also make the problem go away. ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
