Re: [PATCH] reducing uninitialized memory warnings

> "Marius" == Marius Vollmer <[EMAIL PROTECTED]> writes: Marius> [EMAIL PROTECTED] (I.Sheldon) writes: >> With a simple test of starting guile and then typing `(quit)', this >> reduced the number of warnings I was getting from 19270 to 19014. Marius> Since this reduction is s

Re: can't load readline module

> "Orm" == Orm Finnendahl <[EMAIL PROTECTED]> writes: Orm> Hi, after compiling and installing guile 1.6.0 I get the Orm> following error on a Debian with 2.4.19 kernel when trying to Orm> use libreadline as specified in guile's info manual: guile> (use-modules (ice-9 readline

Re: readline (again...)

> "Orm" == Orm Finnendahl <[EMAIL PROTECTED]> writes: Orm> Hi all, Orm> sorry to bug you again, but I experience a strange thing trying to use Orm> readline within an inferior guile process in emacs: When loading the Orm> readline modules in a console, the behaviour of readlin

Re: Updated [PATCH] Some fixes to doc/ref/scheme-data.texi

> "Stephen" == Stephen Compall <[EMAIL PROTECTED]> writes: Stephen> Thien-Thi Nguyen wrote: >> http://csserver.evansville.edu/~sc87/scheme-data-1S11.patch >> the changelog entry neglects to mention some incorrect replacements >> of >> "iff" w/ "if". the former is a notatio

Re: no output from ice-9 `format' after `make-thread'

> "Marius" == Marius Vollmer <[EMAIL PROTECTED]> writes: Marius> Note also that (ice-9 format) is not thread safe... And also -- if it makes any difference -- not async safe. I saw an interesting bug the other day when GC happened somewhere in the middle of (ice-9 format), and then: GC

Failing test from r4rstest.scm

I just tried adding this test (from r4rstest.scm) to r4rs.test ... (SECTION 5 2 1) (define add3 (lambda (x) (+ x 3))) (test 6 'define (add3 3)) (define first car) (test 1 'define (first '(1 2))) (define old-+ +) (begin (begin (begin) (begin (begin (begin) (define + (lambda (x y) (lis

Re: Setting the readline prompt ...

>>>>> "Neil" == Neil Jerram <[EMAIL PROTECTED]> writes: Neil> You can see the effect of set-readline-prompt! like this: guile> (begin (set-readline-prompt! "1> " "2> ") (readline)) 1> something Neil> "som

Re: Failing test from r4rstest.scm

>>>>> "thi" == Thien-Thi Nguyen <[EMAIL PROTECTED]> writes: thi>From: Neil Jerram <[EMAIL PROTECTED]> thi>Date: 06 Jan 2003 19:55:26 + thi>... but it fails. Any idea why? thi> what messages do you see? Testi

Re: Setting the readline prompt ...

>>>>> "Marius" == Marius Vollmer <[EMAIL PROTECTED]> writes: Marius> Neil Jerram <[EMAIL PROTECTED]> writes: >> Marius/Rob, should this go into the stable branch as well? Marius> Yes. (The way I understand it, it is a fix for som

Re: guile source will not compile...

> "bstep" == bstep <[EMAIL PROTECTED]> writes: bstep> After a few attempts, I can't seem to get the guile bstep> source code to compile on bstep> my workstation. I am currently utilizing Slackware 8.1 bstep> distro with 2.4.18 bstep> kernel. Are there some dependencies

Re: property primitives doco

> "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes: Kevin> In the "Property Primitives" node of the manual (in the cvs), there Kevin> seems to be no mention of what parameters are passed to the Kevin> not_found_proc taken by primitive-make-property. Kevin> Experimenting shows

Re: Thread + Socket + Pipes Bug?

> "bobstopper" == bobstopper <[EMAIL PROTECTED]> writes: bobstopper> Ok, well that's pretty annoying. That's certainly what bobstopper> I do to get it complaining. [...] Do you have anything bobstopper> related installed which might be working around the bobstopper> problem?

Re: Thread + Socket + Pipes Bug?

; Sorry, I think I neglected to mention. I'm using Guile 1.6.4 on Solaris Robert> and GNU/Linux. Robert> Thanks heaps for checking it out. Robert> On Fri, 2003-08-08 at 05:25, Neil Jerram wrote: >> Robert, >> >> You probably said in your e

Re: Thread + Socket + Pipes Bug?

> "Robert" == Robert Marlow <[EMAIL PROTECTED]> writes: Robert> I've still got the guile-1.6.4 version I have installed available Robert> though. I've put it in webspace at: Robert> http://system.piscescom.com/~rmarlow/guile-1.6.4.tar.bz2 Robert> If you want to try that. I'll c

Re: guile-tut bugs

> "Jack" == Jack Pavlovsky <[EMAIL PROTECTED]> writes: Jack> Hi Jack> I've found some bugs in the guile tutorial (and probably there're more): Jack> chapter Using guile to program in scheme, Jack>(reverse ls) would produce (7 6 5 4 3 2 1), not as written there! Jack>

Re: core dump.

> "Han-Wen" == Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: Han-Wen> Yeah, I found out so far. Now I have to figure out what in my 1 Han-Wen> lines of Scheme code is causing Han-Wen>ERROR: In procedure car: Han-Wen>ERROR: Wrong type argument in position 1: () Sure

Re: Segmentation fault in scm_igc

David Hansen <[EMAIL PROTECTED]> writes: > Hello, > > my first guile code started with a SIGSEGV. Not sure if > it's not my fault but looks like a bug to me. > > ,[ gtst.c ] > | // -*- compile-command: "gcc -g -Wall `guile-config compile` `guile-config link` > gtst.c -o gtst" -*- > | > |

Re: Serious GC bug in GUILE 1.6 CVS

Han-Wen Nienhuys wrote: [EMAIL PROTECTED] writes: I have fixed this by using the new macro SCM_SET_FREE_CELL_TYPE, which does no checking. Hmm... That's unfortunate. We have reports of GC flakiness with 1.6 on Cygwin. This means that there's still another bug lurking. Have you checked that the bui

Problem with apply-frame trap in 1.6 and 1.7

Working on breakpoints for 1.6.x, I just discovered that the following ENTER_APPLY trap code in eval.c goes into a tight busy loop if (debug-enable 'trace) and (trap-set! apply-frame-handler non-#f). if (CHECK_APPLY && SCM_TRAPS_P)\ if (SCM_APPLY_FRAME_P || (SCM_TRACE_P && PROCTRACEP (proc)

Re: Problem with apply-frame trap in 1.6 and 1.7

Marius Vollmer wrote: Neil Jerram <[EMAIL PROTECTED]> writes: Working on breakpoints for 1.6.x, I just discovered that the following ENTER_APPLY trap code in eval.c goes into a tight busy loop if (debug-enable 'trace) and (trap-set! apply-frame-handler non-#f). if (CHECK_APPLY &am

Can't make a stack from a continuation

[EMAIL PROTECTED]:~$ guile -q guile> (version) "1.6.4" guile> (call-with-current-continuation make-stack) Segmentation fault This has been reported before, but it's still there. I think it's something wrong with these lines from stacks.c, but I haven't investigated further yet. else if (SCM_C

Re: Can't make a stack from a continuation

Neil Jerram wrote: [EMAIL PROTECTED]:~$ guile -q guile> (version) "1.6.4" guile> (call-with-current-continuation make-stack) Segmentation fault I believe I have the fix for this (diffs attached for 1.6.x). Would anyone who feels half-confident in this area please review? Than

Re: Problem with apply-frame trap in 1.6 and 1.7

Neil Jerram wrote: Yes, in CVS 1.6.x I do have that change. I'm sorry - when I reported this I was working with a 1.6.4 release, I think (possibly 1.6.5). So I guess that should fix the problem, because the hashtable here is using hashq - I'll check and let you know. Yes, the us

Re: Can't make a stack from a continuation

Neil Jerram wrote: Neil Jerram wrote: [EMAIL PROTECTED]:~$ guile -q guile> (version) "1.6.4" guile> (call-with-current-continuation make-stack) Segmentation fault I believe I have the fix for this (diffs attached for 1.6.x). Would anyone who feels half-confident in this area

Re: Problem with apply-frame trap in 1.6 and 1.7

Marius Vollmer wrote: Waitaminute! We no longer use alists in 1.6: 2004-08-11 Marius Vollmer <[EMAIL PROTECTED]> * gc.c, procprop.c (scm_init_storage, scm_stand_in_procs, scm_stand_in_proc): Use a hastable for scm_stand_in_procs instead of an alist. Thanks to Matthias Ko

Re: Can't make a stack from a continuation

Marius Vollmer wrote: Marius Vollmer <[EMAIL PROTECTED]> writes: Neil Jerram <[EMAIL PROTECTED]> writes: And one more problem ... the same problem exists in CVS head, but a similar patch doesn't fix it ... still investigating. I'm looking into this as well, now. The fix

Re: Can't make a stack from a continuation

Neil Jerram wrote: This change (calculating and storing the offset in scm_make_continuation) makes sense [...] One more thing - are you happy with the proposed new tests for 1.6 and head? I think one change is needed, namely to save and restore (debug-options) so that the effect of (debug

Re: Can't make a stack from a continuation

Marius Vollmer wrote: Neil Jerram <[EMAIL PROTECTED]> writes: One more thing - are you happy with the proposed new tests for 1.6 and head? Yes. I think one change is needed, namely to save and restore (debug-options) so that the effect of (debug-enable 'debug) can't affect othe

Re: Can't make a stack from a continuation

Marius Vollmer wrote: Hmm, I didn't really try to debug your patch. I followed its idea of also relocating dframe->vect and made the changes that seemed right. Using offset = SCM_CONTREGS (stack)->stack - SCM_BASE(stack) looks right. The bug is probably elsewhere... Fair enough, but when I compar

Re: Can't make a stack from a continuation

Neil Jerram wrote: Yes, will do. Probably not today, though :-) This is now complete. Two notes: - In HEAD, I moved the new tests from eval.test to continuations.test, as the latter seems more appropriate. (I only used eval.test in 1.6 in order to avoid having to create a new file.) - In 1.6

Re: 1.7.2: scmsigs.c,signal_delivery_thread

Werner Scheinast wrote: scmsigs.c: In function `signal_delivery_thread': scmsigs.c:152: warning: no return statement in function returning non-void When I follow Paul's suggestion and add "__attribute__((noreturn))" before the function name (right?), it doesn't change anything. Perhaps the mist

Re: 1.7.2: scmsigs.c,signal_delivery_thread

Werner Scheinast wrote: Am 09.05.05 schrieb NeilJerram: Can you try adding return SCM_UNSPECIFIED; to the end of the definition of signal_delivery_thread(), and see if that solves the problem? Yes, it does! Now the "make" runs without problems. OK, this is committed, so it'll be in the next sn

FAIL: unif.test: make-shared-array: shared of shared

Just noticed a "make check" failure in current CVS, on Debian testing: Running unif.test FAIL: unif.test: make-shared-array: shared of shared Any ideas? Neil ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gu

Re: FAIL: unif.test: make-shared-array: shared of shared

Kevin Ryde wrote: Neil Jerram <[EMAIL PROTECTED]> writes: FAIL: unif.test: make-shared-array: shared of shared Any ideas? There's something wrong with making a shared array from another shared array. The base is or isn't offset or something. OK, thanks for explaining that. I do

Set source property on an evaluated expression

In 1.6.7, given these tests - (with-test-prefix "set-source-property!" (read-enable 'positions) (let ((s (read (open-input-string "(display \"\")" (pass-if "set-source-property! before eval" (set-source-property! s 'test-sym 10) (eval s the-scm-module) #t) (pas

Re: Set source property on an evaluated expression

Marius Vollmer wrote: > Neil Jerram <[EMAIL PROTECTED]> writes: > > >>I propose that the SCM_NECONSP fix is good enough in practice, and >>would like to release it into 1.6.x. Any objections? > > > Not from me! > OK, this fix is in now,

Re: using guile's readline module

Gene Pavlovsky <[EMAIL PROTECTED]> writes: > guile> (readline-set! 'bounce-parens 50) > : In expression (readline-options-interface (append # #)): > : Unbound variable: readline-options-interface > ABORT: (unbound-variable) Does it work if you omit the quote? In other words, like this: (readlin

Re: [bug #14925] Non-portable binary compilations on linux

anonymous <[EMAIL PROTECTED]> writes: > URL: > Well I'd like to ask two questions in response to this. - Can you be more precise about how __libc_stack_end is non-portable? (Is it just a matter of having a recent enough glibc?) -

Re: [bug #14925] Non-portable binary compilations on linux

Kevin Ryde <[EMAIL PROTECTED]> writes: > Neil Jerram <[EMAIL PROTECTED]> writes: >> >> - Can you be more precise about how __libc_stack_end is non-portable? >> (Is it just a matter of having a recent enough glibc?) > > My guess would be __libc_stack_

Re: cygwin guile is broken

"Matt Yu" <[EMAIL PROTECTED]> writes: > It seems that guile just doesn't work on cygwin anymore. I get the > following message with versions 1.6.7 and the 1.7 versions. > ERROR: In procedure make-struct-layout: >>ERROR: Wrong type argument in position 1 (expecting STRINGP): pw For what input? J

Re: libguile/socket.c

[EMAIL PROTECTED] (hyperdivision) writes: > line 1259 from cvs > libguile/socket.c > > size_t c_address_size needs to be set to 0 > otherwise gcc4 croaks. I wonder if that's because it's generally concerned about uninitialized variables, or because it's noticed the apparent bug in scm_c_make_sock

Re: libguile/socket.c

[EMAIL PROTECTED] (Ludovic Courtès) writes: > Hi, > > Neil Jerram <[EMAIL PROTECTED]> writes: > >> I wonder if that's because it's generally concerned about >> uninitialized variables, or because it's noticed the apparent bug in >> scm

Re: libguile/socket.c

Marius Vollmer <[EMAIL PROTECTED]> writes: > Neil Jerram <[EMAIL PROTECTED]> writes: > >> Thanks for confirming this. I'll make the change in CVS. > > Please also make this change in the branch_release-1-8 branch if > appropr

Re: pedantic stuff: C++ comments in 1.8.0

Mike Gran <[EMAIL PROTECTED]> writes: > There are some C++-style comments in 1.8.0. Thanks. I'll apply your patch when I get time at the weekend, if no one else does it first. Neil ___ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.o

Re: undefined reference to `scm_init_guile'

steven mestdagh <[EMAIL PROTECTED]> writes: > hi, > > I'm using OpenBSD 3.9 beta. With guile 1.8.0, the build runs fine but > the following error occurs when running the test suite. The code for > scm_init_guile seems to have been removed from init.c? scm_init_guile is in threads.c, but only if H

Re: Submitting bugs through Savannah

Matt Kraai <[EMAIL PROTECTED]> writes: > Howdy, > > Can I submit bugs against Guile using Savannah > > http://savannah.gnu.org/bugs/?group=guile > > or do I need to use this mailing list? It's better to use this mailing list, because then we can ask further questions about your report. (Alterna

Re: Conflicting types for unlock on QNX 6

Matt Kraai <[EMAIL PROTECTED]> writes: > Howdy, > > When I try to compile guile 1.8.0 on QNX 6.3.0, it fails as follows: > >> source='threads.c' object='libguile_la-threads.lo' libtool=yes \ >> DEPDIR=.deps depmode=gcc /bin/sh ../depcomp \ >> /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_C

Re: Bug in make-shared-array.

Kevin Ryde <[EMAIL PROTECTED]> writes: > "Steve Juranich" <[EMAIL PROTECTED]> writes: >> >> Are there any workarounds for this? > > There's something evil happening, I can't tell what it is. Marius was > the last to give the array bits a prod, he might be able to say. I've fixed this in CVS now:

Re: srfi-4.c: arithmetic on void pointers

Mike Gran <[EMAIL PROTECTED]> writes: > Hi, > > In srfi-4.c, pointer arithmetic on void pointers is done. This is a > GNU C extension, and I think it is not C99. For non-GCC C, you might > consider a cast to (char *) or something. Thanks. I changed the declarations from void* to char*, as I thi

Re: pedantic stuff: unif.c: void function returns void value

Mike Gran <[EMAIL PROTECTED]> writes: > In 1.8.0, in unif.c, the static void function string_set() "returns" > the value of void function scm_c_string_set_x(). > > That type of construction is non-standard, I think, (but I couldn't > find a good reference for it). FWIW, the AIX xlc compiler belie

Re: FC2 configure: error: At least GNU MP 4.1 is required, see README

Aubrey Jaffer <[EMAIL PROTECTED]> writes: > checking for library containing crypt... -lcrypt > checking for __gmpz_init in -lgmp... yes > configure: error: At least GNU MP 4.1 is required, see README Are there any clues at the end of config.log, when this happens? Neil ___

Re: FC2 configure: error: At least GNU MP 4.1 is required, see README

Aubrey Jaffer <[EMAIL PROTECTED]> writes: > | From: Neil Jerram <[EMAIL PROTECTED]> > | Date: Tue, 14 Mar 2006 19:56:31 + > | > | Aubrey Jaffer <[EMAIL PROTECTED]> writes: > | > | > checking for library containing crypt... -lcrypt > | &

Re: what's with the spam?

Mark Galassi <[EMAIL PROTECTED]> writes: > This list is completely out of control; probably the most spam-ridden > list I get. Can anything be done about it? FWIW, I don't notice it myself, because I filter out spam regardless of which list messages belong to. Neil ___

Re: 1.8 build problem

James Bergstra <[EMAIL PROTECTED]> writes: >> I'm on Fedora core, AMD64, with guile 1.6 already installed in /usr/bin, the >> compiler is gcc 4.2.0. I want to install guile 1.8 in my account, so I >> >> 1. download the 1.8 tgz >> 2. issue ./configure --prefix=~/pub/64 (no problem) >> 3. issue m

Re: 1.8 build problem

James Bergstra <[EMAIL PROTECTED]> writes: > On Wed, May 03, 2006 at 01:53:35AM -0400, James Bergstra wrote: >> > I'm on Fedora core, AMD64, with guile 1.6 already installed in /usr/bin, >> > the >> > compiler is gcc 4.2.0. I want to install guile 1.8 in my account, so I >> > >> > 1. download

Re: simple-format causes segfault?

James Bergstra <[EMAIL PROTECTED]> writes: > Hi, > > I'd like to file a bug report on guile-1.8, but I don't know how. You're already doing the right thing: writing to [EMAIL PROTECTED] > I have a program that causes the guile interpreter to segfault when I output > with (simple-format), but run

Re: 'Segmentation fault' in example program

Frithjof <[EMAIL PROTECTED]> writes: > Hey, > when trying to compile the example from chapter "2.3.3 Linking > Guile into Programms" in the Reference Manual with gcc 3.3.5 I get the > following: > > gcc -o simple-guile simple-guile.c -lguile -pthread \ > -Wl,-rpath,/usr/local/lib > > (gdb) run

Re: parallel make fails for guile 1.8

Mattias Holm <[EMAIL PROTECTED]> writes: > Makes fails when parallelisation option -jN is used. This is at > least true for Mac OS X (which also fail in other parts of the make > process, though this later error are apparently known (this also > prevents me from using Guile 1.8 in my project)). >

Re: parallel make fails for guile 1.8

Kevin Ryde <[EMAIL PROTECTED]> writes: > Neil Jerram <[EMAIL PROTECTED]> writes: >> >> I would guess this means that the Makefile >> is failing to work out that the libguile .c files depend on >> scmconfig.h, > > Yep. I added scmconfig.h to the .x an

Re: parallel make fails for guile 1.8

Kevin Ryde <[EMAIL PROTECTED]> writes: > Sticking it in "nodist_noinst_DATA = guile.texi" seems to work to get > it built under "make all", if you still want it. If normal users > don't need it then maybe it should be restricted to "if > ENABLE_MAINTAINER_MODE" though. Thanks for noting that. F

Re: Bug in make-shared-array.

Marius Vollmer <[EMAIL PROTECTED]> writes: > Neil Jerram <[EMAIL PROTECTED]> writes: > >> in lines >> 872-893, this - >> >>if (s[k].inc > 0) >> old_max += (s[k].ubnd - s[k].lbnd) * s[k].inc; >>else

Re: Minor documentation layout flaws

"percy tiglao" <[EMAIL PROTECTED]> writes: > Hello. I decided to make a print version of the reference manual; but > there were so many stuff that ran through the right side of the page > (technically, overfull hboxes). I'm interested in helping you guys > remove those things so that all the stuff

Re: [doc] misc typos

"Marco Maggi" <[EMAIL PROTECTED]> writes: > 'scm_dynwind_free()' is not documented with @deftypefun, > so it does not appear in the functions index. Thanks; I've added doc for this now. > diff --recursive original/doc/ref/api-compound.texi > modified/doc/ref/api-compound.texi > 1046c1046 > < t

Re: MinGW port

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 exac

Re: This is not a bug, maybe it's in GUILE DOCs

"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

Re: [bug #17853] SIGSEGV on v1.8 startup after adding .guile file

Anthony David <[EMAIL PROTECTED]> writes: > URL: > 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

Re: Error with Guile 1.8.1 "make check"

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-

Re: pdf documents won't build

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 r

Re: guile-1.8.1 tarball missing config.rpath

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, i

Re: make-shared-array and bitvectors

"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 (l

Re: pdf documents won't build

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

Re: pdf documents won't build

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

Re: procedure-source inconsistency

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) (proce

No declaration for isblank

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 being

Errors compiling i18n.c

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 '=', ',', ';', 'as

No declaration for cuserid

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

Re: Segmentation fault

[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! Thanks for trying it. >> +

Re: Segmentation fault

eLog 17 Oct 2007 21:56:09 - 1.2412 +++ libguile/ChangeLog 18 Oct 2007 23:26:19 - @@ -1,3 +1,9 @@ +2007-10-19 Neil Jerram <[EMAIL PROTECTED]> + + * eval.c (unmemoize_delay): Extend the environment before + unmemoizing the promise thunk. This fixes a segmentat

Re: Segmentation fault

"frank schwidom" <[EMAIL PROTECTED]> writes: > Original-Nachricht > Datum: Wed, 10 Oct 2007 18:27:42 +0200 > Von: "frank schwidom" <[EMAIL PROTECTED]> > An: bug-guile@gnu.org > Betreff: Segmentation fault > > Hi > > the following code leads to an segmentation fault in guile-1.6 a

Re: Segmentation fault

[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 s

Re: Segmentation fault

[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 sinc

Re: Segmentation fault

[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 automatic

Re: No declaration for isblank

[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'

Re: No declaration for isblank

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&#

Re: 1.8.2 manual describes debugger breakpoint functionality that doesn't exist

[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 di

Re: No declaration for isblank

[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 > betw

Re: Segmentation fault

[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 autom

Re: No declaration for isblank

[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',

Re: No declaration for isblank

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 (be

Re: Segmentation fault

[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. >

[bug #21483] mandelbug whit GUILE_DEBUG_MALLOC

URL: 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

[bug #20941] Modules interact badly with macros

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 straightforwar

Re: PossibleGuileBug : (eq? )

"[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 p

Re: guile.m4 may need serial number

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

Re: guile.m4 may need serial number

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 u

Re: segfault from set!

Jon Wilson <[EMAIL PROTECTED]> writes: > Hi, > $mv ~/.guile ~/guile# rename the setup file so it gets ignored. > $guile > guile> (set! 'a 5) > > Backtrace: > In standard input: >1: 0* Segmentation fault > > > $guile > guile> (define a 7) > guile> (set! 'a 5) > > Backtrace: > In standard in

Re: guile-1.8.3 Intel Mac Leopard compilation fails due to no off64_t

Roger Mc Murtrie <[EMAIL PROTECTED]> writes: > Compilation of guile-1.8.3 fports.c failed as the stat64 package in > Mac OSX Leopard does not seem to declare off64_t. > only off_t seems to be declared. > To get fports.c to compile: > In _scm.h I changed > #define off_t_or_off64_t

Re: guile-1.8.3 Intel Mac Leopard compilation fails due to no off64_t

Roger Mc Murtrie <[EMAIL PROTECTED]> writes: > Similiar problem with filesys.c > Compiles by changing in _scm.h > #define dirent_or_dirent64 > CHOOSE_LARGEFILE(dirent,dirent64) > to > #define dirent_or_dirent64 dirent This follows on from the off_t question. If your off_t is actuall

Re: Intel Mac-mini OSX 10.5.1 guile test results

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 > PASS: test-num2integral > P

Re: Mac PowerBookG4 OS X 10.4.11 (Tiger) guile test results

Roger Mc Murtrie <[EMAIL PROTECTED]> writes: > : In expression (car spec): > : Stack overflow > guile --user-srfi=1,10 fails to run > FAIL: test-use-srfi In eval.c, can you look for this line: { SCM_OPTION_INTEGER, "stack", 2, "Stack size limit (measured in words; 0 = no check)." }, and

<    1   2   3   4   5   >