Commit | Line | Data |
---|---|---|
c14bde86 TTN |
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 | ||
7d87115c TTN |
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 | ||
23c06383 | 13 | DATE is formatted YYYY-MM-DD, or "not-yet". Line numbering is zero-origin; |
7d87115c TTN |
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. | |
c14bde86 TTN |
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 | ||
7d87115c | 22 | bugs are good. |
c14bde86 TTN |
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 | |
7d87115c | 27 | fixed: not-yet |
c14bde86 | 28 | |
7d87115c TTN |
29 | ttn sez: |
30 | buggy behavior confirmed on both 1.5.x and 1.7.x. | |
c14bde86 TTN |
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 | |
7d87115c TTN |
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 | |
23c06383 TTN |
64 | bug 4 -- named-let transform evaluates initvalue in the wrong scope |
65 | reported-by: agj@alum.mit.edu / 2001-09-21 | |
302c12b4 | 66 | fixed: 2001-11-17 (1.7.x) |
23c06383 TTN |
67 | |
68 | currently: | |
69 | > (let name ((var init) ...) body ...) | |
d5b7b584 | 70 | > |
23c06383 | 71 | > to |
d5b7b584 | 72 | > |
23c06383 TTN |
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 | |
969182ac TTN |
85 | bug 5 -- uniform vector read-hash "e" clashes w/ exactness specification |
86 | reported-by: kwright@gis.net / 2001-10-07 | |
1ac8e041 | 87 | fixed: 2001-10-14 (1.5.x, 1.7.x) |
969182ac TTN |
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. | |
d5b7b584 | 92 | > |
969182ac TTN |
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 | |
d5b7b584 TTN |
101 | > |
102 | > This violates both R5RS 7.1 ``Case is insignificant'' and | |
103 | > | |
969182ac TTN |
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 | |
dc5ab9af | 110 | |
1ac8e041 GH |
111 | 2001-10-14 Mikael Djurfeldt <mdj@linnaeus> |
112 | ||
113 | * read.c (scm_lreadr): When user-defined hash procedure returns | |
114 | SCM_UNSPECIFIED: Fall back to standard handling instead of raising | |
115 | an exception. (This prevents parsing of uniform vectors from | |
116 | interfering with parsing of numbers.) | |
117 | ||
dc5ab9af TTN |
118 | \f |
119 | bug 6 -- exactness prefix doesn't do nothing gracefully | |
120 | reported-by: kwright@gis.net / 2001-10-09 | |
1ac8e041 | 121 | fixed: 2001-10-14 (1.5.x, 1.7.x) (see bug 5) |
dc5ab9af TTN |
122 | |
123 | [this may be related to bug 5. --ttn] | |
124 | ||
125 | Keith Wright sez: | |
126 | > The saga continues... | |
d5b7b584 | 127 | > |
dc5ab9af TTN |
128 | > > > The codes for indicating exactness (which can, incidentally, be |
129 | > > > applied to all numerical values) are: | |
130 | > > > | |
131 | > > > * `#e', `#E' -- the number is exact | |
d5b7b584 | 132 | > |
dc5ab9af TTN |
133 | > guile> #E3 ==> 3 |
134 | > guile> #E3.0 | |
135 | > ERROR: In procedure scm_lreadr: | |
136 | > ERROR: unknown # object | |
d5b7b584 | 137 | > |
dc5ab9af | 138 | > Better change the reference manual s/, incidentally,/'t/. |
d5b7b584 | 139 | > |
dc5ab9af TTN |
140 | > (That's a joke son. The Scheme language requires #e in front |
141 | > of any number to at least do nothing successfully.) | |
142 | ||
969182ac | 143 | \f |
6cf0878f TTN |
144 | bug 7 -- readline configuration anomolies not handled gracefully |
145 | reported-by: kwright@gis.net / 2001-10-17 | |
146 | fixed: not-yet | |
147 | ||
148 | \f | |
149 | bug 8 -- install requires makeinfo | |
150 | reported-by: kwright@gis.net / 2001-10-17 | |
151 | fixed: not-yet | |
152 | ||
153 | Keith Wright sez: | |
154 | > I got guile-1.5.4 and installed it on one machine with no problem. | |
155 | > On another I did ./configure;make as before and it died with: | |
d5b7b584 | 156 | > |
6cf0878f TTN |
157 | > > ... |
158 | > > 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 \ | |
159 | > > || { rm guile.texi; false; } | |
160 | > > rm -f guile-procedures.txt | |
161 | > > makeinfo --force -o guile-procedures.txt guile.texi || test -f guile-procedures.txt | |
162 | > > /bin/sh: makeinfo: command not found | |
163 | > > make[1]: *** [guile-procedures.txt] Error 1 | |
164 | > > make[1]: Leaving directory `/home/kwright/build/guile-1.5.4/libguile' | |
165 | > > make: *** [all-recursive] Error 1 | |
d5b7b584 | 166 | > |
6cf0878f TTN |
167 | > I get the impression that it is supposed to build without 'makeinfo', |
168 | > if this is not so it should be mentioned in the README or INSTALL. | |
169 | ||
170 | \f | |
d5b7b584 TTN |
171 | bug 9 -- sibling threads not infinite looping |
172 | reported-by: giraud@tif.inria.fr / 2001-09-24 | |
173 | fixed: not-yet | |
174 | ||
175 | Manuel Giraud sez: | |
176 | > I've configure guile-1.5.4 '--with-threads' and '--with-modules' on a | |
177 | > "classical" Linux box and used this code that crash silently : | |
178 | > | |
179 | > (use-modules (ice-9 threads)) | |
180 | > | |
181 | > (begin-thread | |
182 | > (let loop () | |
183 | > (display "a") | |
184 | > (newline) | |
185 | > (loop))) | |
186 | > | |
187 | > (begin-thread | |
188 | > (let loop () | |
189 | > (display "b") | |
190 | > (newline) | |
191 | > (loop))) | |
192 | ||
193 | mdj sez: | |
194 | + 2001-10-06 Mikael Djurfeldt <mdj@linnaeus> | |
195 | + | |
196 | + These changes fixes a race condition in the Guile coop - pthread | |
197 | + compatibility code. | |
198 | + | |
199 | + * coop.c (mother_awake_p): New variable. | |
200 | + (coop_create): Set mother_awake_p before creating or signalling | |
201 | + mother; wait until mother is going to sleep before returning. | |
202 | + (mother): Reset mother_awake_p before going to sleep. | |
203 | + | |
204 | ||
205 | ttn sez: | |
206 | crash still occurs w/ "guile -s bug.scm" (cvs checkout on 2001/11/06). | |
207 | however, "guile -l bug.scm" works as expected. | |
208 | ||
209 | \f | |
3989f082 TTN |
210 | bug 10 -- embedded libltdl masks system version unconditionally |
211 | reported-by: grib@linuxdevel.com / 2001-11-04 | |
212 | fixed: not-yet | |
213 | ||
214 | Bill Gribble sez: | |
215 | > The guideline for when to use the convenience version of libltdl is | |
216 | > this: | |
217 | > | |
218 | > > In general you can safely use the convenience library in | |
219 | > > programs which don't depend on other libraries that might | |
220 | > > use libltdl too. | |
221 | > | |
222 | > So guile's use of the convenience library embodies an assumption about | |
223 | > programs which use guile: that they will not use libltdl except through | |
224 | > guile's wrapper (dynamic-link and friends). | |
225 | > | |
226 | > It seems like this is a bad assumption for guile to make, since it is | |
227 | > intended to be used as an extension language for many different kinds of | |
228 | > programs and not to put a priori restrictions on what they can do. | |
229 | > Especially when those restrictions are not documented. | |
230 | > | |
231 | > I would suggest that prior to the guile-1.6 release the use of the | |
232 | > convenience ltdl library be removed, instead depending on an installed | |
233 | > version of libltdl. | |
234 | ||
235 | \f | |
22ad0748 TTN |
236 | bug 11 -- (ice-9 optargs) #:rest arg polluted by keys/values |
237 | reported-by: ttn / 2001-11-09 | |
238 | fixed: not-yet | |
239 | ||
240 | ttn sez: | |
241 | > the following code displays | |
242 | > | |
243 | > (#<procedure good x> ()) | |
244 | > (#<procedure good x> (1)) | |
245 | > (#<procedure good x> ((1 2 3))) | |
246 | > (#<procedure blah x> JAY KAY (#:j JAY #:k KAY)) | |
247 | > (#<procedure blah x> JAY KAY (#:j JAY #:k KAY 1)) | |
248 | > (#<procedure blah x> JAY KAY (#:j JAY #:k KAY (1 2 3))) | |
249 | > | |
250 | > but `x' should be the same for both `good' and `blah': | |
251 | > | |
252 | > (use-modules (ice-9 optargs) (ice-9 rdelim)) | |
253 | > | |
254 | > (define* (good #:rest x) | |
255 | > (write-line (list good x))) | |
256 | > | |
257 | > (good) | |
258 | > (good 1) | |
259 | > (good '(1 2 3)) | |
260 | > | |
261 | > (define* (blah #:key (j 'j) (k 'k) #:rest x) | |
262 | > (write-line (list blah j k x))) | |
263 | > | |
264 | > (blah #:j 'JAY #:k 'KAY) | |
265 | > (blah #:j 'JAY #:k 'KAY 1) | |
266 | > (blah #:j 'JAY #:k 'KAY '(1 2 3)) | |
267 | ||
268 | \f | |
c14bde86 | 269 | [BUGS ends here] |