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

playing with spheres
by Michael Greenly 04 Jan '14

04 Jan '14

I'm very new to gambit and a bit confused by this behavior. I'm not sure if it's a Spheres specific issue or if I'm missing something more obvious. Any help pointing me in the right direction would be greatly appreciated. I've installed gambit v4.7.1 and Scheme Spheres v0.4 just as the quick start guide recommends. Everything seems to be working, for example I can create a new project with 'sfusion new -g minimal foo' and 'sake host:run' works as expected. What confuses me is that from the repl I can enter '(##import core: testing)' and then '(check 42 => 42)' and everything works as expected. But if I create a file: ; test.scm (##import core: testing) (check 42=> 42) Then run 'gsi test.scm' I get '***ERROR -- Unbound variable: Check'. I don't understand why there's a difference in behavior between the repl and batch mode when using gsi? -- Michael Greenly http://logic-refinery.com

2 1

versioned shlibs
by Jackson Doak 03 Jan '14

03 Jan '14

What is required to make gambit produce versioned shlibs? Debian had a patch for this ( http://sources.debian.net/src/gambc/4.2.8-1.1/debian/patches/100_pass_sonam… ) but it no longer applies. Provided one build (unlike debian's current system) works, this is the only change gambit-c still needs.

1 0

Gambit IOS- access to SDK
by Fuchs Ira 03 Jan '14

03 Jan '14

I've temporarily given up on using Gambit on Android as it seems to fail almost immediately. I have now downloaded the IOS version. Am I correct that there is no way to access any IOS SDK functions? For example, it appears that set-webView-content is not there (as it is in the Android version). I presume this is due to Apple's restrictions on apps. Perhap someone has a version for jailbroken devices? Also when I type (exit) in the REPL on IOS, I get: "To exit, press the sleep button for 5 seconds then the home button for 10 seconds." What is that all about?

5 10

Memory leak (?) using `c-define`d functions from foreign release functions.
by Estevo 01 Jan '14

01 Jan '14

Valgrind reports Gambit is leaking a "sfun stack marker" if I call, from a foreign release function, another function defined with `c-define`. The code below is about the most innocent looking thing I could come up with. Doesn't Gambit like c-define functions called within release functions, or is Valgrind giving me a false positive here (as it is wont to do quite often.) ; ~/gambit-dbg/bin/gsc -exe -cc-options -g test-c-define.scm && valgrind --leak-check=full ./test-c-define (c-declare #<<c-declare-end typedef struct { int x; int y; } point; void scm_release_point(unsigned long); ___SCMOBJ c_release_point(void *ptr) { scm_release_point((unsigned long)ptr); ___EXT(___release_rc)(ptr); return ___FIX(___NO_ERR); } c-declare-end ) (c-define (release-point ptr) (unsigned-long) void "scm_release_point" "" (println "release-point called")) (c-define-type point (pointer "point" (point*) "c_release_point")) (define p ((c-lambda () point "___result_voidstar = ___EXT(___alloc_rc)(sizeof(point));"))) (println "p is " p) (set! p #f) (##gc) ; for good measure... (##gc) (##gc) (println "Bye.") valgrind --leak-check=full ./test-c-define ==16301== Memcheck, a memory error detector ==16301== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==16301== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==16301== Command: ./test-c-define ==16301== p is #<point* #2 0x5c04640> release-point called Bye. ==16301== ==16301== HEAP SUMMARY: ==16301== in use at exit: 71 bytes in 1 blocks ==16301== total heap usage: 153 allocs, 152 frees, 4,247,198 bytes allocated ==16301== ==16301== 71 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==16301== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==16301== by 0x4C922E: ___alloc_mem (os_base.c:185) ==16301== by 0x4B7DB5: alloc_mem_aligned (mem.c:452) ==16301== by 0x4B8C57: alloc_scmobj_still (mem.c:1245) ==16301== by 0x4B8D61: ___alloc_scmobj (mem.c:1285) ==16301== by 0x4B8E44: ___make_vector (mem.c:1362) ==16301== by 0x4C677B: ___make_sfun_stack_marker (c_intf.c:6452) ==16301== by 0x4B359E: scm_release_point (test-c-define.c:139) ==16301== by 0x4B354B: c_release_point (test-c-define.c:130) ==16301== by 0x4C24D7: ___release_foreign (c_intf.c:1713) ==16301== by 0x4BC354: free_unmarked_still_objs (mem.c:3271) ==16301== by 0x4BE922: ___garbage_collect (mem.c:4698) ==16301== ==16301== LEAK SUMMARY: ==16301== definitely lost: 71 bytes in 1 blocks ==16301== indirectly lost: 0 bytes in 0 blocks ==16301== possibly lost: 0 bytes in 0 blocks ==16301== still reachable: 0 bytes in 0 blocks ==16301== suppressed: 0 bytes in 0 blocks ==16301== ==16301== For counts of detected and suppressed errors, rerun with: -v ==16301== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)

2 8

gambit-ffi-types v0.2 released, now without wills.
by Estevo 01 Jan '14

01 Jan '14

I've finally found a way to manage references between foreign objects (which actually works for any kind of Scheme memory-allocated object) that avoids the problems of using wills. I keep a mapping from _serial numbers_ of dependent objects to references to the objects they depend upon. On garbage collection (using the ##add-gc-interrupt-job! hook), I walk this mapping (currently an assoc list) and remove any entries where the serial number can no longer be found in ##serial-number-to-object-table. So you call it a table with anemic (weaker than weak!) keys. See https://github.com/euccastro/gambit-ffi-types/blob/master/ffi-types-lib.scm This approach is beautifully simple and, unlike the one involving wills, seems robust to me. I also added some usage instructions to the README: https://github.com/euccastro/gambit-ffi-types Happy new year!

1 0