bug#15370: weirdness w/ uniform-vector-read! compat
Proc ‘uniform-vector-read!’ is deprecated (ugh), and its implementation rebased onto ‘(rnrs io ports) get-bytevector-n!’. Unfortunately, there seems to be a glitch in the arg shuffling. Here is /tmp/foo.scm: foo.scm Description: application/scheme and here is a series of invocations that demonstrate the discrepency between ‘get-bytevector-n!’ (ok) and ‘uniform-vector-read!’ (ko): set -x ; guile --version ; guile -s foo.scm ; guile -s foo.scm ok ; guile -s foo.scm ko + guile --version guile (GNU Guile) 2.0.9 Copyright (C) 2013 Free Software Foundation, Inc. License LGPLv3+: GNU LGPL 3 or later http://gnu.org/licenses/lgpl.html. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. + guile -s foo.scm uve: #s16(0) (2) uve: #s16(0) + guile -s foo.scm ok uve: #s16(0) (2) uve: #s16(10794) + guile -s foo.scm ko uve: #s16(0) (2) `uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from `(rnrs io ports)' instead. Backtrace: In ice-9/boot-9.scm: 157: 11 [catch #t #catch-closure 8347f30 ...] In unknown file: ?: 10 [apply-smob/1 #catch-closure 8347f30] In ice-9/boot-9.scm: 63: 9 [call-with-prompt prompt0 ...] In ice-9/eval.scm: 432: 8 [eval # #] In ice-9/boot-9.scm: 2320: 7 [save-module-excursion #procedure 8275ea0 at ice-9/boot-9.scm:3961:3 ()] 3968: 6 [#procedure 8275ea0 at ice-9/boot-9.scm:3961:3 ()] 1645: 5 [%start-stack load-stack ...] 1650: 4 [#procedure 83489c0 ()] In unknown file: ?: 3 [primitive-load /tmp/foo.scm] ?: 2 [call-with-input-string ...] In ice-9/eval.scm: 432: 1 [eval # #] In unknown file: ?: 0 [uniform-vector-read! #s16(0) #input: string 8263d20 ...] ERROR: In procedure uniform-vector-read!: ERROR: In procedure get-bytevector-n!: Value out of range: 4 FWIW, Guile 1.8.8 produces same output as ‘ok’ on a similar (sans the ‘use-modules’ and ‘uniform-vector-element-size’ noise) input, so i think this situation is a regression. Am i missing something? -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) = nil pgpIP6V3o_U0U.pgp Description: PGP signature
bug#14128: web/http.scm: bad-header date check (UTC?)
() Daniel Hartwig mand...@gmail.com () Wed, 3 Apr 2013 17:47:01 +0800 Apparently we are supposed to do this a bit more and accomodate yet another non-compliant service? Maybe that stuff should be exposed to the user. Do a best effort conversion and if not successful, return a pair ‘(raw-string . STRING)’ or whatever -- it's enough that it has a different type and that the type is documented. This way, you avoid carrying forward lots of cruft. Do it now before it's too late! Erk. What is the point of defining protocols and standards then? One purpose is to challenge programmers to learn how and when to say no. -- Thien-Thi Nguyen GPG key: 4C807502 pgp8YeIY0NhOd.pgp Description: PGP signature
bug#12892: ‘gc-stats’ w/o ‘bytes-malloced’
() Andy Wingo wi...@pobox.com () Thu, 07 Mar 2013 20:21:53 +0100 [...] Dunno. As an experiment, i've changed the cc to bug-guile in this response. Maybe that will work. Anyway, i'll followup w/ the debbugs folks. -- Thien-Thi Nguyen GPG key: 4C807502
bug#12892: ‘gc-stats’ w/o ‘bytes-malloced’
In pre-2.x Guile, ‘gc-stats’ returns an alist w/ keys: gc-time-taken cells-allocated total-cells-allocated cell-heap-size bytes-malloced gc-malloc-threshold gc-times gc-mark-time-taken cells-marked cells-swept malloc-yield cell-yield protected-objects cell-heap-segments In Guile 2.0.6, the keys are now: gc-time-taken heap-size heap-free-size heap-total-allocated heap-allocated-since-gc protected-objects gc-times I think the NEWS should mention this change and the documentation should summarize what the fields mean. Practically speaking, i am interested mostly in the 2.x equivalent for pre-2.x ‘bytes-malloced’, as its lack causes Guile-SDL to fail make check DEBUG=1: .ttn.make-check.log.gz Description: Binary data by tripping up proc: (define (malloced) ;; prudence or superstition? you be the judge! (gc) (gc) (assq-ref (gc-stats) 'bytes-malloced)) in test/leak.scm. A related issue is how the error is reported. It seems strange that the file is unknown. -- Thien-Thi Nguyen . GPG key: 4C807502 . NB: ttn at glug dot org is not me . . (and has not been since 2007 or so) . .ACCEPT NO SUBSTITUTES . ... please send technical questions to mailing lists ... pgpw21Cvh0lLr.pgp Description: PGP signature
Re: [Bug-autogen] test failure with guile-2.0.2
() Andy Wingo wi...@pobox.com () Wed, 13 Jul 2011 15:41:42 +0200 I realize that this is irritating to you, but it is the right thing, improves the situation for loads of users, and is largely compatible. I think when you say it is the right thing, you are missing the point. Try to jump up and see things from a perspective that includes the motion of the people who follow the leader. That will make you a better leader.
Re: Typos in the manual
() Mark Harig idirect...@aim.com () Tue, 15 Feb 2011 22:03:39 -0500 (Why do they miss the large similarities but see the small differences?) This is a human condition that afflicts even programmers.
[bug #30167] func-name (#define FUNC_NAME) check not applied fully
URL: http://savannah.gnu.org/bugs/?30167 Summary: func-name (#define FUNC_NAME) check not applied fully Project: Guile Submitted by: ttn Submitted on: gio 17 giu 2010 14:42:17 CEST Category: None Severity: 2 - Minor Item Group: None Status: None Privacy: Public Assigned to: ttn Open/Closed: Open Discussion Lock: Any ___ Details: In libguile/Makefile.am, the awk script guile-func-name-check is not being applied to pairs.c and memoize.c because those files are not derivable from the *DOT_DOC_FILES variables. This incomplete coverage ensures ignorance of (possible, future) func-name bugs there, which is undesirable. Running the check manually on those files produces spurious warnings (false positives), which is probably one reason why they were omitted in the first place. There are some related infelicities surrounding this situation: 1/ The awk script is run in the .c.doc pattern rule. Is that really necessary? It's a static check -- why not move it some dedicated target, like make function-name-check, that can be called less frequently (by maintainers)? See 3/ below. 2/ The long lists of mostly-redundant filenames is bug-prone. Better to restructure the groupings additively and make use of Automake support for $(VAR:OLD=NEW) syntax. 3/ It's awk. That is an affront to my scheming sensibilities. The doc extraction/processing flow tail already uses Scheme, why not the nose, as well?! ___ Reply to this item at: http://savannah.gnu.org/bugs/?30167 ___ Messaggio inviato con/da Savannah http://savannah.gnu.org/
[bug #30167] libguile/Makefile.am ugly
Update of bug #30167 (project guile): Summary: func-name (#define FUNC_NAME) check not applied fully = libguile/Makefile.am ugly ___ Follow-up Comment #1: Actually, both those files are indeed checked, so this is really a non-bug! (Nice mini-rant there, however...) Changing the title. ___ Reply to this item at: http://savannah.gnu.org/bugs/?30167 ___ Messaggio inviato con/da Savannah http://savannah.gnu.org/
Re: make-glil-local ?
() l...@gnu.org (Ludovic Courtès) () Mon, 01 Mar 2010 00:54:05 +0100 Is the warning correct? Of course it is! :-) I don't understand the question or the answer. (That is, what does correct mean?) Does this mean i'm not being cavalier in the right way? thi
Re: make-glil-local ?
() Neil Jerram n...@ossau.uklinux.net () Mon, 01 Mar 2010 19:28:07 + I'm sorry, I should have been clearer. correct would mean that the bug, and hence the fix needed, is in the code that the warning is pointing to. As opposed to the warning-generation code itself being bugged. OK, that's what i suspected you meant. Does this mean i'm not being cavalier in the right way? No :-) It means I wasn't clear enough! Thanks for explaining. :-) thi
make-glil-local ?
There was a warning in about possibly undefined `make-glil-local' in module/language/glil/decompile-assembly.scm and indeed i can't find that symbol anywhere... (This is from a make clean ; make, but i unfortunately deleted the *Compilation* buffer.) thi
libguile/read.c warning
../../GG/libguile/read.c: In function 'scm_read_expression': ../../GG/libguile/read.c:893: warning: 'charname' may be used uninitialized in this function
[PATCH] Use `mkstemp' instead of `mktemp'.
From 030349a79946f992eb2bd58653c39321e9794e95 Mon Sep 17 00:00:00 2001 From: Thien-Thi Nguyen t...@gnuvola.org Date: Wed, 13 Jan 2010 09:49:44 +0100 Subject: [PATCH] Use `mkstemp' instead of `mktemp'. * test-suite/standalone/test-unwind.c (check_ports): Use `mkstemp' instead of `mktemp'. Signed-off-by: Thien-Thi Nguyen t...@gnuvola.org --- According to mktemp(3): BUGS Never use mktemp(). Some implementations follow 4.3BSD and replace XX by the current process ID and a single letter, so that at most 26 different names can be returned. Since on the one hand the names are easy to guess, and on the other hand there is a race between test‐ ing whether the name exists and opening the file, every use of mktemp() is a security risk. The race is avoided by mkstemp(3). test-suite/standalone/test-unwind.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/test-suite/standalone/test-unwind.c b/test-suite/standalone/test-unwind.c index f9820cc..f333c8c 100644 --- a/test-suite/standalone/test-unwind.c +++ b/test-suite/standalone/test-unwind.c @@ -210,7 +210,9 @@ check_ports () strcpy (filename, tmpdir); strcat (filename, FILENAME_TEMPLATE); - if (mktemp (filename) == NULL) + /* Sanity check: Make sure that `filename' is actually writeable. + We used to use mktemp(3), but that is now considered a security risk. */ + if (0 mkstemp (filename)) exit (1); scm_dynwind_begin (0); -- 1.6.3.2
Re: [PATCH] Fix bug: Init auto var to unrandomize `stack_depth' rv.
() l...@gnu.org (Ludovic Courtès) () Wed, 13 Jan 2010 11:02:47 +0100 I would advise adding explanatory comments in the code, rather than in the log. Good point. Will keep it in mind. thi
Re: [PATCH] Update configure script hints wrt precious env vars.
() Andy Wingo wi...@pobox.com () Wed, 13 Jan 2010 20:52:08 +0100 I figured out how to use shell-command-on-region, M-|, so I don't care any more about whether there's comments before or after, though Ludovic is probably right about where they should go. So submit as you like. See also `gnus-summary-pipe-message'. thi
Re: [PATCH] Declare `GC_dump' ourselves if gc/gc.h doesn't.
() l...@gnu.org (Ludovic Courtès) () Tue, 12 Jan 2010 18:19:44 +0100 | dnl See note for PKG_CHECK_MODULES in aclocal.m4. | PKG_PROG_PKG_CONFIG | if test $BDW_GC_CFLAGS || test $BDW_GC_LIBS ; then : | dnl We don't need to declare those env vars precious; | dnl PKG_CHECK_MODULES does that. | else | PKG_CHECK_MODULES([BDW_GC], [bdw-gc]) | fi This patch shouldn’t be necessary since it duplicates what ‘PKG_CHECK_MODULES’ does. Not exactly. If there is no bdw-gc.pc on the system (as is the case here on a Debian Etch installation), PKG_CHECK_MODULES dies, and so does the configure script. The original README recommends in such case to munge three variables. Two of them are valid: BDW_GC_CFLAGS and BDW_GC_LIBS. The other (PKG_CONFIG) is bogus because munging it interferes with make installcheck. ... without reading ‘README’, so you basically shoot yourself in the foot and there’s not much we can do. :-) I don't know where you got that idea. Here's what actually happened: I read the README, applied the bogus advice, noticed the breakage, and then worked on the patch so that the now-updated README gives good advice, supported by the now-updated configure script. Lastly, i posted the patch for review. There IS something you can do: take a stand against pkg-config and DTRT (the Autoconf Way). I know there are other packages that are heavily reliant on pkg-config, but Guile doesn't seem to be one of them. You can do this by helping identify what are the features of libgc (whatever version) that Guile requires. With that info, it would not be hard to write a test for the configure script. So, please help answer that question (if you can). thi
Re: [PATCH] Update configure script hints wrt precious env vars.
() Andy Wingo wi...@pobox.com () Sat, 09 Jan 2010 23:31:55 +0100 .pc file, you can work around this by setting some environment -variables before running ./configure: +as part of the configure command-line: Can you fix this one and resend? Yes, if you can tell me what's wrong w/ the above. thi
[PATCH] Fix bug: Init auto var to unrandomize `stack_depth' rv.
First patch to Guile 1.9!
I prepared the following with git format-patch -s, recopying the
Subject line, sans [PATCH] , and prefixing with a horizontal rule.
Is this ok? Do you prefer some other format? Most importantly:
Am i on the right path to regaining official repo write privs?
thi
___
Fix bug: Init auto var to unrandomize `stack_depth' rv.
* stacks.c (stack_depth): Init `n'.
Signed-off-by: Thien-Thi Nguyen t...@gnuvola.org
---
libguile/stacks.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libguile/stacks.c b/libguile/stacks.c
index 61b7be3..ce16063 100644
--- a/libguile/stacks.c
+++ b/libguile/stacks.c
@@ -66,7 +66,7 @@ static SCM stack_id_with_fp (SCM frame, SCM **fp);
static long
stack_depth (SCM frame, SCM *fp)
{
- long n;
+ long n = 0;
/* count frames, skipping boot frames */
for (; scm_is_true (frame) SCM_VM_FRAME_FP (frame) fp;
frame = scm_frame_previous (frame))
--
1.6.3.2
[PATCH] Update configure script hints wrt precious env vars.
Personally, i dislike environment variable dependence. Maybe that's exposure to lexical binding poisoning my tastes... In any case, (info (autoconf) Defining Variables) has more info. thi _ From 7a7b846cc2eb1f6aadfb06ccb445642f2bc2dfa7 Mon Sep 17 00:00:00 2001 From: Thien-Thi Nguyen t...@gnuvola.org Date: Sat, 9 Jan 2010 10:07:48 +0100 Subject: [PATCH] Update configure script hints wrt precious env vars. * README: Don't suggest setting vars before running configure. Instead, suggest specifying them on the configure command-line. Signed-off-by: Thien-Thi Nguyen t...@gnuvola.org --- README | 19 +++ 1 files changed, 11 insertions(+), 8 deletions(-) diff --git a/README b/README index 5669ce8..e799495 100644 --- a/README +++ b/README @@ -50,16 +50,19 @@ names (where that is supported), makes it impossible to later move the built executables and libraries to an installation location other than the one that was specified at build time. -Another possible approach is to set CPPFLAGS and LDFLAGS before -running configure, so that they include -I options for all the +Another possible approach is to set CPPFLAGS and LDFLAGS on the +configure command-line, so that they include -I options for all the non-standard places where you have installed header files and -L options for all the non-standard places where you have installed libraries. This will allow configure and make to find those headers -and libraries during the build. The locations found will not be -hardcoded into the build executables and libraries, so with this -approach you will probably also need to set LD_LIBRARY_PATH -correspondingly, to allow Guile to find the necessary libraries again -at runtime. +and libraries during the build. E.g.: + + ../configure [...] CPPFLAGS='-I/my/include' LDFLAGS='-L/my/lib' + +The locations found will not be hardcoded into the build executables and +libraries, so with this approach you will probably also need to set +LD_LIBRARY_PATH correspondingly, to allow Guile to find the necessary +libraries again at runtime. Required External Packages @@ -94,7 +97,7 @@ Guile requires the following external packages: compile and link options for libgc. If you don't have pkg-config installed, or you have a version of libgc that doesn't provide a .pc file, you can work around this by setting some environment -variables before running ./configure: +as part of the configure command-line: - PKG_CONFIG=true -- 1.6.3.2
[PATCH] Add cast in `make_vm' to silence compiler warning.
As advertized... thi ___ From e08a92c5f21bab837ab051f5f1866cd066938262 Mon Sep 17 00:00:00 2001 From: Thien-Thi Nguyen t...@gnuvola.org Date: Sat, 9 Jan 2010 15:05:34 +0100 Subject: [PATCH] Add cast in `make_vm' to silence compiler warning. * libguile/vm.c (make_vm): Add cast for .stack_base assignment. Signed-off-by: Thien-Thi Nguyen t...@gnuvola.org --- libguile/vm.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libguile/vm.c b/libguile/vm.c index 0da915b..9f4a2d8 100644 --- a/libguile/vm.c +++ b/libguile/vm.c @@ -346,8 +346,8 @@ make_vm (void) vp-stack_size = VM_DEFAULT_STACK_SIZE; #ifdef VM_ENABLE_PRECISE_STACK_GC_SCAN - vp-stack_base = GC_generic_malloc (vp-stack_size * sizeof (SCM), - vm_stack_gc_kind); + vp-stack_base = (SCM *) +GC_generic_malloc (vp-stack_size * sizeof (SCM), vm_stack_gc_kind); /* Keep a pointer to VP so that `vm_stack_mark ()' can know what the stack top is. */ -- 1.6.3.2
[PATCH] Fix bug: Don't clobber `PKG_CONFIG' when overriding pkg-config search for bdw-gw.
`PKG_CONFIG' is AC_SUBSTed into one of the make installcheck tests, so clobbering it results in make installcheck failure. With this change (and building upon previously submitted patches), i can: $ .../configure -C \ --with-threads \ --prefix /tmp/a/b/z \ BDW_GC_LIBS='-lgc' \ LDFLAGS='-L/home/ttn/local/lib' $ make all check install installcheck to an empty /tmp/a/b/z directory on a Debian Etch Sempron (~35 minutes). Moving right along! thi _ From d6d765a2fcb0354146be6492a1212d5ad45fa385 Mon Sep 17 00:00:00 2001 From: Thien-Thi Nguyen t...@gnuvola.org Date: Sat, 9 Jan 2010 22:40:10 +0100 Subject: [PATCH] Fix bug: Don't clobber `PKG_CONFIG' when overriding pkg-config search for bdw-gw. * configure.ac (PKG_PROG_PKG_CONFIG): New top-level call. (PKG_CHECK_MODULES): Call only if both vars `BDW_GC_FLAGS' and `BDW_GC_LIBS' have no, or empty, value. * README: Remove bogus advice to specify PKG_CONFIG=true. Signed-off-by: Thien-Thi Nguyen t...@gnuvola.org --- README |3 --- configure.ac |9 - 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/README b/README index e799495..55bfad2 100644 --- a/README +++ b/README @@ -99,10 +99,7 @@ Guile requires the following external packages: .pc file, you can work around this by setting some environment as part of the configure command-line: -- PKG_CONFIG=true - - BDW_GC_CFLAGS=compile flags for picking up libgc headers - - BDW_GC_LIBS=linker flags for picking up the libgc library diff --git a/configure.ac b/configure.ac index 78c6418..20e2d62 100644 --- a/configure.ac +++ b/configure.ac @@ -1222,7 +1222,14 @@ main () # Boehm's GC library # # -PKG_CHECK_MODULES([BDW_GC], [bdw-gc]) +dnl See note for PKG_CHECK_MODULES in aclocal.m4. +PKG_PROG_PKG_CONFIG +if test $BDW_GC_CFLAGS || test $BDW_GC_LIBS ; then : + dnl We don't need to declare those env vars precious; + dnl PKG_CHECK_MODULES does that. +else + PKG_CHECK_MODULES([BDW_GC], [bdw-gc]) +fi CFLAGS=$BDW_GC_CFLAGS $CFLAGS LIBS=$BDW_GC_LIBS $LIBS -- 1.6.3.2
Re: Guile 1.9: bug in load
() Andy Wingo wi...@pobox.com () Mon, 16 Nov 2009 20:23:07 +0100 However the use case is important. We need to implement a (current-file) macro, I think, which should allow for file-relative loads. Is `current-load-port' still around for official Guile? If so, (define (current-file) (port-filename (current-load-port))) might be sufficient. thi
Re: guile 1.9.0 scm_read_hash_extend gc trouble
() Bill Schottstaedt b...@ccrma.stanford.edu
() Sun, 21 Jun 2009 05:10:09 -0700
code to implement #|..|# block comment processing triggers either a
glibc memory complaint or a segfault.
FWIW, below is the implementation from Guile 1.4.1.118 (not yet released).
It handles nesting (per R6RS, i believe) and a weird lookahead case.
thi
_
/* Skip #|...|# block comments. */
static void
skip_hashpipe_block_comment (SCM port)
{
#define FUNC_NAME s_scm_read
int c;
bool pipep = false;
int oline = SCM_LINUM (port);
int ocol = SCM_COL (port);
for (;;)
{
if (EOF == (c = GETC ()))
toosoon:
{
char buf[149];
snprintf (buf, 149, %s\n%s:%d:%d: (starting here),
unterminated `#| ... |#' comment,
c_port_filename (port),
1 + oline, ocol - 1);
BADNESS (0, buf);
}
if (pipep '#' == c)
return;
/* Handle nested comments. */
retry:
if ('#' == c)
{
if (EOF == (c = GETC ()))
goto toosoon;
if ('|' == c)
{
skip_hashpipe_block_comment (port);
pipep = false;
}
else
/* Don't get fooled by ##|...|# (ugh). */
goto retry;
}
pipep = ('|' == c);
}
#undef FUNC_NAME
}
Re: string-ci* oddity
FYI, below is the code that all ci comparison
funcs will be using in the next Guile 1.4.x release.
This means, for example:
(char-ci? #\a #\_) = #f.
thi
___
// libguile/chars.c
#define ISLOWER(c) (islower (c) ? (1 + c - 'a') : 0)
#define ISUPPER(c) (isupper (c) ? (1 + c - 'A') : 0)
static int
ccmp_ci (int x, int y)
{
int lx, ux = 0, ly, uy = 0, rv;
rv = ((! ((lx = ISLOWER (x)) || (ux = ISUPPER (x
||
(! ((ly = ISLOWER (y)) || (uy = ISUPPER (y)
/* One or both do not satisfy `isalpha'; subtract directly. */
? (x - y)
/* Both satisfy `isalpha'; subtract in one domain or another. */
: (lx
? (lx - (ly
? ly
: uy))
: (ux - (uy
? uy
: ly)));
return !rv
? 0
: (GOOD (rv)
? 1
: -1);
}
Re: string-ci* oddity
() Bill Schottstaedt b...@ccrma.stanford.edu () Fri, 19 Dec 2008 06:55:21 -0800 Why do both Guile and Gauche give this result in string-ci? (and the other string-ci functions similarly): The odd chars are ASCII 91 to 96: ASCII 91-96 lie between the two ranges A-Z and a-z. One procedure smashes case up and the other down. Smashing happens unconditionally. (define (my-char-ci? p q) ( (down p)) (down q)) Another more complicated (but arguably more correct) approach would be to determine if one/both of the args are not smashable, and entirely avoid smashing in that case. Something like: (define (smashable? c) (or (= #\a c #\z) (= #\A c #\Z))) (define (my-char-ci? p q) (if (and (smashable? p) (smashable? q)) ( (down p) (down q)) ( p q))) Pseudoscheme (numeric operators don't actually take chars), but you get the idea. thi
[patch] maintain output column
before, we see: (guile-user) (port-column (current-output-port)) 13 after, we see: (guile-user) (port-column (current-output-port)) 0 here is the ChangeLog entry for guile 1.4.x: 2007-11-13 Thien-Thi Nguyen [EMAIL PROTECTED] * running-repls.scm (scm-style-repl consume-trailing-whitespace): On #\newline, zero the output port's column. i'm sure you can figure out where this would fit for other versions. thi --- running-repls.scm 12 Sep 2007 12:50:46 - 1.22 +++ running-repls.scm 13 Nov 2007 14:12:55 - 1.23 @@ -287,6 +287,9 @@ (read-char) (consume-trailing-whitespace)) ((char=? ch #\newline) + ;; Conspire w/ the typical user interface (ok, let's just be frank: + ;; Emacs' comint.el or derivative) to keep things straight. + (set-port-column! (current-output-port) 0) (read-char) (define (-read) ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: [bug #20056] guile 1.8.1 regular expressions die on #nul (character zero) in operand
() Gregory Marton [EMAIL PROTECTED] () Sun, 03 Jun 2007 01:29:35 + This used to work in guile 1.3.4 but I haven't checked the versions in between. data point: guile (version) 1.4.1.107.9.0.7 guile (regexp-exec (make-regexp .) (string #\nul)) #f thi ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: guile-www 1.1.1 2.16 problems under guile 1.8.
() [EMAIL PROTECTED] (Ludovic Courtès) () Fri, 11 May 2007 09:16:31 +0200 So your fix seems reasonable, _provided_ `guile-www' doesn't rely on string mutations and interactions between substrings and their parent string. the easy way is to use configure script option --disable-shsub. i have updated the README to mention this for the next release (2.19), like so: You can use the configure script option `--disable-shsub' to explicitly build a version where `make-shared-substring' is replaced w/ simply `substring'. By default, configure arranges for the replacement only if it can't detect that your Guile has `make-shared-substring'. if the configure script is NOT detecting missing `make-shared-substring', then that's a bug -- please post the output of the ./configure run (w/o the `--disable-shsub' option). Maybe you could provide him with a patch allowing `guile-www' to be used with both Guile versions? this should likewise be handled automatically by configure (if not, that's a bug). in the configure run output, there should be something like acts like (ice-9 optargs-kw) ...yes, and the installation script module-install will read `need_optargs_kludge=no'. improvements to the detection routines welcome, in any case! thi ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: guile-www 1.1.1 2.16 problems under guile 1.8.
() [EMAIL PROTECTED] (Ludovic Courtès)
() Fri, 11 May 2007 16:43:09 +0200
Nice that it can detect such things and adapt!
that's the theory, anyway.
However, the `s/make-shared-substring/substring/' occurs only at
module-installation time, which precludes one from running the examples
from within the source directory.
good point. i hadn't thought of that.
Also, while `id.cgi' DTRT (except for `make-shared-substring') so
that it can be run from within the source directory, `you-are-here'
just makes plain `use-modules' that are bound to fail when invoked
from within the source directory.
true.
Maybe all the modules could be moved to a `www' subdir, and then
examples could be generated from `.in' files at configure-time that
start with something like:
${GUILE-guile} -L @top_srcdir@ ...
This way, `(use-modules (www ...))' would work fine.
What do you think?
i think the approach (or something like it) is sound. certainly making
the modules and examples usable pre-install is a worthy goal. thanks
for the suggestion.
thi
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Failure while building Guile-SDL 0.3.6.
() [EMAIL PROTECTED] (Ludovic Courtès) () Mon, 02 Apr 2007 10:02:33 +0200 [EMAIL PROTECTED] (r. clayton) writes: I was trying to build http://www.gnuvola.org/software/guile-sdl/ under guile-1.8 on a debian testing system (updated weekly) and ran into a problem: You should direct this question to its maintainer, Thien-Thi Nguyen [EMAIL PROTECTED] (not sure whether he reads this list). the error seemed to emanate from __scm.h. unfortunately, the grep output was not useful to figure out the nature of the problem. perhaps grep -C 10 will show more info. thi ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: guile 1.4 compilation error with gcc4
From: Aaron Voisine [EMAIL PROTECTED] Date: Fri, 19 Aug 2005 23:42:59 -0700 I'm trying to compile guile 1.4 with apple's gcc 4.0.0 (from xcode tools 2.2 preview 1) and I get the following compilation error: [...] ../libguile/alist.x:5: error: stray '##' in program looking at alist.x the syntax doesn't look like anything i've ever seen in kr (course I'm no expert). Any ideas? could you post the first few lines of alist.x? this file is generated at compile-time, and should not be in the distribution tarball -- if it is, that's probably (another) methodology bug. please also post the output of running the configure script, including some mention of what options you passed to it, etc. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Re: guile-www-2.9 (www cgi) Tests for query-string parsing
From: Alan Grover [EMAIL PROTECTED] Date: Mon, 11 Apr 2005 21:16:26 -0400 This script [...] thanks for posting this. i have touched it up a bit (attached), and used it to verify operation of recently installed changes to cgi.scm (available, along w/ other changes, from cvs). the not necessary comment reflects the thinking that introducing a var is a step away from the encapsulation work that cgi.scm needs prior to the next guile-www release. basically, it's ok to add procedures to the module's interface, but not so ok to add data structures. if possible, it's even better to avoid adding new interface elements altogether, instead extending the current procedures by adding optional args, so that they work w/ old code. more on this later... thi ag-check Description: Binary data ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: guile-www-2.9 (www cgi) names in query-string not url-decoded
From: Alan Grover [EMAIL PROTECTED] Date: Mon, 11 Apr 2005 19:10:24 -0400 cgi.scm 286c286 (and p (subs pair 0 p --- (and p (url-coding:decode (subs pair 0 p) thanks, installed. here is the ChangeLog entry i used: 2005-04-12 Alan Grover [EMAIL PROTECTED] (tiny change) * cgi.scm (parse-form): Fix omission bug: Also url-decode name in each name/value pair. feel free to include something along these lines for future patches. (also, i find diff -u output easier to evaluate.) thi ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile
Re: Bug in http module of guile-www
From: Robert Marlow [EMAIL PROTECTED] Date: Wed, 14 Jul 2004 15:38:17 +0800 I happened accross a bug in the HTTP module of guile-www which seemed to trigger when I visited a page which gave no headers and just whitespace in the body. In such a case the variable second of parse-status-line gets bound to #f which messes up the later make-shared-substrings which use it. in the status line (which has the form: VERSION CODE TEXT), i believe TEXT is optional, but i don't have the http spec (RFC 2616) handy to confirm this. if TEXT is actually optional, that indicates a bug in http.scm. if TEXT is required, that indicates a bug in the server's http implementation. note that the status line cannot be omitted altogether; the most minimal valid HTTP response a server can send is STATUS-LINE, CRLF, CRLF. you may wish to check the server response for conformance using a command like w3m -dump_head or similar. [patch] unfortunately the patch is incorrect because it allows the possibility to derive #f for CODE, which is illegal (CODE must be a 3-digit sequence like 404 or 200). assuming TEXT is indeed optional, i have changed `parse-status-line' (in cvs) to handle a missing TEXT component by returning the empty string. the proc now reads as follows: (define (parse-status-line statline) ;; Handle: VERSION CODE ;; as well as: VERSION CODE TEXT ;; For the former, use the null string for TEXT. (let* ((first (string-index statline #\space)) (second (string-index statline #\space (1+ first (list (make-shared-substring statline 0 first) (make-shared-substring statline (1+ first) (or second (string-length statline))) (if second (make-shared-substring statline (1+ second)) and will appear in guile-www 2.6 (to be released shortly). thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-guile
Re: substantial performance loss when running long-lived or computationally intensive programs
From: Michael A. Wells [EMAIL PROTECTED] Date: Mon, 05 May 2003 22:36:26 -0500 (CDT) Although this problem is present in Guile-1.6.4, the problem dates back to at least Guile 1.4. thanks for the bug report. i have started to clean up the 1.4.x branch (in cvs) as a result. the following functions have been fixed to date: scm_getcwd scm_readlink scm_getgroups scm_fill_sockaddr scm_regexp_exec scm_localtime scm_mktime scm_strftime i expect to finish the audit for the 1.4.1.97 release. please feel free to share further observations (in case i miss something). fyi, below is a simple program i use like so: guile -s stress.scm to eyeball-check for improved behavior (before/after changing the function in question). thi [cc trimmed] (define (report) (format #t ~A : ~A\n (strftime %Y-%m-%d %H:%M:%S (localtime (current-time))) (assq-ref (gc-stats) 'bytes-malloced))) ;;- (define stress getcwd) ;;- (define stress getgroups) ;;- (define (stress) ;;- ;; fports.c -- fport_close ;;- ;; ports.c -- scm_remove_from_port_table ;;- (with-output-to-string (lambda () ;;-(display 1234567890) ;;-(display 1234567890 ;;- (define *token* (make-regexp ^[A-Za-z0-9_]*)) ;;- ;;- (define (stress) ;;- ;; libguile/regex-posix.c -- scm_regexp_exec ;;- (regexp-exec *token* foo)) (define now (localtime (current-time))) (define (stress) (strftime %Y-%m-%d %H:%M:%S now)) (report) (let loop ((n 0)) (stress) (stress) (stress) (stress) (stress) (stress) (stress) (stress) (stress) (stress) (if (= 0 n) (begin (report) (loop 10)) (loop (1- n ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Fix for guile-www/cgi.scm (cgi:make-cookie)
From: Thamer Al-Harbash [EMAIL PROTECTED] Date: Thu, 28 Aug 2003 10:53:34 -0400 (EDT) This cgi::make-cookie breaks under guile-1.6 because it's using a #key and the (bound?) macro which seem to be no longer available or depreciated. Please accept my patch below which fixes the problem: sounds like guile-1.6 breaks guile-www, not the other way around. the solution to supporting both #foo and #:foo style taken for guile-1.4.x is to leave (ice-9 optargs) alone and introduce (ice-9 optargs-kw) which handles the #:foo style. perhaps this can be done for guile-1.6 so that it supports interoperability w/ old code. another idea if guile-1.6 has no desire to support #foo, is to provide (ice-9 optargs-kw) as a simple wrapper/alias for its changed (ice-9 optargs), at which point i would be happy to change guile-www to use (ice-9 optargs-kw) since that would be available in guile-1.4.x and 1.6. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Fix for guile-www/cgi.scm (cgi:make-cookie)
From: Thamer Al-Harbash [EMAIL PROTECTED] Date: Fri, 29 Aug 2003 09:00:57 -0400 (EDT) If this patch works fine with the optargs module why not use it for the sake of simplicity? Does my patch break something? the optargs module has an interface and a name. its interface was changed for guile-1.6 while its name remained the same. this broke old code (a mistake that is not too late to correct). your patch would reinforce the confusion. (btw, simplicity is a matter of how much you leave out of the picture. ;-) thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: FW: problem compiling guile on IA64 by Intel compiler
From: Sysoltsev, Vyatcheslav [EMAIL PROTECTED] Date: Wed, 9 Jul 2003 09:03:57 +0400 Starting from 8.0 Intel compiler defines GNUC macroses. that's very strange (IMHO). anyway, does the intel compiler have plans to support ia64 inline asm in the future? we would have to change the code again at that time. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: FW: problem compiling guile on IA64 by Intel compiler
From: Sysoltsev, Vyatcheslav [EMAIL PROTECTED] Date: Wed, 9 Jul 2003 13:49:20 +0400 No, Intel compiler doesn't plan to support ia64 asm inlines in foreseeable future. looking at __scm.h closely, i see the inline asm is just an implementation detail of SCM_FENCE, but SCM_FENCE is important anyway (having it be defined to be nothing is indeed dangerous). so the question becomes: does the intel compiler have an alternate method to guarantee ordering as required by SCM_FENCE? sorry for not asking this earlier, when you had said you would be willing to dig into the issue. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Autoconf macro GUILE_CHECK
From: Wolfgang Jaehrling [EMAIL PROTECTED] Date: Sun, 9 Mar 2003 17:30:25 +0100 made unambigous. In any case, _something_ is wrong here. :-) no worries, just figure out what is unambiguous and strive to emulate. i have seen in scripts: (exit #f). thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Antiquated (?) Gush fails to run
From: Michael Burschik [EMAIL PROTECTED] Date: Sat, 8 Mar 2003 08:31:05 +0100 I downloaded the archive gush-0.0b.tar.gz from http://www.glug.org/people/ttn/software/gush/ and built it successfully. Whenever I try to run gush, however, I get the following error: Initializing Guile... ERROR: In procedure set-current-module: ERROR: Wrong type argument in position 1 (expecting MODULEP): #module (guile) 8085990 I also noticed that none of the files in the tar archive were more recent than 1998, despite the fact that the changelog available at the above website lead me to believe otherwise. Any help appreciated. generally, the changelog is more live than the versioned tarballs. gush has suffered bit-rot compounded by underlying platform (guile) interface instability. the development sources are presently on an unconnected hard disk, else i'd offer to send them to you (or publish a snapshot). unfortunately, i don't expect to find time for gush for a few months at least. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: virtual host support
From: Jose Roberto B. de A. Monteiro [EMAIL PROTECTED] Date: Thu, 27 Feb 2003 13:50:39 -0300 In guile-www package: in http:request procedure, I am sending a patch to support virtual hosts retrieving. thanks for the patch. currently low-bandwidth, will probably take a look at it in a week or so, after having completed a (residential) move. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Failing test from r4rstest.scm
From: Neil Jerram [EMAIL PROTECTED] Date: 06 Jan 2003 19:55:26 + ... but it fails. Any idea why? what messages do you see? thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Guile and readline on MacOS X
From: Aurelien Chanudet [EMAIL PROTECTED] Date: Sat, 28 Dec 2002 16:06:02 +0100 Would anyone be interested in a patch ? if the patch is small, post it to [EMAIL PROTECTED] thanks, thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: [PATCH] Some fixes to doc/ref/scheme-data.texi
From: Stephen Compall [EMAIL PROTECTED] Date: Sat, 26 Oct 2002 16:11:41 -0500 2002-10-26 Stephen Compall [EMAIL PROTECTED] * scheme-data.texi: Addition and change of many Texinfo tags, particularly usage of @var and @samp, as well as reformatting of some lists into tables and usage of @result. Notes about some things I didn't understand, as well as a missing section on non-control characters. http://csserver.evansville.edu/~sc87/scheme-data-1S11.patch the changelog entry neglects to mention some incorrect replacements of iff w/ if. the former is a notational shorthand for if and only if (see node Manual Conventions). could you correct these and post another patch? thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Updated [PATCH] Some fixes to doc/ref/scheme-data.texi
From: Stephen Compall [EMAIL PROTECTED] Date: Sun, 27 Oct 2002 19:48:53 -0600 Have done. /me foolishly overlooked (guile)Manual Conventions, and drew mental connection to many typos of if.? :-S no worries. http://csserver.evansville.edu/~sc87/scheme-data-2S11.patch thanks. looks like it's time for me to re-read the texinfo manual -- i didn't realize there was @math and @acronym. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: possible bug in srfi-19 implementation (fix included)
From: [EMAIL PROTECTED] Date: Fri, 27 Sep 2002 14:03:19 +0200 (define (mydatetoweeknumber dt) [...]) Is my solution acceptable? If not, is there anyone who can implement a better solution? looks like your solution codifies ISO-8601, but srfi-19 does not specify ISO-8601. if it is possible to implement a date-week-number-ISO-8601 using srfi-19 date-week-number (perhaps by providing an appropriate second arg to date-week-number), it would be good to include that as an example in the documentation. would you like to try this approach? this is a separate issue from whether or not guile's (srfi srfi-19) date-week-number implementation fulfills the srfi-19 specification. i see there is no test for that in test-suite/tests/srfi-19.test. would you like to write one? thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Guile 1.4.1 w/ guile-oops 1.0.2
From: Michael Carmack [EMAIL PROTECTED]
Date: Fri, 6 Sep 2002 08:21:18 +
Is guile-oops/1.0.2 not intended to be used with guile/1.4.1?
more like guile-snarf invocation changing should be considered a bug,
especially in light of 1.4.x goal of compatibility (mea culpa)! i've
since reverted the behavior for 1.4.2, but that's not available yet.
1.4.1.84, a snapshot precursor, is available under:
http://www.glug.org/tmp/2002-09/
if you are building guile-1.4.1 from source, you can replace
guile-snarf.in (note the .in extension) w/ the file appended below.
thi
___
#!/bin/sh
# Extract the initialization actions from source files.
#
# Copyright (C) 1996, 97, 98, 99, 2000, 2001, 2002 Free Software Foundation, Inc.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this software; see the file COPYING. If not, write to
# the Free Software Foundation, Inc., 59 Temple Place, Suite 330,
# Boston, MA 02111-1307 USA
# Commentary:
# Usage: guile-snarf --help
# Usage: guile-snarf --version
#
# Usage: guile-snarf [-o OUTFILE] [CPP-ARGS ...]
#
# Process CPP-ARGS using the C pre-processor and some other programs.
# Write output to a file named OUTFILE or to the standard output when no
# OUTFILE has been specified or when OUTFILE is -. CPP-ARGS should
# include an input filename.
#
# If there are errors during processing, delete OUTFILE and exit with
# non-zero status.
#
# During snarfing, the pre-processor macro SCM_MAGIC_SNARFER is
# defined.
#
# If env var CPP is set, use its value instead of the C pre-processor
# determined at Guile configure-time: @CPP@.
# Code:
## support
do_the_snarf () # writes stdout
{
${cpp} -DSCM_MAGIC_SNARFER $@ ${temp} cpp_ok_p=true
sed -e '/^ *SCM__I/!d' -e 's/^ *SCM__I//' -e 's/ *SCM__D.*$//' ${temp}
}
## main
# process command line
if [ x$1 = x--help ] ; then
@AWK@ '/^#.Commentary:/,/^#.Code:/' $0 | grep -v Code: \
| sed -e 1,2d -e 's/^. *//g'
exit 0
fi
if [ x$1 = x--version ] ; then
echo guile-snarf @VERSION@
exit 0
fi
if [ x$1 = x-o ]
then outfile=$2 ; shift ; shift
else outfile=-
fi
# set vars and handler -- handle CPP override
cpp_ok_p=false
temp=/tmp/snarf.$$
if [ x$CPP = x ] ; then cpp=@CPP@ ; else cpp=$CPP ; fi
trap rm -f $temp 0 1 2 15
if [ ! $outfile = - ]; then
do_the_snarf $@ $outfile
else
do_the_snarf $@
fi
# zonk outfile if errors occurred
if $cpp_ok_p ; then
exit 0
else
[ ! $outfile = - ] rm -f $outfile
exit 1
fi
# guile-snarf ends here
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
Re: open-output-pipe problem
From: Thien-Thi Nguyen [EMAIL PROTECTED]
Date: Wed, 07 Aug 2002 20:20:48 -0700
i have experimented w/ back-porting the new popen.scm (including
associated support in libguile) w/o success [...]
turns out i was laboring under the classic stupidity of forgetting to
unpack an SCM... live and learn. in any case, please find below a
uuencoded tarball containing
libguile/ioext.h
libguile/ioext.c
ice-9/popen.scm
that you should be able to able to unpack in the guile-1.4.1 top-level
directory. as you may notice, popen.scm `open-process' now closes file
descriptors instead of ports, following the change in HEAD. however,
the implementation is more straightforward than in HEAD, w/ only one
addition to libguile (`scm_close_all_fdes_except' and associated scheme
binding). you might notice other changes to popen.scm; those are
related to the documentation methodology and are not relevant to its
operation.
please rebuild and let me know of any problems.
thi
___
begin 644 popen-fix.tar.gz
M'XL(`+04ST``^P\:7/;1I;Y*M7\B(Y:Y,.)%/RM;$L)[1$V=K1M225C,MQ
M84P((`2X`BM:X^-_W'7T!/3/5O8JLQ(9!+I?O_OJ!I-X#V-$_DHSN3G
MB?\X4_XM'9;K6=/GOS0:K5VGS]MN?_Y\GX\?/?V@]?[KWY%GKV/=71B_
M]_A9ZP?1^C.0J7^F11GD0OQ0ENG:7]_S_Z?1PXS;W.;Q]:@4C.FV/WY
MYZ_GU?Y_3WW^EOS][8@\$1G_WQ'$NIAE43D+BF.LVDZ#,HX2SUQDH8[
MF^(A_?ZH[@0DSR[SH.Q@,L()Q5JTKZXS:8B#%*1RV%E'D\F)92Q*4(TNC
M+!?C;!A'MP@'[@%\F8MR)$4I\W$ALHB^O#F_$F]D*O,@$9?301*'XC0.95I(
M$#2*8R:$8$!RL0KQ?2%C)Z+YD7\%WL0*0:`0EXIF+;(*CF@@F2]%
M$I1V[IZ+5E#$:T_B;``DC@`I$S(D$0,IIH6,IHF'(P^/VD__;BJB_:
MY^_$[^UNMWW?[/@\M1!D_EC610\7B2Q``9,F#M+P%GB$LT[W\U,:;\^
M.3WIOT,BCD_ZYYU3QQ?=$5;7+:[_9/#J]-V5UQ=2\OIT=(7H2T9((8`U/
M(Q(+\THRR!.DWX.Y!D`=@E0S$*;B1(-)3Q#`6B!#TZVYI$5N3++TF,F$P
M,\J2L'(B0AE3B\N'QWOX#Z)1)J5GICE,2A.F=TE8M9-3SS]6?0E,$^*
MRR0(I2=Z4P3P^'+1/`Z*TH?-86K;W=W=WMWMY^*JUU;$M@L@JYC(,`8R
MY.=03ACXNJ7%-;`#=`-T-RY091`0C,8#F,`*!`XQE^.@74I#EEY8G+
M`MB:R`#$`(/7)V=JS28L(*AXJF?BB$PLB=-/S'Z`U\'9#?,J,S4GGD
M:T'RU!]A],0S%D#*EL$@D1Y+9)@!AL!R,?$1R81V^@K34GE\4T*6.0
MHIV*,$'%PPQLA0SQ#DW84?J4(S^8'6`L#CS``]B19J#WM[@B6%B(!@:4!V$(
M'^5(2#=B,LBZ6$V!#@I8!:7%=NU3#2DCK(96%P.PV^)`9I2K)_9EP.XLC2
M0LQQK\XF)*ZCLFW?BL'EF`43-#04/2Y!:9BD($*45C).7:FUHVFP5BQ
MA2V)G#'8*DXGL%C169*\II0MFIC%V\B((VD,O3-0N]R=D#V7A*ZYS$8
MR'\DNTHO*02B[;#;A7X!,H`=/0!B9LL'@+7\!L.)7#CM+*2(H.!#URRD9
M6S$-1QQIT)62(7@$?`RI`;BY1):215L1!F`)#/`.!8RTPQDCT2@PV)5;08
M!Y)92I:O`1A`#3DW4`5`$,QM)8CS:([HOCYR6S.YE;6VG%06;$QAG$
M046F*CE%`$/'S[:W-S\_Q_+T[#9`H,?UF4PSC;;VRM[82G3GZ13C6TM
MS3)\K)8\0PL9[CB4;1NWC2-HQ6/PE0KYH621!X+EADV7EBD?H7M)K`KOL
ML?8)*V9S6EV9^S(*TS)!9L*]:@C\;;]6\?O];L0U/RW%:[CTL1VF8)T*^.O
MSD]Z_:/*`-,H9#T+L'9[Y1YWCD_..:(@?2[#PH0@T[)H?_9$UO_@OV
MS;T?MSSQF/[#:.A\@!+T#P$+P3.^N,X%/PF7'5YA9JTM`I^EM;B4
MK2ZL)E!4`7CMO`3^O4FR+_@U#E[$OH.\.?@L,HX$6B]'!G_2+4(`RJUH
M%F,X%\P]MV94E1`Y\NNCL8QTK_,+4,F_D4Z(#PGW/H;F26XQQ,8LN)29
M3))]=I1@9-*S`']X-\B$'KJNHY.!601Z'D^H,I`HZ9(K`7S*WJ]+XUP
MFNR+;?C=#(MMQ%,^[`)7;/,=NCK\!RP`[(L$M8B$P@ZW`T81X3GYQ.E!\
MRR*'R@%Z?`XPSEH6'B3LSJJ-V2@IPJJD`VH%WN0%[':8J@30,U*D.K!#)
MW,$.8CK@7$+E-PV=_Y([9.N!.2@F09QCE2`QBMLJ^*B(50IPF!RP
MT\_5\A8B1+I`!3`(:C4N2?B+LYQQ'4BLD$4]J2HQ53@!'#J\*S6.2$+^9O
MA550F47;V`C4#C?QQ3-\@6($`$^E@:-)^K5$@UU$I6:L-G!!:]R+YCM;
MSU[(`/('\7QU?FA?]X^ZXC7^8%-K^`I5/V_7$?KI`-XF$(2.WK^R)W'X%
MZF%A^(NW0'U$Z$QD$]1/@+V^O@.WT/]UCX].6KW.W[W0OD]3.I%8]=3_D6!
M:(,.U\T.SNQ6GG_$W_K6@XHRI@*T#W/'142`T-1-05(`U/P)AH),#W_KZ
M_.A2-,CFN0$\1)F(?/`#GVP09P@$ZQ1WUB\N3\\N+;E\TGG@$8I'ND_,K
M\LL*Q:.\N6QWPV%+5[O4ZW[T,%^*8#H[1/Y5'BU8%HB?OW]=71-O=JSWS
M4'HDPI(G+%D,ZG\C8_%*+P+T8V7!\Y:BJ.L#?`=DYO1[BCE$9\5*C!U4\_
M,3^_J-O*)9N$G5R^EF6HV+^O'A'03_\M2\^`3Q'J\0GA+KQ!0T1:B4
MY_VG#^(`DBR(7WA?ZR4C]NGO0Y(F0,!R'EC`]IKQZZ`DM/#61K9EU`!,Z
M@G+6_FO'AWJ[S,PQFVHP30,;64/,$5V;MV-`$BC9EO;LPW+4HA(MNY.`8\
MEBX$CUBO,0ZX)J7H-7O/WY`,3`/;ED%]?7)SZQ]Y:H//-Q@(NM*-CQ
MB89?@I^!J='%O_)H(99NQC$O0^#9L7H+@?)C+U)TWR.3B63.OAI%1=EO
MO_8[Y_WN.T#:FMH37L$6:Y`]X@EEO;3N9!KK3`#@FFMR#V_%6W-+%/
MY1X#*EO7,]/J\*[H(H84ZC!WF+=4F*52#@M5W$9!43)LEF6#+6(L
MQ^$(U'92;K\B=DPR2)T_)$^\)R;.'9;N.:3=;9'T';%\T%/2!A0?EOE)
M[#9K\[7-`)7M),EJEDU;2I40ED100@'OU#:M3Q4^,T3%(VB?60/PX0'GE,
MP@$6-QDD,FC+ZA\2#\5@@[+$*@?4;/;[E/QTX%^;DA)JM[J,\/_F@],,]8
MFX0SJ6*L*H:A]ENQUZ60HDD9Z0WFA7,!C_^PC(3`7\002#((/$[EMAIL PROTECTED]
MS1PX=6IL\K:])J4EV!:-D%WJF2AQY*5F@K)6U^G*OAF,'$!QX@R^%(\
M;37%+^)92[P@2`_%WKZFZR2%/$.TO(%SM-$C!J#!@0KDM7H%1IJ%E,N/\=
M1CV@WFZ6JQX=]K)01I:4KUJO?5BUJ?TOI`$6_?VFP@K\/)J@U5#\^\I0
M19:E8@%E)W)FF%:9TV1V;2@%=!$Q`SGJBB;#A-_35G,55B=%`]IZ$CT!
M3=T``6%?7LQ076;RP8V$(@OT96ITQOC33#YS^K%'-]P3`_04%35C9`-,/0
M?#(C;JQLBB!A!+CR3H)#[,=B%JZ,QD,,L9[`*BW-9@H+E`+F$C3`!^
M4F#R))[R%:WG!G(9$R!?2IS5`BPH='(3N.#U-+E;)B5CZ%ERX+*457#D''
MLU9,8R'`@(^1+\`/0'/5/CHT*QY]`K=L0)@*(5Q/Z82B,W'._3@7:DT$
MCMPP@YI;=3P;7Q]5)K1^`KWH.)B9PZ2.VEC466W\TWC*0LHZ[A*)L)
M^7DBP9AO5/M(6T)6/_!F-9%T96.O[57K_J\^0MQN/J*VG`5-O;Q\FJ(G
M*ZB3JZM$UM.=24P(X[::%')2M#I[YD0+6G-D555^(2-!#GN4-G@./CC+5
MDBPR,0X^842KN@H$8I2MCC`2T4P0U[JWXN\'\@=J(@QD%,5A#$.IA]
M`03LWW:$7/APW5Y3$V)#OR]H\9'65CHVQ]FVGJK:\LJT-3P*53/GP35V
M7FU!F\I0%D604[\6@ZCBN8:+[AS,`$33
Re: open-output-pipe problem
From: Satoru Takabayashi [EMAIL PROTECTED] Date: Sat, 13 Jul 2002 22:56:57 +0900 I tried guile 1.4.1 and found a problem on open-output-pipe. hi, thanks for the bug report. i have reproduced the problem and noticed that it is gone in guile-HEAD, but have not yet figured out which of the (many) changes is responsible for the fixed behavior. i plan to devote some hours looking into this because it is an area of libguile i'd like to learn more about. will let you know what i find. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Latest guile reports version 1.4 which appears to break guile-xlib3.0 configure
From: David Hull [EMAIL PROTECTED] Date: Thu, 1 Aug 2002 12:53:32 -0700 I just downloaded what I thought was the latest version, which reports (version) as 1.4. The guile-xlib configure script checks for (string= (version) 1.4.1) and then reports that my guile is too old. did you build from source? which tarball? thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: guile-1.4.1: test failures under shared library, -O3
fyi, i've added this as: 1007-cc-optimizations-break-r4rs-test thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: [PATCH] lambda* fails with #:key and rest argument
From: Christopher Cramer [EMAIL PROTECTED] Date: Thu, 30 May 2002 13:44:11 -0500 Index: ice-9/optargs.scm thanks for the patch. i've applied it for 1.4.2. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: MacOS X
From: richmit [EMAIL PROTECTED] Date: Mon, 17 Jun 2002 23:12:11 -0500 After struggling for a few hours I have finally managed to get guile to build on MacOS X. In order to do this, I had to remove readline from my development system -- I don't know how to get guile to build without readline support. We are using readline 4.2. perhaps --disable-readline would be a useful configure option to add. I also had to use the following command line for configure to get a valid build environment: CPPFLAGS=-traditional-cpp CC=/usr/bin/gcc3 ./configure --prefix=/usr/local/ --disable-threads normally `--prefx=/usr/local' is the default and can be omitted. is this not the case on MacOS X? (or is the difference the extra / ?) During the compile, a few warnings came out: [bad decls] these should be cleaned up for sure. thanks for the tip. Will MacOS X be officially supported in the future? personally, i don't see the value of official support at this time in theory or in practice (guile maintainership is pretty losing, IMHO). by the same token (also personally), i'd like to see if i can munge guile to be as near hassle-free as possible on as many platforms as possible, to gain confidence in my own configury skills. bottom line: this will likely result in guile on MacOS X being supported by its users in some form or another (as it should be ;-). no worries, just keep the bug reports flowing... thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: (dynamic-link) ignores PREFIX/lib and $LD_LIBRARY_PATH
From: [EMAIL PROTECTED] (Paul Jarc) Date: Tue, 18 Jun 2002 12:02:21 -0400 I have guile 1.4.1 installed in an unusual place, so PREFIX/lib isn't in the usual search path for shared libraries. It seems guile should always search PREFIX/lib, preferably before the systemwide directories and after those listed in $LD_LIBRARY_PATH. (Actually, it should search all the -rpath directories that the binary was linked with, which should (and does) include PREFIX/lib.) When I evaluate (use-modules (ice-9 readline)), guile search only /lib when looking for libguilereadline.so (not even /usr/lib). If I set $LD_LIBRARY_PATH to include PREFIX/lib, then guile looks there first and finds it, but keeps looking anyway and still fails: access(/package/host/localhost/guile-1.4.1-1/lib/libguilereadline.so, R_OK) = 0 access(/lib/libguilereadline.so, R_OK) = -1 ENOENT (No such file or directory) open(/lib/libguilereadline.so, O_RDONLY) = -1 ENOENT (No such file or directory) yeah, 1.4.1 tries to follow the nascent conventions cobbled together in 1.6.x and HEAD, which require these kinds of env var weirdness. the fix is to install libguilereadline et al internally (under $pkglibdir) and reference them directly. personally, i use as ~/bin/guile for now (until 1.4.2 release): #!/bin/bash # (prefix is /tmp/a/b/c) export LD_LIBRARY_PATH=/tmp/a/b/c/lib:$LD_LIBRARY_PATH export PATH=/tmp/a/b/c/bin:$PATH exec guile $@ could you post platform info? thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: (dynamic-link) ignores PREFIX/lib and $LD_LIBRARY_PATH
From: [EMAIL PROTECTED] (Paul Jarc) Date: Tue, 18 Jun 2002 13:57:39 -0400 but it would still be nice if guile could tell libtool where to look for libguilereadline.la, since it's known to be in PREFIX/lib. yes. btw, another (smaller scope) fix would be to munge readline.scm `dynamic-link' call. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: inet_aton conflict
From: [EMAIL PROTECTED] Date: Sat, 25 May 2002 03:58:51 +0300 obvious enough. presuming you encountered this w/ guile-1.4, you should check out: ftp://ftp.gnu.org/gnu/guile/guile-1.4.1.tar.gz (it has this fix and other changes -- see NEWS). thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: regexp-exec fails for long strings
From: =?iso-8859-1?Q?Wolfgang_J=E4hrling?= [EMAIL PROTECTED] Date: Wed, 15 May 2002 08:04:20 +0200 AFAIK, the glibc-people are rewriting the regex code for 2.3, because the current implementation got unmaintainable and has various strange limitations. This could be one of those. that's good news (that i wouldn't have known w/o this tip -- thanks!). i suppose i could contribute this as a test case. i wonder what glibc testing framework is like. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: regexp-exec fails for long strings
From: Thien-Thi Nguyen [EMAIL PROTECTED] Date: Thu, 25 Apr 2002 16:29:40 -0700 i traced this to `regexec' (glibc 2.2.4) and stopped -- it's not a guile bug after all, as far as i could tell. (also, could not reproduce the behavior under FreeBSD 4.4-RELEASE.) probably time to apt-get update... this problem persists w/ glibc 2.2.5. hmmm thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: RedHat-7.3 gcc-2.95.3.2
thanks for the report. this will be fixed along w/ some other things in guile 1.4.1 release -- see guile web pages for details on how to get a cvs checkout (cvs module hack). i am curious: what is your use for guile? thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Compilation fix for guile 1.4
From: Davide Angelocola [EMAIL PROTECTED] Date: Fri, 3 May 2002 13:18:23 +0200 I've downloaded guile version 1.4 to learn on how to program in C under UNIX. However, when I try to compile it on my RedHat 7.2 machine I get an error in net_db.c line 85. Well, I've just put a comment at the beginning of line and all works fine now. thanks for trying out guile. the problem you report will be fixed in 1.4.1 and later versions. o add readline and history support this is already available, but the documentation doesn't tell you how to enable it (it's a documentation bug). for now, see NEWS for more info. o add a welcome message like this: guile v. [build info?] Copyright Type (help) for more information o add (copyright), (license) functions o the (help) output in one page o add a TODO file in the source dist (this can very useful for me) I hope that this email can be useful for you! it's useful to let us know what you want. now that you are learning to program, the next logical step (for both of us) is for you to learn how to implement these requirements either by writing new code or modifying existing code. i would suggest looking first at the latter class of changes since (you) going through that process would result in a patch that could be easily applied (by us). because the TODO file changes relatively rapidly, we publish it online, along w/ everything else. check out: http://www.glug.org/snap/workbook/tasks/TODO http://www.glug.org/snap/ http://www.glug.org/ what programming experience do you have presently? why do you want to program in C under UNIX? thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
install-data-local scheduling not guaranteed
in branch_release-1-6 ice-9/Makefile.am, we use `install-data-local' to install and-let*.scm. w/ automake 1.5 (no idea what was before), this frag is run before the rest of the install, and fails if there is no destination directory already set up. the failure is masked by the - action prefix, which is fine (considering the reason for using this mechanism in the first place -- slackful handling of sites where * is not a valid file name). automake documentation sez: Extending installation == It is possible to extend this mechanism by defining an `install-exec-local' or `install-data-local' target. If these targets exist, they will be run at `make install' time. These rules can do almost anything; care is required. Automake also supports two install hooks, `install-exec-hook' and `install-data-hook'. These hooks are run after all other install rules of the appropriate type, exec or data, have completed. So, for instance, it is possible to perform post-installation modifications using an install hook. so probably we should use `install-data-hook' instead. i'll test this and commit changes shortly, presuming all goes well. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Fix for 1001-local-eval-error-backtrace-segfaults - please review
From: Neil Jerram [EMAIL PROTECTED] Date: 02 May 2002 13:59:06 +0100 - SCM_SETCAR (SCM_CAR (env), scm_cons (n, SCM_CAR (SCM_CAR (env; The copy in scm_unmemocopy, which looks as though it might be intended to fix this problem [...] was this used previously? (i'm trying to crawl inside the head of whoever wrote it this way in the first place.) Fix isn't very elegant, though; is there a nicer way of doing this? both the old way and the new way involve mutating some nested list structure, so i'm guessing that doesn't play into elegance. i'm wondering what is it about this fix that makes it not very elegant? 2. Rerun of problem scenarios: cool. this touches upon the need to extend the testing framework to handle interactive cases. actually, i believe that's already possible w/ the current framework via (ice-9 expect); the limitation really is that all tests share an execution environment -- this is fine for the most part, but undesirable for this kind of bug. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
regexp-exec fails for long strings
well, good and bad news. the good news is that another guile project was recently added to the projects list. the bad news is that for www.gnu.org, template.scm now fails due to unfulfilled regexp matching. (this has resulted in an empty project page there.) below is a test case that demonstrates the problem. running pre-inst-guile -s on it shows three ok and three FAIL for both HEAD and branch_release-1-6. if someone can confirm similar behavior on another system (perhaps by varying the appended string length), i will add this to the bugs db. (i ask for this confirmation because my system's old sdrams are prone to mysterious failures, and i want to rule that out as a reason.) thi (use-modules (ice-9 regex)) (define ok section_nameProjects List/section_name) (define rx (make-regexp section_name(.*)/section_name)) (define (+space s n) (string-append s (make-string n #\space))) (define (test s) (format #t string-length ~A\t= ~A\n (string-length s) (if (regexp-exec rx s) ok FAIL))) ;; do it (test ok) ; ok (test (+space ok 11672)); ok (test (+space ok 11673)); ok (test (+space ok 11674)); FAIL (test (+space ok 11675)); FAIL (test (+space ok 11700)); FAIL ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: regexp-exec fails for long strings
From: [EMAIL PROTECTED] Date: Thu, 25 Apr 2002 23:47:13 +0200 | guile (test ok) | string-length 42 = ok | guile (test (+space ok 11672)) | string-length 11714 = ok | guile (test (+space ok 11673)) | string-length 11715 = ok | guile (test (+space ok 11674)) | string-length 11716 = FAIL | guile (test (+space ok 11675)) | string-length 11717 = FAIL | guile (test (+space ok 11700)) | string-length 11742 = FAIL | guile i traced this to `regexec' (glibc 2.2.4) and stopped -- it's not a guile bug after all, as far as i could tell. (also, could not reproduce the behavior under FreeBSD 4.4-RELEASE.) probably time to apt-get update... thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: guile-snarf writes to $srcdir, which is not kosher
From: Rob Browning [EMAIL PROTECTED] Date: Wed, 10 Apr 2002 16:10:56 -0500 I've been trying to make sure to migrate all my 1.6 patches to HEAD, but there are still some outstanding. Of course some of the lag is because I'm not sure we'll want to handle things the same in 1.8. hmmm, this is very different way of looking at things from what i would expect... i'm operating on the assumption that we want to look at things from long-term perspective first and foremost, and interpolate current decisions/activities from that. that is, figure out LATER and then figure out NOW as it relates to LATER, rather than the reverse. in practice, this means changing HEAD branch to conform to LATER first, and branch_release-1-6 to conform to NOW. to me this seems like less work. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: guile-snarf writes to $srcdir, which is not kosher
From: Rob Browning [EMAIL PROTECTED] Date: Tue, 23 Apr 2002 17:42:58 -0500 Depends on the problem. For example, the recent library name changes relating to libltdl/dlopen issues may or may not belong in HEAD, but they're critical for 1.6. the recent changes may or may not belong in HEAD but the questions i'm asking are: (1) what *does* belong in HEAD? (2) how does the 1.6 library handling relate to (1)? Since it's very likely we'll choose a different long-term solution for this problem, and we won't know until we have the discussion, in my judgement there was little point in trying to integrate the changes into HEAD right now. of course these things follow. i'm not questioning the consequence of the approach, but the wisdom of using that approach in the first place, which seems backwards and make-work-ful to me. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: guile-snarf writes to $srcdir, which is not kosher
From: Rob Browning [EMAIL PROTECTED] Date: Tue, 23 Apr 2002 18:09:04 -0500 Furthermore, as I've said several times before, this should give you a clue that saying things on mailing lists isn't as useful to other people understanding you, as writing them down somewhere under workbook/ and inviting review and refinement there. [...] what are the areas of divergence? why not add an item for each (as in port foo to HEAD) to TODO? this would help us understand things more precisely. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: guile-snarf writes to $srcdir, which is not kosher
From: Marius Vollmer [EMAIL PROTECTED]
Date: 08 Apr 2002 18:45:44 +0200
A VPATH build is when you compile in a directory other than the source
directory. This is useful when you want to compile a package for
different configurations but from a common source. The name stems
from the fact that it is implemented using the VPATH variable of make.
could you describe VPATH as configure in place, make from elsewhere?
or is configure done elsewhere also? i've heard the latter referred to
as srcdir!=builddir (and usually make is done where configure is).
if you remove cleaning you need to promote SCM_MAGIC_SNARFER to required
status and document accordingly.
It is already.
all i see is this:
During snarfing, the pre-processor macro @code{SCM_MAGIC_SNARFER} is
defined.
i'm assuming that whatever changes made to branch_release-1-6 that are
long-term applicable would be also made in HEAD roughly concurrently,
but i guess this is saved for later?
thi
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Badness with TODO at dist time
From: Marius Vollmer [EMAIL PROTECTED] Date: 08 Apr 2002 00:22:35 +0200 (One tempting thing is to not distribute TODO at all.) i wouldn't mind if we didn't distribute TODO. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: guile-snarf writes to $srcdir, which is not kosher
From: Marius Vollmer [EMAIL PROTECTED] Date: 08 Apr 2002 00:55:38 +0200 Sigh, I've seen this coming... guile-snarf writes its $cleanfile into the $srcdir, which is not a supported thing to do during a VPATH build. looks like some coding cowboy should've figured out what kind of builds are to be supported before doing this kind of thing. (sorry for that.) what is a VPATH build, specifically? what other kinds of builds are there? (This was uncovered by a simple make distcheck, which thankfully write-protects the source directory. I hope everybody uses make distcheck freely before checking in their changes, eh?) you can do more than hope: why not write down some good tips under workbook/build/ somewhere? [cleaning not required in the presence of SCM_MAGIC_SNARFER] if you remove cleaning you need to promote SCM_MAGIC_SNARFER to required status and document accordingly. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Guile fails tests on Tru64 4.0F
From: David C Sterratt [EMAIL PROTECTED] Date: Fri, 5 Apr 2002 12:55:24 +0100 $ ./autogen.sh . aclocal: configure.in: 167: macro `AM_PROG_LIBTOOL' not found in library I'm using autoconf version 2.53 and automake 1.4p5 Should I be using different versions? Or is there some environment variable I need to set? i would recommend using automake 1.5. for me, AM_PROG_LIBTOOL is defined in /usr/local/share/aclocal/libtool.m4. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: unhandled keywords to goops make should signal errors
From: Neil W. Van Dyke [EMAIL PROTECTED] Date: Thu, 28 Mar 2002 02:00:06 -0500 If I understand Bug 11 correctly, then it appears to be a very different problem than the one I report. what you request for consideration must surely have been considered before. if we figure out precisely how it is different and how it is the same, perhaps we can apply that understanding. because my personal coding has not yet advanced to using goops regularly, my conjecture from reading related material is that keyword handling in goops follows a non-blocking scheme reflecting its original design model. i imagine when i do finally get to designing classes and instantiating objects, i would view mixin techniques darkly if they were (in return) so opaque. perhaps i misunderstand the nature of keywords in goops and compare it against other keyword disciplines, fruitlessly. how would i tell? goops can be extended to do such error checking, in any case. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Guile fails tests on Tru64 4.0F
From: David C Sterratt [EMAIL PROTECTED] Date: Wed, 6 Mar 2002 14:57:11 + In libguile/scmconfig.h I see: /* Define if the system has the type `uintptr_t'. */ /* #undef HAVE_UINTPTR_T */ I can't find any references to SIZEOF_UINTPTR_T, UINTPTR_MAX, INTPTR_MAX and INTPTR_MIN this tells me the fundamental type SCM is implemented by unsigned long. i suspect there is a bug in srfi-4.c function `make_uvec'. could you: - make sure you have relatively recent guile-1.5.x (1.5.6 is fine) - rerun autogen.sh (if necessary), configure, and make - do make install somewhere (e.g., /tmp) - save the following to bug-1000.scm: (use-modules (srfi srfi-4)) (display (u8vector)) - run /tmp/bin/guile under gdb w/ command line: guile -s bug-1000.scm - set breakpoint at make_uvec and step through it - report your observations (see HACKING for some commands for your .gdbinit useful for displaying SCM values.) alternatively you can send me hardware to play w/ (haha just kidding). thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: failed backtrace
From: M Johnson [EMAIL PROTECTED] Date: Sat, 16 Feb 2002 13:50:42 -0500 [new test case triggering different symptoms] debug eval (the-environment) you like torturing guile don't you? I don't know if this helps or sends you off in another direction. i've recorded both test cases. we will probably want to address the original symptoms first, leaving the harden-guile-against-sadists task for later. (at some point bugs database will again be published; this bug is named 1001-local-eval-error-backtrace-segfaults.) thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Bug #1 - (debug-disable 'debug) has no effect ...
From: Neil Jerram [EMAIL PROTECTED] Date: 08 Mar 2002 23:53:35 + I'd say it's a bug, and that it would be better to squash it now than to support strange expectations through 1.6.x. it's also a bug in the sense that side-effects on load (except for `define') are usually considered antithetical to clean modular design, especially since the module system does not (and might never) support instantiable modules. this would be a good check to add to the linter. on the other hand, loading modules serves to extend the basic system in other ways (e.g., syntax), so it might seem natural in a similar fashion to piggyback turning on the debugging evaluator when loading (ice-9 debug). in the long run, the stability of a bad design rarely outweighs the temporary instability that changing it to a good design entails, in terms of both user and maintainer satisfaction. (however, there are always exceptions; see Unix. ;-) thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Guile fails tests on Tru64 4.0F
From: David C Sterratt [EMAIL PROTECTED] Date: Fri, 15 Feb 2002 14:42:44 + Running gcc -E tags.h shows that typedef scm_t_bits SCM; is the line included. ok, next we need to chase down the resolved C type for scm_t_bits, which depends on HAVE_UINTPTR_T. on a (32-bit) x86 box i see in libguile/__scm.h: #if SIZEOF_UINTPTR_T != 0 defined(UINTPTR_MAX) \ defined(INTPTR_MAX) \ defined(INTPTR_MIN) /* Used as SCM if available, so we bundle related attributes to avoid possible type incon[st][oi]n[ae]nce later. Word in tags.h. */ #define HAVE_UINTPTR_T 1 #endif what do you see? if HAVE_UINTPTR_T is 1 for you, what are the values of SIZEOF_UINTPTR_T, UINTPTR_MAX, INTPTR_MAX and INTPTR_MIN? (please cc bug-guile in reply for the archive.) thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: grammar fixes in boot-9.scm comments
From: Christopher Cramer [EMAIL PROTECTED] Date: Tue, 26 Feb 2002 00:26:24 -0600 There are two grammatical errors in the comments for resolve-interface in boot-9.scm. This is a patch for stable; it also applies to unstable. thanks. applied. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Goops docs paper formatting problems
From: Alex Stark [EMAIL PROTECTED] Date: Mon, 11 Feb 2002 15:53:36 -0500 The goops manual printed reasonably, whereas the goops-tutorial was junk. the tutorial is in the manual. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Guile fails tests on Tru64 4.0F
From: David C Sterratt [EMAIL PROTECTED]
Date: Mon, 11 Feb 2002 10:58:25 +
Thanks for you message. Here's what I see when using ./check-guile
--debug at the end:
[tests: srfi-19, srfi-4, time]
looks like two main problem areas: time and uniform vectors.
the first area is a legendary debugging quagmire (unless you are an l10n
guru), so i propose we focus on the second area's characteristic: all
failures involve some kind of memory allocation. this is not surprising
(although i can't remember why ;-)...
if you look how the fundamental type (SCM) is implemented (tags.h:63),
there are several cpp symbols that conditionalize it. could you
summarize those and their values? see top-level config.status, and also
try gcc -E to see what is really being passed to the compiler.
we need to check if the configuration values fulfill the constraints on
SCM implementation described in the comments in the {Architecture and
compiler properties} section of __scm.h, and base further debugging on
this.
at some point when we get back to the time problems, maybe i will have
read enough background to suggest a diagnostic.
thi
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
Re: GC loop
From: Neil Jerram [EMAIL PROTECTED] Date: 03 Feb 2002 13:44:29 + Using the current unstable CVS Guile... Running under gdb, type in the following: fwiw, i was able to reproduce the described behavior. feel free to add this to BUGS... thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: gsubr.c too many args error
From: Bill Schottstaedt [EMAIL PROTECTED] Date: Fri, 8 Feb 2002 03:51:54 -0800 Can I suggest a change in libguile/gsubr.c line 105 from: fputs (ERROR in scm_c_make_gsubr: too many args\n, stderr); to fprintf (stderr, ERROR in scm_c_make_gsubr: too many args (%d) to %s\n, req + opt + rst, name); this has been installed (all branches). thanks for the suggestion. however... Also is it really necessary to call exit after this error? w/o some coherent policy, this cannot be answered easily. i've added devel/policy/exceptions.text (HEAD branch) so that when we figure something out, we can record it there and clean up appropriately. my guess is that we will decide to restrict `exit' and `abort' to a small number of well-defined situations, and convert all other handling to use an internal throw of some sort. if you (or anyone else) would like to help systematize guile error handling, i'd be happy to do the exceptions.text scribe work, and integrate small patches. (please signal intent on guile-devel first, thanks.) thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: UINTPTR_MAX, INTPTR_MAX requirements
From: Dave Love [EMAIL PROTECTED] Date: 05 Feb 2002 16:21:32 + Don't the dependencies take care of CVS updates, as one would expect? If not, the ANON-CVS instructions should say so. actually, to avoid (a more fundamental kind of) confusion, auto* tools side-step explicit version control support entirely. note that grep CVS Makefile shows nothing that would indicate that make(1) should look in a directory's CVS subdir for branch info (or for anything else). this is with configure --enable-maintainer-mode, so probably a Makefile otherwise configured would be even less supportive. i will add this blurb to ANON-CVS. thanks for pointing this out. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Install failure - missing libs
From: Martin Grabmueller [EMAIL PROTECTED] Date: Mon, 4 Feb 2002 15:28:14 +0100 (MET) make maintainer-clean; cvs update; ./autogen.sh; ./configure --enable-maintainer-mode --with-threads; make; su; make install prefix=/usr/local/stow/guile-1.5.4; cd /usr/local/stow; stow guile-1.5.4 i did in source dir: make distclean cvs update sh -ex autogen.sh and in another dir: .../configure -C --enable-maintainer-mode --with-threads --enable-htmldoc make make check make prefix=/tmp/a/b/c install which seemed to work fine (i see libguile et al in /tmp/a/b/c/lib). thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: UINTPTR_MAX, INTPTR_MAX requirements
From: Dave Love [EMAIL PROTECTED] Date: 15 Jan 2002 11:58:32 + I don't know which headers one should include for UINTPTR_MAX, INTPTR_MAX on random systems, so I haven't tried the autoconfiscation. could you post the output of: grep PTR config.status ? thanks, thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: typo
From: fabrice bauzac [EMAIL PROTECTED] Date: Sun, 6 Jan 2002 15:39:31 +0100 Done! applied! (to unstable branch, that is. application to the stable branch was not clean, although in the end, i was able to hunt down most of the .rej hunks, and check in spellfixes.) many thanks. i ended up trying (and fighting) `M-x ediff-patch-file', but now i know where to smooth things out in patch.el (for next time). forget the spellcheck script idea -- here's a better one: i would love to have a script that, given some lines from a texi file, determines if those lines are somehow processed from source code (snarfed) and if so, list the suspected snarf method/target. this tool would make it easy for casual docs maintainers (like me and you) to find out the Real Place to fix things if need be, instead of worrying that any applied fix might be overridden later by snarfing. does this make sense? i suppose it's best to just ask snarfing gurus for a tour, but there may be usefulness for this tool outside of guile docs maintenance, where all you have is a tarball you want to fix, and an email address you want to pipe the patch to. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: CVS: module guile/guile-statprof can't be found
From: fabrice bauzac [EMAIL PROTECTED] Date: Mon, 7 Jan 2002 22:41:20 +0100 The error in http://www.gnu.org/software/guile/anon-cvs.html misdirected me. thanks for the report. fixed. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: [doc:ref] clearer
From: fabrice bauzac [EMAIL PROTECTED] Date: Sun, 6 Jan 2002 11:00:25 +0100 Hey, where should that information go then? All the information about scm_boot_guile is located there! I had to browse Guile's sources in order to see the argument order. docs are improving steadily still; your local copy may be out of date. i took a look through: http://www.glug.org/docbits/guile-doc-out/html/guile-1.7.0/ and although the organization is somewhat confusing, the information you seek seems to be in section 5.3.1 (Guile Initialization Functions). thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: typo
From: Fabrice Bauzac [EMAIL PROTECTED] Date: Sat, 05 Jan 2002 13:18:06 +0100 [misspelling] thanks. it would be nice if someone wrote a spellcheck script that we could add to guile-tools. could you do that? thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: [doc:ref] clearer
From: Fabrice Bauzac [EMAIL PROTECTED] Date: Sat, 05 Jan 2002 14:14:36 +0100 Let's make that sentence clearer: because this is the intro, i think it's ok to leave out details like call-argument order. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Error while loading boot-9.scm
From: john lin [EMAIL PROTECTED] Date: Tue, 27 Nov 2001 11:10:40 -0800 (PST) Please advise. i see the same behavior on my guile, but it doesn't bother me because normally, boot-9.scm is loaded automatically as a part of guile startup; i've never needed to load it manually. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: spelling fix in posix.texi
From: Chris Cramer [EMAIL PROTECTED]
Date: Sun, 25 Nov 2001 12:32:32 -0600
-in compination with @code{crypt}, that is why it appears in this
+in combination with @code{crypt}, that is why it appears in this
thanks... fixed in repo.
thi
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
Re: (ice-9 optargs) #:rest args polluted?
From: Marius Vollmer [EMAIL PROTECTED] Date: 13 Nov 2001 00:34:11 +0100 The behavior of Guile mirrors that of Common Lisp here, so I think we should keep it. Together with :allow-other-keys, you need :rest to get at the other keys; and without :allow-other-keys, :rest makes not much sense, I'd say. so what's the idiom to isolate the non-keys rest-args? i can't believe everyone is writing `remove-keys' (like me!)... (define* (blah #:key (j 'j) (k 'k) #:rest x) (set! x (remove-keys x)) (write-line (list blah j k x))) thi (define (remove-keys ls) (let loop ((ls ls) (acc '())) (if (null? ls) (reverse acc) (let ((kw? (keyword? (car ls (loop ((if kw? cddr cdr) ls) (if kw? acc (cons (car ls) acc))) ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: doc bug in string-null?
From: Neil Jerram [EMAIL PROTECTED] Date: 11 Nov 2001 21:46:45 + M-x load-file RET .../doc/maint/docstring.el RET M-x docstring-process-module RET (guile) RET Save all modified .texi files and copy the current libguile/guile.texi to doc/maint/guile.texi, then commit. Unless other stuff has changed since the auto update that I checked in today, the *Docstring Results* output buffer should only mention changes for docstrings that you think you've actually changed - i.e. string-null?. if the commands above are invoked automatically by cron on some machine under your control, i'll just sit back and watch. :- one thing i'd like to request is that generated docs have some @c generated comment near each item (or perhaps, less verbosely, a similar one-time hint at the top of the file, to remind people to look at ../libguile files instead of editing the texi directly. BTW, did you fix this in stable as well? I just fixed docstring.el to cope with the moving of the reference manual into the ref subdirectory, but haven't yet copied this change to the unstable branch; so you might want to grab docstring.el from unstable. hmmm i'm confused by your suggestion. in any case, in both branches, i fixed libguile/strop.c only. [munge munge] i've just tweaked docstring.el (unstable) to use an env var for some of its directory inits and will be trying it out soon. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: doc bug in string-null?
From: Scott Lenser [EMAIL PROTECTED] Date: Sun, 11 Nov 2001 06:05:29 -0500 Part of the documentation for string-null? is incorrect where it says nonzero, it means zero. thanks for the bug report. fixed in libguile/strop.c -- however, i need to familiarize myself w/ doc snarfing procedures to figure out how this is to propagate to the texi file... thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: doc bug in string-null?
From: Neil Jerram [EMAIL PROTECTED] Date: 11 Nov 2001 21:46:45 + M-x load-file RET .../doc/maint/docstring.el RET M-x docstring-process-module RET (guile) RET Save all modified .texi files and copy the current libguile/guile.texi to doc/maint/guile.texi, then commit. Unless other stuff has changed since the auto update that I checked in today, the *Docstring Results* output buffer should only mention changes for docstrings that you think you've actually changed - i.e. string-null?. if the commands above are invoked automatically by cron on some machine under your control, i'll just sit back and watch. :- one thing i'd like to request is that generated docs have some @c generated comment near each item (or perhaps, less verbosely, a similar one-time hint at the top of the file, to remind people to look at ../libguile files instead of editing the texi directly. BTW, did you fix this in stable as well? I just fixed docstring.el to cope with the moving of the reference manual into the ref subdirectory, but haven't yet copied this change to the unstable branch; so you might want to grab docstring.el from unstable. hmmm i'm confused by your suggestion. in any case, in both branches, i fixed libguile/strop.c only. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
(ice-9 optargs) #:rest args polluted?
the code following produces this output (w/ guile -s bug.scm) on guile-1.5.4: (#procedure good x ()) (#procedure good x (1)) (#procedure good x ((1 2 3))) (#procedure blah x JAY KAY (#:j JAY #:k KAY)) (#procedure blah x JAY KAY (#:j JAY #:k KAY 1)) (#procedure blah x JAY KAY (#:j JAY #:k KAY (1 2 3))) it seems to me `x' should be the same for both `good' and `blah'. thi ___ (use-modules (ice-9 optargs) (ice-9 rdelim)) (define* (good #:rest x) (write-line (list good x))) (good) (good 1) (good '(1 2 3)) (define* (blah #:key (j 'j) (k 'k) #:rest x) (write-line (list blah j k x))) (blah #:j 'JAY #:k 'KAY) (blah #:j 'JAY #:k 'KAY 1) (blah #:j 'JAY #:k 'KAY '(1 2 3)) ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Threads bug ?
From: Manuel Giraud [EMAIL PROTECTED] Date: 06 Nov 2001 18:32:32 +0100 But does anyone know which version correct this bug? Because, I just download guile-1.5.4, and I'm able to reproduce it (not downloading, the bug ;-). w/ fresh cvs guile (stable), the program prints out about 20 lines, then silently exits successfully. this is when invoked w/: guile -s bug.scm using -l instead of -s, however, loops infinitely, as expected. bug-guile cc'ed. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Threads bug ?
From: Thien-Thi Nguyen [EMAIL PROTECTED] Date: Tue, 6 Nov 2001 16:43:45 -0800 bug-guile cc'ed. this is now bug 9 (in cvs both branches). thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: guile-1.5.4 srfi-14
From: Ian Grant [EMAIL PROTECTED] Date: Mon, 29 Oct 2001 10:34:00 + guile-1.5.4 looks good! I got a compile error when using --disable-deprecated. Here's a patch: thanks for the patch. unfortunately, i believe it is counter to the recent (non-published except in mailing list archives) decision to move away from foo_t type names due to conflict w/ some standard or other. the fact that i can't cite the reasoning by pointing to some design docs can probably be considered a bug. :-/ for now, could you try another approach that uses HAVE_* macros? thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
