Well, quote is syntax. You can't pass it around like a function. Guile 2.0
fixes that:
that's an improvement?
In Guile 1.9.10
scheme@(guile-user) 0e1000
Throw to key `out-of-range':
ERROR: In procedure string-number:
ERROR: Value out of range: 1000
In Guile 1.9.10, typing
'(1 ']x)
or lots of similar cases involving ']', to the repl
gets into an infinite loop.
Let me know if I'm missing something here.
Independent of standards, it means your arithmetic is inconsistent:
scheme@(guile-user) (= -0.0 0.0)
#t
scheme@(guile-user) (= +inf.0 +inf.0)
#t
scheme@(guile-user) (= 1.0 1.0)
#t
scheme@(guile-user) (= (/ 1.0 0.0) +inf.0)
#t
scheme@(guile-user) (= (/
Here's a slightly better example:
scheme@(guile-user) ( (/ 1.0 -0.0) -1e100 1e100 (/ 1.0 0.0))
#t
I find this issue has been discussed elsewhere and:
However, the IEEE committee decided that the advantages of utilizing the sign
of zero outweighed the
disadvantages.
humph. Another committee covers itself with glory.
I just noticed a case where -0.0 is apparently negative:
scheme@(guile-user) (/ 1.0 0.0)
+inf.0
scheme@(guile-user) (/ -1.0 0.0)
-inf.0
scheme@(guile-user) (/ 1.0 -0.0)
-inf.0
scheme@(guile-user) (/ -1.0 -0.0)
+inf.0
scheme@(guile-user) (negative? -0.0)
#f
And here's a separate oddity:
Right -- I realized just as I hit return that 1+ could go to 1+i, and
I like the name 1+, but it seemed kinda poltroonish to send a
complaint, then immediately say oh forget it. I can't decide
what the right thing is in this regard -- guile's choice is the best I
can come up with.
I believe r5rs says an identifier can't start with a digit, but
guile allows it to:
scheme@(guile-user) (symbol? (make-symbol 0))
#t
scheme@(guile-user) (symbol-string (make-symbol 0))
0
scheme@(guile-user) (keyword? (symbol-keyword (string-symbol 0)))
#t
scheme@(guile-user) (symbol?
Is this a bug?
scheme@(guile-user) (call/cc (lambda (a . b) (a 1)))
1
scheme@(guile-user) (call/cc (lambda arg ((car arg) 1)))
1
scheme@(guile-user) (call/cc (lambda (a b) (a 1)))
ERROR: Wrong number of arguments to #program 8bf5330 at standard input:3:9 (a
b)
r5rs.html and r6rs.html say Proc
Can you confirm that it allows you to build Guile with 32-bit offsets and Snd
with 64-bit offsets (or vice versa)?
Yes, I think it is ok.
This is trickier than I thought -- it's not the GC after all. In my configure
script for Snd, autoconf defines _FILE_OFFSET_BITS to 64 if large files are
implemented.
The config.h include precedes everything else. When scm_getc is called
within guile, it thinks sizeof(scm_t_port) is 92.
Can you spot some way in which what you are doing
is different to this?
I believe this is a GC problem; you're doing exactly what I'm doing,
but in a context where the GC is not called. If I place the
skip comment function in its own file, and compile it
with optimization turned off,
In the new Guile (1.9.0), the scsh-derived code to implement #|..|# block
comment processing triggers either a glibc memory complaint
or a segfault. (The following code is slightly translated, so
I may have introduced typos, but the basic idea has worked for
maybe 10 years):
static SCM
Why do both Guile and Gauche give this result in string-ci?
(and the other string-ci functions similarly):
guile (char-ci? #\a #\_)
#t
guile (string-ci? a _)
#f
gosh (char-ci? #\a #\_)
#t
gosh (string-ci? a _)
#f
The odd chars are ASCII 91 to 96:
guile (string-ci? a [)
#f
guile (char-ci? #\a
guile (version)
1.8.6
guile (+ 1050879503.0+3.0i 1050879503)
2101759006.0+3.0i
guile (- 1050879503.0+3.0i 1050879503)
Segmentation fault (core dumped)
in gdb:
guile (- 1050879503.0+3.0i 1050879503)
Program received signal SIGSEGV, Segmentation fault.
0x4006ea80 in scm_difference (x=0x40251128,
Rats. I'll try to look at libguile/numbers.c soon.
Any news on that? :-)
No -- sorry -- my TODO list is so long, even emacs complains.
(There's a problem: the scheme spec seems to insist on the simplest
ratio which they define in terms of the size of the integers -- my
rationalize used
I think number? should not signal an error -- it should
return either #t or #f:
guile (number? '1e310)
ERROR: In procedure string-number:
ERROR: Value out of range: 310
ABORT: (out-of-range)
guile ERROR: In procedure scm_read_expression:
ERROR: standard input:1:17: unexpected )
ABORT:
I believe this shows a bug in letrec:
guile (let ((x 1)) (let ((x 32) (y x)) y))
1
guile (let ((x 1)) (letrec ((x 32) (y x)) y))
Backtrace:
In standard input:
2: 0* (let* ((x 1)) (letrec ((x 32) (y x)) y))
2: 1 (letrec ((x 32) (y x)) y)
standard input:2:14: In expression (letrec (# #)
I read those same paragraphs and interpreted them differently,
but now I agree with you.
guile (number? '1.0+.1i)
#f
guile .1
0.1
guile 1+.1i
1.0+0.1i
guile 1.0+.1i
ERROR: Unbound variable: 1.0+.1i
ABORT: (unbound-variable)
Other similar cases:
.1+.0i
1.+.0i
.1+.1i
1e1+.1i
Sorry, I don't see what you're referring to -- if the preceding
(lambda () (begin ...)) doesn't get an error, then there's no
difference that I can see in the formal syntax between it and
the same thing sitting in a let.
oh -- it's the (f) that triggers the silly error, not the preceding stuff.
Hmm -- gauche and stklos are happy with the first version,
and guile is happy with this version:
guile (let ((f (lambda () (begin (define x 0)) (+ x 1 (f))
1
This is basically taken from Jaffer's r4rstest.html.
I've stared at the formal syntax, and read it as:
lambda is (lambda formals body)
body is definition* sequence
definition* is
(define variable expression)
| (define (variable def formals) body)
| (begin definition*)
so (lambda () (begin (define ...) ... in both forms looks
Is this a bug?
guile (begin (define x 0) (+ x 1))
1
guile (lambda () (begin (define x 0) (+ x 1)))
#procedure #f ()
guile (let ((f (lambda () (begin (define x 0) (+ x 1) (f))
Backtrace:
In standard input:
3: 0* (let* ((f (lambda () #))) (f))
3: 1 [#procedure #f ()]
standard
map does not accept no list:
guile (map (lambda (a) a))
Backtrace:
In standard input:
1: 0* [map #procedure #f (a)]
standard input:1:1: In procedure map in expression (map (lambda # a)):
standard input:1:1: Wrong number of arguments to #primitive-generic map
ABORT: (wrong-number-of-args)
+
I thought it odd that:
guile (string-length )
0
guile (string-ref 3)
#\nul
but:
guile (string-set! 123 #\a)
guile (string-ref 123)
#\a
guile (substring 123 124)
Backtrace:
In standard input:
6: 0* [substring {123} 124]
standard input:6:1: In procedure substring in expression
according to r5rs.html, these should signal an error, I believe:
guile (string-set! (symbol-string 'immutable)
0
#\?)
guile (define (g) ***)
guile (string-set! (g) 0 #\?)
guile (g)
?**
A couple similar cases:
guile ( 2 1 hi)
#f
guile (* 0 hi)
0
On the (apply ...) business, I'd rather get an error than have something
broken go by just because it is prettier. That null list is going to trip
you...
There are actually more problems in that area; for example:
guile ( 2 1 1.0+3.0i)
#f
which perhaps should be an error also. My druthers for the
one arg case is to simply disallow it -- why does Guile support
stuff like:
guile ()
#t
gcd is supposed to ignore factors of -1.
is restricted to reals -- a complex arg should be an error.
I hate to report a bug in my own handiwork, but I noticed
this morning, while writing a scheme numerics test suite
(numtst.c in the Snd tools directory), that if the error is
1.0, rationalize rounds the wrong way:
guile (rationalize 0.1 1.0)
1.0
guile (rationalize -0.9 1.0)
0.0
Rats. I'll try
guile ( 1.0+1.0i)
#t
guile ( 2.0 1.0+1.0i)
Backtrace:
In standard input:
2: 0* [ 2.0 {1.0+1.0i}]
standard input:2:1: In procedure in expression ( 2.0 1.0+1.0i):
standard input:2:1: Wrong type: 1.0+1.0i
ABORT: (wrong-type-arg)
(Happens also with = =)
Since Guile now supports exact rationals, shouldn't it return an exact result?
I actually agree with you (I implemented rationalize in Guile, and originally
it always returned a ratio -- why else call it rationalize?), but Marius
pointed out that R5RS says With the exception of inexact-exact,
just to follow up -- not as an argument, but to add data --
this inaccurate printout happens with smaller numbers
(in the 2^50 range), and as noted by others, the internal
representation seems ok. Here's another example:
guile 1007.0
1010.0
guile (odd? 1007.0)
Is this an important problem for you in practice? What's the impact?
(Asking for prioritization purposes...)
What? Is this something new that Guile prioritizes bug reports?
Decide for yourself.
Not sure this is a bug, but it is confusing:
guile (version)
1.8.5
guile (+ 40816513889983671.0 3.0)
40816513889983700.0
guile (= (+ 40816513889983671.0 3.0) 40816513889983700.0)
#f
guile (= (+ 40816513889983671.0 3.0) 40816513889983674.0)
#t
In the CVS Guile (or reasonable facsimile thereof)
(expt 2 (log 0))
gets into an infinite loop.
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-guile
In the CVS guile, if you don't have GUILE_LOAD_PATH set,
you get an immediate segfault:
/home/bil/cl/ gdb ../test/bin/guile
(gdb) run
Starting program: /home/bil/test/bin/guile
[New Thread 1075184800 (LWP 29892)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1075184800
(begin
(display 1)
#!
(display 2)
!#
)
gets:
ERROR: In procedure scm_lreadr:
ERROR: tmp34.scm:6:2: unexpected )
ABORT: (read-error)
whereas
(begin
#!
(display 2)
!#
(display 1)
)
is ok. This is the case in both the current CVS guile and version 1.6.4.
I also have hit that bug -- next time it happens, I'll
try to track it down. Have you (Dirk) had a chance to
look at the procedure-source bug mentioned a few weeks
ago (and related to this one, I bet)? It is a real
problem for me that procedure-source is not a usable
source anymore -- I can't
In Sunday's Guile:
guile (define (hi a) (+ a 1))
guile (procedure-source hi)
(lambda (a) [EMAIL PROTECTED] (+ a 1))
Is this (the new [EMAIL PROTECTED]) an intentional change?
If I call the procedure, the [EMAIL PROTECTED] disappears:
guile (define (hi a) (+ a 1))
guile (hi 1)
2
guile
Now (in Saturday's CVS Guile) I get this:
guile (define defvar #f)
guile (set! defvar define)
guile (set! defvar define)
Backtrace:
In standard input:
4: 0* (set! #primitive-builtin-macro! define define)
standard input:4:1: In expression (set! #primitive-builtin-macro! define define):
standard
In the current CVS Guile:
/home/bil/cl/ ../test/bin/guile
guile (define defvar #f)
guile (set! defvar define)
guile (set! defvar define)
Backtrace:
In standard input:
3: 0* (set! defvar define)
standard input:3:1: In procedure memoization in expression (set! defvar define):
standard input:3:1:
Can you try that variant? I have comitted it to HEAD.
So far so good -- I'll keep watching for the old troubles (this bug is
not completely repeatable since my giant test suite has a lot of
built-in randomness, and it never happens in simple cases, so it's
hard to be sure about anything). Your
define* is a bit confusing in that it simply ignores invalid arguments:
/home/bil/cl/ guile
guile (use-modules (ice-9 optargs))
guile (define* (ho #:key a b) (list a b))
guile (ho 1 2)
(#f #f)
guile (ho 1 2 3 4 5)
(#f #f)
guile (ho 1 2 3 #:a 1)
(1 #f)
In Lisp, this gives an eror:
USER(1): (defun
Please try again, I think I have fixed it:
The backtrace problem seems to be fixed -- thanks!
In Friday's CVS guile there are two redundant declarations.
In gc.h (line 273):
SCM_API unsigned long scm_gc_cells_collected;
SCM_API unsigned long scm_gc_cells_collected;
net_db.h: SCM_API SCM
0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
(gdb) bt
#0 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
I've hit this so many times I've stopped using the CVS Guile -- there's
definitely a bug tickled by backtrace, but I haven't had time to try to
Another oddity in ice-9/format.scm:
Thanks, I recorded this in our backwater bug database, but I'm afraid
I'll need a patch for fixing this... do you have any?
Perhaps this will do it (line 740):
(if param-value-found (format:error misplaced '#'))
as in:
((#\#)
Here are some ways to get guile 1.6.4 (and 1.7.0 I think)
to segfault or go into an infinite loop:
guile (array-in-bounds? 1.5)
Program received signal SIGSEGV, Segmentation fault.
scm_array_in_bounds_p (v=0x7f, args=0x2974) at unif.c:1023
1023 switch SCM_TYP7 (v)
guile
The documentation says the argument to make-stack can be a
continuation, but I think that case segfaults:
guile (let ((cont (call-with-current-continuation
(lambda (return)
return
(make-stack cont))
Program received signal SIGSEGV, Segmentation fault.
0x4006fa65
Currently format truncates a list at the 100th item without any warning:
(define nums (list
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32 33 34 35 36 37 38 39 40 41 42
43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70
Could you condense this into a patch that we can apply?
For Mac OSX 10.2:
change libguile/gc_os_dep.c line 255 from
# if defined(macosx)
to
# if defined(macosx) || (defined(__APPLE__) defined(__ppc__))
This could be
# if defined(macosx) || defined(__ppc__)
but in linuxppc, the compiler
Just in case the blizzard of stuff in the Mac OSX message
obscured a simple bugfix:
in iselect.c the HAVE_UNISTD_H macro is used before
it has any chance to be defined. The code should be
something like:
#include libguile/_scm.h
#ifdef HAVE_UNISTD_H
#include unistd.h
#endif
#include
guile (number-string 5 2.0)
standard input:1:1: In procedure number-string in expression (number-string 5 2.0):
standard input:1:1: Wrong type argument in position 2 (expecting INUMP): 2.0
ABORT: (wrong-type-arg)
INUMP is internal jargon -- integer or exact integer would be better.
Also, I
(use-modules (ice-9 syncase))
(define-syntax IF
(syntax-rules ()
((IF form1 form2) (if form1 form2))
((IF form1 form2 form3) (if form1 form2 form3
In 1.6.0 and including the CVS guile of Aug 22 (I didn't try a later
one until Friday's), this worked fine. In the current CVS guile,
On the Sun (Solaris 2.9), guile 1.6.0, scm_num2dbl segfaults if
accidentally passed #f instead of a number.
Program received signal SIGSEGV, Segmentation fault.
0x3ba15c in scm_num2dbl (a=0x2174, why=0x404a40 list2vct) at numbers.c:3641
3641 } else if (SCM_BIGP (a)) {
(gdb) where
#0
On Mac OSX 10.2, guile 1.6.0 guile-snarf screws up (It's ok in guile 1.4).
I can send details, but I'm told that someone is already looking into this
bug -- what is its status?
___
Bug-guile mailing list
[EMAIL PROTECTED]
I guess this is not news, but just in case... Some Guile numerical
primitives that should (could?) accept inexact integers (at least that's
the way I read r5rs) do not. The remainder example below is taken
from r5rs:
guile (version)
1.7.0
guile (modulo 4.0 2)
Backtrace:
In standard input:
I think define-syntax is stumbling on vector constants:
(use-modules (ice-9 syncase))
(define-syntax IF
(syntax-rules ()
((IF form1 form2) (if form1 form2))
((IF form1 form2 form3) (if form1 form2 form3
(IF (not (vector? #(4.0)))
(display oops))
invalid syntax #(4.0)
In
Can I suggest a change in libguile/gsubr.c line 105 from:
fputs (ERROR in scm_c_make_gsubr: too many args\n, stderr);
to
fprintf (stderr, ERROR in scm_c_make_gsubr: too many args (%d) to %s\n, req +
opt + rst, name);
Also is it really necessary to call exit after this error?
(The
I think that the SGI C compiler/library for Irix 6.3 does not
include snprintf used in libguile/version.c around line 83.
I changed it to use sprintf to continue compilation.
Also, less certain about this (our SGI's here are a mess),
but I think uint32_t is defined in sys/types.h but the
So the single quotes aren't having the expected effect? What shell
are you using, and does it help if the makefile is changed to refer to
and-let\*.scm or 'and-let\*.scm'?
This was using tcsh -- I'll try the two cases and report back.
Hmm. Could this one be a libtool version issue? What
On both the Sun (Solaris 2.7) and Irix 5.3:
the Makefile (install) line
.././install-sh -c -m 644 and-let-star-compat.scm \
/usr/local/share/guile/1.5.2/ice-9/'and-let*.scm'
actually copies and-let-star-compat.scm to and-let-star.scm!
/usr/local/share/guile/1.5.2/ice-9/ diff
I noticed two glitches in the 1.5.2 installation on the Irix 5.3.
I still hit the lt_preloaded_symbols problem mentioned earlier.
It is triggered by DYNAMIC_LOADING begin defined (by configure),
and used in libguile/guile.c at the line (89):
#ifdef DYNAMIC_LINKING
LTDL_SET_PRELOADED_SYMBOLS
Following up the previous note, in guile 1.5.1, all's well
except that the SGI compiler wants the GC_noop1 declaration
to precede its use. As a side note, in Solaris 2.7, I
got this warning:
gcc -DHAVE_CONFIG_H -I.. -I./.. -I../libltdl -g -O2 -Wall -Wmissing-prototypes -c
posix.c -fPIC -DPIC
I tried to build the snapshot on SGI Irix 5.3, and hit a few problems.
First, inttypes.h and sys/types.h aren't compatible on this system:
/usr/people/bil/test/guile-core-20010820/ make
{...]
cc -DHAVE_CONFIG_H -I.. -I./.. -I../libltdl -g -c alist.c -DPIC -o alist.o
cfe: Warning 753:
Thanks very much for the response -- it turns out that my local
CVS directory was garbled probably by a disk crash we suffered
a few weeks ago -- I started over from scratch and everything
is ok now. Sorry to waste your time.
___
Bug-guile mailing
I decided to nuke the old cvs directory and checkout guile from
scratch, and it appears I have the current version now -- not
sure how cvs got confused.
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
I must have some local problem with CVS; I went back to autogen.sh
etc (even make distclean etc), and still only get:
/user/b/bil/test/ find guile-core -type f -exec grep -l WARN_DEPRECATED {} \;
guile-core/libguile/deprecation.c
/user/b/bil/test/
And the EXTRA_DOT_X_FILES business is also
I think this macro is missing from the CVS guile-core/libguile/deprecation.h.
I used
#define GUILE_WARN_DEPRECATED_DEFAULT no
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
Out of mild curiousity, I translated some of Clisp's numerical tests
(released under GPL in Clisp, so presumably this is ok) to Scheme
using the "pass-if" style of Guile's tests, and noticed some odd
cases. I spot-checked some of the worst looking results in
gmp-3.0.1's pexpr program which
In Friday's CVS guile,
if you (print-enable 'source), hit an error while parsing a
procedure, then call backtrace, you can get a segfault if
the garbage collector is called during the backtrace -- the
"pstate" is freed. I can't seem to find a simple case of this bug,
but here's some info. An
In the current CVS guile, the build process creates a file
libguile/guile-procedures.txt that is about 48 MBytes, mostly white
space (this file used to be very much smaller).
___
Bug-guile mailing list
[EMAIL PROTECTED]
Also, as I'm sure you guys know already (I'm not on this
mailing list), (use-modules (ice-9 syncase)) dies in the
current guile with a segfault.
Hmm, it works for me. Can you try the latest CVS version and give
detailed instructions to make it crash?
Yesterday's version works fine -- I
I think the line (209 in optargs.scm)
((allow-other-keys) #:allow-other-keys-value)
should be
((allow-other-keys) #:allow-other-keys)
Also, as I'm sure you guys know already (I'm not on this
mailing list), (use-modules (ice-9 syncase)) dies in the
current guile with a segfault.
Guile 1.4.1 builds and works fine in Mac OS-X (developer
version), but there's one small glitch in the configure
process -- it doesn't recognize the name "Darwin" as the
OS name (I think -- I'm no Mac or configure expert).
The mac-supplied config.guess and config.sub (from
/usr/libexec) do work.
I think 'help' has trouble with goops entities:
guile-oops-0.1.8 is buggy. Please use 0.9.0.
Humph! I was using 0.9.0:
/home/bil/test/guile-oops-0.9.0/ ./guile-oops
guile (use-modules (ice-9 session))
guile (use-modules (oop goops))
guile (goops-version)
"0.9.0"
guile (help define-class)
guile (version)
"1.4"
guile (define hi (lambda (a) (do () (( a 6)) (set! a ho
guile (hi 2)
standard input:1:41: In expression (set! a ho):
standard input:1:41: Unbound variable: ho
ABORT: (unbound-variable)
Type "(backtrace)" to get more information or "(debug)" to enter the debugger.
guile
On an SGI running irix 5.3, after ./configure and make, the build
stops with
cc -DHAVE_CONFIG_H -I.. -I./.. -I../libltdl -g -c net_db.c -DPIC -o .libs/net_db.lo
cfe: Error: net_db.c, line 194: 'NETDB_INTERNAL' undefined; reoccurrences will not be
reported.
if (h_errno == NETDB_INTERNAL)
Pursuant to yesterday's request to try out the current version
of guile on various machines, I noticed the following problems:
on linuxppc 2000, the include of ltdl.h line 237 dynl.c needs
to be #include libltdl/ltdl.h (as in the other reference to
it -- forgot write down where I saw it).
on
line 73 of the cvs guile-core INSTALL file says "-qt"
but I think it means "-lqt".
83 matches
Mail list logo
