diff --git a/BUGS b/BUGS index e9235b567..e69de29bb 100644 --- a/BUGS +++ b/BUGS @@ -1,430 +0,0 @@ -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: 2001-11-07 (1.7.x) - -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. - -NJ 2002-03-08: - -Problem was caused by (top-repl)'s loading of (ice-9 debug), which -ended with unconditional `(debug-enable 'debug)'. Fixed by removing -the offending lines. - - -bug 2 -- documentation mirroring not complete -reported-by: lord@regexps.com / 2001-08 -fixed: 2002-03-17 - -ttn sez: -uncollated mirroring is already available: -http://savannah.gnu.org/cgi-bin/viewcvs/guile/ -http://mail.gnu.org/pipermail/guile-devel/ - -collated snapshots: http://www.glug.org/snap/ (user initiative) - - -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. - -NJ 2002-03-08: - -Addressed partially in Makefile.am, by copying guile-procedures.texi -to guile-procedures.txt if makeinfo is not available. - -However, a better IMO fix would be to include a prebuilt -guile-procedures.txt in the distribution. - - -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]