- Gambit-list - mailman.iro.umontreal.ca

gambit + blackhole + srfi 13
by Steve Huffman 02 Sep '09

02 Sep '09

Hi All, I'm attempting to compile Black Hole on Gambit 4.5.1. I've installed BH from Git. I ran modules-compile!, and each of the standard BH modules compiled successfully, except for srfi-13, which fails because it runs out of memory. I'm running OS X with 4 gigs of ram. I notice the cc process that is spawned uses about 3.5 gigs before it dies. That seems a bit excessive, no? > (modules-compile! (modules-in-dir "~~/lib/modules/std") #t) Compiling 1 modules "/usr/local/Gambit-C/lib/modules/std/srfi/13.scm" (1/1) cc1(209) malloc: *** mmap(size=97247232) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug cc1: out of memory allocating 97245440 bytes after a total of 0 bytes Warning: Compilation failed: C compilation or link failed while compiling "/usr/local/Gambit-C/lib/modules/std/srfi/13.scm" > Thanks for any help, Steve

3 3

Thread undocumented features...
by David St-Hilaire 01 Sep '09

01 Sep '09

Hi all! I address this message to Marc, but I thought it might interest others so I cc'ed it to the gambit list ;). What is the difference between the undocumented thread-interrupt! and thread-suspend! functions? Is it possible to retrieve an interrupted thread's continuation? Basically I want to know if its possible to do something like: (let ((t (make-thread (lambda () (let loop ((i 0)) (write 'o_O) (loop (+ i 1))))))) (thread-start! t) (thread-sleep! 0.5) (thread-interrupt!/suspend! t) (let ((k (get-the-continuation t))) (continuation-graft k (lambda (r) i)))) I don't know if this pseudo code is clear enough to illustrate my needs? I'd like to stop another thread and use continuation-graft to execute some code on it's stack. Thanks! -- David

3 2

srfi-9
by Michele Zaffalon 31 Aoû '09

31 Aoû '09

Hi, here's a trivial question, but I couldn't find it in the documentation. The documentation says that Gambit has support for srfi 9. However none of the procedures seem implemented. What am I doing wrong? michele

3 5

different set! behavior in interpreted and compiled code
by vasil 30 Aoû '09

30 Aoû '09

Hi! Suppose I have a.scm with next code: ;;------------------------------------------ (define l #f) (let ((t 0)) (set! l (lambda (q) (pp t) (set! t q)))) ;;------------------------------------------ Then I start gsc and do next things: Gambit v4.5.1 > (load "a.scm") ".../a.scm" > (l 2) 0 > (l 3) 2 > (compile-file "a.scm") > (load "a") ".../a.o1" > (l 2) 0 #&2 > (l 3) 2 #&3 Why in compiled code set! returns boxed value, but in interpreted code not? Vasil

2 2

Memory issue with threads
by vasil 29 Aoû '09

29 Aoû '09

Hi! I'm trying to understand what is happening with memory in next test cases: 1. Making many threads, but not staring them -------------------------------------------- Gambit v4.5.1 > (gc-report-set! #t) > (##gc) *** GC: 1 ms, 1.33M alloc, 2.14M heap, 654K live (30% 635200+34704) > (define t (do ((i 0 (+ 1 i)) (l '() (cons (make-thread (lambda () (void))) l))) ((> i 1000000) l))) *** GC: 2 ms, 2.82M alloc, 4.77M heap, 2.08M live (44% 2149968+34704) *** GC: 5 ms, 5.50M alloc, 10.0M heap, 4.76M live (47% 4953664+34704) *** GC: 16 ms, 10.8M alloc, 20.5M heap, 10.0M live (49% 10459472+34704) *** GC: 27 ms, 21.3M alloc, 41.5M heap, 20.5M live (49% 21468624+34704) *** GC: 54 ms, 42.3M alloc, 83.5M heap, 41.5M live (50% 43486848+34704) *** GC: 97 ms, 84.3M alloc, 168M heap, 83.5M live (50% 87527232+34704) *** GC: 200 ms, 168M alloc, 336M heap, 168M live (50% 175605712+34704) *** GC: 392 ms, 336M alloc, 672M heap, 336M live (50% 351765360+34704) *** GC: 801 ms, 672M alloc, 1.31G heap, 671M live (50% 704080736+34704) > (##gc) *** GC: 1417 ms, 1.15G alloc, 2.30G heap, 1.15G live (50% 1232640240+34704) > (set! t #f) > (##gc) *** GC: 943 ms, 1.15G alloc, 2.30G heap, 1.15G live (50% 1232640192+34704) 2. Making many threads, starting them and waiting for termination ----------------------------------------------------------------- Gambit v4.5.1 > (gc-report-set! #t) > (##gc) *** GC: 3 ms, 1.33M alloc, 2.14M heap, 654K live (30% 635200+34704) > (define t (do ((i 0 (+ 1 i)) (l '() (cons (make-thread (lambda () (void))) l))) ((> i 1000000) l))) *** GC: 4 ms, 2.83M alloc, 4.77M heap, 2.12M live (44% 2187824+34704) *** GC: 6 ms, 5.47M alloc, 10.0M heap, 4.76M live (47% 4953664+34704) *** GC: 14 ms, 10.7M alloc, 20.5M heap, 10.0M live (49% 10460704+34704) *** GC: 26 ms, 21.2M alloc, 41.5M heap, 20.5M live (49% 21468624+34704) *** GC: 51 ms, 42.2M alloc, 83.5M heap, 41.5M live (50% 43486848+34704) *** GC: 97 ms, 84.2M alloc, 168M heap, 83.5M live (50% 87527232+34704) *** GC: 199 ms, 168M alloc, 336M heap, 168M live (50% 175605712+34704) *** GC: 396 ms, 336M alloc, 672M heap, 336M live (50% 351765360+34704) *** GC: 814 ms, 672M alloc, 1.31G heap, 671M live (50% 704080736+34704) > (##gc) *** GC: 1404 ms, 1.15G alloc, 2.30G heap, 1.15G live (50% 1232640240+34704) > (for-each (lambda (x) (thread-start! x) (thread-join! x)) t) > (##gc) *** GC: 660 ms, 1.55G alloc, 1.16G heap, 596M live (50% 624635824+34704) > (set! t #f) > (##gc) *** GC: 133 ms, 1.55G alloc, 2.14M heap, 654K live (30% 635200+34704) --------------------------------------------------------------------- The question is: why GC does not collect unreferenced thread objects in first case and do collect them in second case? Vasil

2 2

gsc segfaults
by Ralf Schmitt 28 Aoû '09

28 Aoû '09

Hi all, I get a segfault when trying to compile srfi-13: $ curl -O http://srfi.schemers.org/srfi-13/srfi-13.scm $ gsc -e '(load "~~/lib/syntax-case.scm")' srfi-13.scm zsh: segmentation fault gsc -e '(load "~~/lib/syntax-case.scm")' srfi-13.scm this happens with gambit v4.5.1 on a x86-64 arch linux using gcc 4.4.1. Regards, - Ralf

5 5

Problems with using both -o and -c at the commandline with v4.5.1
by Cameron Hatfield 27 Aoû '09

27 Aoû '09

I've been trying for a little bit now to try to get this type of command line working: gsc -:d- -c -o <build directory>\<sub set build directory> ..\<some set of paths>\main.scm > out.txt And I end up with this error: *** ERROR IN ##main -- string expected for output: parameter What am I doing wrong? At least judging by the documentation, using the flags together should be supported. I've also tried many different permutation of the above command, just in case including: gsc -:d- -o <build directory>\<sub set build directory> -c ..\<some set of paths>\main.scm > out.txt gsc -:d- -o -c <build directory>\<sub set build directory> ..\<some set of paths>\main.scm > out.txt gsc -:d- -c <build directory>\<sub set build directory> ..\<some set of paths>\main.scm > out.txt Full story: I'm trying to get the gambit compiler working with the waf build system. Currently using this as the arguments to the build step: gsc -:d- -c -o ${TGT[0].bld_dir(env)} ${SRC} > out.txt Sadly, all I get is the above error. Any ideas? Thanks, Cameron

2 3

(define ((...) ...)
by Michele Zaffalon 25 Aoû '09

25 Aoû '09

Hi, this question has nothing to do with Gambit in particular but I couldn't find an explanation. In Structure and Interpretation of Classical Mechanics, the *first* procedure defined is (define ((L-free-particle mass) local) (let ((v (velocity local))) ...) and the book explains that L-free-particle is a procedure that takes mass as an argument and returns a procedure that takes local as a parameter. Now, what doesn't (define ((L-free-particle mass) local) ... work with Gambit? What is missing? Thanks, michele

4 5

Re: [gambit-list] simple gsc'd program segfaults
by Stephen Sinclair 25 Aoû '09

25 Aoû '09

On Tue, Aug 25, 2009 at 6:22 PM, Stephen Sinclair<radarsat1(a)gmail.com> wrote: > On Tue, Aug 25, 2009 at 6:12 PM, Ivan Kelly<ivan(a)ivankelly.net> wrote: >> On Tue, Aug 25, 2009 at 06:10:35PM -0400, Stephen Sinclair wrote: >>> $ gsc -o test test.scm >> try gsc -exe test.scm > > As you mentioned to me on IRC, I guess this isn't available in the > Ubuntu version. Maybe it's worth installing from source.. > >> >>> $ gsc -link -o test.c test.scm >>> >>> $ gcc -o test test.c -lgambc >> gsc -link will also produce a test_.c file, you need to compile that >> also. >> > > Thanks, that worked! > > I see now that if I use both -link and -o, it doesn't produce test_.c. > However, just -link produces the two .c files, which don't segfault. > > cheers, > Steve >

1 0

simple gsc'd program segfaults
by Stephen Sinclair 25 Aoû '09

25 Aoû '09

Hello! I'm interested in playing with Scheme a bit lately, so I thought I'd check out Gambit. Well, I had no problems getting the interpreter to work, but I seem to be having issues with the compiler. I installed this from the Ubuntu intrepid repo btw. Here is an example session, showing that some very simple code just seems to segfault when compiled. Tried this on two different computers, what am I doing wrong? Thanks. Steve $ echo '(display (+ 1 2))' >test.scm $ gsc -o test test.scm $ ./test Segmentation fault $ gsc -link -o test.c test.scm $ gcc -o test test.c -lgambc $ ./test Segmentation fault $ gcc -O0 -g -o test test.c -lgambc $ gdb ./test GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu"... (gdb) r Starting program: /home/sinclairs/scheme/space-invaders/test Program received signal SIGSEGV, Segmentation fault. 0xb7ffc223 in ?? () from /usr/lib/libgambc.so.4 (gdb) bt #0 0xb7ffc223 in ?? () from /usr/lib/libgambc.so.4 Cannot access memory at address 0x5 (gdb)

2 1