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 You can use "fixed: no-need (EXPLANATION)" if the bug doesn't need to be
  18 fixed.  EXPLANATION might be "not a bug", "user error", etc.
  19
  20 \f
  21 bug 0 -- no BUGS file
  22 reported-by: ttn / 2001-09-25
  23 fixed: 2001-09-30 (1.5.x, 1.7.x)
  24
  25 bugs are good.
  26
  27 \f
  28 bug 1 -- (debug-disable 'debug) has no effect if first form in ~/.guile
  29 reported-by: Sven.Hartrumpf@fernuni-hagen.de / 2001-08-31
  30 fixed: not-yet
  31
  32 ttn sez:
  33 buggy behavior confirmed on both 1.5.x and 1.7.x.
  34
  35 on the other hand, when second or later, the expected effect (disabling use of
  36 debugging evaluator) seems to be reflected when viewing the debug options.  it
  37 could be that the bug is in display and not the actual setting.
  38
  39 \f
  40 bug 2 -- documentation mirroring not complete
  41 reported-by: lord@regexps.com / 2001-08
  42 fixed: not-yet
  43
  44 ttn sez:
  45 uncollated mirroring is already available:
  46 http://savannah.gnu.org/cgi-bin/viewcvs/guile/
  47 http://mail.gnu.org/pipermail/guile-devel/
  48
  49 \f
  50 bug 3 -- design decisions not recorded
  51 reported-by: lord@regexps.com / 2001-08
  52 fixed: not-yet
  53
  54 changes are made w/ little documentation on their motivation, design and
  55 consequences.  past initiatives and current maintainer discipline to support
  56 them need shoring up.
  57
  58 ttn sez:
  59 someone also mentioned that process and product are orthogonal; nastiness can
  60 result in/from either, and for different reasons.  i tend to believe this up
  61 until a certain point, when the process becomes self-aware and includes its own
  62 improvement in its considerations.  then, hopefully it becomes light.
  63
  64 to change people is difficult, but that's why we have guile...
  65
  66 \f
  67 bug 4 -- named-let transform evaluates initvalue in the wrong scope
  68 reported-by: agj@alum.mit.edu / 2001-09-21
  69 fixed: 2001-11-17 (1.7.x)
  70
  71 currently:
  72 > (let name ((var init) ...) body ...)
  73 >
  74 > to
  75 >
  76 > (letrec ((name (lambda (var ...) body ...)))
  77 >   (name init ...))
  78
  79 should be:
  80 > ((letrec ((name (lambda (var ...) body ...))) name) init ...)
  81
  82 Dirk Herrmann sez:
  83 I will do it - no big deal (I hope).  But, I won't have time to do it
  84 before next week.  What about adding this code as a test case to the test
  85 suite?  Until it is fixed, it can be tagged as expected to fail.
  86
  87 \f
  88 bug 5 -- uniform vector read-hash "e" clashes w/ exactness specification
  89 reported-by: kwright@gis.net / 2001-10-07
  90 fixed: 2001-10-14 (1.5.x, 1.7.x)
  91
  92 Keith Wright sez:
  93 > Before getting into philosophy, I want to mention that while poking
  94 > around and rethinking I found the following Bug.
  95 >
  96 >     guile> (version)
  97 >     "1.5.2"
  98 >     guile> #E3
  99 >     3
 100 >     guile> #e3
 101 >     ERROR: read:uniform-vector list not found
 102 >     ABORT: (misc-error)
 103 >     guile> 3
 104 >
 105 > This violates both R5RS 7.1 ``Case is insignificant'' and
 106 >
 107 > > From: guile-1.5.2/doc/ref/guile.info-3 Line 568
 108 > >
 109 > >     The codes for indicating exactness (which can, incidentally, be
 110 > >  applied to all numerical values) are:
 111 > >
 112 > >   * `#e', `#E' -- the number is exact
 113
 114 2001-10-14  Mikael Djurfeldt  <mdj@linnaeus>
 115
 116         * read.c (scm_lreadr): When user-defined hash procedure returns
 117         SCM_UNSPECIFIED: Fall back to standard handling instead of raising
 118         an exception.  (This prevents parsing of uniform vectors from
 119         interfering with parsing of numbers.)
 120
 121 \f
 122 bug 6 -- exactness prefix doesn't do nothing gracefully
 123 reported-by: kwright@gis.net / 2001-10-09
 124 fixed: 2001-10-14 (1.5.x, 1.7.x) (see bug 5)
 125
 126 [this may be related to bug 5. --ttn]
 127
 128 Keith Wright sez:
 129 > The saga continues...
 130 >
 131 > > >     The codes for indicating exactness (which can, incidentally, be
 132 > > >  applied to all numerical values) are:
 133 > > >
 134 > > >   * `#e', `#E' -- the number is exact
 135 >
 136 >   guile> #E3  ==>  3
 137 >   guile> #E3.0
 138 >   ERROR: In procedure scm_lreadr:
 139 >   ERROR: unknown # object
 140 >
 141 > Better change the reference manual s/, incidentally,/'t/.
 142 >
 143 > (That's a joke son.  The Scheme language requires #e in front
 144 > of any number to at least do nothing successfully.)
 145
 146 \f
 147 bug 7 -- readline configuration anomolies not handled gracefully
 148 reported-by: kwright@gis.net / 2001-10-17
 149 fixed: not-yet
 150
 151 \f
 152 bug 8 -- install requires makeinfo
 153 reported-by: kwright@gis.net / 2001-10-17
 154 fixed: not-yet
 155
 156 Keith Wright sez:
 157 > I got guile-1.5.4 and installed it on one machine with no problem.
 158 > On another I did ./configure;make as before and it died with:
 159 >
 160 > > ...
 161 > > 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 \
 162 > > || { rm guile.texi; false; }
 163 > > rm -f guile-procedures.txt
 164 > > makeinfo --force -o guile-procedures.txt guile.texi || test -f guile-procedures.txt
 165 > > /bin/sh: makeinfo: command not found
 166 > > make[1]: *** [guile-procedures.txt] Error 1
 167 > > make[1]: Leaving directory `/home/kwright/build/guile-1.5.4/libguile'
 168 > > make: *** [all-recursive] Error 1
 169 >
 170 > I get the impression that it is supposed to build without 'makeinfo',
 171 > if this is not so it should be mentioned in the README or INSTALL.
 172
 173 \f
 174 bug 9 -- sibling threads not infinite looping
 175 reported-by: giraud@tif.inria.fr / 2001-09-24
 176 fixed: not-yet
 177
 178 Manuel Giraud sez:
 179 > I've configure guile-1.5.4 '--with-threads' and '--with-modules' on a
 180 > "classical" Linux box and used this code that crash silently :
 181 >
 182 > (use-modules (ice-9 threads))
 183 >
 184 > (begin-thread
 185 >  (let loop ()
 186 >    (display "a")
 187 >    (newline)
 188 >    (loop)))
 189 >
 190 > (begin-thread
 191 >  (let loop ()
 192 >    (display "b")
 193 >    (newline)
 194 >    (loop)))
 195
 196 mdj sez:
 197 + 2001-10-06  Mikael Djurfeldt  <mdj@linnaeus>
 198 +
 199 +       These changes fixes a race condition in the Guile coop - pthread
 200 +       compatibility code.
 201 +
 202 +       * coop.c (mother_awake_p): New variable.
 203 +       (coop_create): Set mother_awake_p before creating or signalling
 204 +       mother; wait until mother is going to sleep before returning.
 205 +       (mother): Reset mother_awake_p before going to sleep.
 206 +
 207
 208 ttn sez:
 209 crash still occurs w/ "guile -s bug.scm" (cvs checkout on 2001/11/06).
 210 however, "guile -l bug.scm" works as expected.
 211
 212 \f
 213 bug 10 -- embedded libltdl masks system version unconditionally
 214 reported-by: grib@linuxdevel.com / 2001-11-04
 215 fixed: not-yet
 216
 217 Bill Gribble sez:
 218 > The guideline for when to use the convenience version of libltdl is
 219 > this:
 220 >
 221 > > In general you can safely use the convenience library in
 222 > > programs which don't depend on other libraries that might
 223 > > use libltdl too.
 224 >
 225 > So guile's use of the convenience library embodies an assumption about
 226 > programs which use guile: that they will not use libltdl except through
 227 > guile's wrapper (dynamic-link and friends).
 228 >
 229 > It seems like this is a bad assumption for guile to make, since it is
 230 > intended to be used as an extension language for many different kinds of
 231 > programs and not to put a priori restrictions on what they can do.
 232 > Especially when those restrictions are not documented.
 233 >
 234 > I would suggest that prior to the guile-1.6 release the use of the
 235 > convenience ltdl library be removed, instead depending on an installed
 236 > version of libltdl.
 237
 238 \f
 239 bug 11 -- (ice-9 optargs) #:rest arg polluted by keys/values
 240 reported-by: ttn / 2001-11-09
 241 fixed: no-need (behavior consistent w/ Common Lisp, user error)
 242
 243 ttn sez:
 244 > the following code displays
 245 >
 246 >   (#<procedure good x> ())
 247 >   (#<procedure good x> (1))
 248 >   (#<procedure good x> ((1 2 3)))
 249 >   (#<procedure blah x> JAY KAY (#:j JAY #:k KAY))
 250 >   (#<procedure blah x> JAY KAY (#:j JAY #:k KAY 1))
 251 >   (#<procedure blah x> JAY KAY (#:j JAY #:k KAY (1 2 3)))
 252 >
 253 > but `x' should be the same for both `good' and `blah':
 254 >
 255 >   (use-modules (ice-9 optargs) (ice-9 rdelim))
 256 >
 257 >   (define* (good #:rest x)
 258 >     (write-line (list good x)))
 259 >
 260 >   (good)
 261 >   (good 1)
 262 >   (good '(1 2 3))
 263 >
 264 >   (define* (blah #:key (j 'j) (k 'k) #:rest x)
 265 >     (write-line (list blah j k x)))
 266 >
 267 >   (blah #:j 'JAY #:k 'KAY)
 268 >   (blah #:j 'JAY #:k 'KAY 1)
 269 >   (blah #:j 'JAY #:k 'KAY '(1 2 3))
 270
 271 mvo sez:
 272 > In Common Lisp, there are no non-key rest-args when you have keyword
 273 > parameters.  After the required and optional arguments, there must
 274 > follow an even number of additional arguments, and every two of them
 275 > are treated as a keyword/value pair.
 276 >
 277 > I think it makes sense the way CL specifies this.  Anything beyond
 278 > this would lead to confusion.  If you want to go beyond what (ice-9
 279 > optargs) offers, yo are probably best off writing your own argument
 280 > parser.
 281
 282 \f
 283 [BUGS ends here]