*** empty log message ***

[bpt/guile.git] / BUGS

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.

You can use "fixed: no-need (EXPLANATION)" if the bug doesn't need to be
fixed.  EXPLANATION might be "not a bug", "user error", etc.

\f
bug 0 -- no BUGS file
reported-by: ttn / 2001-09-25
fixed: 2001-09-30 (1.5.x, 1.7.x)

bugs are good.

\f
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.

\f
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/

\f
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...

\f
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.

\f
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  <mdj@linnaeus>

	* 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.)

\f
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.)

\f
bug 7 -- readline configuration anomolies not handled gracefully
reported-by: kwright@gis.net / 2001-10-17
fixed: not-yet

\f
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.

\f
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  <mdj@linnaeus>
+
+ 	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.

\f
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.

\f
bug 11 -- (ice-9 optargs) #:rest arg polluted by keys/values
reported-by: ttn / 2001-11-09
fixed: no-need (behavior consistent w/ Common Lisp, user error)

ttn sez:
> the following code displays
>
>   (#<procedure good x> ())
>   (#<procedure good x> (1))
>   (#<procedure good x> ((1 2 3)))
>   (#<procedure blah x> JAY KAY (#:j JAY #:k KAY))
>   (#<procedure blah x> JAY KAY (#:j JAY #:k KAY 1))
>   (#<procedure blah x> 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))

mvo sez:
> In Common Lisp, there are no non-key rest-args when you have keyword
> parameters.  After the required and optional arguments, there must
> follow an even number of additional arguments, and every two of them
> are treated as a keyword/value pair.
>
> I think it makes sense the way CL specifies this.  Anything beyond
> this would lead to confusion.  If you want to go beyond what (ice-9
> optargs) offers, yo are probably best off writing your own argument
> parser.

\f
[BUGS ends here]