mirror of
https://git.savannah.gnu.org/git/guile.git
synced 2025-05-01 04:10:18 +02:00
*** empty log message ***
This commit is contained in:
Rob Browning
parent
42030fb275
commit
c44b6ec0d3
1 changed files with 0 additions and 430 deletions
430
BUGS
430
BUGS
|
|
@ -1,430 +0,0 @@
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
||||||
bug 0 -- no BUGS file
|
|
||||||
reported-by: ttn / 2001-09-25
|
|
||||||
fixed: 2001-09-30 (1.5.x, 1.7.x)
|
|
||||||
|
|
||||||
bugs are good.
|
|
||||||
|
|
||||||
|
|
||||||
bug 1 -- (debug-disable 'debug) has no effect if first form in ~/.guile
|
|
||||||
reported-by: Sven.Hartrumpf@fernuni-hagen.de / 2001-08-31
|
|
||||||
fixed: 2001-11-07 (1.7.x)
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
NJ 2002-03-08:
|
|
||||||
|
|
||||||
Problem was caused by (top-repl)'s loading of (ice-9 debug), which
|
|
||||||
ended with unconditional `(debug-enable 'debug)'. Fixed by removing
|
|
||||||
the offending lines.
|
|
||||||
|
|
||||||
|
|
||||||
bug 2 -- documentation mirroring not complete
|
|
||||||
reported-by: lord@regexps.com / 2001-08
|
|
||||||
fixed: 2002-03-17
|
|
||||||
|
|
||||||
ttn sez:
|
|
||||||
uncollated mirroring is already available:
|
|
||||||
http://savannah.gnu.org/cgi-bin/viewcvs/guile/
|
|
||||||
http://mail.gnu.org/pipermail/guile-devel/
|
|
||||||
|
|
||||||
collated snapshots: http://www.glug.org/snap/ (user initiative)
|
|
||||||
|
|
||||||
|
|
||||||
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...
|
|
||||||
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
||||||
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.)
|
|
||||||
|
|
||||||
|
|
||||||
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.)
|
|
||||||
|
|
||||||
|
|
||||||
bug 7 -- readline configuration anomolies not handled gracefully
|
|
||||||
reported-by: kwright@gis.net / 2001-10-17
|
|
||||||
fixed: not-yet
|
|
||||||
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
NJ 2002-03-08:
|
|
||||||
|
|
||||||
Addressed partially in Makefile.am, by copying guile-procedures.texi
|
|
||||||
to guile-procedures.txt if makeinfo is not available.
|
|
||||||
|
|
||||||
However, a better IMO fix would be to include a prebuilt
|
|
||||||
guile-procedures.txt in the distribution.
|
|
||||||
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
||||||
bug 12 -- goops class redefinition not signalling "no such accessor" error
|
|
||||||
reported-by: wawrzin@cs.tu-berlin.de / 2001-12-04
|
|
||||||
fixed: not-yet
|
|
||||||
|
|
||||||
Thomas Wawrzinek sez:
|
|
||||||
> Running the following script produces some guile output which confueses me:
|
|
||||||
>
|
|
||||||
> ;;; script.scm
|
|
||||||
> (use-modules (oop goops))
|
|
||||||
>
|
|
||||||
> (define-class <root> ())
|
|
||||||
>
|
|
||||||
> (define-class <foo> (<root>)
|
|
||||||
> (a #:init-value #f #:accessor a-value #:init-keyword #:a-value)
|
|
||||||
> (b #:init-value #f #:accessor b-value #:init-keyword #:b-value))
|
|
||||||
>
|
|
||||||
> (define-class <bar> (<foo>))
|
|
||||||
>
|
|
||||||
> (define-method (initialize (o <bar>) . args)
|
|
||||||
> (set! (a-value o) "BAR")
|
|
||||||
> (next-method))
|
|
||||||
>
|
|
||||||
> (define-generic print)
|
|
||||||
>
|
|
||||||
> (define-method (print (o <bar>))
|
|
||||||
> (display (a-value o)) (newline)
|
|
||||||
> (display (b-value o)) (newline))
|
|
||||||
>
|
|
||||||
> ;;; OK, this is very *wrong*!
|
|
||||||
> (define-class <bar> (<root>))
|
|
||||||
>
|
|
||||||
> (define baz (make <bar> #:b-value "BAZ"))
|
|
||||||
>
|
|
||||||
> (print baz)
|
|
||||||
>
|
|
||||||
> $ guile -s script.scm
|
|
||||||
> BAR
|
|
||||||
> #<unknown-immediate 0x69746163>
|
|
||||||
> $ guile -v
|
|
||||||
> Guile 1.5.4
|
|
||||||
> Copyright (c) 1995, 1996, 1997, 2000, 2001 Free Software Foundation
|
|
||||||
> Guile may be distributed under the terms of the GNU General Public Licence;
|
|
||||||
> certain other uses are permitted as well. For details, see the file
|
|
||||||
> `COPYING', which is included in the Guile distribution.
|
|
||||||
> There is no warranty, to the extent permitted by law.
|
|
||||||
>
|
|
||||||
> I'm running on a SuSE Linux 7.2 box ...
|
|
||||||
>
|
|
||||||
> I expected that because of the second (define-class <bar> ...) I would get
|
|
||||||
> some sensible error message (at least about the usage of (a-value ...) in
|
|
||||||
> the (print ...) generic function call).
|
|
||||||
>
|
|
||||||
> Maybe I'm mistaken here, I know that GOOPS has a class redefinition
|
|
||||||
> protocol, but does it go with the define-class macro?
|
|
||||||
>
|
|
||||||
> I accidently had such a second (define-class ...) with an already
|
|
||||||
> used class-name. In a much more complex program than the above, this
|
|
||||||
> resulted in a segmentation fault (backtrace told me it was GC related).
|
|
||||||
>
|
|
||||||
> To avoid such behavior, would it be sensible to have guile indicate
|
|
||||||
> a wrong usage error or something?
|
|
||||||
|
|
||||||
|
|
||||||
bug 13 -- incorrect error reporting after stack overflow
|
|
||||||
reported-by: Panagiotis Vossos <jacbre@internet.gr> / 2002-02-19
|
|
||||||
fixed: not-yet
|
|
||||||
|
|
||||||
Panagiotis Vossos sez:
|
|
||||||
|
|
||||||
I have guile 1.5.4 installed and I discovered something strange.
|
|
||||||
|
|
||||||
guile> (define (foo n) (+ n (foo n)))
|
|
||||||
guile> (foo 10)
|
|
||||||
ERROR: Stack overflow
|
|
||||||
ABORT: (stack-overflow)
|
|
||||||
guile> thisisabug
|
|
||||||
<unnamed port>: In expression thisisabug:
|
|
||||||
<unnamed port>: Unbound variable: thisisabug
|
|
||||||
ABORT: (unbound-variable)
|
|
||||||
guile> (foo 10)
|
|
||||||
<unnamed port>: In expression thisisabug:
|
|
||||||
<unnamed port>: Stack overflow
|
|
||||||
ABORT: (stack-overflow)
|
|
||||||
|
|
||||||
The last message shows the previous unbound variable 'thisisabug'.
|
|
||||||
'foo' is just an example, this seems to happen for every function that
|
|
||||||
causes overflow. It's not serious, but it sure looks misleading..
|
|
||||||
|
|
||||||
Neil Jerram sez:
|
|
||||||
|
|
||||||
It's something to do with the way that debug info frames cope with
|
|
||||||
stack overflow.
|
|
||||||
|
|
||||||
|
|
||||||
bug 14 -- strange gc loop caused by trap misuse
|
|
||||||
reported-by: Neil Jerram <neil@ossau.uklinux.net> / 2002-02-03
|
|
||||||
fixed: not-yet
|
|
||||||
|
|
||||||
Neil Jerram sez:
|
|
||||||
|
|
||||||
Using the current unstable CVS Guile...
|
|
||||||
|
|
||||||
Running under gdb, type in the following:
|
|
||||||
|
|
||||||
(gdb) run -q
|
|
||||||
Starting program: /usr/local/bin/guile -q
|
|
||||||
guile> (trap-set! enter-frame-handler (lambda () 1))
|
|
||||||
(exit-frame-handler #f apply-frame-handler #f enter-frame-handler #<procedure #f ()> traps)
|
|
||||||
guile> (trap-enable 'enter-frame)
|
|
||||||
|
|
||||||
There is no response. Wait a few seconds, and then C-c to send an
|
|
||||||
interrupt. You'll find that the call stack shows a huge number of
|
|
||||||
recursive calls to scm_gc_mark (about 4000 per second waited on my
|
|
||||||
box). (If you don't see scm_gc_mark immediately, you may have
|
|
||||||
interrupted too quickly: let it run for another second and then C-c
|
|
||||||
again.)
|
|
||||||
|
|
||||||
Here's as much of an explanation as I can offer... The intended
|
|
||||||
effect of the two `trap' lines above is that the evaluator calls the
|
|
||||||
specified procedure every time it enters a new evaluation frame or is
|
|
||||||
about to perform an application. However, the procedure above doesn't
|
|
||||||
accept the right number of arguments, so the attempt to call it gives
|
|
||||||
rise to a wrong-num-args error, which (I presume) jumps us out of that
|
|
||||||
level of the evaluator and is caught by the usual REPL machinery in
|
|
||||||
boot-9.scm.
|
|
||||||
|
|
||||||
Then, the next time that we need to GC, we hit this scm_gc_mark loop.
|
|
||||||
My guess is that something about the trap+error scenario has left data
|
|
||||||
or the stack in a state which exposes a bug in the GC.
|
|
||||||
|
|
||||||
|
|
||||||
[BUGS ends here]
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue