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

Mailing list problem
by Marc Feeley 13 Sep '06

13 Sep '06

Hello. The Gambit mailing list server had some problems which prevented new subscriptions to the list. That problem should now be solved. Marc

1 0

A new socket interface for Gambit
by Jeff Read 12 Sep '06

12 Sep '06

Greetings, In light of Taylor's and Christian's concerns over socket support for Gambit -- concerns which I share -- I am currently working on Gamsock, a library that provides a convenient wrapper over the BSD socket interface for Gambit. The code is still not-quite-ready-for-prime-time, but currently I can bind, connect, and send to and receive from TCP sockets (and ostensibly Unix-domain and UDP sockets as well, but I haven't tested these fully). I anticipate doing a preliminary release soon (fixnum days, but probably less than 2^4 days). I hope that Gamsock fills a void that some of you have programming with Gambit. By the way, I seem unable to subscribe to gambit-list with my gmail account; it says "you need a valid email address". Is gmail not valid? Is it considered too spammy by Mailman? --Jeff

1 0

Re: [gambit-list] file read performance
by Marc Feeley 09 Sep '06

09 Sep '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4-Sep-06, at 4:35 AM, phil(a)phildawes.net wrote: > Hi Gambit List, > > What's the quickest way of reading a file from disk into memory? > > I tried 'read-all' with 'read-line', but unfortunately even with > compiling I get an order of magnitude worse performance than doing > the same in python. > I'm using the following code, compiled using gsc and gcc -O3, and I > get 500ms to read the 'bib' file supplied in the bench.tgz package. > > ---------------------- > > (define (f) > (call-with-input-file "bib" > (lambda (p) (read-all p read-line)))) > > (time (f)) > > ------------------------ > > In python, the same takes about 50ms > e.g. > for line in file("bib").readlines(): > # do something > > Is there anything I can do to speed this up? > (I've tried setting > #define ___MAX_CHR 0xff > ) > > Many thanks, > > Phil It depends what you mean by "reading into memory". You might want to slirp the content of the file into a single u8vector (as a sequence of bytes), or you might want to get the list of strings corresponding to the lines in the file (which requires a byte to character conversion). On my MacBook Pro, the former takes about 60 milliseconds for the "bib" file and the latter about 200 milliseconds (I also get about 50 ms for the Python code). I tried to improve the time with a specialized buffering but that only improved the timing by 20%. Using 1 byte characters instead of 4 byte characters helps, but it is still roughly 2.5 times slower than slirping the bytes into a u8vector. If you iterate using read-line (instead of using read- all) you save some more because the list of lines does not have to be kept in memory all the time. See the code below. I think the largest cost here is the allocation of the strings and conversion from bytes to characters. I'm not sure if the conversion to characters is a cost that Python is paying (can the text be encoded in something other than ISO-8859-1? that's something that you can easily change with Gambit's I/O system). Marc (declare (standard-bindings) (block) (fixnum) (not safe)) (define (read-all-file-v1 filename) (let* ((size (file-size filename)) (buffer (make-u8vector size))) (call-with-input-file filename (lambda (in) (let ((n (read-subu8vector buffer 0 size in))) buffer))))) (define (read-all-file-v2 filename) (call-with-input-file filename (lambda (in) (read-all in read-line)))) (define (read-all-file-v3 filename) (call-with-input-file filename (lambda (in) (let* ((size 4096) (buffer (make-string (+ size 1)))) (let loop1 ((rev-lines '()) (incomplete-line #f)) (let ((n (read-substring buffer 0 size in))) (string-set! buffer n #\newline) (if (= n 0) (reverse (if incomplete-line (cons incomplete-line rev-lines) rev-lines)) (let loop2 ((i 0) (rev-lines rev-lines) (incomplete-line incomplete-line)) (let loop3 ((j i)) (if (char=? (string-ref buffer j) #\newline) (if (= j n) (loop1 rev-lines (cond ((= i j) incomplete-line) (incomplete-line (string-append incomplete-line (substring buffer i j))) (else (substring buffer i j)))) (loop2 (+ j 1) (cons (if incomplete-line (string-append incomplete-line (substring buffer i j)) (substring buffer i j)) rev-lines) #f)) (loop3 (+ j 1)))))))))))) (define (read-all-file-v4 filename) (call-with-input-file filename (lambda (in) (let loop () (let ((line (read-line in))) (if (string? line) (begin ; do something with line (loop)))))))) (define filename "bench/src/bib") ; Execution time with character size = 4 bytes 1 byte (time (read-all-file-v1 filename)) ; 57 ms 57 ms (time (read-all-file-v2 filename)) ; 229 ms 170 ms (time (read-all-file-v3 filename)) ; 181 ms 146 ms (time (read-all-file-v4 filename)) ; 162 ms 130 ms -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFAafz//V9Zc2T/v4RAr97AJ43/61utp7eFKE7M2f3AuaUBNs/aACgvw+j 7m+CVSFm+kqVjkRtIRgm5Lg= =+0j4 -----END PGP SIGNATURE-----

2 1

Register usage
by Bradley Lucier 08 Sep '06

08 Sep '06

Marc: The code for the main loop of this function is scheduled in 35 cycles when target gvm registers is 20 and target arg registers is 8; it's scheduled in 113 cycles when gvm registers is 5 and arg registers is 3 (the default). This is with the compile command gcc -mcpu=970 -m64 -no-cpp-precomp -Wall -W -Wno-unused -O1 -fno- math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing - fwrapv -fomit-frame-pointer -fPIC -fno-common -bundle -flat_namespace -undefined suppress -I${GSC_CC_O_ARG1}include -D___DYNAMIC - D___SINGLE_HOST -o ${GSC_CC_O_ARG2} $* ${GSC_CC_O_ARG3} -save-temps - dR -freorder-blocks in gsc-cc-o on my PowerMac G5. This is a problem. You know that lambda-lifting and register allocation don't work well together in the compiler. This is a rather extreme example. It's hard to look for faster algorithms when the simple ones are compiled to something that takes three times as long as it should take. Brad (define (direct-fft-recursive a W-table) ;; This is a direcct complex fft, using a decimation-in-time algorithm ;; with inputs in natural order and outputs in bit-reversed order. ;; The table of "twiddle" factors is in bit-reversed order. ;; this is from page 66 of Chu and George (let ((W (##f64vector 0. 0.))) (define (make-W W-table W K) ;; look at Colin Percival's FFT notes for how to calculate this. ;; this works, but I'll be damned if I know why. (cond ((##fixnum.even? K) (let* ((K-index K) (K-index+1 (##fixnum.+ K-index 1)) (basic-real (##f64vector-ref W-table K-index)) (basic-imag (##f64vector-ref W-table K-index+1)) (result-real basic-real) (result-imag basic-imag)) (##f64vector-set! W 0 result-real) (##f64vector-set! W 1 result-imag))) (else (let* ((K-index (##fixnum.bitwise-and K -2)) (K-index+1 (##fixnum.+ K-index 1)) (basic-real (##f64vector-ref W-table K-index)) (basic-imag (##f64vector-ref W-table K-index+1)) (result-real (##flonum.- basic-imag)) (result-imag basic-real)) (##f64vector-set! W 0 result-real) (##f64vector-set! W 1 result-imag))))) (define (main-loop M N K SizeOfGroup) (##declare (not interrupts-enabled)) (let inner-loop ((K K) (JFirst M)) (if (##fixnum.< JFirst N) (let* ((JLast (##fixnum.+ JFirst SizeOfGroup))) (make-W W-table W K) (let J-loop ((J JFirst)) (if (##fixnum.< J JLast) (let ((J+1 (##fixnum.+ J 1 )) (J+SizeOfGroup (##fixnum.+ J SizeOfGroup)) (J+SizeOfGroup+1 (##fixnum.+ J 1 SizeOfGroup))) (let ((W-real (##f64vector-ref W 0)) (W-imag (##f64vector-ref W 1)) (a_J-real (##f64vector-ref a J )) (a_J-imag (##f64vector-ref a J+1)) (a_J+SizeOfGroup-real (##f64vector-ref a J+SizeOfGroup )) (a_J+SizeOfGroup-imag (##f64vector-ref a J+SizeOfGroup+1))) (let ((Temp-real (##flonum.- (##flonum.* W-real a_J+SizeOfGroup-real) (##flonum.* W-imag a_J+SizeOfGroup-imag))) (Temp-imag (##flonum.+ (##flonum.* W-real a_J+SizeOfGroup-imag) (##flonum.* W-imag a_J+SizeOfGroup-real)))) (let ((Result-J-real (##flonum.+ a_J-real Temp-real)) (Result-J-imag (##flonum.+ a_J-imag Temp-imag)) (Result-J+SizeOfGroup-real (##flonum.- a_J-real Temp-real)) (Result-J+SizeOfGroup-imag (##flonum.- a_J-imag Temp-imag))) (##f64vector-set! a J Result-J-real) (##f64vector-set! a J+1 Result-J-imag) (##f64vector-set! a J+SizeOfGroup Result-J+SizeOfGroup-real) (##f64vector-set! a J+SizeOfGroup+1 Result-J+SizeOfGroup-imag) (J-loop (##fixnum.+ J 2)))))) (inner-loop (##fixnum.+ K 1) (##fixnum.+ JLast SizeOfGroup)))))))) (define (recursive-bit M N K SizeOfGroup) (if (##fixnum.<= 2 SizeOfGroup) (begin (main-loop M N K SizeOfGroup) (if (##fixnum.< 2048 (##fixnum.- N M)) (begin (recursive-bit M (##fixnum.+ M SizeOfGroup) (##fixnum.* K 2) (##fixnum.quotient SizeOfGroup 2)) (recursive-bit (##fixnum.+ M SizeOfGroup) N (##fixnum.+ (##fixnum.* K 2) 1) (##fixnum.quotient SizeOfGroup 2))) (recursive-bit M N (##fixnum.* K 2) (##fixnum.quotient SizeOfGroup 2)))))) (recursive-bit 0 (##f64vector-length a) 0 (##fixnum.quotient (##f64vector-length a) 2))))

1 0

Re: [gambit-list] "Number of arguments exceeds implementation
by Bill Richter 07 Sep '06

07 Sep '06

>(define (filter-map/tail fn tail lis . morelis) [...] ) > >Christian, your code isn't tail-recursive, right? No it's not - it can't be if the order of the output should be the same as the input (and mutation isn't used). Thanks, Christian. That's a very helpful way to put it: functions like map can't be tail-recursive if they preserve the order unless we use mutation. (Unless you throw in some `reverse's) I had noted that mutation was used in various tail-recursive map-like functions, but I had only dimly noted the rule. I have my Sudoku code working now. It takes too long, but 1) quite likely that's because of beginner tail-recursion problems 2) The real problem was some "infinite loops" that I fixed.

2 2

file read performance
by Phil Dawes 04 Sep '06

04 Sep '06

Hi Gambit List, What's the quickest way of reading a file from disk into memory? I tried 'read-all' with 'read-line', but unfortunately even with compiling I get an order of magnitude worse performance than doing the same in python. I'm using the following code, compiled using gsc and gcc -O3, and I get 500ms to read the 'bib' file supplied in the bench.tgz package. ---------------------- (define (f) (call-with-input-file "bib" (lambda (p) (read-all p read-line)))) (time (f)) ------------------------ In python, the same takes about 50ms e.g. for line in file("bib").readlines(): # do something Is there anything I can do to speed this up? (I've tried setting #define ___MAX_CHR 0xff ) Many thanks, Phil

1 0

Gambit-C vs. Bigloo vs. MzScheme
by Marc Feeley 28 Aoû '06

28 Aoû '06

After I saw Eli Barzilay's post to comp.lang.scheme about the performance of MzScheme compared to other Scheme systems (http:// groups.google.com/group/comp.lang.scheme/msg/473f91e7065b6f73? dmode=source) I was tempted to do some benchmarking of my own using the Gambit Scheme benchmark suite which goes beyond the classical Gabriel benchmarks (it has close to 60 Scheme benchmarks). Most benchmarks are straightforward R4RS code and so should work on just about any Scheme system. I have updated the benchmarking infrastructure to accomodate other Scheme systems, and MzScheme and Bigloo in particular. I also wrote a script to run all benchmarks and automatically generate an HTML table of the results. The table can be viewed here: http://www.iro.umontreal.ca/~gambit/bench.html And the benchmark suite is available here: http://www.iro.umontreal.ca/~gambit/bench.tar.gz As you can see from the table, Gambit-C is faster than Bigloo and MzScheme on roughly 3 out of 4 benchmarks. I have used the same assumptions as Eli, which approximate the semantics of R6RS (see the last section of the result page for details). It would be really interesting to extend this experiment to other Scheme systems. It should not be too difficult to modify the benchmarking scripts to test other systems. The hardest parts are installing the Scheme system, figuring out which compiler options are equivalent to the ones used by the other systems (i.e. approximate R6RS semantics), and work out unexpected problems. The following systems are particularly interesting to compare to: - Chicken - Scheme 48 - Larceny - Chez Scheme Are there any volunteers? Marc

4 6

Re: [gambit-list] Fwd: Gambit-C vs. Bigloo vs. MzScheme
by Manuel Serrano 27 Aoû '06

27 Aoû '06

On Sat, 26 Aug 2006 21:31:16 -0400 Marc Feeley <feeley(a)iro.umontreal.ca> wrote: > Désolé j'ai oublié de te mettre en CC. > > Marc > > > Begin forwarded message: > > > From: Marc Feeley <feeley(a)iro.umontreal.ca> > > Date: August 26, 2006 9:28:15 PM EDT (CA) > > To: Gambit List <Gambit-list(a)iro.umontreal.ca> > > Cc: Eli Barzilay <eli(a)barzilay.org>, Matthew Flatt > > <mflatt(a)cs.utah.edu> > > Subject: Gambit-C vs. Bigloo vs. MzScheme > > > > After I saw Eli Barzilay's post to comp.lang.scheme about the > > performance of MzScheme compared to other Scheme systems (http:// > > groups.google.com/group/comp.lang.scheme/msg/473f91e7065b6f73? > > dmode=source) I was tempted to do some benchmarking of my own > > using the Gambit Scheme benchmark suite which goes beyond the > > classical Gabriel benchmarks (it has close to 60 Scheme > > benchmarks). Most benchmarks are straightforward R4RS code and so > > should work on just about any Scheme system. > > > > I have updated the benchmarking infrastructure to accomodate other > > Scheme systems, and MzScheme and Bigloo in particular. I also > > wrote a script to run all benchmarks and automatically generate an > > HTML table of the results. The table can be viewed here: > > > > http://www.iro.umontreal.ca/~gambit/bench.html > > > > And the benchmark suite is available here: > > > > http://www.iro.umontreal.ca/~gambit/bench.tar.gz > > > > As you can see from the table, Gambit-C is faster than Bigloo and > > MzScheme on roughly 3 out of 4 benchmarks. I have used the same > > assumptions as Eli, which approximate the semantics of R6RS (see > > the last section of the result page for details). > > > > It would be really interesting to extend this experiment to other > > Scheme systems. It should not be too difficult to modify the > > benchmarking scripts to test other systems. The hardest parts are > > installing the Scheme system, figuring out which compiler options > > are equivalent to the ones used by the other systems (i.e. > > approximate R6RS semantics), and work out unexpected problems. > > > > The following systems are particularly interesting to compare to: > > > > - Chicken > > - Scheme 48 > > - Larceny > > - Chez Scheme > > > > Are there any volunteers? > > > > Marc > Hello Marc, Ah, benchmarking... Definitely we can't escape benchmarks :-). I had more or less sweared not to benchmark any more because this is an activity that can consume all your time and for which the result is not necessarily very useful. However, because I didn't want to spend a bad Sunday :-) I have downloaded your benchmarks and make some measurements with Bigloo. Here is what I got: -----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|----- General command line: bigloo -O6 OFP=-copt -fomit-frame-pointer fixnum= /+/+fx/, /-/-fx/, ... unsafe=bigloo -O6 -unsafe FLOAT= re-implementing FLOAT+, FLOAT-, ... ====================================================================== tak1: Marc's time: real: 11.22s sys: 0.02s user: 11.13s fixnum: real: 3.61s sys: 0.01s user: 3.57s fixnum, omit-frame-pointer: real: 2.80s sys: 0.01s user: 2.78s ====================================================================== fft: Marc's time: real: 11.71s sys: 0.03s user: 11.32s FLOAT fixed: real: 4.39s sys: 0.02s user: 4.10s FLOAT fixed, unsafe real: 3.44s sys: 0.01s user: 3.33s FLOAT fixed, unsafe, $OFP real: 3.02s sys: 0.01s user: 2.92s ====================================================================== pnpoly: Marc's time: real: 16.39s sys: 0.02s user: 15.79s FLOAT: real: 15.81s sys: 0.02s user: 14.50s FLOAT, unsafe: real: 1.86s sys: 0.01s user: 1.82s FLOAT, unsafe, $OFP: real: 1.49s sys: 0.00s user: 1.47s ====================================================================== sum: Marc's time: real: 5.44s sys: 0.01s user: 5.36s FLOAT, unsafe, $OFP: real: 5.29s sys: 0.01s user: 5.22s FIXNUM, unsafe, $OFP: real: 0.29s sys: 0.00s user: 0.27s ====================================================================== sumfp: Marc's time: real: 9.76s sys: 0.01s user: 9.57s FLOAT: real: 0.55s sys: 0.01s user: 0.52s FLOAT, unsafe, $OFP: real: 0.54s sys: 0.00s user: 0.52s -----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|----- As you can notice, changing the compilation options and improving your prefix-bigloo.scm file has a huge impact. As you can notice some benchmarks now go 18 times faster! Here is a description of the modiication I have applied: 1- I have re-implemented your macros FLOATxxx that were badling implemented for Bigloo. They used to expanse into call to the generic functions. They now expanse to the floating point operator. The improvement for benchmark using floating applications is in between 2 and 5 times faster. 2- I have used the proper benchmarking compilation options. a- The produced C code must be compiled with -fomit-frame-pointer (when using GCC). b- The option -unsafe has to be used. 3- For fixnum benchmarks, I have replaced the call to the generic functions with calls to fixnum functions. Please, find enclosed the new version of prefix-bigloo.scm. I would appreciate if you could re-execute the Bigloo benchmarks with the new prefix and update your web pages with the new Bigloo results. Thanks in advance. -- Manuel -----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|----- (module prefix (main main-entry) (extern (include "sys/times.h")) (extern (include "time.h")) (option (set! *unsafe-rgc* #t)) (option (set! *unsafe-library* #t)) (option (set! *unsafe-arity* #t)) (option (set! *unsafe-type* #t)) (option (set! *unsafe-struct* #t)) (option (set! *unsafe-range* #t)) (option (set! *unsafe-version* #t)) (option (set! *cc-options* (string-append "-fomit-frame-pointer " *cc-options*)))) (define (clock-to-msecs x) (quotient (* x 1000) (pragma::int "CLOCKS_PER_SEC"))) (define (process-times) (let () (pragma "struct tms buf") (let ((real::long (pragma::long "times(&buf)"))) (cons real (+ (pragma::long "buf.tms_utime") (pragma::long "buf.tms_stime")))))) (define (time* thunk) (let ((start (process-times))) (let ((result (thunk))) (let ((end (process-times))) (let ((cpu (clock-to-msecs (- (cdr end) (cdr start)))) (real (clock-to-msecs (- (car end) (car start))))) (display "cpu time: ") (display cpu) (display " real time: ") (display real) (newline) result))))) (define (run-benchmark name count ok? run-maker . args) (let* ((run (apply run-maker args)) (result (time* (lambda () (run-bench name count ok? run))))) (if (not (ok? result)) (begin (display "*** wrong result ***") (newline) (display "*** got: ") (write result) (newline))))) (define (run-bench name count ok? run) (let loop ((i 0) (result (list 'undefined))) (if (< i count) (loop (+ i 1) (run)) result))) (define (fatal-error . args) (for-each display args) (newline) (exit 1)) (define (main-entry args) (main)) ;------------------------------------------------------------------------------ ; Macros... (define-macro (def-macro form . body) `(define-macro ,form (let () ,@body))) ; Flonum arithmetic. (begin (def-macro (FLOATvector-const . lst) `',(list->vector lst)) (def-macro (FLOATvector? x) `(vector? ,x)) (def-macro (FLOATvector . lst) `(vector ,@lst)) (def-macro (FLOATmake-vector n . init) `(make-vector ,n ,@init)) (def-macro (FLOATvector-ref v i) `(vector-ref ,v ,i)) (def-macro (FLOATvector-set! v i x) `(vector-set! ,v ,i ,x)) (def-macro (FLOATvector-length v) `(vector-length ,v)) (def-macro (nuc-const . lst) `',(list->vector lst)) ) (begin (def-macro (+ . lst) (if (null? (cdr lst)) (car lst) `(+fx ,(car lst) (+ ,@(cdr lst))))) (def-macro (- . lst) (if (null? (cdr lst)) (car lst) `(-fx ,(car lst) (- ,@(cdr lst))))) (def-macro (* . lst) (if (null? (cdr lst)) (car lst) `(*fx ,(car lst) (* ,@(cdr lst))))) (def-macro (/ . lst) (if (null? (cdr lst)) (car lst) `(/fx ,(car lst) (/ ,@(cdr lst))))) (def-macro (FLOAT+ . lst) (if (null? (cdr lst)) (car lst) `(+fl ,(car lst) (FLOAT+ ,@(cdr lst))))) (def-macro (FLOAT- . lst) (if (null? (cdr lst)) (car lst) `(-fl ,(car lst) (FLOAT- ,@(cdr lst))))) (def-macro (FLOAT* . lst) (if (null? (cdr lst)) (car lst) `(*fl ,(car lst) (FLOAT* ,@(cdr lst))))) (def-macro (FLOAT/ . lst) (if (null? (cdr lst)) (car lst) `(/fl ,(car lst) (FLOAT/ ,@(cdr lst))))) (def-macro (FLOAT= a b) `(=fl ,a ,b)) (def-macro (FLOAT< a b) `(<fl ,a ,b)) (def-macro (FLOAT<= a b) `(<= ,a ,b)) (def-macro (FLOAT> a b) `(> ,a ,b)) (def-macro (FLOAT>= a b) `(>= ,a ,b)) (def-macro (FLOATnegative? a) `(negativefl? ,a)) (def-macro (FLOATpositive? a) `(positivefl? ,a)) (def-macro (FLOATzero? a) `(zerofl? ,a)) (def-macro (FLOATabs a) `(abs ,a)) (def-macro (FLOATsin a) `(sin ,a)) (def-macro (FLOATcos a) `(cos ,a)) (def-macro (FLOATatan a) `(atan ,a)) (def-macro (FLOATsqrt a) `(sqrt ,a)) (def-macro (FLOATmin a) `(min ,a)) (def-macro (FLOATmax a) `(max ,a)) (def-macro (FLOATround a) `(round ,a)) (def-macro (FLOATinexact->exact a) `(inexact->exact ,a)) ) ; Generic arithmetic. (begin (def-macro (GENERIC+ . lst) `(+ ,@lst)) (def-macro (GENERIC- . lst) `(- ,@lst)) (def-macro (GENERIC* . lst) `(* ,@lst)) (def-macro (GENERIC/ . lst) `(/ ,@lst)) (def-macro (GENERICquotient . lst) `(quotient ,@lst)) (def-macro (GENERICremainder . lst) `(remainder ,@lst)) (def-macro (GENERICmodulo . lst) `(modulo ,@lst)) (def-macro (GENERIC= . lst) `(= ,@lst)) (def-macro (GENERIC< . lst) `(< ,@lst)) (def-macro (GENERIC<= . lst) `(<= ,@lst)) (def-macro (GENERIC> . lst) `(> ,@lst)) (def-macro (GENERIC>= . lst) `(>= ,@lst)) (def-macro (GENERICexpt . lst) `(expt ,@lst)) ) (begin (def-macro (bitwise-or x y) `(bit-or ,x ,y)) (def-macro (bitwise-and x y) `(bit-and ,x ,y)) (def-macro (bitwise-not x) `(bit-not ,x)) ) -----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|----- ps: benchmarks using vector of float could be improved by using Bigloo typed vectors. I have not tried to apply this because as I said, I don't want to allocate to much time to benchmarking. However, if you want accurate Bigloo measurement. You should try to add the following to prefix-bigloo.scm: (module prefix (main main-entry) (extern (include "sys/times.h")) (extern (include "time.h")) ... (type (tvector f64vector (double)))) (def-macro (FLOATvector? x) `(f64vector? ,x)) (def-macro (FLOATvector-ref v i) `(f64vector-ref ,v ,i)) ...

3 2

Cygwin installation
by Alexander S. Petrov 24 Aoû '06

24 Aoû '06

Hello, I have problem installing Gambit under Cygwin. "make" command runs whole "configure" again and again. Is it normal?

1 0

MySQL FFI (Version 0.2 ready), FFI questions: strings not terminated with null, passed in strings
by Jonathan Arkell 20 Aoû '06

20 Aoû '06

Okay, I know it was only last week, but I have a new version of the MySQL FFI ready for testing. As soon as a Gambit module system is in place, I will totally be making this a module. There are much improvements made here. There are a few more higher level functions (mysql-map-rows, mysql-map-fields, get-mysql-datum, mysql-row->list, mysql-column->list, mysql-result->alist, mysql-result->list) and better testing and error recovery. I have also commented the source a lot more, licensed it under the Apache 2.0 license. As Usual, play with it, make suggestions, comments bug reports, etc. Blog entry about it (including personal motivations for writing it! Wow!): http://blog.jonnay.net/archives/744-More-Gambit-MySQL-Mana-From-Heaven,-due… Link to Download: http://blog.jonnay.net/index.php?serendipity[subpage]=downloadmanager&thisc… I also have a few questions regarding how the C functions handle strings with null values and how they handle references, The C Function mysql_real_escape_string is defined like this: unsigned long mysql_real_escape_string(MYSQL *mysql, char *to,const char *from, unsigned long length); "to" is the variable where the result of mysql_real_escape_string is stored, "from" is the string to escape which may contain null bytes, and length is the length of "from". If I define my c-lambda in similar terms, will the string I pass in be properly mutated? Or will I have to build a wrapper function that will return the "to" string instead? (which might be the better option anyway) Also, what happens when I have a Scheme string that contains a null character, and I pass it into a c-function? Will the passed in string be terminated at the first null byte? If so, how do I get around this? Thanks in Advance! -- ,-------. The Cute Grim Floating Skull of Hello Cthulu Says / | | \ / _ ^ _ \ Listen To Crazy Shaman Techno \_/ }|||{ \_/ http://www.jonnay.net '^"^` I'm Jonnay!

1 0