Nils Durner [EMAIL PROTECTED] writes:
Hi,
the attached patch fixes compiler errors on Win32/MinGW.
- execv (exec_file, exec_argv);
+ execv (exec_file,
+#ifdef __MINGW32__
+ (const char * const *)
+#endif
+ exec_argv);
Thanks for the patch, but do you understand exactly what
moayyad sadi [EMAIL PROTECTED] writes:
I have an old debian were the docs says that dh_* should not be used any more
and more to
shm_*
Yes, that's correct. (Assuming you mean gh_* and scm_*)
but they weren't documented well at least in the tutorial
Can you let us know what version you're
Anthony David [EMAIL PROTECTED] writes:
URL:
http://savannah.gnu.org/bugs/?17853
Thanks for taking the time to report this. We believe we've fixed
this now in CVS, so the problem should be gone when 1.8.1 is
released. (And we'll close the bug at that time.)
Regards,
Neil
Dale Smith [EMAIL PROTECTED] writes:
The failure was in srfi-14.test
Running srfi-14.test
UNRESOLVED: srfi-14.test: Latin-1 (8-bit charset): char-set:letter
(membership)
UNRESOLVED: srfi-14.test: Latin-1 (8-bit charset): char-set:letter (size)
UNRESOLVED: srfi-14.test: Latin-1 (8-bit
Ross Boylan [EMAIL PROTECTED] writes:
I got the tarball for guile-1.6.8 and ran configure at the top level. I
did this solely to get the documentation.
When I do make pdf from the top, I get (excerpt)
make[1]: Entering directory `/usr/local/src/tools/guile-1.6.8/doc'
Making pdf in ref
Ralf Wildenhues [EMAIL PROTECTED] writes:
Hello bug-guile readers,
The tarball at ftp://ftp.gnu.org/gnu/guile/guile-1.8.1.tar.gz
has a configure script that uses the script config.rpath. But
this script is not shipped with the tarball. This can cause
interesting and weird bugs, if I
Ryan Moore [EMAIL PROTECTED] writes:
Making a shared array out of a bit vector does not result in a bit
vector being returned when the shared array does not have as many
elements as the original:
(define somebits (make-bitvector 8 #f))
(define subbits (make-shared-array somebits (lambda
Ross Boylan [EMAIL PROTECTED] writes:
2. In the doc/tutorial, I got these errors, even on the 2nd run of
pdftex:
Chapter 4 [11]
l.945: Undefined cross reference `Scheme data representation-snt'.
l.945: Undefined cross reference `Scheme data representation-snt'.
l.945: Undefined cross
Ross Boylan [EMAIL PROTECTED] writes:
Thanks for fixing it!
Any chance of backporting this to 1.6, since that's still in use at
least on Debian (cf the thread about problems with some module in 1.8
that's preventing the move to 1.8)?
Yes, I've done that. I can't say exactly when the next
Eric Eisner [EMAIL PROTECTED] writes:
Hello,
The built-in 'procedure-source' changes its output in procedures calling
'let' after the procedure in is applied. For example (define (f) (let ((x
3)) x)) (procedure-source f) returns '(lambda () (let ((x 3)) x))
But (begin (f)
Compiling current CVS on Debian Etch:
...
gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I../lib -I../lib -pthread -g -O2 -Wall
-Wmissing-prototypes -Werror -MT libguile_la-srfi-14.lo -MD -MP -MF
.deps/libguile_la-srfi-14.Tpo -c srfi-14.c -fPIC -DPIC -o
.libs/libguile_la-srfi-14.o
cc1: warnings
gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I../lib -I../lib -pthread -g -O2 -Wall
-Wmissing-prototypes -Werror -MT libguile_i18n_v_0_la-i18n.lo -MD -MP -MF
.deps/libguile_i18n_v_0_la-i18n.Tpo -c i18n.c -fPIC -DPIC -o
.libs/libguile_i18n_v_0_la-i18n.o
i18n.c:186: error: expected '=', ',', ';',
Neil Jerram [EMAIL PROTECTED] writes:
Compiling current CVS on Debian Etch:
...
gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I../lib -I../lib -pthread -g -O2
-Wall -Wmissing-prototypes -Werror -MT libguile_la-srfi-14.lo -MD -MP -MF
.deps/libguile_la-srfi-14.Tpo -c srfi-14.c -fPIC -DPIC -o
+1,9 @@
+2007-10-19 Neil Jerram [EMAIL PROTECTED]
+
+ * eval.c (unmemoize_delay): Extend the environment before
+ unmemoizing the promise thunk. This fixes a segmentation fault
+ reported by Frank Schwidom.
+
2007-10-17 Ludovic Courtès [EMAIL PROTECTED]
* read.c
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Hi,
Neil Jerram [EMAIL PROTECTED] writes:
I believe the patch below is the correct fix for this. Please test
and/or comment!
Works like a charm!
For 1.6 the fix is slightly different; please see below and let me
know if you have any comments
[EMAIL PROTECTED] (Ludovic Courtès) writes:
It seems unlikely to introduce a regression. However, that means we
should keep producing bug-fix releases of 1.6?
I suggest that we ask on the lists if there is any demand for another
1.6.x. When we do this, we should say what has been fixed since
[EMAIL PROTECTED] (Ludovic Courtès) writes:
(I had forgotten about it, which may be an indication that we should
really start using the bug tracker.)
What would that involve?
Not much actually. Just mention it in the relevant pieces of
documentation. The bug tracker automatically sends
Neil Jerram [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Hi,
Neil Jerram [EMAIL PROTECTED] writes:
The patch below cures this, but is it correct?
No, because M4 macro `gl_EARLY' requires `AC_GNU_SOURCE', which in turn
defines `_GNU_SOURCE' when available.
My
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Hi,
Mike Gran [EMAIL PROTECTED] writes:
The 1.8.2 manual, in the 3.4.X Intro to Breakpoints section describes
functionality that doesn't exist, and suggests adding to the .guile
file the following libraries that do not appear in the distro
[EMAIL PROTECTED] (Ludovic Courtès) writes:
My `gl_EARLY' does require `AC_GNU_SOURCE'. I'm using:
$ gnulib-tool --version
/usr/bin/gnulib-tool (GNU gnulib) 2007-07-01
This is from Debian unstable.
(I couldn't find in Gnulib's Git log whether `AC_GNU_SOURCE' appeared in
between both
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Hi,
Neil Jerram [EMAIL PROTECTED] writes:
So would then ask people to raise bugs on savannah, instead of
emailing bug-guile? Or can we implement something to catch emails to
bug-guile and automatically raise corresponding bugs on savannah
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Did you try clearing the `m4' dir (expect for `gnulib-cache.m4') and
re-running `gnulib-tool --update'? Assuming we both use the same Gnulib
snapshot, `m4' should contain the same files on both machines. With
Debian's `gnulib-20071001+dfsg-1', I
Neil Jerram [EMAIL PROTECTED] writes:
So I guess the question becomes: why don't alloca.m4 and extensions.m4
appear for me?
OK, problem solved now, and was all my fault. Since switching to a
different machine, I've been running cvs update without the -d option
(because I forgot to copy over
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Hi Neil,
Neil Jerram [EMAIL PROTECTED] writes:
It would be convenient if it worked though, as then we wouldn't have
to invalidate email bug-guile@gnu.org as a method of reporting bugs.
Note: just because we recommend using the bug tracker
URL:
http://savannah.gnu.org/bugs/?21483
Summary: mandelbug whit GUILE_DEBUG_MALLOC
Project: Guile
Submitted by: ossau
Submitted on: Wednesday 10/31/07 at 00:31
Category: None
Severity: 3 - Normal
Update of bug #20941 (project guile):
Status:None = Invalid
___
Follow-up Comment #1:
Is this causing real trouble for you?
From the practical point of view, isn't it straightforward
[EMAIL PROTECTED] [EMAIL PROTECTED] writes:
Hello,
Sorry if this email is a waste of your time. I think I might have encountered
an error in guile.
I am running guile with a very recent install for Fedora Core 8.
Thanks for your email; it certainly was not a waste of time.
Simply put: If
Mike Gran [EMAIL PROTECTED] writes:
The automake manual recommends that .m4 files use a serial number
for versioning, so that it is possible to tell when an .m4 installed
by aclocal is updated.
Sounds good. Could you provide a patch? (I know it's trivial, but it
will give a useful check
Mike Gran [EMAIL PROTECTED] writes:
From: Neil Jerram [EMAIL PROTECTED]
The automake manual recommends that .m4 files use a serial number
for versioning, so that it is possible to tell when an .m4 installed
by aclocal is updated.
Sounds good. Could you provide a patch? (I know it's
Roger Mc Murtrie [EMAIL PROTECTED] writes:
Still fails with 4:
Yes, but not because of stack overflow. So the doubling of the stack
size was successful.
sizeof long: 4
As hoped. The point is that most of the data that Guile puts on the C
stack are pointers or pointer-like. Hence the
Roger Mc Murtrie [EMAIL PROTECTED] writes:
Seems to be 32 bit?
Well, according to your previous email:
checking size of off_t... 8
Which means 64 bit.
I'm struggling to get my head round Darwin's overall story on 64-bit
APIs. For off_t, it seems to have decided that it's fine to go
Follow-up Comment #1, bug #22022 (project guile):
I think I have a fix for the segfault, but now I'm seeing several other test
failures. Here's one...
(pass-if (let ((table (make-hash-table)))
(hashx-set! (lambda (k v) 1) assoc table 'foo 'bar)
(equal?
Follow-up Comment #2, bug #22022 (project guile):
Another one:
(pass-if (equal? #hash-table 34/61
(with-output-to-string (lambda () (write table)))
Actual output here has 33 instead of 34. I believe 33 is correct, because
the additions to the hash table run from 2
Gregory Marton [EMAIL PROTECTED] writes:
As an enhancement request, it would be nice for the common case to be able to
pass a hash-function argument and assoc to make-hash-table or to have a
(make-hashx-table hash assoc [size]), and in either case to remember the hash
function so that resize
Follow-up Comment #3, bug #22022 (project guile):
And here are all the remaining ones. I've added a (pk ...) in each case, so
the output from make check shows what the actual hash?-ref value was.
;;; (#f)
FAIL: hash.test: auto-resizing hashx: (equal? (quote eq) (pk (hashq-ref table
4)))
;;;
Gregory Marton [EMAIL PROTECTED] writes:
Ack. I think I meant to replace assoc as well, with something like
(lambda (k alist) (cdar alist)).
That wouldn't be assoc-like. (lambda (k al) (car al)) accesses the
correct level of alist structure, but would fault in the case where al
is empty.
So
Roger Mc Murtrie [EMAIL PROTECTED] writes:
I think the libguile-ltdl is a separate thing.
Yes, libguile-ltdl was a tweaked version of libltdl that we used
during the 1.6.x series, while waiting for upstream to make a fix that
we needed. It isn't needed anymore.
On 11/01/2008, at 11:56 PM,
Roger Mc Murtrie [EMAIL PROTECTED] writes:
This might help:
http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting
Roger
Thank you, that was helpful. Amongst a lot of detail, one of its
messages was that most system call APIs (i.e. the traditional ones
_without_ 64 in
Roger Mc Murtrie [EMAIL PROTECTED] writes:
Hi Neil,
That sounds like an excellent solution.
Great, thanks. I'll just give others a chance to comment before
proceeding.
Attached is my config.guess file. (Its just the one from the
distribution with no changes).
I'm sorry, I wasn't clear.
Neil Jerram [EMAIL PROTECTED] writes:
Roger Mc Murtrie [EMAIL PROTECTED] writes:
make check-TESTS
PASS: test-system-cmds
ERROR: In procedure dynamic-link:
ERROR: file: libguile-srfi-srfi-1-v-3, message: dlopen(libguile-
srfi-srfi-1-v-3.a, 9): image not found
FAIL: test-require-extension
Roger Mc Murtrie [EMAIL PROTECTED] writes:
I did as you suggested but make check produced the same result.
As before ./configure failed with a couple of undefined symbols so I
had build without shared libraries.
I'm sorry, but I've lost track of what those undefined symbol errors
were, and I
Gregory Marton [EMAIL PROTECTED] writes:
Hi folks,
I'm wondering what to make of this behavior, seen in both guile 1.8.1
and 1.8.3, discovered by my colleague L. Brown Westrick, cc:ed above:
guile (define (apply2 f a b) (f a b))
guile (apply2 or #t #f)
#t
guile (apply2 and #t #f)
#t
[
Gregory Marton [EMAIL PROTECTED] writes:
Hi folks,
I just wanted to send in a test case for a bug that is fixed as of
guile 1.8.2, but recently bit me, and it's just not that obvious to
test for. It is essentially exposed in 1.8.1 by
(let ((x 1/2))
(display x)
(equal? x 1/2))
Gregory Marton [EMAIL PROTECTED] writes:
The differences are not significant. I guess I wanted to make clear
in the test case that this isn't something to do with literal
rationals, and I didn't want the test case to be printing things to
the console.
OK, thanks for explaining that. I
URL:
http://savannah.gnu.org/bugs/?22159
Summary: Concerns about hash table API
Project: Guile
Submitted by: ossau
Submitted on: Tuesday 01/29/08 at 22:38
Category: None
Severity: 3 - Normal
Roger Mc Murtrie [EMAIL PROTECTED] writes:
I'm having trouble implementing the patches.
[...]
I managed to get configure to work by changing in guile-readline/
configure.in
AC_INIT(guile-readline,
m4_esyscmd(. ../GUILE-VERSION echo -n ${GUILE_VERSION}))
to
Roger Mc Murtrie [EMAIL PROTECTED] writes:
I agree the patch didn't change that line.
I don't think the problem was caused by your patch or any corruption
of it as I actually implemented the patch by hand.
It seemed to me that m4_esyscmd wasn't working properly as it inserted
a CR at the
Shaojun Zhao [EMAIL PROTECTED] writes:
Hi,
I download http://ftp.gnu.org/pub/gnu/guile/guile-1.8.3.tar.gz, but
the ./configure gave me this:
...
checking for lt_dlinit in -lltdl... no
configure: error: libltdl not found. See README.
I worked on this for 2 days and found a solution:
BTW:
Neil Jerram [EMAIL PROTECTED] writes:
In that light, and also because a Guile without LARGEFILE64 support is
surely better than no Guile at all, I think we should address this
problem for the Mac OSes (and also HP-UX, per [1]), by adding a
--disable-64-calls option to ./configure, whose
Neil Jerram [EMAIL PROTECTED] writes:
Neil Jerram [EMAIL PROTECTED] writes:
In that light, and also because a Guile without LARGEFILE64 support is
surely better than no Guile at all, I think we should address this
problem for the Mac OSes (and also HP-UX, per [1]), by adding a
--disable-64
Rainer Tammer [EMAIL PROTECTED] writes:
Testing /daten/source/guile-1.6.8/pre-inst-guile ...
with GUILE_LOAD_PATH=/daten/source/guile-1.6.8/test-suite
[...]
ERROR: In procedure dynamic-link:
ERROR: file: libguile-srfi-srfi-13-14-v-1, message: 0509-022
Cannot load module
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Actually, I'm wondering whether it would be a good idea since some
messages have been used in programs as error condition descriptions,
most notably in the test suite, because they provide more information
that just the `throw' key. Thus,
Roger Mc Murtrie [EMAIL PROTECTED] writes:
I tried building autogen which needs guile but it failed the make
check test of guile.
[...]
++ gcc -std=gnu99 -DHAVE_CONFIG_H -g -O2 -DTEST_TEST_GUILE_OPTS -I/
Users/Roger/Downloads/autogen-5.9.2 -I/Users/Roger/Downloads/
autogen-5.9.2/agen5
Leonardo Valeri Manera [EMAIL PROTECTED] writes:
magnus gave me this backtrace
jyujin it's always in precisely this location:
/lib/libguile.so.17(scm_mark_locations+0x17)[0x2e6192b7]
Thanks, Leonardo. Could you also say what version of Guile you're
using, and provide or point us to the
Rainer Tammer [EMAIL PROTECTED] writes:
ERROR: srfi-4.test: u8 vector: u8vector? success - arguments:
((memory-allocation-error make-u8vector Memory allocation error #f
#f))
[...]
t = (char*)realloc(NULL, 0);
if (t == NULL)
{
printf(is NULL\n);
}
else
{
Rainer Tammer [EMAIL PROTECTED] writes:
Hello Neil,
sorry to bother you again (and again)...
No problem; I'm sorry that Guile doesn't Just Work yet on AIX...
There is also a problem in filesys.c
The function
#define FUNC_NAME s_scm_readdir
{
struct dirent_or_dirent64 *rdent;
[...]
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Hi,
Neil Jerram [EMAIL PROTECTED] writes:
Rainer Tammer [EMAIL PROTECTED] writes:
Under Linux: is not NULL
Under AIX: is NULL
Note: in HEAD, we could use the `malloc' and `realloc' Gnulib modules to
address this.
Hmm, yes, we could. But (i
You've both recently reported a compilation problem with _Complex_I,
compiling with GCC on Solaris and AIX.
My proposed fix for this is attached; please can you review and let me
know if you have any comments?
(Should I also attach the regenerated ./configure, so you can run that
and check that
Neil Jerram [EMAIL PROTECTED] writes:
You've both recently reported a compilation problem with _Complex_I,
compiling with GCC on Solaris and AIX.
My proposed fix for this is attached; please can you review and let me
know if you have any comments?
Actually I'd like to make a small change
Stephen Uitti [EMAIL PROTECTED] writes:
I've been scratching my head over random numbers.
[...]
It really should say that (random) produces the same
list of numbers every time, unless a state is
specified. And it should have an example showing use.
Thanks for pointing out that we could do
Rainer Tammer [EMAIL PROTECTED] writes:
OK, I have tested the second patch on AIX 6.1
Thanks. From the fact that compile succeeds, I assume the _Complex_I
fix was good, so I'll go ahead with committing that.
I had to regenerate the configure scripts with the latest
Greg Troxel [EMAIL PROTECTED] writes:
Looking over your patch again, I feel quite a bit better about it.
[...]
I would add
# This is a workaround for the failure of these systems to conform to C99.
So this all seems ok to me.
Hi Greg,
Many thanks for your review, thoughts and second
Greg Troxel [EMAIL PROTECTED] writes:
Adding a remedial
#define _Complex_I 1.0fi
to the beginning of numbers.c if _Complex_I weren't defined would seem
less objectionable, and also work.
Just one detail for the record: unfortunately that wouldn't work for
GCC on AIX, because there:
-
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Hi,
Hans Aberg [EMAIL PROTECTED] writes:
Guile-1.8.4 does not compile on Mac OS X 10.4.11 PPC G4 (see below).
readline.c:109: error: ‘rl_pending_input’ undeclared (first use in
As we already discussed, you'll want to install GNU Readline, as
Hi there!
Guile uses GMP as you may know, and one of our MacOS users has
reported the following link error, which appears to be related to GMP.
ld: warning codegen in ___gmpn_popcount (offset 0x0007) prevents
image from loading in dyld shared cache
ld: warning codegen in ___gmpn_popcount
Roger Mc Murtrie [EMAIL PROTECTED] writes:
Mac OSX 10.5.2
./configure
make
Link failed at
gcc -dynamiclib -o .libs/libguile.17.1.2.dylib .
ld: warning codegen in ___gmpn_popcount (offset 0x0007) prevents
image from loading in dyld shared cache
ld: warning codegen in
Torbjorn Granlund [EMAIL PROTECTED] writes:
If you file a proper bug report, with all the facts and with a test
case, then we can perhaps help.
http://gmplib.org/manual/Reporting-Bugs.html
That's fair enough. I guess I was hoping that this was something
you've seen before, and so could
Mikael Djurfeldt [EMAIL PROTECTED] writes:
I was thinking about inserting code which actually *measures* the size
of frames during startup. This could be done, for example, by
introducing a primitive which uses the internal stack measuring
functions. One could use this primitive to measure
Roger Mc Murtrie [EMAIL PROTECTED] writes:
Hi Neil.
I wonder if its got something to do with my GMP version:
/usr/local/lib/libgmp.3.4.2.dylib
Regards
Roger
Maybe. What release version of GMP does that correspond to? (Note
that shared library numbers are not necessarily the same as
Kamaraju S Kusumanchi [EMAIL PROTECTED] writes:
Just wanted to bring to your attention that guile 1.8.4 failed to build on
alpha, ia64 architectures. The build log can be found at
http://buildd.debian.org/fetch.cgi?pkg=guile-1.8arch=alphaver=1.8.4%2B1-1stamp=1203917145file=logas=raw
Roger Mc Murtrie [EMAIL PROTECTED] writes:
Well, Maybe not!
For gmp-4.2.2 I just did
./configure
make
sudo make install
then for guile-1.8.4
./configure
make
Success!
make check
All tests passed.
Mysterious!
Regards
Well that's good news. I'm sure there are subtle build
Neil Jerram [EMAIL PROTECTED] writes:
Looking into ia64 first... On my test machine, and without the Debian
patches, I'm seeing other problems that prevent me from reaching the
Illegal instruction that your build is getting.
One of them is: Undefined reference to .L16, when trying to link
Hans Aberg [EMAIL PROTECTED] writes:
readline.c: In function rl_cleanup_after_signal:
readline.c:109: error: rl_pending_input undeclared (first use in
this function)
readline.c:109: error: (Each undeclared identifier is reported only once
readline.c:109: error: for each function it
Hans Aberg [EMAIL PROTECTED] writes:
Otherwise, a fix might be that the Guile installation checks for
readline in /usr/local/.
I could well be wrong, but my current understanding is that that won't
work, because at link time GCC or ld.so will always prefer to pick up
-lreadline from /usr/lib
Hi Remco,
Thanks for your email...
Remco Bras [EMAIL PROTECTED] writes:
Hello,
I have run into a double problem with guile, that has to do with threads. The
situation is roughly as follows. First, scm_init_guile is called from one
thread, after which scm_c_define_gsubr is used in that
Marijn Schouten (hkBst) [EMAIL PROTECTED] writes:
Hi list,
Using guile-1.8.4 I get:
$ guile -c (scheme-report-environment 5)
ERROR: Unbound variable: scheme-report-environment
but also:
$ guile
guile (scheme-report-environment 5)
#interface (ice-9 r5rs) 2b312d45dc80
guile (eval '(* 2
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Line 194 of pthread.h (of Gnu PTH 2.0.7) is typedef int socklen_t;,
the platform doesn't have socklen_t otherwise. Problem workaround by
--disable-error-on-warning.
Isn't that a GNU Pth problem (that its header contains an empty
declaration)?
How
Levine, Zachary [EMAIL PROTECTED] writes:
There was a bug reported in version 1.8.0,
guile.c:(.text+0x2f): undefined reference to
`lt__PROGRAM__LTX_preloaded_symbols'
This happens when libguile tries to link against a more recent version
of libltdl than we're expecting.
and a proposed fix
Marijn Schouten (hkBst) [EMAIL PROTECTED] writes:
Possible patch [1] that fixes this from bug [2].
[1]: http://bugs.gentoo.org/attachment.cgi?id=145645
[2]: http://bugs.gentoo.org/show_bug.cgi?id=212723
OK, but that just breaks pre-opening completely, doesn't it?
What's the underlying issue
attached.
Neil
From 0d185db93e484bda87c0d3c441db3b804148413f Mon Sep 17 00:00:00 2001
From: Neil Jerram [EMAIL PROTECTED]
Date: Tue, 13 May 2008 00:00:34 +0100
Subject: [PATCH] Expand DEFFROM and DEFTO macros in discouraged.c
* discouraged.c: Expand DEFFROM and DEFTO macros, to avoid
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Hi,
Neil Jerram [EMAIL PROTECTED] writes:
--- a/libguile/ChangeLog
+++ b/libguile/ChangeLog
@@ -1,3 +1,9 @@
+2008-05-12 Neil Jerram [EMAIL PROTECTED]
+
+* discouraged.c: Expand DEFFROM and DEFTO macros, to avoid
+compiler warnings
On cygwin (with current 1.8.x branch code), there are two failures in
reader.test:
Running reader.test
ERROR: reader.test: mismatching parentheses: closing parenthesis
following mismatched opening - arguments: ((regular-expression-syntax
make-regexp parentheses not balanced #f (unexpected \)\$)))
2008/6/18 Patrick Horgan [EMAIL PROTECTED]:
Running threads.test
FAIL: threads.test: lock-mutex: timed locking succeeds if mutex unlocked
Not with you, I'm afraid. What git branch is this? Are you thinking
that this is a regression? What platform? etc...
Neil
2008/7/12 Dave Page [EMAIL PROTECTED]:
Hi there,
I would like to create artwork for a free software project, using the
cartoon gnu head from the Guile logo [1]. Please can you clarify the
license used for this logo, so I know how to license my derivative
work? If you have a higher-resolution
2008/7/17 Gregory Marton [EMAIL PROTECTED]:
They're taking a while to run, but so far all my other tests are also
passing in mono-threaded guile 1.8.5
commit 9143131b2766d1e29e05d61b5021395b4c93a6bc Neil Jerram, July 11
Just to be clear: do you mean that they are passing _after_ this
commit
2008/7/26 Anye Li [EMAIL PROTECTED]:
Even if it is not a bug that rationalize returns inexact results (surprising
and useless as they may be to me), I believe it is still a bug that (help
rationalize) says Return an exact number... when in fact it does not.
Agreed. I'm just fixing this now,
Follow-up Comment #1, bug #24009 (project guile):
Thanks for noticing and reporting this. I think you are right - at least for
the one in async.c (I haven't checked any others yet), so we'll hopefully get
to fixing this soon.
Neil
2008/7/22 Gregory Marton [EMAIL PROTECTED]:
Hi folks,
We're running into an issue where we're trying to associate some information
about functions by associating the info with their serialized form, which is
in part their procedure-source. Unfortunately, the procedure-source changes
when a
2008/8/11 Bill Schottstaedt [EMAIL PROTECTED]:
guile (gcd -2)
-2
(or any negative single argument).
Is that wrong?
Neil
2008/8/11 Bill Schottstaedt [EMAIL PROTECTED]:
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)
My guess
2008/8/12 Bill Schottstaedt [EMAIL PROTECTED]:
gcd is supposed to ignore factors of -1.
According to? (I'm not suggesting that you're wrong. I'd just like
you to be precise about your references.)
is restricted to reals -- a complex arg should be an error.
Again, is that specified?
2008/8/12 Mikael Djurfeldt [EMAIL PROTECTED]:
2008/8/12 Neil Jerram [EMAIL PROTECTED]:
2008/8/12 Bill Schottstaedt [EMAIL PROTECTED]:
gcd is supposed to ignore factors of -1.
According to? (I'm not suggesting that you're wrong. I'd just like
you to be precise about your references.)
R5RS
This is mostly for the record, as I'm afraid I don't have any fix yet...
2008/8/12 Neil Jerram [EMAIL PROTECTED]:
2008/8/11 Bill Schottstaedt [EMAIL PROTECTED]:
guile ( 1.0+1.0i)
#t
My guess (without actually looking at the code) is that
- the single arg case is being optimized before
Hi...
2008/9/19 tantalum [EMAIL PROTECTED]:
hi
having dependencies
gmp 4.2.2-2
libtool 2.2.6a-1
installed and 64bit linux,
im trying to compile guile 1.8.5, but it fails leaving the message found
here:
http://pastebin.com/m3bd2e879
Speicherzugriffsfehler translates to segmentation fault
2008/9/19 Bill Schottstaedt [EMAIL PROTECTED]:
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
Those _do_ look dangerous. I'll take a look...
guile (substring 123 124)
Backtrace:
In
2008/9/20 tantalum [EMAIL PROTECTED]:
i meant the version one gets when issuing git clone
git://git.sv.gnu.org/guile.git.
now trying this again, it wont complete autoconf configure.in (i found no
further documentation how to compile except a comment in configure.in)
it runs a second then
2008/9/21 tantalum [EMAIL PROTECTED]:
ok, i did try to compile from the latest snapshot.
same error, i guess.
OK, I'm sorry about that. The similar problem on other platforms was
caused by incorrect detection of the stack direction (i.e. whether the
stack grows upwards or downwards), so you
2008/9/22 tantalum [EMAIL PROTECTED]:
it did not work.
i copied and unpacked todays snapshot, and removed the 60 lines.
all text in between SCM_I_GSC_STACK_GROWS_UP=0
and
{ echo $as_me:$LINENO: checking for float 5
error happens again, with same output as before.
OK we're doing well
Hi!
2008/9/22 Ludovic Courtès [EMAIL PROTECTED]:
Hi,
Bill Schottstaedt [EMAIL PROTECTED] writes:
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)
2008/9/25 Marijn Schouten (hkBst) [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill Schottstaedt wrote:
Is this a bug?
No. See the R5RS formal syntax. Different things are allowed for
(begin ...) at top level and (begin ...) inside a definition.
Weird thing is it
101 - 200 of 296 matches
Mail list logo
