BUGS

   1 BUGS
   2
   3 This file contains bugs we haven't fixed yet, and some we have.
   4 The format is very simple (one bug per page):
   5
   6 #   line                                   regexp
   7
   8 1   bug NUMBER -- ONE-LINE-DESCRIPTION     ^bug ([0-9]+) -- (.+)$
   9 2   reported-by: SOMEONE / DATE            ^reported-by: ([^/]) */ *(.+)$
  10 3   fixed: DATE (for guile VERSION)        ^fixed: (.+) .for guile (.+).$
  11 4+  OTHER-NOTES
  12
  13 DATE is formatted YYYY-MM-DD, or "not-yet".  Line numbering is zero-origin;
  14 line 0 is empty (newline always follows newpage (recognizable w/ "\f\n")).
  15 The suggested regexps can be used in a line-oriented parser.
  16
  17 \f
  18 bug 0 -- no BUGS file
  19 reported-by: ttn / 2001-09-25
  20 fixed: 2001-09-30 (1.5.x, 1.7.x)
  21
  22 bugs are good.
  23
  24 \f
  25 bug 1 -- (debug-disable 'debug) has no effect if first form in ~/.guile
  26 reported-by: Sven.Hartrumpf@fernuni-hagen.de / 2001-08-31
  27 fixed: not-yet
  28
  29 ttn sez:
  30 buggy behavior confirmed on both 1.5.x and 1.7.x.
  31
  32 on the other hand, when second or later, the expected effect (disabling use of
  33 debugging evaluator) seems to be reflected when viewing the debug options.  it
  34 could be that the bug is in display and not the actual setting.
  35
  36 \f
  37 bug 2 -- documentation mirroring not complete
  38 reported-by: lord@regexps.com / 2001-08
  39 fixed: not-yet
  40
  41 ttn sez:
  42 uncollated mirroring is already available:
  43 http://savannah.gnu.org/cgi-bin/viewcvs/guile/
  44 http://mail.gnu.org/pipermail/guile-devel/
  45
  46 \f
  47 bug 3 -- design decisions not recorded
  48 reported-by: lord@regexps.com / 2001-08
  49 fixed: not-yet
  50
  51 changes are made w/ little documentation on their motivation, design and
  52 consequences.  past initiatives and current maintainer discipline to support
  53 them need shoring up.
  54
  55 ttn sez:
  56 someone also mentioned that process and product are orthogonal; nastiness can
  57 result in/from either, and for different reasons.  i tend to believe this up
  58 until a certain point, when the process becomes self-aware and includes its own
  59 improvement in its considerations.  then, hopefully it becomes light.
  60
  61 to change people is difficult, but that's why we have guile...
  62
  63 \f
  64 bug 4 -- named-let transform evaluates initvalue in the wrong scope
  65 reported-by: agj@alum.mit.edu / 2001-09-21
  66 fixed: not-yet
  67
  68 currently:
  69 > (let name ((var init) ...) body ...)
  70 >
  71 > to
  72 >
  73 > (letrec ((name (lambda (var ...) body ...)))
  74 >   (name init ...))
  75
  76 should be:
  77 > ((letrec ((name (lambda (var ...) body ...))) name) init ...)
  78
  79 Dirk Herrmann sez:
  80 I will do it - no big deal (I hope).  But, I won't have time to do it
  81 before next week.  What about adding this code as a test case to the test
  82 suite?  Until it is fixed, it can be tagged as expected to fail.
  83
  84 \f
  85 bug 5 -- uniform vector read-hash "e" clashes w/ exactness specification
  86 reported-by: kwright@gis.net / 2001-10-07
  87 fixed: not-yet
  88
  89 Keith Wright sez:
  90 > Before getting into philosophy, I want to mention that while poking
  91 > around and rethinking I found the following Bug.
  92 >
  93 >     guile> (version)
  94 >     "1.5.2"
  95 >     guile> #E3
  96 >     3
  97 >     guile> #e3
  98 >     ERROR: read:uniform-vector list not found
  99 >     ABORT: (misc-error)
 100 >     guile> 3
 101 >
 102 > This violates both R5RS 7.1 ``Case is insignificant'' and
 103 >
 104 > > From: guile-1.5.2/doc/ref/guile.info-3 Line 568
 105 > >
 106 > >     The codes for indicating exactness (which can, incidentally, be
 107 > >  applied to all numerical values) are:
 108 > >
 109 > >   * `#e', `#E' -- the number is exact
 110
 111 \f
 112 bug 6 -- exactness prefix doesn't do nothing gracefully
 113 reported-by: kwright@gis.net / 2001-10-09
 114 fixed: not-yet
 115
 116 [this may be related to bug 5. --ttn]
 117
 118 Keith Wright sez:
 119 > The saga continues...
 120 >
 121 > > >     The codes for indicating exactness (which can, incidentally, be
 122 > > >  applied to all numerical values) are:
 123 > > >
 124 > > >   * `#e', `#E' -- the number is exact
 125 >
 126 >   guile> #E3  ==>  3
 127 >   guile> #E3.0
 128 >   ERROR: In procedure scm_lreadr:
 129 >   ERROR: unknown # object
 130 >
 131 > Better change the reference manual s/, incidentally,/'t/.
 132 >
 133 > (That's a joke son.  The Scheme language requires #e in front
 134 > of any number to at least do nothing successfully.)
 135
 136 \f
 137 bug 7 -- readline configuration anomolies not handled gracefully
 138 reported-by: kwright@gis.net / 2001-10-17
 139 fixed: not-yet
 140
 141 \f
 142 bug 8 -- install requires makeinfo
 143 reported-by: kwright@gis.net / 2001-10-17
 144 fixed: not-yet
 145
 146 Keith Wright sez:
 147 > I got guile-1.5.4 and installed it on one machine with no problem.
 148 > On another I did ./configure;make as before and it died with:
 149 >
 150 > > ...
 151 > > 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 \
 152 > > || { rm guile.texi; false; }
 153 > > rm -f guile-procedures.txt
 154 > > makeinfo --force -o guile-procedures.txt guile.texi || test -f guile-procedures.txt
 155 > > /bin/sh: makeinfo: command not found
 156 > > make[1]: *** [guile-procedures.txt] Error 1
 157 > > make[1]: Leaving directory `/home/kwright/build/guile-1.5.4/libguile'
 158 > > make: *** [all-recursive] Error 1
 159 >
 160 > I get the impression that it is supposed to build without 'makeinfo',
 161 > if this is not so it should be mentioned in the README or INSTALL.
 162
 163 \f
 164 [BUGS ends here]