Gambit-list Mai 2006

gambit-list@iro.umontreal.ca

12 participants
23 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

heartbeat on v17
by brian 13 Jui '06

13 Jui '06

This is almost certainly a dupe, but I don't have a record of it: I built on mac os x 10.4.6 and got warnings about the heartbeat frequency, e.g., ./mix > test6.out 1.374983 secs elapsed cpu time heartbeat frequency = 48.72787518100223 Hz *** possible problem: expected heartbeat frequency = 100. Hz Reporting, as a just-in-case. Brian

2 1

faster process-status polling.2
by Christian 12 Jui '06

12 Jui '06

Hello I think this patch is better than my first one. Thanks Christian. BTW I'm not getting any mail from the list anymore since May 14th. I'm seeing that my mails are making it to the list archive, though. Is it a fault on my end? --- gambc40b17/lib/_io.scm~ 2006-01-08 21:38:12.000000000 +0100 +++ gambc40b17/lib/_io.scm 2006-05-26 13:32:01.000000000 +0200 @@ -5225,7 +5225,7 @@ (if (##eq? absrel-timeout (macro-absent-obj)) #f absrel-timeout))))) - (let loop () + (let loop ((sleeptime 0.001)) (let ((result (##os-device-process-status (##port-device port)))) (cond ((##not result) (let ((now (##current-time-point))) @@ -5234,8 +5234,8 @@ ; Polling is evil but fixing this would require ; substantial changes to the I/O subsystem. We'll ; tackle that in a future release. - (##thread-sleep! 0.2) - (loop)) + (##thread-sleep! sleeptime) + (loop (* 1.2 sleeptime))) (if (##eq? timeout-val (macro-absent-obj)) (##raise-unterminated-process-exception process-status

2 1

Tables and serialization
by Pouex Machinax 12 Jui '06

12 Jui '06

>(define table-1 (make-table)) >(table-set! table-1 'foo (list 1 2 3 4 5)) >(table-ref table-1 'foo #f) (1 2 3 4 5) >(define table-1-ser (object->u8vector table-1)) >(define table-2 (u8vector->object table-1-ser)) >(table-ref table-2 'foo #f) #f >(table->list table-1) ((foo 1 2 3 4 5)) >(table->list table-2) ((foo 1 2 3 4 5)) _________________________________________________________________ MSN® Calendar keeps you organized and takes the effort out of scheduling get-togethers. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.

2 1

faster process-status polling
by Christian 25 Mai '06

25 Mai '06

Hello The 0.2 second sleep in process-status (while waiting for the waidpid on child to happen) is too big for me. I suggest to make it considerably smaller. 100 polls per second don't seem very much, or is the relevant code path costly? Thanks Christian. --- gambc40b17/lib/_io.scm~ 2006-01-08 21:38:12.000000000 +0100 +++ gambc40b17/lib/_io.scm 2006-05-25 17:59:33.000000000 +0200 @@ -5234,7 +5234,7 @@ ; Polling is evil but fixing this would require ; substantial changes to the I/O subsystem. We'll ; tackle that in a future release. - (##thread-sleep! 0.2) + (##thread-sleep! 0.01) (loop)) (if (##eq? timeout-val (macro-absent-obj)) (##raise-unterminated-process-exception

1 0

Times for fft multiplication
by Bradley Lucier 24 Mai '06

24 Mai '06

Marc: Bottom line for this message: I think Gambit needs to generate basic- block--local GVM general registers. Can we have a beta with this change, so we can test it? Brad Details: All the nontrivial operations on large bignums (multiplication, division, gcd) depend on fast multiplication, which we implement using an fft algorithm. The implementation compares unfavorably with that in gmp, and I am trying to investigate why. Here are run times for some parts of the program for (* a a) where a is (expt 3 5000000). Allocate zero f64vector of 2097152 elements (we do this twice, three times for (* a b)) 36 ms cpu time (12 user, 24 system) 16777248 bytes allocated Extract 8-bit fdigits from a and insert them into f64vector (we do this twice for (* a b)) 8 ms cpu time (8 user, 0 system) -16 bytes allocated Calculate the sin and cosine weight vector: 35 ms cpu time (35 user, 0 system) 16 bytes allocated Calculate another table of sins and cosines: 15 ms cpu time (15 user, 0 system) 16 bytes allocated Bit reverse the f64vector containing the digits of a (NOTE THIS ONE) (we do this twice, three times for (* a b)): 138 ms cpu time (137 user, 1 system) -16 bytes allocated Do a complex fft (we do this twice, three times for (* a b)): 218 ms cpu time (212 user, 6 system) 13978480 bytes allocated Do some post-processing to turn a complex fft into a real fft (we do this twice, three times for (* a b)): 18 ms cpu time (18 user, 0 system) -16 bytes allocated Round and transfer the digits from the result f64vector to the result bignum, as fdigits: 98 ms cpu time (96 user, 2 system) 12160 bytes allocated Now, it all adds up, but what really strikes me here is the CPU time for bitrv2. Here is the code for the first nontrivial loop of bitrv2, the bit reversal routine, GVM, macro-expanded, and assembly: ___DEF_GLBL(___L6_bitrv2) ___SET_R4(___VECTORREF(___STK(-1),___R2)) ___SET_STK(1,___FIXASHL(___R3,___FIX(1L))) ___SET_R4(___FIXADD(___STK(1),___R4)) ___SET_STK(1,___VECTORREF(___STK(-1),___R3)) ___SET_STK(2,___FIXASHL(___R2,___FIX(1L))) ___SET_STK(1,___FIXADD(___STK(2),___STK(1))) ___SET_STK(2,___FIXADD(___R4,___FIX(0L))) ___SET_F64(___F64V1,___F64VECTORREF(___STK(0),___STK(2))) ___SET_STK(3,___FIXADD(___R4,___FIX(1L))) ___SET_F64(___F64V2,___F64VECTORREF(___STK(0),___STK(3))) ___SET_STK(4,___FIXADD(___STK(1),___FIX(0L))) ___SET_F64(___F64V3,___F64VECTORREF(___STK(0),___STK(4))) ___SET_STK(5,___FIXADD(___R4,___FIX(0L))) ___F64VECTORSET(___STK(0),___STK(5),___F64V3) ___SET_STK(4,___FIXADD(___STK(1),___FIX(1L))) ___SET_F64(___F64V4,___F64VECTORREF(___STK(0),___STK(4))) ___SET_R4(___FIXADD(___R4,___FIX(1L))) ___F64VECTORSET(___STK(0),___R4,___F64V4) ___SET_R4(___FIXADD(___STK(1),___FIX(0L))) ___F64VECTORSET(___STK(0),___R4,___F64V1) ___SET_R4(___FIXADD(___STK(1),___FIX(1L))) ___F64VECTORSET(___STK(0),___R4,___F64V2) ___SET_R3(___FIXADD(___R3,___FIX(1L))) ___IF(___FIXLT(___R3,___R2)) ___GOTO(___L6_bitrv2) ___END_IF ___L6_bitrv2: ___r4=(*(long*)(((long)(((long*)((___fp[-(-1)])-(1)))+1))+((___r2) <<(3 -2)))); ___fp[-(1)]=(((___r3)<<(((((long)(1L))<<2))>>2))); ___r4=(((long)((___fp[-(1)])+(___r4)))); ___fp[-(1)]=(*(long*)(((long)(((long*)((___fp[-(-1)])-(1)))+1))+ ((___r3)<<(3 -2)))); ___fp[-(2)]=(((___r2)<<(((((long)(1L))<<2))>>2))); ___fp[-(1)]=(((long)((___fp[-(2)])+(___fp[-(1)])))); ___fp[-(2)]=(((long)((___r4)+((((long)(0L))<<2))))); ___F64V1=*(double*)(((long)(((long*)((___fp[-(0)])-(1)))+1))+ ((___fp[-(2)])<<(3-2))); ___fp[-(3)]=(((long)((___r4)+((((long)(1L))<<2))))); ___F64V2=*(double*)(((long)(((long*)((___fp[-(0)])-(1)))+1))+ ((___fp[-(3)])<<(3-2))); ___fp[-(4)]=(((long)((___fp[-(1)])+((((long)(0L))<<2))))); ___F64V3=*(double*)(((long)(((long*)((___fp[-(0)])-(1)))+1))+ ((___fp[-(4)])<<(3-2))); ___fp[-(5)]=(((long)((___r4)+((((long)(0L))<<2))))); *(double*)(((long)(((long*)((___fp[-(0)])-(1)))+1))+((___fp[-(5)]) <<(3-2)))=___F64V3; ___fp[-(4)]=(((long)((___fp[-(1)])+((((long)(1L))<<2))))); ___F64V4=*(double*)(((long)(((long*)((___fp[-(0)])-(1)))+1))+ ((___fp[-(4)])<<(3-2))); ___r4=(((long)((___r4)+((((long)(1L))<<2))))); *(double*)(((long)(((long*)((___fp[-(0)])-(1)))+1))+((___r4)<< (3-2)))=___F64V4; ___r4=(((long)((___fp[-(1)])+((((long)(0L))<<2))))); *(double*)(((long)(((long*)((___fp[-(0)])-(1)))+1))+((___r4)<< (3-2)))=___F64V1; ___r4=(((long)((___fp[-(1)])+((((long)(1L))<<2))))); *(double*)(((long)(((long*)((___fp[-(0)])-(1)))+1))+((___r4)<< (3-2)))=___F64V2; ___r3=(((long)((___r3)+((((long)(1L))<<2))))); if (((___r3)<(___r2))) { goto ___L6_bitrv2; } L13478: ld r0,8(r7) sldi r2,r6,1 addi r6,r6,4 cmpd cr7,r30,r6 add r9,r4,r0 addi r9,r9,7 ld r8,0(r9) std r2,-8(r7) ld r9,0(r7) add r8,r8,r2 add r2,r2,r0 addi r2,r2,7 sldi r10,r8,1 addi r11,r8,4 add r10,r9,r10 ld r0,0(r2) std r8,-16(r7) add r0,r4,r0 std r0,-8(r7) lfd f13,7(r10) std r11,-24(r7) sldi r11,r11,1 add r2,r9,r11 lfd f12,7(r2) std r0,-32(r7) sldi r0,r0,1 add r9,r9,r0 lfd f0,7(r9) std r8,-40(r7) stfd f0,7(r10) ld r9,-8(r7) ld r2,0(r7) addi r9,r9,4 add r11,r11,r2 std r9,-32(r7) sldi r9,r9,1 add r2,r2,r9 lfd f0,7(r2) stfd f0,7(r11) ld r0,-8(r7) ld r2,0(r7) sldi r0,r0,1 add r2,r2,r0 stfd f13,7(r2) ld r9,-8(r7) ld r2,0(r7) addi r11,r9,4 sldi r0,r11,1 add r2,r2,r0 stfd f12,7(r2) bgt cr7,L13478 and for the second: ___DEF_GLBL(___L10_bitrv2) ___SET_R4(___VECTORREF(___STK(-2),___R2)) ___SET_STK(1,___FIXASHL(___R3,___FIX(1L))) ___SET_R4(___FIXADD(___STK(1),___R4)) ___SET_STK(1,___VECTORREF(___STK(-2),___R3)) ___SET_STK(2,___FIXASHL(___R2,___FIX(1L))) ___SET_STK(1,___FIXADD(___STK(2),___STK(1))) ___SET_STK(2,___FIXADD(___R4,___FIX(0L))) ___SET_F64(___F64V1,___F64VECTORREF(___STK(-1),___STK(2))) ___SET_STK(3,___FIXADD(___R4,___FIX(1L))) ___SET_F64(___F64V2,___F64VECTORREF(___STK(-1),___STK(3))) ___SET_STK(4,___FIXADD(___STK(1),___FIX(0L))) ___SET_F64(___F64V3,___F64VECTORREF(___STK(-1),___STK(4))) ___SET_STK(5,___FIXADD(___R4,___FIX(0L))) ___F64VECTORSET(___STK(-1),___STK(5),___F64V3) ___SET_STK(4,___FIXADD(___STK(1),___FIX(1L))) ___SET_F64(___F64V4,___F64VECTORREF(___STK(-1),___STK(4))) ___SET_STK(5,___FIXADD(___R4,___FIX(1L))) ___F64VECTORSET(___STK(-1),___STK(5),___F64V4) ___SET_STK(4,___FIXADD(___STK(1),___FIX(0L))) ___F64VECTORSET(___STK(-1),___STK(4),___F64V1) ___SET_STK(2,___FIXADD(___STK(1),___FIX(1L))) ___F64VECTORSET(___STK(-1),___STK(2),___F64V2) ___SET_R4(___FIXADD(___R4,___R1)) ___SET_STK(1,___FIXADD(___STK(1),___R1)) ___SET_STK(2,___FIXADD(___R4,___FIX(0L))) ___SET_F64(___F64V5,___F64VECTORREF(___STK(-1),___STK(2))) ___SET_STK(3,___FIXADD(___R4,___FIX(1L))) ___SET_F64(___F64V6,___F64VECTORREF(___STK(-1),___STK(3))) ___SET_STK(4,___FIXADD(___STK(1),___FIX(0L))) ___SET_F64(___F64V7,___F64VECTORREF(___STK(-1),___STK(4))) ___SET_STK(5,___FIXADD(___R4,___FIX(0L))) ___F64VECTORSET(___STK(-1),___STK(5),___F64V7) ___SET_STK(4,___FIXADD(___STK(1),___FIX(1L))) ___SET_F64(___F64V8,___F64VECTORREF(___STK(-1),___STK(4))) ___SET_R4(___FIXADD(___R4,___FIX(1L))) ___F64VECTORSET(___STK(-1),___R4,___F64V8) ___SET_R4(___FIXADD(___STK(1),___FIX(0L))) ___F64VECTORSET(___STK(-1),___R4,___F64V5) ___SET_R4(___FIXADD(___STK(1),___FIX(1L))) ___F64VECTORSET(___STK(-1),___R4,___F64V6) ___SET_R3(___FIXADD(___R3,___FIX(1L))) ___IF(___FIXLT(___R3,___R2)) ___GOTO(___L10_bitrv2) ___END_IF ___L10_bitrv2: ___r4=(*(long*)(((long)(((long*)((___fp[-(-2)])-(1)))+1))+((___r2) <<(3 -2)))); ___fp[-(1)]=(((___r3)<<(((((long)(1L))<<2))>>2))); ___r4=(((long)((___fp[-(1)])+(___r4)))); ___fp[-(1)]=(*(long*)(((long)(((long*)((___fp[-(-2)])-(1)))+1))+ ((___r3)<<(3 -2)))); ___fp[-(2)]=(((___r2)<<(((((long)(1L))<<2))>>2))); ___fp[-(1)]=(((long)((___fp[-(2)])+(___fp[-(1)])))); ___fp[-(2)]=(((long)((___r4)+((((long)(0L))<<2))))); ___F64V1=*(double*)(((long)(((long*)((___fp[-(-1)])-(1)))+1))+ ((___fp[-(2)])<<(3-2))); ___fp[-(3)]=(((long)((___r4)+((((long)(1L))<<2))))); ___F64V2=*(double*)(((long)(((long*)((___fp[-(-1)])-(1)))+1))+ ((___fp[-(3)])<<(3-2))); ___fp[-(4)]=(((long)((___fp[-(1)])+((((long)(0L))<<2))))); ___F64V3=*(double*)(((long)(((long*)((___fp[-(-1)])-(1)))+1))+ ((___fp[-(4)])<<(3-2))); ___fp[-(5)]=(((long)((___r4)+((((long)(0L))<<2))))); *(double*)(((long)(((long*)((___fp[-(-1)])-(1)))+1))+((___fp[- (5)])<<(3-2)))=___F64V3; ___fp[-(4)]=(((long)((___fp[-(1)])+((((long)(1L))<<2))))); ___F64V4=*(double*)(((long)(((long*)((___fp[-(-1)])-(1)))+1))+ ((___fp[-(4)])<<(3-2))); ___fp[-(5)]=(((long)((___r4)+((((long)(1L))<<2))))); *(double*)(((long)(((long*)((___fp[-(-1)])-(1)))+1))+((___fp[- (5)])<<(3-2)))=___F64V4; ___fp[-(4)]=(((long)((___fp[-(1)])+((((long)(0L))<<2))))); *(double*)(((long)(((long*)((___fp[-(-1)])-(1)))+1))+((___fp[- (4)])<<(3-2)))=___F64V1; ___fp[-(2)]=(((long)((___fp[-(1)])+((((long)(1L))<<2))))); *(double*)(((long)(((long*)((___fp[-(-1)])-(1)))+1))+((___fp[- (2)])<<(3-2)))=___F64V2; ___r4=(((long)((___r4)+(___r1)))); ___fp[-(1)]=(((long)((___fp[-(1)])+(___r1)))); ___fp[-(2)]=(((long)((___r4)+((((long)(0L))<<2))))); ___F64V5=*(double*)(((long)(((long*)((___fp[-(-1)])-(1)))+1))+ ((___fp[-(2)])<<(3-2))); ___fp[-(3)]=(((long)((___r4)+((((long)(1L))<<2))))); ___F64V6=*(double*)(((long)(((long*)((___fp[-(-1)])-(1)))+1))+ ((___fp[-(3)])<<(3-2))); ___fp[-(4)]=(((long)((___fp[-(1)])+((((long)(0L))<<2))))); ___F64V7=*(double*)(((long)(((long*)((___fp[-(-1)])-(1)))+1))+ ((___fp[-(4)])<<(3-2))); ___fp[-(5)]=(((long)((___r4)+((((long)(0L))<<2))))); *(double*)(((long)(((long*)((___fp[-(-1)])-(1)))+1))+((___fp[- (5)])<<(3-2)))=___F64V7; ___fp[-(4)]=(((long)((___fp[-(1)])+((((long)(1L))<<2))))); ___F64V8=*(double*)(((long)(((long*)((___fp[-(-1)])-(1)))+1))+ ((___fp[-(4)])<<(3-2))); ___r4=(((long)((___r4)+((((long)(1L))<<2))))); *(double*)(((long)(((long*)((___fp[-(-1)])-(1)))+1))+((___r4)<< (3-2)))=___F64V8; ___r4=(((long)((___fp[-(1)])+((((long)(0L))<<2))))); *(double*)(((long)(((long*)((___fp[-(-1)])-(1)))+1))+((___r4)<< (3-2)))=___F64V5; ___r4=(((long)((___fp[-(1)])+((((long)(1L))<<2))))); *(double*)(((long)(((long*)((___fp[-(-1)])-(1)))+1))+((___r4)<< (3-2)))=___F64V6; ___r3=(((long)((___r3)+((((long)(1L))<<2))))); if (((___r3)<(___r2))) { goto ___L10_bitrv2; } L13483: ld r2,0(r24) sldi r9,r12,1 addi r12,r12,4 cmpd cr7,r30,r12 add r2,r2,r28 addi r2,r2,7 ld r8,0(r2) std r9,0(r5) add r8,r8,r9 sldi r11,r8,1 addi r7,r8,4 sldi r10,r7,1 ld r0,0(r24) add r9,r9,r0 addi r9,r9,7 ld r0,0(r9) std r0,0(r5) std r28,0(r3) nop nop ld r0,0(r5) add r0,r28,r0 std r0,0(r5) std r8,0(r3) ld r2,0(r6) add r2,r2,r11 lfd f13,7(r2) std r7,0(r25) ld r2,0(r6) ld r0,0(r5) add r2,r2,r10 lfd f12,7(r2) std r0,0(r4) sldi r0,r0,1 ld r2,0(r6) add r2,r2,r0 lfd f0,7(r2) std r8,0(r29) add r8,r27,r8 ld r0,0(r6) add r11,r11,r0 stfd f0,7(r11) addi r11,r8,4 ld r9,0(r5) addi r9,r9,4 std r9,0(r4) sldi r9,r9,1 ld r2,0(r6) add r2,r2,r9 lfd f0,7(r2) std r7,0(r29) ld r0,0(r6) add r10,r10,r0 stfd f0,7(r10) sldi r10,r8,1 ld r0,0(r5) std r0,0(r4) sldi r0,r0,1 ld r2,0(r6) add r2,r2,r0 stfd f13,7(r2) ld r9,0(r5) addi r9,r9,4 std r9,0(r3) ld r2,0(r6) sldi r9,r9,1 add r2,r2,r9 stfd f12,7(r2) ld r0,0(r5) add r0,r27,r0 std r0,0(r5) std r8,0(r3) ld r2,0(r6) add r2,r2,r10 lfd f13,7(r2) std r11,0(r25) sldi r11,r11,1 ld r2,0(r6) ld r0,0(r5) add r2,r2,r11 lfd f12,7(r2) std r0,0(r4) sldi r0,r0,1 ld r2,0(r6) add r2,r2,r0 lfd f0,7(r2) std r8,0(r29) ld r0,0(r6) add r10,r10,r0 stfd f0,7(r10) ld r9,0(r5) addi r9,r9,4 std r9,0(r4) sldi r9,r9,1 ld r2,0(r6) add r11,r11,r2 add r2,r2,r9 lfd f0,7(r2) stfd f0,7(r11) ld r0,0(r5) ld r2,0(r6) sldi r0,r0,1 add r2,r2,r0 stfd f13,7(r2) ld r9,0(r5) ld r2,0(r6) addi r11,r9,4 sldi r0,r11,1 add r2,r2,r0 stfd f12,7(r2) bgt cr7,L13483 Now, bitrv2 really exercises the memory system (which is pretty good on my 2GHz G5), and I'm not saying that this is the best code one can write, but without basic-block--local GVM registers the code sucks (and gcc can't assume that the writes to the f64vector can't kill the reads from the stack because we have to compile with -fno-strict- aliasing).

1 0

Final CFP: Scheme & Functional Programming Workshop 2006
by Robby Findler 23 Mai '06

23 Mai '06

Dear all, Just one last reminder that the Scheme and Functional programming workshop's deadline is fast approaching. Only a little more than two weeks to go. Do submit! 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

Annoying little problem
by Bradley Lucier 19 Mai '06

19 Mai '06

Marc: I hope you fixed this in the next beta. euler-24% gsc Gambit Version 4.0 beta 17 > (load "convex2.scm") *** INTERRUPTED IN #<procedure #2>, "../generic-arrays.scm"@1373.65 1> ,b 0 #<procedure #2> "../generic-arrays.scm"@1373:65 (indexer i j) 1 #<procedure #3> "../generic-arrays.scm"@418:5 (f i j) 2 ##Array->Fixed-array "../generic-arrays.scm"@1544:2 (interval- for-each (case (##Inte... 3 #<procedure #4> "../generic-arrays.scm"@538:20 (operator result (f i)) 4 projection "convex2.scm"@29:9 (Array-reduce (lambda (result A_l*p^l) ... 5 p-step "convex2.scm"@46:21 (projection p theta g Lambda A) 6 #<procedure #5> "convex2.scm"@75:8 (p-step p g Lambda theta tau A A^*) 7 ##time 8 ##call-with-values 9 with-output-to-file 10 (interaction) "convex2.scm"@137:1 (with-output-to- file "8-d-results-3" (l... 11 ##load 12 ##load 13 (interaction) (console)@1:1 (load "convex2.scm") 1> > (compile-file "convex2.scm") *** ERROR IN c#read-source -- (Argument 1) VECTOR expected (vector-length '#<readtable #6>)

1 0

Subscriber trouble?
by Logan, Patrick D 18 Mai '06

18 Mai '06

I have tried to subscribe twice recently to this list. Could Marc or someone email me at Patrick.d.logan(a)intel.com if there is a known problem or if something unexpected may be afoot. Thanks, Patrick

1 0

Some tweaks to _num.scm
by Bradley Lucier 18 Mai '06

18 Mai '06

Marc: Here's a _num.scm with some small tweaks to the fft multiplication code. Memory allocation is cut by roughly 40% when squaring large integers; memory allocation is also cut when the length of one integer is > 2^M bits, but the some of the lengths of the two integers is <= 2^{2M} bits. And I've defined a new macro for the constant inexact-pi/4 to remove a small dependence on the accuracy of the atan routine on fft multiplication. (It still depends on the accuracy of sin and cos in the interval [0,pi/4), which, on all modern systems, is excellent.) So, we have Old: > (time (* 0 (* (expt 3 1000000) (expt 3 100001)))) (time (* 0 (* (expt 3 1000000) (expt 3 100001)))) 427 ms real time 424 ms cpu time (340 user, 84 system) 22 collections accounting for 45 ms real time (14 user, 30 system) 43347960 bytes allocated no minor faults no major faults New: > (time (* 0 (* (expt 3 1000000) (expt 3 100001)))) (time (* 0 (* (expt 3 1000000) (expt 3 100001)))) 422 ms real time 388 ms cpu time (334 user, 54 system) 24 collections accounting for 38 ms real time (23 user, 16 system) 38710968 bytes allocated no minor faults no major faults 0 Old: > (time (* 0 (expt 3 1000000))) (time (* 0 (expt 3 1000000))) 200 ms real time 194 ms cpu time (162 user, 32 system) 13 collections accounting for 17 ms real time (9 user, 8 system) 17846920 bytes allocated no minor faults no major faults 0 New: > (time (* 0 (expt 3 1000000))) (time (* 0 (expt 3 1000000))) 172 ms real time 167 ms cpu time (150 user, 17 system) 10 collections accounting for 12 ms real time (9 user, 3 system) 13683504 bytes allocated no minor faults no major faults 0 Brad

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Mai 2006