Hi Luca,
Luca Saiu writes:
> (define (fibo n)
> (if (< n 2)
> n
> (+ (fibo (- n 1))
> (fibo (- n 2)
This function is not tail-recursive, so it consumes stack space, which
increases the amount of memory the GC has to scan. My guess is that
this has to do with the time
Recently, git guile has been consistently hanging in fluids.test. Cpu usage
drops to 0. This is on a single core machine running a fairly up-to-date
Debian Testing.
$ gcc --version
gcc (Debian 4.4.2-9) 4.4.3 20100108 (prerelease)
$ git describe
release_1-9-9-23-g6128f34
Here is a gdb backtra
dsm...@roadrunner.com wrote:
> Recently, git guile has been consistently hanging in fluids.test. Cpu usage
> drops to 0. This is on a single core machine running a fairly up-to-date
> Debian Testing.
>
> Here is a gdb backtrace connected to the hung process:
After 10 make check runs, f
Hi Dale,
writes:
> Recently, git guile has been consistently hanging in fluids.test. Cpu
> usage drops to 0. This is on a single core machine running a fairly
> up-to-date Debian Testing.
What does ./build-aux/config.guess say?
Thanks,
Ludo’.
"Ludovic Courtès" wrote:
> Hi Dale,
>
> writes:
>
> > Recently, git guile has been consistently hanging in fluids.test. Cpu
> > usage drops to 0. This is on a single core machine running a fairly
> > up-to-date Debian Testing.
>
> What does ./build-aux/config.guess say?
$ ./build-au
Hi,
writes:
> Thread 1 (Thread 0x404f92f0 (LWP 14857)):
> #0 0x4001e424 in __kernel_vsyscall ()
> #1 0x4046c285 in sem_wait@@GLIBC_2.1 () at
> ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/sem_wait.S:80
> #2 0x40168018 in GC_stop_world () at pthread_stop_world.c:426
The other thread sho
Hello,
Luca Saiu writes:
> The effect is much weaker in either case, when using tail-recursive
> functions. This is interesting.
Another guess: it could be that the non-tail-recursive version fills the
L2 cache (/sys/devices/system/cpu/cpu0/cache/index2/size says it’s 2 MiB
on my laptop), or so
This is with the latest from git.
(use-modules (srfi srfi-26))
(define (f! A B) (array-fill! B 0.))
(define x (make-typed-array 'f64 0. 2))
(cut f! #2f64((0 1) (2 3)) <>)
Throw to key `wrong-type-arg':
ERROR: Wrong type (expecting array): #< key: f!>
Entering the debugger. Type `bt' for a backt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ludovic.
Ludovic Courtès wrote:
> Hello,
>
> Luca Saiu writes:
>
>> The effect is much weaker in either case, when using tail-recursive
>> functions. This is interesting.
>
> Another guess: it could be that the non-tail-recursive version fills
On Tue 30 Mar 2010 17:02, Daniel Llorens del Río
writes:
> 0 (assoc-ref ((#< key: f!> . 1)) #2f64((0 1) (2
> 3)))
This was actually a problem with the runtime, not the compiler: equal?
on an array and a non-array bombed. Fixed, thanks!
Andy
--
http://wingolog.org/
10 matches
Mail list logo
