* eval.c: Removed bogus comment about acros.
[bpt/guile.git] / BUGS
CommitLineData
c14bde86
TTN
1BUGS
2
3This file contains bugs we haven't fixed yet, and some we have.
4The format is very simple (one bug per page):
5
7d87115c
TTN
6# line regexp
7
81 bug NUMBER -- ONE-LINE-DESCRIPTION ^bug ([0-9]+) -- (.+)$
92 reported-by: SOMEONE / DATE ^reported-by: ([^/]) */ *(.+)$
103 fixed: DATE (for guile VERSION) ^fixed: (.+) .for guile (.+).$
114+ OTHER-NOTES
12
23c06383 13DATE is formatted YYYY-MM-DD, or "not-yet". Line numbering is zero-origin;
7d87115c
TTN
14line 0 is empty (newline always follows newpage (recognizable w/ "\f\n")).
15The suggested regexps can be used in a line-oriented parser.
c14bde86
TTN
16
17\f
18bug 0 -- no BUGS file
19reported-by: ttn / 2001-09-25
20fixed: 2001-09-30 (1.5.x, 1.7.x)
21
7d87115c 22bugs are good.
c14bde86
TTN
23
24\f
25bug 1 -- (debug-disable 'debug) has no effect if first form in ~/.guile
26reported-by: Sven.Hartrumpf@fernuni-hagen.de / 2001-08-31
7d87115c 27fixed: not-yet
c14bde86 28
7d87115c
TTN
29ttn sez:
30buggy behavior confirmed on both 1.5.x and 1.7.x.
c14bde86
TTN
31
32on the other hand, when second or later, the expected effect (disabling use of
33debugging evaluator) seems to be reflected when viewing the debug options. it
34could be that the bug is in display and not the actual setting.
35
36\f
7d87115c
TTN
37bug 2 -- documentation mirroring not complete
38reported-by: lord@regexps.com / 2001-08
39fixed: not-yet
40
41ttn sez:
42uncollated mirroring is already available:
43http://savannah.gnu.org/cgi-bin/viewcvs/guile/
44http://mail.gnu.org/pipermail/guile-devel/
45
46\f
47bug 3 -- design decisions not recorded
48reported-by: lord@regexps.com / 2001-08
49fixed: not-yet
50
51changes are made w/ little documentation on their motivation, design and
52consequences. past initiatives and current maintainer discipline to support
53them need shoring up.
54
55ttn sez:
56someone also mentioned that process and product are orthogonal; nastiness can
57result in/from either, and for different reasons. i tend to believe this up
58until a certain point, when the process becomes self-aware and includes its own
59improvement in its considerations. then, hopefully it becomes light.
60
61to change people is difficult, but that's why we have guile...
62
63\f
23c06383
TTN
64bug 4 -- named-let transform evaluates initvalue in the wrong scope
65reported-by: agj@alum.mit.edu / 2001-09-21
302c12b4 66fixed: 2001-11-17 (1.7.x)
23c06383
TTN
67
68currently:
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
76should be:
77> ((letrec ((name (lambda (var ...) body ...))) name) init ...)
78
79Dirk Herrmann sez:
80I will do it - no big deal (I hope). But, I won't have time to do it
81before next week. What about adding this code as a test case to the test
82suite? Until it is fixed, it can be tagged as expected to fail.
83
84\f
969182ac
TTN
85bug 5 -- uniform vector read-hash "e" clashes w/ exactness specification
86reported-by: kwright@gis.net / 2001-10-07
1ac8e041 87fixed: 2001-10-14 (1.5.x, 1.7.x)
969182ac
TTN
88
89Keith 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
1112001-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
119bug 6 -- exactness prefix doesn't do nothing gracefully
120reported-by: kwright@gis.net / 2001-10-09
1ac8e041 121fixed: 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
125Keith 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
144bug 7 -- readline configuration anomolies not handled gracefully
145reported-by: kwright@gis.net / 2001-10-17
146fixed: not-yet
147
148\f
149bug 8 -- install requires makeinfo
150reported-by: kwright@gis.net / 2001-10-17
151fixed: not-yet
152
153Keith 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
171bug 9 -- sibling threads not infinite looping
172reported-by: giraud@tif.inria.fr / 2001-09-24
173fixed: not-yet
174
175Manuel 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
193mdj 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
205ttn sez:
206crash still occurs w/ "guile -s bug.scm" (cvs checkout on 2001/11/06).
207however, "guile -l bug.scm" works as expected.
208
209\f
3989f082
TTN
210bug 10 -- embedded libltdl masks system version unconditionally
211reported-by: grib@linuxdevel.com / 2001-11-04
212fixed: not-yet
213
214Bill 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
236bug 11 -- (ice-9 optargs) #:rest arg polluted by keys/values
237reported-by: ttn / 2001-11-09
238fixed: not-yet
239
240ttn 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]