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: 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: 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: Tue, 5 Mar 2002 12:30:27 + I can't find any of those macros defined, or even appearing in the file. I assume that ./configure ought to change libguile/__scm.h However, I notice that this file was last modified on Jun 14 2001, not when I last ran ./configure Perhaps it's a problem with ./configure? sorry, i was unclear. libguile/__scm.h is where these are used. if you grep around, you'll see that SIZEOF_UINTPTR_T is defined in libguile/scmconfig.h, and the other values are defined in the system headers. if you still can't find them, try a more recent snapshot (i see that the original problem was reported against guile-core-20020205). 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: failed backtrace
From: M Johnson <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2002 16:37:56 -0500
Backtrace:
0* [assignments ("guile")]
1 (let ((env #)) (for-each (lambda # #) (quote #)))
2 Segmentation fault
thanks for the bug report. i have started to look at this. it appears
the environment at segf time has both `a' and `commandls' as names, but
no value for `a':
(gdb) gp env
$5 = 0x80651c8 "(((a commandls) (\"/usr/local/bin/guile\")) #)"
because the bad-define-placement error is correct -- using `local-eval'
requires application and thus the head-of-scope requirement for internal
defines cannot be met -- my question then becomes: why is `a' in the
environment at all?
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: 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: 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: 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: Guile fails tests on Tru64 4.0F
From: David C Sterratt <[EMAIL PROTECTED]> Date: Fri, 8 Feb 2002 14:58:15 + I've compiled guile-core-20020205 on Tru64 4.0F using gcc 2.95.2. It seemed to compile fine, but when I run 'make check' it gives me the following: look through check-guile.log to see which test(s) failed. you can also run check-guile manually, to see what files are being loaded, like so: ./check-guile --debug fyi, here's what i see at the end of the process, on an i386 box: Totals for this test run: passes: 2227 failures: 0 unexpected passes: 0 expected failures: 19 unresolved test cases: 1 untested test cases:0 unsupported test cases: 9 errors: 0 thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Trouble compiling Guile 1.4 on HP-UX 10.20
From: Atro Tossavainen <[EMAIL PROTECTED]> Date: Tue, 5 Feb 2002 12:01:28 +0200 (EET) I'm using CFLAGS="-Ae +O4" and the HP ANSI C compiler to compile Guile. Compiling eval.c gives me the following stack of errors that doesn't make an awful lot of sense. Compilation succeeded on Alpha, SGI, Sun (all with vendor-provided compilers) and Linux (gcc) without any problems. Any ideas? maybe cpp mangled the code in a bad way. try this: capture the "make" output, find where the compiler is compiling eval.c, and use that command to run cpp only (the equivalent of "gcc -E"). see if the resulting code looks legitimate, or post a snippet of it if you are unsure. if the code is badly mangled (and you can correlate this w/ your error messages), probably the easiest workaround is to use gcc. 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: 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: UINTPTR_MAX, INTPTR_MAX requirements
From: Dave Love <[EMAIL PROTECTED]>
Date: 28 Jan 2002 13:38:19 +
${ac_dA}HAVE_UINTPTR_T${ac_dB}HAVE_UINTPTR_T${ac_dC}1${ac_dD}
${ac_dA}HAVE_PTRDIFF_T${ac_dB}HAVE_PTRDIFF_T${ac_dC}1${ac_dD}
${ac_uA}HAVE_UINTPTR_T${ac_uB}HAVE_UINTPTR_T${ac_uC}1${ac_uD}
${ac_uA}HAVE_PTRDIFF_T${ac_uB}HAVE_PTRDIFF_T${ac_uC}1${ac_uD}
I'm not sure how that helps. If you're going to use the ..._MAX
macros, a configure test needs to be added, along with fallback
definitions.
true. i asked this because i was hoping to see something like:
${ac_dA}SIZEOF_UINTPTR_T${ac_dB}SIZEOF_UINTPTR_T${ac_dC}4${ac_dD}
${ac_dA}SIZEOF_PTRDIFF_T${ac_dB}SIZEOF_PTRDIFF_T${ac_dC}4${ac_dD}
${ac_uA}SIZEOF_UINTPTR_T${ac_uB}SIZEOF_UINTPTR_T${ac_uC}4${ac_uD}
${ac_uA}SIZEOF_PTRDIFF_T${ac_uB}SIZEOF_PTRDIFF_T${ac_uC}4${ac_uD}
which would confirm that you are on the HEAD branch. the output posted
above seems to indicate that you are on the 1.6 branch, but that doesn't
require UINTPTR_MAX. perhaps a fresh autogen.sh + configure run would
help...
in the meantime, i'll add those tests. thanks for the tip.
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: autoconf-macros.texi srcdir!=builddir
From: "Golubev I. N." <[EMAIL PROTECTED]>
Date: Tue, 08 Jan 2002 19:33:52 (GMT)
-$(top_srcdir)/scripts/snarf-guile-m4-docs $< > $@
+$(top_srcdir)/scripts/snarf-guile-m4-docs $< > ${srcdir}/$@
thanks, applied (both branches).
looks like there might be further problems, though. looking into it...
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: 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: typo
From: fabrice bauzac <[EMAIL PROTECTED]> Date: Sun, 6 Jan 2002 15:40:54 +0100 No, I'm afraid I'm not able to. There are too many non-english variables in the example code... if you have the elisp reference manual source, look at file "spellfile". maybe we can do something similar. on the other hand, looks like you've done the actual spellcheck job already... thanks for the weighty spellcheck patch -- it is motivating me to complete emacs/patch.el (so as to be able to apply your patch w/ minimal keystrokes :-). 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 Hello, this is my first contribution to Guile: one byte (stop laughing please! ;-) i've spell checked intro.texi and checked in changes including the one you spotted. for anyone interested in helping w/ spell checking the documentation: if you have ispell installed, you can spell check other texi files by visiting that file, making sure it is writeable, and typing `M-x ispell-buffer'. after the ispell session, save the buffer and send the patch to [EMAIL PROTECTED] 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: 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: Missing file when installing guile
From: [EMAIL PROTECTED] Date: Tue, 27 Nov 2001 22:19:39 -0500 When I run make on guile it quits with the message make[1]: *** [net_db.lo] Error 1 I checked /usr/include/arpa/inet.h and discovered that the net_db.lo and socket.lo in the library list are missing from libltdl directory. How do I fix this? I can't find a site with the individual files not packaged to see if they're supposed to be there. you need to be more specific: which guile, which platform, etc. w/o this kind of info, it's difficult to answer your question. 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: 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
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
(ice-9 optargs) #:rest args polluted?
the code following produces this output (w/ "guile -s bug.scm") on guile-1.5.4: (# ()) (# (1)) (# ((1 2 3))) (# JAY KAY (#:j JAY #:k KAY)) (# JAY KAY (#:j JAY #:k KAY 1)) (# 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: 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: 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: guile-1.5.4 srfi-14
From: Ian Grant <[EMAIL PROTECTED]> Date: Wed, 31 Oct 2001 16:17:06 + > 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. I disagree. From NEWS: you are right. sleep dep loses another one. patch applied (i found another instance, too). thanks! 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
Re: FAQ posted to bug guile is incorrect
From: "Dale P. Smith" <[EMAIL PROTECTED]> Date: Fri, 26 Oct 2001 08:06:38 -0400 http://www.gnu.org/software/guile/docs/faq/guile-faq.html yep. thanks for catching the typo. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: all guiles
From: [EMAIL PROTECTED] Date: Sun, 21 Oct 2001 23:42:37 +0200 Please check and help out http://www.gnu.org/software/guile/docs/guile-faq.html thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: ice-9 scrdir!=builddir
From: "Golubev I. N." <[EMAIL PROTECTED]> Date: Sat, 06 Oct 2001 12:35:07 (GMT) To be frank, in my original patch I just stole (known to be robust) code from `install-*DATA' target generated by automake. And if what you describe passes all tests, why not contact automake maintainers to use it more widely and make `Makefile.in's shorter. despite its apparent effacacy at this time, the original expansion was quite hairy, which does not give me confidence in its robustness. in any case, the issue was (and may continue to be, depending on what we learn about this kind of situation) a legitimate usage bug, so if anything, we should look for hints in the automake documentation that pertain to this situation, apply them, and suggest to the automake maintainers how to make these hints more easy to get at. well, having written the above, i scanned automake-1.5 info pages for "scrdir" and found a similar usage in node "Extending": For instance, here is one way to install a file in `/etc': install-data-local: $(INSTALL_DATA) $(srcdir)/afile /etc/afile that this usage is in this node suggests that your analysis may be correct after all; automake is not well-defined for this situation, so perhaps we can contribute more substantially than i originally thought. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Tcl War link
From: Neil Jerram <[EMAIL PROTECTED]> Date: 05 Oct 2001 19:32:23 +0100 Opinions? i'm in favor of dropping the link -- anyone who wants to maintain that kind of thing should consider putting on the guile wiki: http://www.glug.org/docbits/index.html#guile-wiki thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: ice-9 scrdir!=builddir
From: "Golubev I. N." <[EMAIL PROTECTED]> Date: Fri, 05 Oct 2001 16:47:29 (GMT) Yes, if `and-let-star-compat.scm' never ever will be generated in build time (so that right version of it will appear in build dir). from looking at the makefiles, i could not infer when (if ever) and-let-star-compat.scm would be generated, and so i've gone ahead and made the small change. thanks for the report! thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: ice-9 scrdir!=builddir
is the following change sufficient? - -$(INSTALL_DATA) and-let-star-compat.scm \ + -$(INSTALL_DATA) $(srcdir)/and-let-star-compat.scm \ thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: ice-9 scrdir!=builddir
From: "Golubev I. N." <[EMAIL PROTECTED]> Date: Thu, 04 Oct 2001 16:25:07 (GMT) To get 'and-let*.scm' installed correctly when source directory is not the same as build one, I copied commands from `Makefile.in' in `Makefile.am'. what behavior do you see w/o this patch? thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: guile.info: Writing
From: Martin Grabmueller <[EMAIL PROTECTED]> Date: Fri, 5 Oct 2001 17:20:14 +0200 (MEST) I'm not sure, but I think Alex was talking about the `R5RS Index' node in the GRM. of course! sorry for the brain fade... i've added a "display" entry to the node "Writing" (both branches). the entry is included in "R5RS Index". thanks for the clarification, and thanks, Alex, for the suggestion. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: guile.info: Writing
From: Alex Schroeder <[EMAIL PROTECTED]> Date: Mon, 24 Sep 2001 12:10:45 +0200 I just wanted some details on "display" but it was not in the R5RS Index. The node "Writing" has info on "newline". I think "display" should be added to that node as well and an appropriate index entry should be available. we have different r5rs.info files, apparently. here, the index shows both "display" and "newline" in "output". thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: unconditional `intptr_t'
From: "Golubev I. N." <[EMAIL PROTECTED]>
Date: Thu, 04 Oct 2001 16:24:44 (GMT)
--- chars.h 2001/09/21 17:51:01 1.11.4.2
+++ chars.h 2001/09/25 17:51:55
-#define SCM_MAKE_CHAR(x) SCM_MAKE_ITAG8((intptr_t) x, scm_tc8_char)
+#define SCM_MAKE_CHAR(x) SCM_MAKE_ITAG8((scm_t_bits) x, scm_tc8_char)
already applied; see 1.11.4.3 chars.h.
--- error.c 2001/09/21 17:50:45 1.63.2.3
+++ error.c 2001/09/25 17:51:56
- int error = (intptr_t) pos;
+ scm_t_bits error = (scm_t_bits) pos;
applied to branch_release-1-6 (see 1.63.2.4 error.c).
thanks for the reports! a quick "grep intptr *.[ch]" hits only in
libguile/{scmconfig,tags}.h, which seems reasonable.
thi
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
Re: -c 0
From: "Golubev I. N." <[EMAIL PROTECTED]> Date: Mon, 24 Sep 2001 17:42:51 (GMT) System: i586-pc-sco3.2v5.0.2 `guile -c 0' from cvs prints: ERROR: Unbound variable: 0 The same hapeens with one invoked inside `guile-snarf-docs-texi'. do you still see this w/ guile-1.5.4? you can get this at: ftp://alpha.gnu.org/gnu/guile/guile-1.5.4.tar.gz thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: unconditional `intptr_t'
From: "Golubev I. N." <[EMAIL PROTECTED]> Date: Mon, 24 Sep 2001 17:18:28 (GMT) "chars.h" uses `intptr_t' even on systems not having it. This causes compilation failure. thanks! applied to both branches. (unfortunately, i committed change log entries w/ "Golubev I. N." intead of "I. N. Golubev" as it appears in the THANKS file -- i'll try not to make that mistake in the future.) thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: guile.info: syntax index entries
From: Alex Schroeder <[EMAIL PROTECTED]> Date: Sat, 22 Sep 2001 12:06:48 +0200 When searching the index for "syntax" I find only two occurences: procedure->syntax and use-syntax. I think the node "The R5RS `syntax-rules' System" also requires a "syntax" related index entry. good suggestion -- thanks! applied to doc/ref/scheme-procedures.texi (both branches). please take a look at the (1-line) change and consider submitting future suggestions in the form of a patch. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: guile.info: Procedures for On the Fly Evaluation
From: Alex Schroeder <[EMAIL PROTECTED]>
Date: Sun, 16 Sep 2001 23:19:22 +0200
In the node "Procedures for On the Fly Evaluation" of the Guile
Reference manual, the primitive "read-and-eval!" is described.
However, it doesn't seem to be available. Maybe it is defined in some
module? If so, I looked at the paragraph describing the primitive, at
the beginning of the node, and one node up ("Reading and Evaluating
Scheme Code").
guile> (read-and-eval!)
(read-and-eval!)
standard input:12:1: In expression (read-and-eval!):
standard input:12:1: Unbound variable: read-and-eval!
ABORT: (unbound-variable)
i believe this bug is actually a misunderstanding. i could not
reproduce the above behavior. see below for a more straightforward way
to see if some proc is available.
thi
_
guile> read-and-eval!
#
guile> (version)
"1.5.2"
guile>
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
Re: `debug' debug option not disable-able from ~/.guile
From: Thien-Thi Nguyen <[EMAIL PROTECTED]> Date: Wed, 05 Sep 2001 14:09:02 -0700 thanks for the report -- that behavior is very strange! i will look into this. followups set to bug-guile. ok, i'm releasing ownership of this for now due to Other Activities. however, i've added the item to TODO (unstable branch) so that it can be picked up later. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: guile.info: Reading
From: Alex Schroeder <[EMAIL PROTECTED]> Date: Tue, 25 Sep 2001 11:10:29 +0200 guile> (call-with-input-file ".emacs" drain-input) "" here's another example, using `unread-char': guile> (define p (open-file ".emacs" "r")) guile> (define c (read-char p)) guile> c #\; guile> (unread-char c p) #\; guile> (drain-input p) " ~/.emacs ..." thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Possible Bug
check out: http://www.gnu.org/software/guile/docs/faq/guile-faq.html thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: guile-tut.info: Jump Start
From: Alex Schroeder <[EMAIL PROTECTED]> Date: Sun, 16 Sep 2001 19:43:32 +0200 for the factorial of 1000. fixed in cvs. thanks for the bug report! thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: guile-tut: Using Guile to program in Scheme
From: Alex Schroeder <[EMAIL PROTECTED]> Date: Sun, 16 Sep 2001 19:55:38 +0200 ;; ask for the length of `ls' guile> (length ls) 7=> [and so on] thanks for the bug report! fixed in cvs version of guile. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
ice-9/expect.scm commentary fix
- ;; macros: expect + ;; macros: expect, expect-strings ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
ice-9/boot-9.scm `process-use-modules'
undefined local `mif-spec' - (error "no such module" mif-spec)) + (error "no such module" mif-args)) i'll fix this unless someone beats me to it (my dev machine hdd is currently toast)... thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Has bignumber support changed since 1.4?
From: "Crowder, Brian" <[EMAIL PROTECTED]> Date: Mon, 10 Sep 2001 14:28:23 -0700 Perhaps I am configuring something wrong in the build? what is the line you used for configuration? what is the contents of your ~/.guile (if any)? can you supply a small piece of code (and its build process, if not scheme) that demonstrates this behavior? lacking these basic pieces of info, it is very difficult to help you. [followups set to bug-guile.] thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
ice-9/and-let-star-compat.scm needs to use `re-export-syntax'
i'll fix this as soon as the repo is accessible again... thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
`debug' debug option not disable-able from ~/.guile
From: [EMAIL PROTECTED] Date: Fri, 31 Aug 2001 10:46:27 +0200 (MET DST) (debug-disable 'debug) (debug-set! stack 0) is a good idea. BUT: if this is in ~/.guile the first line has no effect, while the second has an effect: thanks for the report -- that behavior is very strange! i will look into this. followups set to bug-guile. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
[dirk@ida.ing.tu-bs.de: failing test cases in srfi-19.test]
maybe local misconfiguration? thi --- Start of forwarded message --- From: Dirk Herrmann <[EMAIL PROTECTED]> Subject: failing test cases in srfi-19.test Date: Wed, 29 Aug 2001 00:09:46 +0200 (MEST) To: Guile Development List <[EMAIL PROTECTED]> Hello, with check-guile (CVS version, 1.7.0) I get the following failures: FAIL: srfi-19.test: SRFI date/time library: #date (time . tz-offset)> respects local DST if no TZ-OFFSET given FAIL: srfi-19.test: SRFI date/time library: #date (time . tz-offset)> respects local DST if no TZ-OFFSET given FAIL: srfi-19.test: SRFI date/time library: #date (time . tz-offset)> respects local DST if no TZ-OFFSET given FAIL: srfi-19.test: SRFI date/time library: #date (jdn . tz-offset)> respects local DST if no TZ-OFFSET given FAIL: srfi-19.test: SRFI date/time library: #date (jdn . tz-offset)> respects local DST if no TZ-OFFSET given FAIL: srfi-19.test: SRFI date/time library: string->date respects local DST if no time zone is read Best regards, Dirk Herrmann --- End of forwarded message --- ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: irix 5.3 (guile 1.5.1)
From: Bill Schottstaedt <[EMAIL PROTECTED]> Date: Thu, 23 Aug 2001 05:10:25 -0700 GC_noop1(x) thanks for the bug report. i've moved the func definition before its usage. please see cvs version of guile or wait for 1.5.2 release. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: doesn't compile with ./configure --enable-guile-debug
From: Chris Cramer <[EMAIL PROTECTED]> Date: Thu, 16 Aug 2001 15:49:40 -0500 Here is a patch that fixes it. thanks! i've applied the fix (but not the patch directly, preferring to move the proto to within the `#ifdef' block) to both stable and unstable branches. simple testing w/ a "./configure --enable-debug-freelist && make && make check" doesn't show any problems. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
`intern-symbol' takes string or symbol?
the docs for `intern-symbol' say: - primitive: intern-symbol obarray string Add a new symbol to OBARRAY with name STRING, bound to an unspecified initial value. The symbol table is not modified if a symbol with this name is already present. however, in the guile-1.5.0 repl, i see: guile> (define o (module-obarray (current-module))) guile> (intern-symbol o "hello") Backtrace: In standard input: 19: 0* [intern-symbol #(() () () ((o . #)) () () () () () ...) "hello"] standard input:19:1: In procedure intern-symbol in expression (intern-symbol o "hello"): standard input:19:1: Wrong type argument in position 2 (expecting SYMBOLP): "hello" ABORT: (wrong-type-arg) guile> (intern-symbol o 'hello) guile> "intern" type procs have traditionally taken strings, so the documentation seems more right to me than the actual behavior. perhaps someone got confused by the name, thinking the proc arg should be a symbol? although this proc is marked "deprecated" (along w/ everything else in libguile/symbols-deprecated.[hc]), it should still be fixed. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: CVS snapshot link
From: Martin Grabmueller <[EMAIL PROTECTED]> Date: Mon, 16 Jul 2001 17:09:49 +0200 (MEST) ftp://krusty.e-technik.uni-dortmund.de/pub/guile/snapshots/ fixed. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
fyi guile-1.5.0 build failure when using `--enable-ltdl-convenience'
for some reason, i invoked configure like so:
./configure -C --enable-maintainer-mode \
--with-threads --enable-ltdl-convenience \
--enable-htmldoc
which resulted in "make" showing:
./guile-snarf-docs-texi alist.doc arbiters.doc [...]
|| { rm guile.texi; false; }
gcc: .libs/guileS.o: No such file or directory
doing a "make distclean" and then reconfiguring w/o
`--enable-ltdl-convenience' made the problem go away.
i guess hencforth i will avoid `--enable-ltdl-convenience'...
thi
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
Re: web pages
From: Marius Vollmer <[EMAIL PROTECTED]> Date: 19 Jun 2001 22:13:37 +0200 Can we have the HTML version of the reference manual of the latest released guile-core there? sure. but what about unreleased guile-core? actually, probably better to put released at http://www.gnu.org/manual and unreleased at http://www.gnu.org/software/guile/docs/. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: web pages
From: Martin Grabmueller <[EMAIL PROTECTED]> Date: Tue, 19 Jun 2001 17:48:37 +0200 could someone w/ write privs nuke the mentioning of the guile-doc CVS module from http://www.gnu.org/software/guile/docs/docs.html done. anyone have an idea for what to do w/ the rest of that page? thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: "mkstemp.c":"scmconfig.h"
thanks, applied. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: guile-doc-snarf bug
From: Sergey Poznyakoff <[EMAIL PROTECTED]> Date: Tue, 08 May 2001 16:42:47 +0300 guile-doc-snarf passes guile-func-name-check to awk without absolute path. Thus it bails out unless guile-func-name-check is in current direcory. Fix (for guile-doc-snarf 1.16): now fixed in cvs. thanks for the bug report! thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: web page image tag broken
From: Martin Grabmueller <[EMAIL PROTECTED]> Date: Mon, 30 Apr 2001 16:57:08 +0200 (MEST) could anyone w/ write privs please change the tag in page_template.html to have an absolute path name? Otherwise, the image is not found for the subdirectory pages (mail/mail.html etc.) thanks for the bug report. tag fixed. docs/docs.html and mail/mail.html regenerated. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: ./check-guile: test: argument expected
fixed in cvs. thanks! thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: set-current-module broken in current Guile CVS version
From: Dirk Herrmann <[EMAIL PROTECTED]> Date: Fri, 19 Jan 2001 17:00:24 +0100 (MET) I like your patch a lot. If nobody objects, I would like to apply it to CVS. However, can you please post the complete patch again, including the latest fixes? wonderful! please see directory: http://www.glug.org/people/ttn/software/patches/ where you will find three files (hopefully, self-explanatory): README guile-cvs20010120-cvs20010120ttn1.diff.gz check-guile.in i apologize for (still, despite much cvs info page grovelling, some cvs-info mailing list perusal, and an update to cvs-1.11) not being able to figure out how to get "cvs diff" to include check-guile.in; you will have to manually copy that file into top-level guile-core. maybe we can include some hints in HACKING on how to submit patches that touch more than one file, especially new files. btw, i note (w/ some satisfaction) that "./check-guile -i /usr/local/bin/guile" gives errors. that means the patch works! btw2, i have not added support for "make post-install-check"; better to keep the patch focused, IMHO. i can do that later if requested. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Guile webpages [still] unreadable
... ok, fixed. (find-grep-dired for "FFF" (seven Fs) is clean.) thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: Guile webpages [still] unreadable
thanks for the bug report (this is news to me). fixing... thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: set-current-module broken in current Guile CVS version
From: Michael Livshin <[EMAIL PROTECTED]> Date: 15 Jan 2001 18:20:26 +0200 Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Dirk Herrmann <[EMAIL PROTECTED]> writes: > Does the produced file "check-guile" get installed? (please forgive my > autoconf/make ignorance). If so, is it possible to have it _not_ > installed? IMO, it is sufficient if "make check" works from the build > directory after "make install" has been performed. This would mean that > there should not be a need for a check-guile script (or at least that is > what I think). not really related, but: it would be nice to have some way to check the installation, too. perhaps by having a script that runs the test suite with the installed guile, or something like that. there wouldn't be any need to install the script itself, of course. yeah, check-guile handles this with the "-i INTERPRETER" switch, so that you can check any guile against the (current build-dir) test-suite. i just posted a bugfixed version try something like: make make check make install ./check-guile -i PREFIX/bin/guile the auto* tools don't (yet?) support a post-install step, although we could suggest the above simple check in the INSTALL file for people to do manually (or add a makefile rule that does it so that people can do "make post-install-check"). thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: set-current-module broken in current Guile CVS version
From: Dirk Herrmann <[EMAIL PROTECTED]> Date: Mon, 15 Jan 2001 17:10:10 +0100 (MET) Does the produced file "check-guile" get installed? (please forgive my autoconf/make ignorance). If so, is it possible to have it _not_ installed? IMO, it is sufficient if "make check" works from the build directory after "make install" has been performed. This would mean that there should not be a need for a check-guile script (or at least that is what I think). first off, thanks for the response! check-guile indeed does NOT get installed. fyi, you can find out what gets installed by doing "make -n install | grep ^list=". the intent of check-guile is that it can be used to check an installed guile as well as the one in the build directory. this is useful to see the difference (if any) in behavior in new versus installed. however, apparently i foolishly posted a buggy check-guile.in w/o testing if the "-i INTERPRETER" switch actually works. please find below a revised check-guile.in. (the bug was that the installed guile could not find the test-suite dir, so now we jam its parent on the end of the "native" %load-path and pass the whole thing in using env var `GUILE_LOAD_PATH', just like for testing the uninstalled guile. an alternate solution that relies on symlinks is to do "cd test-suite ; ln -s . test-suite".) [insert quote about fools here...] thi ___ #! /bin/sh # Usage: check-guile [-i GUILE-INTERPRETER] [GUILE-TEST-ARGS] # If `-i GUILE-INTERPRETER' is omitted, use libguile/guile. # See test-suite/guile-test for documentation on GUILE-TEST-ARGS. # # Example invocations: # ./check-guile # ./check-guile numbers.test # ./check-guile -i /usr/local/bin/guile # ./check-guile -i /usr/local/bin/guile numbers.test TEST_SUITE_DIR=@test_suite_dir@ export TEST_SUITE_DIR parent=`dirname $TEST_SUITE_DIR` if [ x"$1" = x-i ] ; then guile=$2 shift shift else guile=$parent/libguile/guile glp=$parent fi if [ -f "$guile" -a -x "$guile" ] ; then echo Testing $guile ... "$@" if [ -z "$glp" ] ; then glp=`$guile -c "(for-each write-line %load-path)"` glp=`echo $glp | sed 's/ /:/g'`:$parent fi GUILE_LOAD_PATH=$glp export GUILE_LOAD_PATH echo with GUILE_LOAD_PATH = \`$GUILE_LOAD_PATH\' else echo ERROR: Cannot execute $guile exit 1 fi cd $TEST_SUITE_DIR exec $guile -e main -s guile-test "$@" # check-guile ends here ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: set-current-module broken in current Guile CVS version
From: Dirk Herrmann <[EMAIL PROTECTED]> Date: Thu, 28 Dec 2000 11:21:57 +0100 (MET) Believe me, I _always_ run the test-suite before committing changes. The problem is not the lack of a 'make check' command (although this would be nice to have, agreed), but rather of the large areas of untested stuff within the test-suite itself. ok, please find below the latest attempt to get "make check" to run the test suite into guile. the earlier attempt can be seen at: http://sources.redhat.com/ml/guile/2000-03/msg00579.html http://sources.redhat.com/ml/guile/2000-03/msg00580.html please do one of the following: a - incorporate the changes b - give me feedback on what is wrong so i can fix it and resubmit c - ignore it and suffer my whining (you have been warned :-) there is a new file "check-guile.in" and a unidiff that touches four files. but first, here are some changelog entries: [top-level] 2001-01-10 Thien-Thi Nguyen <[EMAIL PROTECTED]> * Makefile.am (TESTS): New automake var. * configure.in (test_suite_dir): New substituted var. (AC_OUTPUT): Add check-guile. [subdir test-suite] 2001-01-10 Thien-Thi Nguyen <[EMAIL PROTECTED]> * paths.scm (datadir): Allow override by env var `TEST_SUITE_DIR'. * guile-test (main): Add local var `global-pass', register a reporter to modify it on "fail" or "xpass", and use it as exit status. If env var `DEBUG' set, display load path, set `%load-verbosely', and enable backtrace and debug-evaluator. here is the new top-level file "check-guile.in". this is munged in the normal way by configure to produce executable "check-guile". see header comments for invocation details. #! /bin/sh # Usage: check-guile [-i GUILE-INTERPRETER] [GUILE-TEST-ARGS] # If `-i GUILE-INTERPRETER' is omitted, use libguile/guile. # See test-suite/guile-test for documentation on GUILE-TEST-ARGS. # # Example invocations: # ./check-guile # ./check-guile -i /usr/local/bin/guile # ./check-guile numbers.test # ./check-guile -i /usr/local/bin/guile numbers.test TEST_SUITE_DIR=@test_suite_dir@ export TEST_SUITE_DIR if [ x"$1" = x-i ] ; then guile=$2 shift shift else parent=`dirname $TEST_SUITE_DIR` guile=$parent/libguile/guile GUILE_LOAD_PATH=$parent export GUILE_LOAD_PATH fi if [ -f "$guile" -a -x "$guile" ] ; then echo Testing $guile ... echo with GUILE_LOAD_PATH = \`$GUILE_LOAD_PATH\' else echo ERROR: Cannot execute $guile exit 1 fi cd $TEST_SUITE_DIR exec $guile -e main -s guile-test "$@" # check-guile ends here the rest of this mail is a copy of the emacs buffer where i did a time-stamped cvs update and diff. it ends w/ "Compilation finished". in case of mta misbehavior, this is also available as: http://www.glug.org/people/ttn/software/patches/guile-cvs20010110-cvs20010110ttn1.diff.gz thi __ cd ~/build/.gnu/subversions/guile-core/ date -u ; cvs update ; date -u ; cvs diff ; date -u Wed Jan 10 11:44:09 UTC 2001 ? libltdl ? guile.log ? patch ? check-guile.in ? check-guile ? doc/version.texi ? doc/stamp-vti ? libguile/.ttn-load.c ? libguile/.ttn-Makefile.am cvs server: Updating . M Makefile.am M configure.in cvs server: Updating build cvs server: Updating devel cvs server: Updating devel/build cvs server: Updating devel/policy cvs server: Updating devel/strings cvs server: Updating devel/translation cvs server: Updating devel/vm cvs server: Updating devel/vm/ior cvs server: Updating doc cvs server: Updating doc/example-smob cvs server: Updating emacs cvs server: Updating guile-config cvs server: Updating guile-readline cvs server: Updating ice-9 cvs server: Updating lang cvs server: Updating libguile cvs update: in directory libltdl: cvs update: cannot open CVS/Entries for reading: No such file or directory cvs server: Updating libltdl cvs server: Updating oop cvs server: Updating oop/goops cvs server: Updating qt cvs server: Updating qt/md cvs server: Updating qt/time cvs server: Updating test-suite M test-suite/guile-test M test-suite/paths.scm cvs server: Updating test-suite/tests cvs server: Updating test-suite/tests/asmobs cvs server: Updating test-suite/tests/c-api cvs server: Updating www Wed Jan 10 11:44:11 UTC 2001 ? libltdl ? guile.log ? patch ? check-guile.in ? check-guile ? doc/version.texi ? doc/stamp-vti ? libguile/.ttn-load.c ? libguile/.ttn-Makefile.am cvs server: Diffing . Index: Makefile.am === RCS file: /cvs/guile/guile-core/Makefile.am,v retrieving revision 1.19 diff -u -p -w -r1.19 Makefile.am --- Makefile.am 2000/10/25 14:45:36 1.19 +++ Makefile.am 2001/01/10 11:44:32 @@ -24,6 +24,8 @@ SUBDIRS = ice-9 oop qt libltdl libguile include_HEADERS = libg
Re: where is the mailing list?
From: thi <[EMAIL PROTECTED]> Date: Wed, 3 Jan 2001 10:06:33 -0800 oops, the faq was updated, but not the main page... munging... fixed. i also added guile-devel and bug-guile and a link to the developer's page. http://www.gnu.org/server/whatsnew.html updated, too. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: where is the mailing list?
From: "Steven G. Johnson" <[EMAIL PROTECTED]> Date: Wed, 3 Jan 2001 12:40:38 -0500 (EST) The old Guile mailing list page (http://sources.redhat.com/ml/guile/) says: "This list has moved! See the Guile home page for more information." However, the Guile home page on www.gnu.org doesn't give any more information as far as I can tell, and still points to the old list. oops, the faq was updated, but not the main page... munging... thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: set-current-module broken in current Guile CVS version
From: Matthias Koeppe <[EMAIL PROTECTED]> Date: 27 Dec 2000 13:06:41 +0100 Some of the Guile changes since 2000-12-13 broke `set-current-module'. oops, previous mail sent too fast... anyway, could someone w/ write privs comment on the status of the patch referenced in the previous mail (originally sent 24-Mar-2000)? if the patch is insufficient, by all means let me know so i can rework it and resubmit... i think it's high time guile had a non-vestigial "make check". thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: set-current-module broken in current Guile CVS version
From: thi <[EMAIL PROTECTED]> Subject: patch to have "make check" invoke test-suite/guile-test Date: Fri, 24 Mar 2000 13:21:43 -0800 To: [EMAIL PROTECTED] hello guile folks, please see below for an incomplete[1] patch that allows "make check" to invoke test-suite/guile-test. we introduce a new top-level script called "test-guile" and call it from "make check". here is a top-level ChangeLog entry: 2000-03-24 Thien-Thi Nguyen <[EMAIL PROTECTED]> * Makefile.am (TESTS): New automake var. * configure.in (test_suite_dir): New substituted var. (AC_OUTPUT): Add test-guile. here is a ChangeLog entry for subdir test-suite: 2000-03-24 Thien-Thi Nguyen <[EMAIL PROTECTED]> * paths.scm (datadir): Allow override by env var `TEST_SUITE_DIR'. * guile-test (main): Add local var `global-pass', register a reporter to modify it on "fail" or "xpass", and use it as exit status. [1] the test-guile script is not included in the patch because i don't know how to get cvs diff to recognize it as (a to-be-) part of the source tree. i will submit that next, with more info. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: typo
thanks for the bug report. fixed. thi ___ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
Re: rl_pre_input_hook checked as code when it is data
From: Marius Vollmer <[EMAIL PROTECTED]> Date: 17 Jul 2000 21:16:57 +0200 > Btw. your page at http://www.gnu.org/software/guile/guile.html > seems to lag behind. Doesn't the whole web? ;) this should no longer be the case. apologies for any misconvenience. thi
Re: assoc-ref broken?
From: Marius Vollmer <[EMAIL PROTECTED]> Date: 09 Apr 2000 11:12:19 +0200 Use guile> (assoc-ref '((1 . 2) (3 . 4) (5 . 6)) 3) 4 instead. Arguments for assoc-ref are the other way around from assoc. Also note that it does return the value and not the cell. Both things are to make assoc-ref rhyme with vector-ref, string-ref, list-ref, etc. d'oh! ok, time to go to bed 8-} thanks for the clue. thi
assoc-ref broken?
something is weird w/ assoc-ref this is w/ latest cvs guile.
does anyone else see this behavior?
thi
guile> (assoc 3 '((1 . 2) (3 . 4) (5 . 6)))
(3 . 4)
guile> (assoc-ref 3 '((1 . 2) (3 . 4) (5 . 6)))
#f
guile> (assoc-ref 3 '((1 . 2) (3 4) (5 . 6)))
#f
guile> (assoc-ref 3 '((1 . 2) (3 "zz") (5 . 6)))
#f
guile> (assoc-ref 3 '((1 . 2) (3 . "zz") (5 . 6)))
#f
guile> (assoc-ref "yy" '((1 . 2) ("yy" . "zz") (5 . 6)))
#f
guile> (assoc-ref "yy" '((1 . 2) ("yy" "zz") (5 . 6)))
#f
guile> (let ((key 3)) (assoc-ref key (list (cons 1 2) (cons key 4) (cons 5 6
#f
guile> (let ((key "yy")) (assoc-ref key (list (cons 1 2) (cons key 4) (cons 5 6
#f
guile> (let ((key 'yy)) (assoc-ref key (list (cons 1 2) (cons key 4) (cons 5 6
#f
using `SCM_UNPACK' in libguile/eval.h to placate compiler
during guile-oops compilation (w/ egcs-2.91.66), there are warnings: "pointer of type `void *' used in arithmetic" the following small patch to libguile/eval.h wraps SCM args to the C `-' operator w/ `SCM_UNPACK'. this makes the warnings go away. thi --- Index: eval.h === RCS file: /cvs/guile/guile/guile-core/libguile/eval.h,v retrieving revision 1.39 diff -c -p -w -c -r1.39 eval.h *** eval.h 2000/03/19 19:01:10 1.39 --- eval.h 2000/03/20 01:42:57 *** extern long scm_tc16_macro; *** 162,170 * tag of 1. This is called a "gloc". */ ! #define SCM_GLOC_SYM(x) (SCM_CAR((x)-1L)) ! #define SCM_GLOC_VAL(x) (SCM_CDR((x)-1L)) ! #define SCM_GLOC_VAL_LOC(x) (SCM_CDRLOC((x)-1L)) --- 162,170 * tag of 1. This is called a "gloc". */ ! #define SCM_GLOC_SYM(x) (SCM_CAR (SCM_UNPACK (x) - 1L)) ! #define SCM_GLOC_VAL(x) (SCM_CDR (SCM_UNPACK (x) - 1L)) ! #define SCM_GLOC_VAL_LOC(x) (SCM_CDRLOC (SCM_UNPACK (x) - 1L))
new test-suite/tests/numbers.test (w/ more `ash' tests)
numbers.test --- test suite for Guile's numerical ops -*- scheme -*- Author: Thien-Thi Nguyen <[EMAIL PROTECTED]> Copyright (C) 1999 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: ;;; Both R4RS and R5RS define these 54 numerical operations: ;;; ;;; * + - / < <= = > >= abs acos angle asin atan ceiling complex? cos ;;; denominator even? exact->inexact exact? exp expt floor gcd imag-part ;;; inexact->exact inexact? integer? lcm log magnitude make-polar ;;; make-rectangular max min modulo negative? number? numerator odd? ;;; positive? quotient rational? rationalize real-part real? remainder ;;; round sin sqrt tan truncate zero? ;;; ;;; You should probably put tests for these operations in the appropriate ;;; r?rs.test file. This file has tests for numerical operations unique ;;; to Guile. Code: (use-modules (test-suite lib)) (pass-if "(ash 2 0) => 2" (= 2 (ash 2 0))) (pass-if "(ash 2 1) => 4" (= 4 (ash 2 1))) (pass-if "(ash 2 -1) => 1" (= 1 (ash 2 -1))) (pass-if "(ash 1 0) => 1" (= 1 (ash 1 0))) (pass-if "(ash 1 1) => 2" (= 2 (ash 1 1))) (pass-if "(ash 1 -1) => 0" (= 0 (ash 1 -1))) (pass-if "(ash 0 0) => 0" (= 0 (ash 0 0))) (pass-if "(ash 0 1) => 0" (= 0 (ash 0 1))) (pass-if "(ash 0 -1) => 0" (= 0 (ash 0 -1))) (pass-if "(ash -1 0) => -1" (= -1 (ash -1 0))) (pass-if "(ash -1 1) => -2" (= -2 (ash -1 1))) (pass-if "(ash -1 -1) => -1" (= -1 (ash -1 -1))) (pass-if "(ash -2 0) => -2" (= -2 (ash -2 0))) (pass-if "(ash -2 1) => -4" (= -4 (ash -2 1))) (pass-if "(ash -2 -1) => -1" (= -1 (ash -2 -1))) numbers.test ends here
libguile/numbers.c patch to fix `ash' bug
before the patch, `(ash 2 -1)' yielded arg-out-of-range error.
the fix is to `SCM_UNPACK (cnt)' before comparing it w/ zero.
this change was made to both branches of the `#ifdef SCM_BIGDIG'.
thi
---
Index: numbers.c
===
RCS file: /cvs/guile/guile/guile-core/libguile/numbers.c,v
retrieving revision 1.71
diff -c -p -w -c -r1.71 numbers.c
*** numbers.c 2000/03/18 08:44:04 1.71
--- numbers.c 2000/03/19 16:26:43
*** SCM_DEFINE (scm_ash, "ash", 2, 0, 0,
*** 1068,1074
SCM res = SCM_PACK (SCM_INUM (n));
SCM_VALIDATE_INUM (2,cnt);
#ifdef SCM_BIGDIG
! if (cnt < 0)
{
res = scm_integer_expt (SCM_MAKINUM (2), SCM_MAKINUM (-SCM_INUM (cnt)));
if (SCM_NFALSEP (scm_negative_p (n)))
--- 1068,1074
SCM res = SCM_PACK (SCM_INUM (n));
SCM_VALIDATE_INUM (2,cnt);
#ifdef SCM_BIGDIG
! if (SCM_UNPACK (cnt) < 0)
{
res = scm_integer_expt (SCM_MAKINUM (2), SCM_MAKINUM (-SCM_INUM (cnt)));
if (SCM_NFALSEP (scm_negative_p (n)))
*** SCM_DEFINE (scm_ash, "ash", 2, 0, 0,
*** 1080,1089
else
return scm_product (n, scm_integer_expt (SCM_MAKINUM (2), cnt));
#else
! SCM_VALIDATE_INUM (1,n)
cnt = SCM_INUM (cnt);
- if (cnt < 0)
- return SCM_MAKINUM (SCM_SRS (res, -cnt));
res = SCM_MAKINUM (res << cnt);
if (SCM_INUM (res) >> cnt != SCM_INUM (n))
scm_num_overflow (FUNC_NAME);
--- 1080,1088
else
return scm_product (n, scm_integer_expt (SCM_MAKINUM (2), cnt));
#else
! if (SCM_UNPACK (cnt) < 0)
! return SCM_MAKINUM (SCM_SRS (res, -SCM_UNPACK (cnt)));
cnt = SCM_INUM (cnt);
res = SCM_MAKINUM (res << cnt);
if (SCM_INUM (res) >> cnt != SCM_INUM (n))
scm_num_overflow (FUNC_NAME);
new file: test-suite/tests/numbers.test
this test demonstrates a bug w/ `ash'. i will send a patch in the next email. thi -- numbers.test --- test suite for Guile's numerical ops -*- scheme -*- Author: Thien-Thi Nguyen <[EMAIL PROTECTED]> Copyright (C) 2000 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: ;;; Both R4RS and R5RS define these 54 numerical operations: ;;; ;;; * + - / < <= = > >= abs acos angle asin atan ceiling complex? cos ;;; denominator even? exact->inexact exact? exp expt floor gcd imag-part ;;; inexact->exact inexact? integer? lcm log magnitude make-polar ;;; make-rectangular max min modulo negative? number? numerator odd? ;;; positive? quotient rational? rationalize real-part real? remainder ;;; round sin sqrt tan truncate zero? ;;; ;;; You should put tests for these operations in the appropriate ;;; r?rs.test file. This file has tests for numerical operations unique ;;; to Guile. Code: (use-modules (test-suite lib)) (pass-if "(ash 2 -1) => 1" (= 1 (ash 2 -1))) numbers.test ends here
libguile/coop-threads.c needs string.h for `scm_makfrom0str'
this supercedes a previous patch (coop-threads.c needs both root.h and string.h). thi - Index: coop-threads.c === RCS file: /cvs/guile/guile/guile-core/libguile/coop-threads.c,v retrieving revision 1.17 diff -c -p -w -c -p -r1.17 coop-threads.c *** coop-threads.c 2000/03/12 16:09:34 1.17 --- coop-threads.c 2000/03/19 14:19:52 *** *** 46,51 --- 46,53 #include "validate.h" #include "coop-threads.h" + #include "root.h" + #include "string.h" /* A counter of the current number of threads */ size_t scm_thread_count = 0;
libguile/coop-threads.c needs root.h for various definitions
Index: coop-threads.c === RCS file: /cvs/guile/guile/guile-core/libguile/coop-threads.c,v retrieving revision 1.17 diff -c -p -w -c -r1.17 coop-threads.c *** coop-threads.c 2000/03/12 16:09:34 1.17 --- coop-threads.c 2000/03/19 13:55:58 *** *** 46,51 --- 46,52 #include "validate.h" #include "coop-threads.h" + #include "root.h" /* A counter of the current number of threads */ size_t scm_thread_count = 0;
ilbguile/debug.c needs root.h for `scm_top_level_lookup_closure_var'
Index: debug.c === RCS file: /cvs/guile/guile/guile-core/libguile/debug.c,v retrieving revision 1.65 diff -c -p -w -c -r1.65 debug.c *** debug.c 2000/03/17 16:10:12 1.65 --- debug.c 2000/03/19 13:51:42 *** *** 64,69 --- 64,70 #include "dynwind.h" #include "modules.h" #include "ports.h" + #include "root.h" #include "validate.h" #include "debug.h"
libguile/threads.h needs throw.h for `scm_catch_body_t'
Index: threads.h === RCS file: /cvs/guile/guile/guile-core/libguile/threads.h,v retrieving revision 1.10 diff -c -p -w -c -r1.10 threads.h *** threads.h 2000/03/02 20:54:43 1.10 --- threads.h 2000/03/19 13:29:33 *** *** 50,55 --- 50,56 #include "libguile/__scm.h" #include "libguile/procs.h" + #include "libguile/throw.h" /* smob tags for the thread datatypes */ extern long scm_tc16_thread;
Re: autogen.sh broken for guile-readline
From: Marius Vollmer <[EMAIL PROTECTED]> Date: 19 Mar 2000 11:54:44 +0100 Anyway, back to this specific workaround, I think it has a special audience that might make me reconsider my position. they way I understand the situation, it should help people most who want to compile Guile from CVS, but are not really doing development on Guile. I think we want to encourage people to compile from CVS because we then don't have to release a tarball so often. [Do the nightly snapshots still exists?] this all depends on one's definition of "developer". some people like to browse and build code, and sometimes they find ways to make things better. perhaps they are not full-fledged developers, but i wouldn't exclude those people from the development process. on the other hand, i can see value in conventions; sometimes that is what binds a community. (i don't know about the nightly snapshots...) In that light, we should make it easy to compile from CVS. The next question then is: how common is this automake/libtool problem? I think it's quite common, it has happened to me on all platforms and all projects. How hard is it to fix this problem without hacking automake, libtool, or Guile? Not too hard, I'd say. You just need to install automake and libtool with a common prefix and use them instead of the old ones. I found that I had to do that in the end anyway, because I don't want to depend on the versions installed by vendors. Installation from source is very easy for both automake and libtool. cool, i'm glad i did not offend you w/ my approach. unfortunately, i still view prescribed prefixes w/ some trepidation. if j.r.hacker wants to use different prefixes, we should not encode the assumption otherwise in autogen.sh. because we (nor anyone) cannot really mandate same prefix, it's reasonable to handle the worst-case scenario (which is not a bug, simply a common situation) and be able to grok w/ different prefixes. basically, some assumptions are good to make, but this one doesn't smell that way to me. (especially since i've stepped in the mud, personally.) i suppose calling it a problem was improper of me; it's just another Situation To Handle. luckily here, there is no slippery slope. if we can reliably handle different prefixes, that's as bad as it gets (unless i'm missing some curious wrinkle...). But I agree that it would be much more convenient when it would just work. Therefore, your patch is probably the right thing, anyway. But we should make sure that it is consistent. One thing I'm aware of is that the "-I" options are only passed to aclocal when it is invoked from autogen.sh, but not when invoked from make. We should probably also set ACLOCAL_AMFLAGS in the relevant Makefile.am files. Could you update your patch to do that? sure. In addition to this workaround, we shuld also be approaching the autoconf/automake/libtool guys with this problem and ask for their opinion. Maybe they have a superior solution that would help all packages that use automake/libtool and not just Guile. Or maybe we can help them develop one. that's very constructive. even though i'm backing away from viewing it as a problem, i'd still welcome insight from the original toolsmiths. surely they have run across this situation before. i've nothing against canonical, sanctioned, workarounds. :-> thi
Re: autogen.sh broken for guile-readline
From: Marius Vollmer <[EMAIL PROTECTED]> Date: 17 Mar 2000 22:56:41 +0100 thi <[EMAIL PROTECTED]> writes: > a while ago, i submitted a small patch to address the situation > where aclocal and libtool are installed w/ different PREFIX. > perhaps this is the problem (still)? (insert standard grumble about > dropped patches here.) I'm not opposed to this change, but I generally think that a package should not try too hard to workaround misinstalled auxiliary packages. Is there a some situation where one absolutely has to use this hack? i don't believe installation of tools using different prefixes is really considered a misinstallation. this situation is actually quite common: aclocal is supplied by the vendor and has prefix /usr. libtool is installed later by the admin and has prefix /usr/local. this is what happened to me and i'm disappointed that you don't see the patch as my way of preventing this from happening to others. try to solve the problem another way if you want. ignoring it doesn't make the problem go away. thi
Re: autogen.sh broken for guile-readline
From: [EMAIL PROTECTED]
Date: Wed, 15 Mar 2000 10:10:14 -0800 (PST)
when running autogen.sh in guile-readline, you get the following
error:
aclocal: configure.in: 8: macro `AM_PROG_LIBTOOL' not found in library
I imagine this leads to the configure problems later in the build.
a while ago, i submitted a small patch to address the situation where
aclocal and libtool are installed w/ different PREFIX. perhaps this is
the problem (still)? (insert standard grumble about dropped patches
here.)
thi
--- ./autogen.sh --
#!/bin/sh
[ -f GUILE-VERSION ] || {
echo "autogen.sh: run this command only at the top of a Guile source tree."
exit 1
}
libtool=`set \`type libtool\` ; echo $3`
libtool_prefix=`echo $libtool | sed 's|/bin/libtool||g'`
aclocal -I . -I ${libtool_prefix}/share/aclocal
libtoolize --copy --automake --ltdl
autoheader
autoconf
automake --add-missing
( echo "guile-readline..."; cd guile-readline; ./autogen.sh )
- guile-readline/autogen.sh --
#!/bin/sh
[ -f readline-activator.scm ] || {
echo "autogen.sh: run this command only in the guile-readline directory."
exit 1
}
libtool=`set \`type libtool\` ; echo $3`
libtool_prefix=`echo $libtool | sed 's|/bin/libtool||g'`
aclocal -I . -I ${libtool_prefix}/share/aclocal
libtoolize --copy --automake
autoconf
automake --add-missing
--
configure.in local vars needs terminating tag
Index: configure.in === RCS file: /cvs/guile/guile/guile-core/configure.in,v retrieving revision 1.109 diff -c -p -w -c -r1.109 configure.in *** configure.in2000/01/23 20:25:27 1.109 --- configure.in2000/02/26 01:56:22 *** dnl Local Variables: *** 491,494 dnl comment-start: "dnl " dnl comment-end: "" dnl comment-start-skip: "\\bdnl\\b\\s *" ! dnl --- 491,494 dnl comment-start: "dnl " dnl comment-end: "" dnl comment-start-skip: "\\bdnl\\b\\s *" ! dnl End:
