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

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 th

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

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 unco

Re: hashx -set! and -ref

Gregory Marton <[EMAIL PROTECTED]> writes: > I may be misunderstanding something, but I thought this should yield 'bar: > > guile> (let ((ht (make-hash-table))) > (hashx-set! (lambda (k s) 1) equal? ht 'foo 'bar) > (hashx-ref (lambda (k s) 1) equal? ht 'foo)) > > #f The second a

[bug #22022] hashx-set! and -ref

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? 'ba

[bug #22022] hashx-set! and -ref

Follow-up Comment #2, bug #22022 (project guile): Another one: (pass-if (equal? "#" (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 up to 34, not f

Re: [bug #22022] hashx-set! and -ref

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 re

[bug #22022] hashx-set! and -ref

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))) ;;; (#

Re: [bug #22022] hashx-set! and -ref

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.

Re: Make problem Mac OS X

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,

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

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"

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

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 cle

Re: Intel Mac-mini OSX 10.5.1 guile test results

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

Re: Intel Mac-mini OSX 10.5.1 guile test results

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

Re: dirname & basename not working on mingw

"Charles Day" <[EMAIL PROTECTED]> writes: > Hello, Hi Charles! > This is my first post to any guile list. I write because I am using > Guile 1.6.8 on mingw, and the dirname and basename procedures don't > work properly. I tried a few variations: > > (dirname "abc/def") returns "." > (dirname "a

Re: comparing procedures

Gregory Marton <[EMAIL PROTECTED]> writes: > Hi folks, > > I'm trying to write a meaningful comparison operator for > procedures. Out of interest, why? > Clearly this wants more than procedure-source, because > variables in the source may be bound to different values in the > procedure-environme

Re: sending and and or as an argument links their behavior

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 #

Re: A passing test case

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?

Re: A passing test case

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

[bug #22022] hashx-set! and -ref

Update of bug #22022 (project guile): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #4: (For the bug record.

MacOS issues

There have been several MacOS issues raised recently, and I'd like to check that I haven't lost track of any of them, hence this email. Could MacOS-interested people please review and comment on the following? (We're not there yet, because some of the following points still need work, but the obje

[bug #22159] Concerns about hash table API

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

Re: Intel Mac-mini OSX 10.5.1 guile test results

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 > AC_INIT(gui

Re: Intel Mac-mini OSX 10.5.1 guile test results

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

Re: patch for a installation bug in guile

"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 solu

Re: No declaration for isblank

[EMAIL PROTECTED] (Ludovic Courtès) writes: > Hi, > > I'm slowly getting back to Guile, and the first thing I came across was > this old Gnulib-related bootstrap issue (HEAD). > > [EMAIL PROTECTED] (Ludovic Courtès) writes: > >> My `gnulib-cache.m4' is the same as the one in CVS HEAD: >> >> >>

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

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

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

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

Re: guile 1.6.8 make check failure on AIX 6.1

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 > /opt

Re: String translation

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

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

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/agen

Re: Guile licensing, also R6RS/ERR5RS

"Leonardo Valeri Manera" <[EMAIL PROTECTED]> writes: > magnus gave me this backtrace > > " 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 t

Re: guile 1.6.8 make check failure on AIX 6.1

Rainer Tammer <[EMAIL PROTECTED]> writes: > ERROR: srfi-4.test: u8 vector: u8vector? success - arguments: > ((memory-allocation-error "make-u8vector" "Memory allocation error" #f > #f)) [...] Those errors would occur if realloc(NULL, 0) returns NULL on AIX. (Whereas on GNU/Linux, it returns non-N

Re: guile 1.6.8 make check failure on AIX 6.1

Rainer Tammer <[EMAIL PROTECTED]> writes: > In file included from ../libguile/gc.h:27, > from ../libguile.h:73, > from discouraged.c:22: > ../libguile/hooks.h:43: error: expected ';', ',' or ')' before '.' token > ../libguile/hooks.h:48: error: expected specifier-qu

Re: guile 1.6.8 make check failure on AIX 6.1

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");

Re: guile 1.8.3 compilation errors on AIX 6.1

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

Re: guile 1.6.8 make check failure on AIX 6.1

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

Fix for _Complex_I problems

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 i

Re: Fix for _Complex_I problems

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? Actuall

Re: Random Doc improvement

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

Re: Fix for _Complex_I problems

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 > autoconf/automake/lib

Re: Fix for _Complex_I problems

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 sec

Re: Fix for _Complex_I problems

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:

Re: Guile-1.8.4 compile bug Mac OS X 10.4.11 PPC G4

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

FW: Mac Intel Leopard guile 1.8.4 link fails

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

Re: Mac Intel Leopard guile 1.8.4 link fails

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 i

Re: FW: Mac Intel Leopard guile 1.8.4 link fails

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

Re: stack overflow

"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 m

Re: Mac Intel Leopard guile 1.8.4 link fails

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

Re: GNU Guile 1.8.4 released

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.8&arch=alpha&ver=1.8.4%2B1-1&stamp=1203917145&file=log&as=raw

Re: Mac Intel Leopard guile 1.8.4 link fails

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

Re: GNU Guile 1.8.4 released

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 referen

Re: Guile-1.8.4 compile bug Mac OS X 10.4.11 PPC G4

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

Re: Guile-1.8.4 compile bug Mac OS X 10.4.11 PPC G4

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/li

Re: Guile-1.8.4 compile bug Mac OS X 10.4.11 PPC G4

Hans Aberg <[EMAIL PROTECTED]> writes: > On 7 Mar 2008, at 23:21, Neil Jerram wrote: > >>> 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 th

Re: Unable to make threads from scm_c_primitive_load'ed files/Previously scm_c_define_gsubr-defined values unbound in new threads

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 t

Re: guile -c "(scheme-report-environment 5)" ==> ERROR: Unbound variable: scheme-report-environment

"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) > # > guile> (eval '(* 2 3) (scheme-rep

Re: Guile 1.8.4 build difficulties on old Linux

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

Re: Bug 17344 lives

"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

Re: Bug 17344 lives

"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 underlyin

Re: Compiling v1.8.5 on tru64 5.1b

REENTRANT -O4 -g3 > -I/usr/local/gmp/include -I/usr/local/readline/include -c -MD discouraged.c > -DPIC -o .libs/libguile_la-discouraged.o > cc: Info: discouraged.c, line 30: Extraneous semicolon. (extrasemi) > DEFFROM (short, scm_short2num, scm_from_short); > ---

Re: Compiling v1.8.5 on tru64 5.1b

[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]> >> + >> +

[PATCH] reader.test fix for cygwin

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 \")

Re: Failure in check after git and configure and build

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

Re: big number printout

2008/7/2 Bill Schottstaedt <[EMAIL PROTECTED]>: > 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: [...] Is this an imp

Re: big number printout

2008/7/4 Bill Schottstaedt <[EMAIL PROTECTED]>: >> 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? Not "Guile", me. As one of Guile's maintainers, my desire - and

Re: Guile Logo License

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-res

Re: signal handling different in 1.8.3 than 1.8.1?

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 the

Re: rationalize returns inexact results.

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

[bug #24009] does not check for short write()s

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 _

Re: procedure-source inconsistencies

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 >

Re: (gcd -2) -> -2

2008/8/11 Bill Schottstaedt <[EMAIL PROTECTED]>: > guile> (gcd -2) > -2 > > (or any negative single argument). Is that wrong? Neil

Re: (< complex) and friends

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-ty

Re: (gcd -2) -> -2

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?

[PATCH] Re: (gcd -2) -> -2

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: (< complex) and friends

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 c

Re: guile 1.8.5 compile segfault

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 "segm

Re: (< complex) and friends

2008/9/19 Jon Wilson <[EMAIL PROTECTED]>: > Here's a different way to think about it that makes the (<) case, as well as > perhaps (< 2 1 "hi"), make sense quite naturally. [...] Thanks everyone for discussing these cases. It seems to me that although it may seem curious, Guile's current behavior

Re: (< complex) and friends

2008/9/19 Bill Schottstaedt <[EMAIL PROTECTED]>: > map does not accept no list: > > guile> (map (lambda (a) a)) > > Backtrace: > In standard input: > 1: 0* [map #] > > standard input:1:1: In procedure map in expression (map (lambda # a)): > standard input:1:1: Wrong number of arguments to # > ABO

Re: null string oddities

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

Re: guile 1.8.5 compile segfault

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 seco

Re: guile 1.8.5 compile segfault

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

Re: guile 1.8.5 compile segfault

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: string-set! examples in r5rs.html

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

Re: string-set! examples in r5rs.html

Hi Ludovic, Thanks for your responses; all make sense to me. 2008/9/23 Ludovic Courtès <[EMAIL PROTECTED]>: > > I committed a revised patch (attached). And for the patch! Neil

Re: begin oddities

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

Re: begin oddities

2008/9/25 Bill Schottstaedt <[EMAIL PROTECTED]>: > oh -- it's the (f) that triggers the silly error, not the preceding stuff. Yes. This particular error isn't picked up until the code is actually executed. Neil

Re: guile-1.8.5 test failures

2008/5/29 Peter O'Gorman <[EMAIL PROTECTED]>: > > We built guile-1.8.5 on multiple machines with the native compilers and > these patches: > > http://lists.gnu.org/archive/html/guile-devel/2008-05/msg00020.html > http://lists.gnu.org/archive/html/guile-devel/2008-05/msg00017.html > (attached patch)

Re: guile 1.8.5 compile segfault

Sorry to take a while to continue this investigation. 2008/9/23 tantalum <[EMAIL PROTECTED]>: > > i managed to get a core dump file. heres a backtrace and some "frame x" > calling: > http://pastebin.com/m3c55053b This: (gdb) frame 0 #0 scm_mark_locations (x=0x7fff7f4c8d68, n=1844674407370955156

Re: [bug #24554] Pthreads and Stack overflow in guile (reopen bug 20814?) (guile 1.8.5)

2008/10/14 Kannan Vijayan <[EMAIL PROTECTED]>: > > Follow-up Comment #1, bug #24554 (project guile): > > > Hrm, this may be a non-issue after-all. Digging through the source, I > discovered the SCM_USE_PTHREAD_THREADS macro referred to in key places > (crucially, the one-time thread initialization

Re: [bug #24554] Pthreads and Stack overflow in guile (reopen bug 20814?) (guile 1.8.5)

2008/10/14 <[EMAIL PROTECTED]>: > > I would imagine that --with-threads will not be turned back on until a 1.10.x > (or 2.0.0 ?) release of Guile. > > My limited understanding of the situation (possibly incorrect): Using > --without-threads changes the sizes of some data structures (I'm guessin

Re: guile-1.8.5 segfaults while building on ppc with gcc-4.3 and -O2

2008/11/12 Marijn Schouten (hkBst) <[EMAIL PROTECTED]>: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > I've had some reports that guile-1.8.5 segfaults while building on ppc with > gcc-4.3 and -O2[1]. It seems to build fine with -O1 instead. Did anyone else > see > this behavior? Y

Re: [PATCH] fix for Re: crash in gc with upside-down stack

2008/11/13 Ludovic Courtès <[EMAIL PROTECTED]>: > Hi, > > "Linas Vepstas" <[EMAIL PROTECTED]> writes: > >> The patch below fixes a crash during garbage collection, where, during >> the mark-stack phase, the top and bottom of the stack are found to be >> in backwards order, typically because scm_wit

Re: [PATCH]: deadlock in make_struct()

2008/11/18 Ludovic Courtès <[EMAIL PROTECTED]>: > > Kevin asked the same question a while back: > > http://lists.gnu.org/archive/html/guile-devel/2007-02/msg6.html > > One we've had enough developers wondering why it's here, maybe we can > safely remove it. :-) I agree. I also can't see an

Re: [PATCH] Final: thread lock nesting debugging

2008/11/17 Linas Vepstas <[EMAIL PROTECTED]>: > I've been seeing all sorts of deadlocks in guile, and so I wrote a small > debugging utility to try to track down the problems. Interesting patch! One query; I may be being a bit dumb, I'm only just recovering from a bad cold, but anyway... Your pa

Re: [PATCH] Final: thread lock nesting debugging

2008/11/19 Neil Jerram <[EMAIL PROTECTED]>: > 2008/11/17 Linas Vepstas <[EMAIL PROTECTED]>: >> I've been seeing all sorts of deadlocks in guile, and so I wrote a small >> debugging utility to try to track down the problems. > > Interesting patch! > > On

Re: [PATCH] Final: thread lock nesting debugging

2008/11/19 Neil Jerram <[EMAIL PROTECTED]>: > > Also I wondered if there are already tools to debug this kind of thing > (without new Guile code), and a quick search finds this [1], which > suggests that helgrind could catch bad lock ordering for us. > > [1] http://www.n

Re: compiling problems

2008/11/27 David Kyle <[EMAIL PROTECTED]>: > Hoping someone has a bit of time to look at this "undefined reference to > `lt__PROGRAM__LTX_preloaded_symbols" bug. David, This is a known problem, caused by your machine having libltdl installed from Libtool 2.2 - whereas guile expects libltdl from L

[bug #22022] hashx-set! and -ref

Follow-up Comment #5, bug #22022 (project guile): Grem's copyright assignment has now been processed, so his additional hashtable tests have been committed. ___ Reply to this item at: _

Re: 1.8.6 build error

2008/12/9 Ben Isajiw <[EMAIL PROTECTED]>: > Hi, > > I apologize if this is wrong email list for my question. Please provide > correct list. This is the correct list. > I try to build guile 1.8.6 as requirement for autogen as requirement for > Anjuta. First error was cannot find libltdl.so.7.

Re: 1.8.6 build error

2008/12/9 Ben Isajiw <[EMAIL PROTECTED]>: > > Yes, this is feasible as I can root Fedora 10 distribution of course. But > maybe I'm not sure where -dev package for libltdl are served. Can you link > me please? I don't know Fedora very well, but from a bit of googling it looks like you should

<    1   2   3   4   5   >