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

Re: [gambit-list] Experience with the new compile options
by Guillaume Cartier 07 Aoû '07

07 Aoû '07

>> It seems like using --enable-optimize-space gives a faster build >> *and* faster execution. So maybe I will probably make this the >> default if I observe the same thing on other benchmarks. Just as a side note, when I was fiddling with Visual C++ compiler options on Windows, I noticed the exact same behavior where optimizing for speed versus optimizing for space gave only a marginal speed advantage and at a large compilation time premium. Guillaume

1 0

Experience with the new compile options
by Bradley Lucier 07 Aoû '07

07 Aoû '07

Marc: I've had a lot of experience now with the new compile options (and I'm not talking about --enable-gcc-opts) and I have to say that they just aren't worth it. You don't know which of them help the most in execution time, and you don't know which cost the most in compile time. (Hell, you don't even know which ones help *at all*; you could be running compiler passes that hurt run-time performance while eating up compile time.) You ran a genetic algorithm to guess which optimizations to run. That's fine to get an idea of what to try, but it's not sufficient to foist this pain on your users. Even on my Opteron server development is painful. So pull back to the old -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict- aliasing -fwrapv -fomit-frame-pointer by default; even offer a configure optimization to add - D___OPTIMIZE_SPACE to the compile line. You have a development model that does whole-program compilation by default; it just can't support the default compiler options chosen at configure time. Brad

2 2

non blocking IO bug ?
by Adrien Pierard 07 Aoû '07

07 Aoû '07

Hi ! I'm having some trouble with simple sockets operations, and I'm not sure whether this is a bug, or whether I definitely misunderstood the documentation. Here is a sample code: ;; Create a server (define node-socket (open-tcp-server (list port-number: 8284 eol-encoding: 'cr-lf))) ;; Set it non blocking (input-port-timeout-set! node-socket 0) ;; read once. Should return EOF because no one tried to connect to the ;; server (define c (read node-socket)) ;; returns #t (eof-object? c) ;; Drink a coffee and read again. ;; It should return eof again for no one is connected (define d (read node-socket)) *** ERROR IN ##thread-deadlock-action! -- Deadlock detected Hum... Deadlock ? Should I do something specific after "failing" to read the socket to let some other expression to read it again ? Or is it a bug^Wundocumented feature in the non-blocking ports routines ? This happens as well on beta 22 as on beta 17. Does it happen at yours too on a mac/windows ? Do you use non blocking IO a different manner, and that works ? Regards, Adrien -- "I am not a Church numeral; I am a free variable!" (The Scheme Underground) For every complex problem, there is a solution that is simple, neat, and wrong.

3 2

Installing Gambit-C on Windows using Visual C++ 7
by Kevin Brammer 04 Aoû '07

04 Aoû '07

Hi, I am new to using Gambit Scheme. I would like to be able to use Gambit Scheme with VC7. So I am trying to install Gambit Scheme 4.0 beta 22 on Windows XP. I have followed the instructions in the INSTALL file that came with the tarball and I was able to compile Gambit-C using VC7. I notices that six.exe didn't seem to be included. My main question is after I have the binaries compiled what is the proceedure for setting up the install directory? I originally tried manually copying the binaries into (as I compiled the system in C:\Temp\Gambit-C\): C:\Gambit-C\4.0b22\bin; I copied the lib file into C:\Gambit-C\4.0b22\lib; and I copied the include file into C:\Gambit-C\4.0b22\include. I then set up the following environment variables: INCLUDE=C:\Gambit-C\4.0b22\include; LIB=C:\Gambit-C\4.0b22\lib; PATH=C:\Gambit-C\4.0b22\bin I then wrote up the following file (hello.scm): (display "Hello World :)" ) At the command prompt I entered: C:\Temp> gsc -link hello.scm *** ERROR IN ##parameterize -- No such file or directory (current-directory "C:\\lib") I think the following error has to do with location Gambit-C was compiled at, but I'm not sure. As well if it is the error I'm not sure how to fix it. I would appreciate any help I could get on this and the above issues as I would really like to be able to use Gambit Scheme. - Kevin

2 1

Gambit installers
by Marc Feeley 03 Aoû '07

03 Aoû '07

Does anyone have experience creating installers for Windows and MacOS X? What are the best free installers? Marc

7 9

Is there a way to adjust serial port settings?
by Terry Parks 30 Jul '07

30 Jul '07

Also is there a way to search the list archives? Terry Parks

3 3

Valid namespace prefix
by James Long 30 Jul '07

30 Jul '07

How come Gambit enforces the module# syntax for namespaces? I have just started using them, and have looked at many posts describing the system, but I don't remember anyone explaining the reason for this syntax. For example, trying anything different than module gives an error: > (namespace ("foo:")) *** ERROR IN (console)(a)1.13 -- Ill-formed namespace prefix I would like to use the colon syntax as I find it much more readable, especially for user-land code. I'm going to usually use fully qualified names, so this slight readability improvement is important. Is there a reason I shouldn't be able to do this?

3 4

Using the tcc compiler
by Christian Jaeger 28 Jul '07

28 Jul '07

Hello I've just discovered that tcc¹ is able to compile the C code generated by Gambit. In simple cases the compiled object files work just flawlessly (albeit ~3 times slower than when compiled with gcc in a fixnum-loop microbenchmark, but that's ok). When I compile one of my bigger modules (which takes 3 seconds for compilation from Scheme to C and 17 seconds to compile from C to binary with gcc 4.1.2, and only 1 second to compile from C to binary with tcc 0.9.23), it's doing wrong calculations (I'm doing signal processing, with tcc it just outputs zeroes all the time). The way I've used tcc in the above tests was by just linking tcc into the PATH as gcc (mkdir ~/bin; ln -s /usr/bin/tcc ~/bin/gcc; PATH="~/bin:$PATH"; start gsc interactively and use compile-file (through chjmodule) as usual). Should I take a different approach? Or should I start debugging problems / send bug reports with code when compiled with tcc? Having 5 times faster compile times would help development in those cases where using the interpreter isn't possible (because it is too slow or because the modules are including FFI code), albeit it's not a high priority. (Alternatively I might possibly speed up gcc by not using single-host and no -O flag. How can I achieve those settings from inside gsc (when using |compile-file|), btw?) Christian. ¹http://fabrice.bellard.free.fr/tcc/

3 3

Possible gc bug?
by Bradley Lucier 26 Jul '07

26 Jul '07

Marc: I've got a vector of length 262,144, each element of which is supposed to be a length 4 f64vector. Well, I get a interrupt in my program when it hits one of these elements that is only of length 2. Further investigation shows that only two elements of the whole vector have length 2: > 1> (Array-for-each (lambda (p) (if (not (= (f64vector-length p) 4)) > (pp p))) p) > #f64(-.7079566418808501 -.2467907960478973) > #f64(-.6672517342403924 -.31362141535348953) This presents a very interesting debugging problem. Eventually, I changed the code storing an array to check whether all the f64vectors are the same length when the Array is built: > (set! make-Array-base > (lambda (domain ;; an Interval > getter ;; (lambda (i_0 ... i_n-1) ...) > returns a value for (i_0,...,i_n-1) in (Array-domain a) > ;; Part of mutable arrays > setter ;; (lambda (v i_0 ... i_n-1) ...) > sets a value for (i_0,...,i_n-1) in (Array-domain a) > ;; Part of Fixed arrays > manipulators ;; a Fixed-array-manipulator > body ;; the backing store for this array > indexer ;; see below > affine ;; A list that says in which > coordiantes the indexer is affine. > safe? ;; do we check whether bounds (in > getters and setters) and values (in setters) are valid > ) > (if (and body > (vector? body) > (< 0 (vector-length body)) > (let ((element (vector-ref body 0))) > (and (f64vector? element) > (let ((l (f64vector-length element))) > (not (every (lambda (p) (= (f64vector-length p) l)) (vector- > >list body))))))) > (error "Bzzt, thank you for playing") > (original-make-Array-base domain ;; an Interval > getter ;; (lambda (i_0 ... i_n-1) ...) > returns a value for (i_0,...,i_n-1) in (Array-domain a) > ;; Part of mutable arrays > setter ;; (lambda (v i_0 ... i_n-1) ...) > sets a value for (i_0,...,i_n-1) in (Array-domain a) > ;; Part of Fixed arrays > manipulators ;; a Fixed-array-manipulator > body ;; the backing store for this array > indexer ;; see below > affine ;; A list that says in which > coordiantes the indexer is affine. > safe? ;; do we check whether bounds (in > getters and setters) and values (in setters) are valid > )))) and everything passed. The code works and is exercised: > 1> (make-Array-base #f #f #f #f (vector '#f64(0.0) '#f64(0. 0.)) #f > #f #f) > *** ERROR IN (console)(a)8.1 -- Bzzt, thank you for playing I'm only human, so I want to blame the system rather than my own code. It makes me wonder whether there is still a gc bug in beta 22, whether that bug has been fixed for the upcoming beta 23, etc. Any suggestions? Brad

1 1

System Type
by Jeremie Lasalle Ratelle 25 Jul '07

25 Jul '07

Is there a way to get the host system type at runtime in Gambit-C? ex. i686-pc-linux-gnu

2 1