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. 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: not-yet 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)) [BUGS ends here]