Gambit-list Avril 2006

gambit-list@iro.umontreal.ca

6 participants
10 discussions

Edge triggered I/O with libevent
by Adam Langley 04 Avr '13

04 Avr '13

Gambit uses the select call on POSIX systems to multiplex IO operations. This is fine for small numbers of file descriptors, but falls apart quickly with large numbers[1]. libevent[2] is a wrapper library around a number of modern IO multiplexing systems (epoll on Linux, kqueue on the BSDs as well as poll and select). Attached is a patch which converts Gambit to using edge triggered I/O with epoll and libevent. This also requires a patch (attached) of libevent since the standard distribution doesn't include edge triggering support and the upstream appears to be on holiday. (epoll is required because I don't have a BSD box on which to develop edge triggering support for kqueue) This patch (for Gambit) preprocesses away to nothing unless --enable-libevent is passed to the configure script. (Note that, since this patches the configure.ac script, you'll need to run autoconf to regenerate). I hope I've not broken anything, but at this stage I've only tested that the console and tcp ports work. This patch (in the future) should also allow people, who write programs which use socket calls directly, to integrate into the main event loop at some point. Testing is more than welcome and, if you find a form of IO which is broken, please email me. [1] http://monkey.org/~provos/libevent/libevent-benchmark2.jpg [2] http://monkey.org/~provos/libevent/ -- Adam Langley agl(a)imperialviolet.org http://www.imperialviolet.org (+44) (0)7906 332512 PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60

2 2

Performance observations
by Christian 28 Avr '06

28 Avr '06

Hello Here are a few observations about runtime performance (of compiled code on Linux/x86). - the generational garbage collector is about 3 times faster than allocation/collection of "still" objects. But it looks like it is only about as fast as the BoehmGC as being used by Bigloo. Comparing Chicken with Gambit, it looks like Chicken allocates for all function calls, but it has a collector which seems to be 3 times faster than the generational collector of Gambit (Chicken is sometimes faster than Gambit for allocation intensive code (like closures are about as cheap as normal function calls), but only in benchmarking mode (-Ob), Gambit is faster for most other code and less dependent on unsafe optimizations. It surprises me a bit that Chicken's stack allocation/scanning approach is so fast, since also return addresses from function calls are saved on the stack for no benefit (which should make the memory usage slightly bigger and scanning more costly, right?). Maybe this is highly cpu cache dependent? Chicken does some timings during configuration, which makes me suspect that there is room for tuning for Gambit, too. - function calls across compilation block boundaries usually are quite slow (like hundreds of cpu cycles), I guess since they are looked up dynamically by name on each call. For example replacing calls to ##promise? with calls to my_promise? with the definition (define (my_promise? obj) (and (##subtyped? obj) (##eq? (##subtype obj) 12 ;; current definition of (macro-subtype-promise) ))) in the same block makes the time needed for calling this predicate drop from around 200 cpu cycles down to about 30 cycles. A mechanism for static function calls across block boundaries might be beneficial in such cases where a function is known not to change during runtime except when a new object file is loaded. (An alternative may be to include copies of those function definitions which are speed critical into every block which is using them, that also opens the possibility for inlining, but code bloat may be the downside.) (In case gambit is currently using a name lookup in a table for each call: I'm wondering if (just an idea) using a box around the lambda value wouldn't speed such calls up already. Callers could keep a reference to the box and wouldn't have to do a costly table lookup anymore on subsequent calls, and the system could still replace functions at any time.) Or are those cpu cache effects too? - maybe as a result of the above, delay and force might be faster than they are: a stream using those (in the same block) instead of the builtin delay / force is about 1.5 times faster for me: ;; I couldn't find a more lowlevel way to allocate a promise ;; structure: (define alloc_promise ##make-promise) (define-macro (my_delay body) `(alloc_promise (lambda () ,body))) ;; my_promise? -> see definition above (define (my_force promise) (if (my_promise? promise) (let ((maybe-thunk (##vector-ref promise 0))) (if maybe-thunk (let ((value (maybe-thunk))) (##vector-set! promise 1 value) (##vector-set! promise 0 #f) value) (##vector-ref promise 1))) (error "not a promise: " promise))) Thanks Christian.

1 1

Re: trouble making Gambit-C 4.0b17 under Solaris
by Marc Feeley 20 Avr '06

20 Avr '06

Will, something seems to be wrong with the timestamps on the files in the distribution. I'll check it out. In the meantime it may help to do: % touch lib/_kernel.c lib/_gambc.c gsi/_gsi_.c gsc/_gsc_.c % make The touch may be required of other files too. Once the compiler (gsc/ gsc) is built, you can change the .scm files in the runtime library and they will be recompiled by the Scheme compiler. Marc On 20-Apr-06, at 4:14 PM, William D Clinger wrote: > I'm having trouble getting Gambit-C 4.0b17 to build > under Solaris on various SunBlade systems. A typical > attempt is summarized below. > > Will > > [gambc40b17]% pwd > /proj/will/Apps/Gambit/gambc40b17 > > [gambc40b17]% which make > /arch/gnu/bin/make > > [gambc40b17]% ./configure --prefix=/proj/will/Apps/Gambit/ > > [gambc40b17]% make > making all in include > make[1]: Entering directory `/proj/will/Apps/Gambit/gambc40b17/ > include' > make[1]: Leaving directory `/proj/will/Apps/Gambit/gambc40b17/include' > making all in lib > make[1]: Entering directory `/proj/will/Apps/Gambit/gambc40b17/lib' > gcc -I../include -I. -Wall -W -Wno-unused -O1 -fno-math-errno - > fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit- > frame-pointer -fPIC -fno-common -DHAVE_CONFIG_H -D___PRIMAL - > D___LIBRARY -D___GAMBCDIR=\"/proj/will/Apps/Gambit/\" -c main.c > gcc -I../include -I. -Wall -W -Wno-unused -O1 -fno-math-errno - > fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit- > frame-pointer -fPIC -fno-common -DHAVE_CONFIG_H -D___PRIMAL - > D___LIBRARY -D___GAMBCDIR=\"/proj/will/Apps/Gambit/\" -c setup.c > gcc -I../include -I. -Wall -W -Wno-unused -O1 -fno-math-errno - > fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit- > frame-pointer -fPIC -fno-common -DHAVE_CONFIG_H -D___PRIMAL - > D___LIBRARY -D___GAMBCDIR=\"/proj/will/Apps/Gambit/\" -c mem.c > gcc -I../include -I. -Wall -W -Wno-unused -O1 -fno-math-errno - > fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit- > frame-pointer -fPIC -fno-common -DHAVE_CONFIG_H -D___PRIMAL - > D___LIBRARY -D___GAMBCDIR=\"/proj/will/Apps/Gambit/\" -c c_intf.c > gcc -I../include -I. -Wall -W -Wno-unused -O1 -fno-math-errno - > fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit- > frame-pointer -fPIC -fno-common -DHAVE_CONFIG_H -D___PRIMAL - > D___LIBRARY -D___GAMBCDIR=\"/proj/will/Apps/Gambit/\" -c os.c > gcc -I../include -I. -Wall -W -Wno-unused -O1 -fno-math-errno - > fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit- > frame-pointer -fPIC -fno-common -DHAVE_CONFIG_H -D___PRIMAL - > D___LIBRARY -D___GAMBCDIR=\"/proj/will/Apps/Gambit/\" -c os_base.c > gcc -I../include -I. -Wall -W -Wno-unused -O1 -fno-math-errno - > fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit- > frame-pointer -fPIC -fno-common -DHAVE_CONFIG_H -D___PRIMAL - > D___LIBRARY -D___GAMBCDIR=\"/proj/will/Apps/Gambit/\" -c os_time.c > gcc -I../include -I. -Wall -W -Wno-unused -O1 -fno-math-errno - > fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit- > frame-pointer -fPIC -fno-common -DHAVE_CONFIG_H -D___PRIMAL - > D___LIBRARY -D___GAMBCDIR=\"/proj/will/Apps/Gambit/\" -c os_shell.c > gcc -I../include -I. -Wall -W -Wno-unused -O1 -fno-math-errno - > fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit- > frame-pointer -fPIC -fno-common -DHAVE_CONFIG_H -D___PRIMAL - > D___LIBRARY -D___GAMBCDIR=\"/proj/will/Apps/Gambit/\" -c os_files.c > gcc -I../include -I. -Wall -W -Wno-unused -O1 -fno-math-errno - > fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit- > frame-pointer -fPIC -fno-common -DHAVE_CONFIG_H -D___PRIMAL - > D___LIBRARY -D___GAMBCDIR=\"/proj/will/Apps/Gambit/\" -c os_dyn.c > gcc -I../include -I. -Wall -W -Wno-unused -O1 -fno-math-errno - > fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit- > frame-pointer -fPIC -fno-common -DHAVE_CONFIG_H -D___PRIMAL - > D___LIBRARY -D___GAMBCDIR=\"/proj/will/Apps/Gambit/\" -c os_tty.c > gcc -I../include -I. -Wall -W -Wno-unused -O1 -fno-math-errno - > fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit- > frame-pointer -fPIC -fno-common -DHAVE_CONFIG_H -D___PRIMAL - > D___LIBRARY -D___GAMBCDIR=\"/proj/will/Apps/Gambit/\" -c os_io.c > ../gsc/gsc -:=".." -f -c -check _kernel.scm > /bin/sh: ../gsc/gsc: not found > make[1]: *** [_kernel.c] Error 1 > make[1]: Leaving directory `/proj/will/Apps/Gambit/gambc40b17/lib' > make: *** [all-recursive] Error 1

1 0

Re: [gambit-list] How to link files like *.c and *_.c generated by Gambit-C 4.0 beta 17 to a ".exe" file in Windows XP using GCC 3.4?
by Bradley Lucier 18 Avr '06

18 Avr '06

I think this was answered in the replies to http://groups.google.com/group/comp.lang.scheme/browse_thread/thread/ 51f3bade52ff76d3/8918ef34bcaad7cd#8918ef34bcaad7cd ? Brad On Apr 10, 2006, at 4:27 AM, 盛茅 wrote: > Hi,Schemes, > I'm completely a newbie here. I have after this question for weeks, > but get nothing. Thank you for helping me. > My questions are: > How to link files like *.c and *_.c generated by Gambit-C 4.0 beta > 17 to a ".exe" file in Windows XP using GCC 3.4? > How to compile Gambit-C itself and ".c" and "_.c" files generated > by it using Visual C++ 2003 Toolkit? > Thank you! > Mao.. > > 雅虎1G免费邮箱百分百防垃圾信 > 雅虎助手-搜索、杀毒、防骚扰 > _______________________________________________ > Gambit-list mailing list > Gambit-list(a)iro.umontreal.ca > http://mailman.iro.umontreal.ca/mailman/listinfo/gambit-list

1 0

needed - MacGambit-C 3.0
by Frank Gizinski 14 Avr '06

14 Avr '06

I lost my MacGambit-C 3.0 because of a hard disk failure. If there is any place I can download it or someone who can e-mail it to me as an attachment I would appreciate it. Willing to pay for the trouble taken. Frank Gizinski

2 1

How to link files like *.c and *_.c generated by Gambit-C 4.0 beta 17 to a ".exe" file in Windows XP using GCC 3.4?
by 盛茅 10 Avr '06

10 Avr '06

Hi,Schemes, I'm completely a newbie here. I have after this question for weeks, but get nothing. Thank you for helping me. My questions are: How to link files like *.c and *_.c generated by Gambit-C 4.0 beta 17 to a ".exe" file in Windows XP using GCC 3.4? How to compile Gambit-C itself and ".c" and "_.c" files generated by it using Visual C++ 2003 Toolkit? Thank you! Mao.. --------------------------------- 雅虎1G免费邮箱百分百防垃圾信雅虎助手-搜索、杀毒、防骚扰

1 0

Need MacGambit-C 3.0
by Frank Gizinski 08 Avr '06

08 Avr '06

To Whom it may concern, I had a hard disk failure. Wasn't backed up because I didn't have anything to back it up with. Recovered almost everything I had except MacGambit-C 3.0. Does anyone have a copy I can download or know where I can find one? Tried Google but couldn't find one there. Frank Gizinski

1 0

Clumsy reference to closure variable
by Bradley Lucier 08 Avr '06

08 Avr '06

I don't know if this is important in practice, but ... In lib/_num.scm you have (define (advance-state!) (##declare (not interrupts-enabled)) (let* ((x10 (##flonum.- (##flonum.* 1403580.0 (##f64vector-ref state 1)) (##flonum.* 810728.0 (##f64vector-ref state 2)))) (y10 (##flonum.- x10 (##flonum.* (##flonum.floor (##flonum./ x10 (macro-m1- inexact))) (macro-m1-inexact)))) (x20 (##flonum.- (##flonum.* 527612.0 (##f64vector-ref state 3)) (##flonum.* 1370589.0 (##f64vector-ref state 5)))) (y20 (##flonum.- x20 (##flonum.* (##flonum.floor (##flonum./ x20 (macro-m2- inexact))) (macro-m2-inexact)))) (dx (##flonum.- y10 y20)) (dy (##flonum.- dx (##flonum.* (##flonum.floor (##flonum./ dx (macro-m1- inexact))) (macro-m1-inexact))))) (##f64vector-set! state 5 (##f64vector-ref state 4)) (##f64vector-set! state 4 (##f64vector-ref state 3)) (##f64vector-set! state 3 y20) (##f64vector-set! state 2 (##f64vector-ref state 1)) (##f64vector-set! state 1 (##f64vector-ref state 0)) (##f64vector-set! state 0 y10) (##f64vector-set! state 6 dy))) where state is declared in the surrounding lexical environment. This is compiled to the C code: ___DEF_GLBL(___L199__23__23_make_2d_random_2d_source_2d_mrg32k3a) ___SET_R2(___UNBOX(___R1)) ___SET_F64(___F64V1,___F64VECTORREF(___R2,___FIX(2L))) ___SET_F64(___F64V2,___F64MUL(810728.,___F64V1)) ___SET_R3(___UNBOX(___R1)) ___SET_F64(___F64V3,___F64VECTORREF(___R3,___FIX(1L))) ___SET_F64(___F64V4,___F64MUL(1403580.,___F64V3)) ___SET_F64(___F64V5,___F64SUB(___F64V4,___F64V2)) ___SET_F64(___F64V6,___F64DIV(___F64V5,4294967087.)) ___SET_F64(___F64V7,___F64FLOOR(___F64V6)) ___SET_F64(___F64V8,___F64MUL(___F64V7,4294967087.)) ___SET_F64(___F64V9,___F64SUB(___F64V5,___F64V8)) ___SET_R3(___UNBOX(___R1)) ___SET_F64(___F64V10,___F64VECTORREF(___R3,___FIX(5L))) ___SET_F64(___F64V11,___F64MUL(1370589.,___F64V10)) ___SET_R4(___UNBOX(___R1)) ___SET_F64(___F64V12,___F64VECTORREF(___R4,___FIX(3L))) ___SET_F64(___F64V13,___F64MUL(527612.,___F64V12)) ___SET_F64(___F64V14,___F64SUB(___F64V13,___F64V11)) ___SET_F64(___F64V15,___F64DIV(___F64V14,4294944443.)) ___SET_F64(___F64V16,___F64FLOOR(___F64V15)) ___SET_F64(___F64V17,___F64MUL(___F64V16,4294944443.)) ___SET_F64(___F64V18,___F64SUB(___F64V14,___F64V17)) ___SET_F64(___F64V19,___F64SUB(___F64V9,___F64V18)) ___SET_F64(___F64V20,___F64DIV(___F64V19,4294967087.)) ___SET_F64(___F64V21,___F64FLOOR(___F64V20)) ___SET_F64(___F64V22,___F64MUL(___F64V21,4294967087.)) ___SET_F64(___F64V23,___F64SUB(___F64V19,___F64V22)) ___SET_STK(1,___UNBOX(___R1)) ___SET_F64(___F64V24,___F64VECTORREF(___STK(1),___FIX(4L))) ___SET_STK(2,___UNBOX(___R1)) ___F64VECTORSET(___STK(2),___FIX(5L),___F64V24) ___SET_STK(1,___UNBOX(___R1)) ___SET_F64(___F64V25,___F64VECTORREF(___STK(1),___FIX(3L))) ___SET_STK(2,___UNBOX(___R1)) ___F64VECTORSET(___STK(2),___FIX(4L),___F64V25) ___SET_STK(1,___UNBOX(___R1)) ___F64VECTORSET(___STK(1),___FIX(3L),___F64V18) ___SET_R3(___UNBOX(___R1)) ___SET_F64(___F64V26,___F64VECTORREF(___R3,___FIX(1L))) ___SET_STK(1,___UNBOX(___R1)) ___F64VECTORSET(___STK(1),___FIX(2L),___F64V26) ___SET_R3(___UNBOX(___R1)) ___SET_F64(___F64V27,___F64VECTORREF(___R3,___FIX(0L))) ___SET_STK(1,___UNBOX(___R1)) ___F64VECTORSET(___STK(1),___FIX(1L),___F64V27) ___SET_R3(___UNBOX(___R1)) ___F64VECTORSET(___R3,___FIX(0L),___F64V9) ___SET_R1(___UNBOX(___R1)) ___F64VECTORSET(___R1,___FIX(6L),___F64V23) ___JUMPPRM(___NOTHING,___R0) Note how state is continually unboxed into new registers and stack entries. If I change the argument list to (define (advance-state! state) <etc> and update all callers, the new code is ___DEF_GLBL(___L199__23__23_make_2d_random_2d_source_2d_mrg32k3a) ___SET_F64(___F64V1,___F64VECTORREF(___R1,___FIX(2L))) ___SET_F64(___F64V2,___F64MUL(810728.,___F64V1)) ___SET_F64(___F64V3,___F64VECTORREF(___R1,___FIX(1L))) ___SET_F64(___F64V4,___F64MUL(1403580.,___F64V3)) ___SET_F64(___F64V5,___F64SUB(___F64V4,___F64V2)) ___SET_F64(___F64V6,___F64DIV(___F64V5,4294967087.)) ___SET_F64(___F64V7,___F64FLOOR(___F64V6)) ___SET_F64(___F64V8,___F64MUL(___F64V7,4294967087.)) ___SET_F64(___F64V9,___F64SUB(___F64V5,___F64V8)) ___SET_F64(___F64V10,___F64VECTORREF(___R1,___FIX(5L))) ___SET_F64(___F64V11,___F64MUL(1370589.,___F64V10)) ___SET_F64(___F64V12,___F64VECTORREF(___R1,___FIX(3L))) ___SET_F64(___F64V13,___F64MUL(527612.,___F64V12)) ___SET_F64(___F64V14,___F64SUB(___F64V13,___F64V11)) ___SET_F64(___F64V15,___F64DIV(___F64V14,4294944443.)) ___SET_F64(___F64V16,___F64FLOOR(___F64V15)) ___SET_F64(___F64V17,___F64MUL(___F64V16,4294944443.)) ___SET_F64(___F64V18,___F64SUB(___F64V14,___F64V17)) ___SET_F64(___F64V19,___F64SUB(___F64V9,___F64V18)) ___SET_F64(___F64V20,___F64DIV(___F64V19,4294967087.)) ___SET_F64(___F64V21,___F64FLOOR(___F64V20)) ___SET_F64(___F64V22,___F64MUL(___F64V21,4294967087.)) ___SET_F64(___F64V23,___F64SUB(___F64V19,___F64V22)) ___SET_F64(___F64V24,___F64VECTORREF(___R1,___FIX(4L))) ___F64VECTORSET(___R1,___FIX(5L),___F64V24) ___SET_F64(___F64V25,___F64VECTORREF(___R1,___FIX(3L))) ___F64VECTORSET(___R1,___FIX(4L),___F64V25) ___F64VECTORSET(___R1,___FIX(3L),___F64V18) ___SET_F64(___F64V26,___F64VECTORREF(___R1,___FIX(1L))) ___F64VECTORSET(___R1,___FIX(2L),___F64V26) ___SET_F64(___F64V27,___F64VECTORREF(___R1,___FIX(0L))) ___F64VECTORSET(___R1,___FIX(1L),___F64V27) ___F64VECTORSET(___R1,___FIX(0L),___F64V9) ___F64VECTORSET(___R1,___FIX(6L),___F64V23) ___JUMPPRM(___NOTHING,___R0) Benchmarking shows that in this case it makes little difference (about 10%), perhaps because of the overhead of the glue surrounding the random-number generator. Before the change, simple fixnum loops (the number of iterations is the parameter) take: > (time (test-integers 1000000)) (time (test-integers 1000000)) 230 ms real time 230 ms cpu time (230 user, 0 system) no collections -16 bytes allocated 2 minor faults no major faults 81 > (time (test-integers 1000000)) (time (test-integers 1000000)) 231 ms real time 231 ms cpu time (231 user, 0 system) no collections -16 bytes allocated no minor faults no major faults 67 > (time (test-reals 1000000)) (time (test-reals 1000000)) 220 ms real time 219 ms cpu time (210 user, 9 system) no collections 32000016 bytes allocated 3907 minor faults no major faults .6123283969620956 > (time (test-reals 1000000)) (time (test-reals 1000000)) 221 ms real time 221 ms cpu time (209 user, 12 system) no collections 32000016 bytes allocated 3906 minor faults no major faults .7141848196160148 after: > (time (test-integers 1000000)) (time (test-integers 1000000)) 206 ms real time 205 ms cpu time (205 user, 0 system) no collections -16 bytes allocated 3 minor faults no major faults 81 > (time (test-integers 1000000)) (time (test-integers 1000000)) 203 ms real time 203 ms cpu time (203 user, 0 system) no collections -16 bytes allocated no minor faults no major faults 67 > (time (test-reals 1000000)) (time (test-reals 1000000)) 197 ms real time 197 ms cpu time (187 user, 10 system) no collections 32000016 bytes allocated 3906 minor faults no major faults .6123283969620956 > (time (test-reals 1000000)) (time (test-reals 1000000)) 203 ms real time 204 ms cpu time (189 user, 15 system) no collections 32000016 bytes allocated 3906 minor faults no major faults .7141848196160148 while a loop that just makes calls to (values 0) through the trampoline takes: > (time (test-empty 1000000)) (time (test-empty 1000000)) 35 ms real time 35 ms cpu time (35 user, 0 system) no collections -16 bytes allocated no minor faults no major faults and a loop that does absolutely nothing except increment and test the loop variable takes > (time (test-really-empty 1000000)) (time (test-really-empty 1000000)) 1 ms real time 1 ms cpu time (1 user, 0 system) no collections -16 bytes allocated no minor faults no major faults 0 It does make a significant difference in the code size: euler-42% ll `which gsc` -rwxr-xr-x 1 lucier pfaculty 7525990 Feb 2 00:57 /pkgs/Gambit-C/bin/ gsc* euler-43% ll gsc/gsc -rwxr-xr-x 1 lucier pfaculty 7464437 Apr 8 13:59 gsc/gsc* It would be nice if the compiler would just unbox the closure variable once and we wouldn't have to worry about this. Brad

1 0

Scheme Workshop 2006
by Robby Findler 05 Avr '06

05 Avr '06

Dear all, I'm writing to let you know about the upcoming Scheme and Functional Programming workshop -- specifically that the submission deadline is June 9, about 2 months from now. The workshop will be held Portland Oregon on September 17, the day before ICFP. We look forward you your submissions! Best, Robby ============================================================ The purpose of the workshop is to discuss experience with and future developments of the Scheme programming language, as well as general aspects of computer science loosely centered on the general theme of Scheme. http://scheme2006.cs.uchicago.edu/ IMPORTANT DATES Submission deadline: Friday June 9 Author notification: Friday June 30 Final versions due: Friday July 14 Workshop: Sunday September 17, the day before ICFP CALL FOR PAPERS Papers are invited concerning all aspects of the design, semantics, theory, application, implementation, and teaching of Scheme. Some example areas include (but are not limited to): * Language design Scheme's simple syntactic framework and minimal static semantics has historically made the language an attractive lab bench for the development and experimentation of novel language features and mechanisms. Topics in this area include modules systems, exceptions, control mechanisms, distributed programming, concurrency and synchronisation, macro systems, and objects. Past, present and future SRFIs are welcome. * Type systems Static analyses for dynamic type systems, type systems that bridge the gap between static and dynamic types, static systems with type dynamic extensions, weak typing. * Theory Formal semantics, calculi, correctness of analyses and transformations, lambda calculus. * Implementation Compilers, runtime systems, optimisation, virtual machines, resource management, interpreters, foreign-function and operating system interfaces, partial evaluation, program analysis and transformation, embedded systems, and generally implementations with novel or noteworthy features. * Program-development environments and tools The Lisp and Scheme family of programming languages have traditionally been the source of innovative program-development environments. Authors working on these issues are encouraged to submit papers describing their technologies. Topics include profilers, tracers, debuggers, program understanding tools, performance and conformance test suites and tools. * Education Scheme has achieved widespread use as a tool for teaching computer science. Papers on the theory and practice of teaching with Scheme are invited. * Agile Methogologies Dynamic languages seem to share a symbiotic relationship with agile software development methodologies. In particular, the dynamic type checking of Scheme clearly benefits from test-driven development, but that same dynamic checking makes the software more easily adapted to changing requirements. * Applications and experience Interesting applications which illuminate aspects of Scheme experience with Scheme in commercial or real-world contexts; use of Scheme as an extension or scripting language. * Scheme pearls Elegant, instructive examples of functional programming. A Scheme pearl submission is a special category, and should be a short paper presenting an algorithm, idea or programming device using Scheme in a way that is particularly elegant. Following the model of earlier workshops, experience papers need not necessarily report original research results; they may instead report practical experience that will be useful to others, re-usable programming idioms, or elegant new ways of approaching a problem. The key criterion for such a paper is that it makes a contribution from which other practitioners can benefit. It is not enough simply to describe a program! ORGANIZERS Program Chair Robby Findler, University of Chicago Program Committee John Clements, Cal Poly Sebastian Egner, Philips Research Robby Findler, University of Chicago Cormac Flanagan, UC Santa Cruz Erik Hilsdale, Google Eric Knauel, University of Tubingen Steering Committee William D. Clinger, Northeastern University Marc Feeley, University of Montreal Robby Findler, University of Chicago Dan Friedman, Indiana University Christian Queinnec, University Paris 6 Manuel Serrano, INRIA Olin Shivers, Georgia Tech Mitchell Wand, Northeastern University

1 0

"make clean; make" doesn't work with --enable-shared on MacOS X
by Bradley Lucier 04 Avr '06

04 Avr '06

It rebuilds the dynamic library in lib, then in gsi you get DYLD_LIBRARY_PATH=../lib:/sw/lib:/pkgs/gcc-4.1.0/lib:/usr/local/ Gambit-C/lib/:/sw/lib ../gsc/gsc -:=".." -f -c -check _gsi.scm make[1]: *** [_gsi.c] Illegal instruction The problem is, you're trying to execute the old gsc, which depends on the old libgambc.dylib, with the recently-built libgambc.dylib. Perhaps we just need a "Don't do that" message in the documentation. Brad

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Avril 2006