BUGS This file contains bugs we haven't fixed yet, and some we have. The format is very simple (one bug per page): # line regexp 1 bug NUMBER -- ONE-LINE-DESCRIPTION ^bug ([0-9]+) -- (.+)$ 2 reported-by: SOMEONE / DATE ^reported-by: ([^/]) */ *(.+)$ 3 fixed: DATE (for guile VERSION) ^fixed: (.+) .for guile (.+).$ 4+ OTHER-NOTES DATE is formatted YYYY-MM-DD, or "not-yet". Line numbering is zero-origin; line 0 is empty (newline always follows newpage (recognizable w/ "\f\n")). The suggested regexps can be used in a line-oriented parser. You can use "fixed: no-need (EXPLANATION)" if the bug doesn't need to be fixed. EXPLANATION might be "not a bug", "user error", etc. bug 0 -- no BUGS file reported-by: ttn / 2001-09-25 fixed: 2001-09-30 (1.5.x, 1.7.x) bugs are good. bug 1 -- (debug-disable 'debug) has no effect if first form in ~/.guile reported-by: Sven.Hartrumpf@fernuni-hagen.de / 2001-08-31 fixed: not-yet ttn sez: buggy behavior confirmed on both 1.5.x and 1.7.x. on the other hand, when second or later, the expected effect (disabling use of debugging evaluator) seems to be reflected when viewing the debug options. it could be that the bug is in display and not the actual setting. bug 2 -- documentation mirroring not complete reported-by: lord@regexps.com / 2001-08 fixed: not-yet ttn sez: uncollated mirroring is already available: http://savannah.gnu.org/cgi-bin/viewcvs/guile/ http://mail.gnu.org/pipermail/guile-devel/ bug 3 -- design decisions not recorded reported-by: lord@regexps.com / 2001-08 fixed: not-yet changes are made w/ little documentation on their motivation, design and consequences. past initiatives and current maintainer discipline to support them need shoring up. ttn sez: someone also mentioned that process and product are orthogonal; nastiness can result in/from either, and for different reasons. i tend to believe this up until a certain point, when the process becomes self-aware and includes its own improvement in its considerations. then, hopefully it becomes light. to change people is difficult, but that's why we have guile... bug 4 -- named-let transform evaluates initvalue in the wrong scope reported-by: agj@alum.mit.edu / 2001-09-21 fixed: 2001-11-17 (1.7.x) currently: > (let name ((var init) ...) body ...) > > to > > (letrec ((name (lambda (var ...) body ...))) > (name init ...)) should be: > ((letrec ((name (lambda (var ...) body ...))) name) init ...) Dirk Herrmann sez: I will do it - no big deal (I hope). But, I won't have time to do it before next week. What about adding this code as a test case to the test suite? Until it is fixed, it can be tagged as expected to fail. bug 5 -- uniform vector read-hash "e" clashes w/ exactness specification reported-by: kwright@gis.net / 2001-10-07 fixed: 2001-10-14 (1.5.x, 1.7.x) Keith Wright sez: > Before getting into philosophy, I want to mention that while poking > around and rethinking I found the following Bug. > > guile> (version) > "1.5.2" > guile> #E3 > 3 > guile> #e3 > ERROR: read:uniform-vector list not found > ABORT: (misc-error) > guile> 3 > > This violates both R5RS 7.1 ``Case is insignificant'' and > > > From: guile-1.5.2/doc/ref/guile.info-3 Line 568 > > > > The codes for indicating exactness (which can, incidentally, be > > applied to all numerical values) are: > > > > * `#e', `#E' -- the number is exact 2001-10-14 Mikael Djurfeldt * read.c (scm_lreadr): When user-defined hash procedure returns SCM_UNSPECIFIED: Fall back to standard handling instead of raising an exception. (This prevents parsing of uniform vectors from interfering with parsing of numbers.) bug 6 -- exactness prefix doesn't do nothing gracefully reported-by: kwright@gis.net / 2001-10-09 fixed: 2001-10-14 (1.5.x, 1.7.x) (see bug 5) [this may be related to bug 5. --ttn] Keith Wright sez: > The saga continues... > > > > The codes for indicating exactness (which can, incidentally, be > > > applied to all numerical values) are: > > > > > > * `#e', `#E' -- the number is exact > > guile> #E3 ==> 3 > guile> #E3.0 > ERROR: In procedure scm_lreadr: > ERROR: unknown # object > > Better change the reference manual s/, incidentally,/'t/. > > (That's a joke son. The Scheme language requires #e in front > of any number to at least do nothing successfully.) bug 7 -- readline configuration anomolies not handled gracefully reported-by: kwright@gis.net / 2001-10-17 fixed: not-yet bug 8 -- install requires makeinfo reported-by: kwright@gis.net / 2001-10-17 fixed: not-yet Keith Wright sez: > I got guile-1.5.4 and installed it on one machine with no problem. > On another I did ./configure;make as before and it died with: > > > ... > > on.doc vports.doc weaks.doc symbols-deprecated.doc regex-posix.doc ramap.doc unif.doc filesys.doc posix.doc net_db.doc socket.doc | ./guile-snarf-docs-texi > guile.texi \ > > || { rm guile.texi; false; } > > rm -f guile-procedures.txt > > makeinfo --force -o guile-procedures.txt guile.texi || test -f guile-procedures.txt > > /bin/sh: makeinfo: command not found > > make[1]: *** [guile-procedures.txt] Error 1 > > make[1]: Leaving directory `/home/kwright/build/guile-1.5.4/libguile' > > make: *** [all-recursive] Error 1 > > I get the impression that it is supposed to build without 'makeinfo', > if this is not so it should be mentioned in the README or INSTALL. bug 9 -- sibling threads not infinite looping reported-by: giraud@tif.inria.fr / 2001-09-24 fixed: not-yet Manuel Giraud sez: > I've configure guile-1.5.4 '--with-threads' and '--with-modules' on a > "classical" Linux box and used this code that crash silently : > > (use-modules (ice-9 threads)) > > (begin-thread > (let loop () > (display "a") > (newline) > (loop))) > > (begin-thread > (let loop () > (display "b") > (newline) > (loop))) mdj sez: + 2001-10-06 Mikael Djurfeldt + + These changes fixes a race condition in the Guile coop - pthread + compatibility code. + + * coop.c (mother_awake_p): New variable. + (coop_create): Set mother_awake_p before creating or signalling + mother; wait until mother is going to sleep before returning. + (mother): Reset mother_awake_p before going to sleep. + ttn sez: crash still occurs w/ "guile -s bug.scm" (cvs checkout on 2001/11/06). however, "guile -l bug.scm" works as expected. bug 10 -- embedded libltdl masks system version unconditionally reported-by: grib@linuxdevel.com / 2001-11-04 fixed: not-yet Bill Gribble sez: > The guideline for when to use the convenience version of libltdl is > this: > > > In general you can safely use the convenience library in > > programs which don't depend on other libraries that might > > use libltdl too. > > So guile's use of the convenience library embodies an assumption about > programs which use guile: that they will not use libltdl except through > guile's wrapper (dynamic-link and friends). > > It seems like this is a bad assumption for guile to make, since it is > intended to be used as an extension language for many different kinds of > programs and not to put a priori restrictions on what they can do. > Especially when those restrictions are not documented. > > I would suggest that prior to the guile-1.6 release the use of the > convenience ltdl library be removed, instead depending on an installed > version of libltdl. bug 11 -- (ice-9 optargs) #:rest arg polluted by keys/values reported-by: ttn / 2001-11-09 fixed: no-need (behavior consistent w/ Common Lisp, user error) ttn sez: > the following code displays > > (# ()) > (# (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))) > > but `x' should be the same for both `good' and `blah': > > (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)) mvo sez: > In Common Lisp, there are no non-key rest-args when you have keyword > parameters. After the required and optional arguments, there must > follow an even number of additional arguments, and every two of them > are treated as a keyword/value pair. > > I think it makes sense the way CL specifies this. Anything beyond > this would lead to confusion. If you want to go beyond what (ice-9 > optargs) offers, yo are probably best off writing your own argument > parser. bug 12 -- goops class redefinition not signalling "no such accessor" error reported-by: wawrzin@cs.tu-berlin.de / 2001-12-04 fixed: not-yet Thomas Wawrzinek sez: > Running the following script produces some guile output which confueses me: > > ;;; script.scm > (use-modules (oop goops)) > > (define-class ()) > > (define-class () > (a #:init-value #f #:accessor a-value #:init-keyword #:a-value) > (b #:init-value #f #:accessor b-value #:init-keyword #:b-value)) > > (define-class ()) > > (define-method (initialize (o ) . args) > (set! (a-value o) "BAR") > (next-method)) > > (define-generic print) > > (define-method (print (o )) > (display (a-value o)) (newline) > (display (b-value o)) (newline)) > > ;;; OK, this is very *wrong*! > (define-class ()) > > (define baz (make #:b-value "BAZ")) > > (print baz) > > $ guile -s script.scm > BAR > # > $ guile -v > Guile 1.5.4 > Copyright (c) 1995, 1996, 1997, 2000, 2001 Free Software Foundation > Guile may be distributed under the terms of the GNU General Public Licence; > certain other uses are permitted as well. For details, see the file > `COPYING', which is included in the Guile distribution. > There is no warranty, to the extent permitted by law. > > I'm running on a SuSE Linux 7.2 box ... > > I expected that because of the second (define-class ...) I would get > some sensible error message (at least about the usage of (a-value ...) in > the (print ...) generic function call). > > Maybe I'm mistaken here, I know that GOOPS has a class redefinition > protocol, but does it go with the define-class macro? > > I accidently had such a second (define-class ...) with an already > used class-name. In a much more complex program than the above, this > resulted in a segmentation fault (backtrace told me it was GC related). > > To avoid such behavior, would it be sensible to have guile indicate > a wrong usage error or something? bug 13 -- incorrect error reporting after stack overflow reported-by: Panagiotis Vossos / 2002-02-19 fixed: not-yet Panagiotis Vossos sez: I have guile 1.5.4 installed and I discovered something strange. guile> (define (foo n) (+ n (foo n))) guile> (foo 10) ERROR: Stack overflow ABORT: (stack-overflow) guile> thisisabug : In expression thisisabug: : Unbound variable: thisisabug ABORT: (unbound-variable) guile> (foo 10) : In expression thisisabug: : Stack overflow ABORT: (stack-overflow) The last message shows the previous unbound variable 'thisisabug'. 'foo' is just an example, this seems to happen for every function that causes overflow. It's not serious, but it sure looks misleading.. Neil Jerram sez: It's something to do with the way that debug info frames cope with stack overflow. bug 14 -- strange gc loop caused by trap misuse reported-by: Neil Jerram / 2002-02-03 fixed: not-yet Neil Jerram sez: Using the current unstable CVS Guile... Running under gdb, type in the following: (gdb) run -q Starting program: /usr/local/bin/guile -q guile> (trap-set! enter-frame-handler (lambda () 1)) (exit-frame-handler #f apply-frame-handler #f enter-frame-handler # traps) guile> (trap-enable 'enter-frame) There is no response. Wait a few seconds, and then C-c to send an interrupt. You'll find that the call stack shows a huge number of recursive calls to scm_gc_mark (about 4000 per second waited on my box). (If you don't see scm_gc_mark immediately, you may have interrupted too quickly: let it run for another second and then C-c again.) Here's as much of an explanation as I can offer... The intended effect of the two `trap' lines above is that the evaluator calls the specified procedure every time it enters a new evaluation frame or is about to perform an application. However, the procedure above doesn't accept the right number of arguments, so the attempt to call it gives rise to a wrong-num-args error, which (I presume) jumps us out of that level of the evaluator and is caught by the usual REPL machinery in boot-9.scm. Then, the next time that we need to GC, we hit this scm_gc_mark loop. My guess is that something about the trap+error scenario has left data or the stack in a state which exposes a bug in the GC. [BUGS ends here]