Gambit-list Mai 2012

gambit-list@iro.umontreal.ca

11 participants
17 discussions

Sack web server & client updates: Receives HTTP request body content now, in a streaming fashion. Several minor improvements to server and client. Documentation and examples improved.
by Mikael 21 Mai '12

21 Mai '12

The Sack server has been stable for two years or so now. The http-client part of it should be considered stable by this release. By this update, the circle is kind of closed as regards the functionality that Sack, as a HTTP middleware inspired by Rack, can be viewed as supposed to have. Repo and readme at https://github.com/pereckerdal/sack/ , listed on the dumping grounds. There is commented-out HTTPS (openssl) support in http-client. HTTPS support is intended to be added at some point to the server . File upload handling code exists, if you'd want it query for it. (The current repo online uses the Black Hole naming scheme for SRFI packages that currently only the syntactictower branch uses, thus minor changes are needed to make it spin on non-syntactictower BH. The naming scheme between these two BH branches is intended to be unified soon enough.) (Anyone interested in making Sack run directly on vanilla Gambit is of course welcome to do so, just make a vanilla Gambit-specific boot script and add the appropriate cond-expand:s to the code. If so just put it on github and make a pull request with the updates to the author.) Best regards, Mikael

1 0

Unicode library released
by Mikael 21 Mai '12

21 Mai '12

Hi guys, A Unicode library for Gambit has been released. Many thanks to Florian Loitsch for releasing the Unicode library for Bigloo, of which this library in many respects is a port. The Unicode library for Gambit does the following Unicode handling: unicode-char-upper unicode-char-lower unicode-string-upper unicode-string-upper! ; "aBc" => "ABC" unicode-string-lower unicode-string-lower! ; "aBc" => "abc" unicode-string-capitalize-strict! unicode-string-capitalize-strict ; "aBc" => "Abc" string-unicode-ci<? string-unicode-ci<=? string-unicode-ci=? string-unicode-ci>? string-unicode-ci>=? It runs out of the box on vanilla Gambit and on Black Hole. License is New BSD. It's both released on the Dumping grounds http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Dumping_Grounds and on GitHub at https://github.com/m-i-k-a-e-l/gambit-unicode . For some more info, please see the copy of the library headers below. Kind regards, Mikael - Gambit Unicode library 1.0 New BSD license Enables Gambit Scheme with Unicode handling features. Runs out of the box on vanilla Gambit and on Black Hole. The Gambit-specific code and distribution: Copyright (C) 2010-2012 Mikael More The unicode-data.scm generator and Bigloo unicode library this library was inspired by, found in the bigloo-unicode directory: Copyright (C) 2007-2012 Florian Loitsch The source data for the unicode-data.scm generator, found in the bigloo-unicode/data directory: Copyright (C) 1991-2011 Unicode, Inc. ## Exports unicode-char-upper unicode-char-lower unicode-string-upper unicode-string-upper! ; "aBc" => "ABC" unicode-string-lower unicode-string-lower! ; "aBc" => "abc" unicode-string-capitalize-strict! ; "aBc" => "Abc" unicode-string-capitalize-strict ; string-unicode-ci<? string-unicode-ci<=? string-unicode-ci=? string-unicode-ci>? string-unicode-ci>=? ## Relation with Bigloo Unicode library. Intended scope of use of this library. This library is based on the Unicode library for Bigloo Scheme by Florian Loitsch, as bundled with the js2scheme distribution as found on http://code.google.com/p/js2scheme/source/browse/ . A copy of this library is provided in this distribution in the bigloo-unicode directory, to enable you to easily generate Unicode constants based on any new Unicode Character Database versions. The vesion of the Bigloo Unicode library bundled here is was pulled from the abovementioned repo the 13:t of May 2012. Florian's last changes were the 12:th of March 2011. Florian's code is to be viewed as stable since at least 2010, to the best of my knowledge the only changes since then have been minor restructurings. Please note that the scope of this library and the Bigloo unicode library are different, in that Gambit has complete native Unicode character handling and charset encoding/decoding features built-in and thus none of this needs to be provided in a separate library, whereas the Bigloo Unicode library provides such functionality to Bigloo. ## Distribution overview unicode.scm - The Gambit Unicode handling library unicode-data.scm - The constants required to make unicode.scm spin. Generated out of the Unicode Character Database. bigloo-unicode/* - Florian Loitsch's unicode-data.scm generator, and Bigloo Unicode library that was used as inspiration for making this library. Use this to generate a new unicode-data.scm out of a Unicode Character Database update, if that would ever be released and relevant. Latest version as of the 13:th of May 2012, see more above. bigloo-unicode/data/* - The required files of the Unicode Character Database, see below. ## How to update unicode-data.scm with a new version of the Unicode Character Database In case by any reason this would ever be relevant, here is how to proceed: Update the bigloo-unicode/data/ files (namely SpecialCasing.txt and UnicodeData.txt) with the new Unicode Character Database files. As of the date of writing, these are released on http://www.unicode.org/Public/UNIDATA/SpecialCasing.txt and http://www.unicode.org/Public/UNIDATA/UnicodeData.txt , and you can see the release date of the latest update of them on http://www.unicode.org/Public/UNIDATA/ .

1 0

Update of both branches of Black Hole: Making code 'crosscompatible' with both Vanilla Gambit and Black Hole is smoother now as cond-expand is there and responds to the 'black-hole feature (examples in email).
by Mikael 21 Mai '12

21 Mai '12

Black Hole update for both branches: cond-expand, Scheme's correspondent to C's ifdef, has been implemented in both branches, and 'black-hole is added to ##cond-expand-features , thus making code compat to Vanilla Gambit and Black Hole. Code example: (cond-expand (black-hole 'code-for-black-hole-here) (else 'code-for-vanilla-gambit-here)) Execution example: $ *bsc* > *(cond-expand* * (black-hole* * 'code-for-black-hole-here)* * (else* * 'code-for-vanilla-gambit-here))* code-for-black-hole-here > *,q* $ *gsc* Gambit v4.6.2 > *(cond-expand* * (black-hole* * 'code-for-black-hole-here)* * (else* * 'code-for-vanilla-gambit-here))* code-for-vanilla-gambit-here > For a practical use example, see row 73 - 92 at https://github.com/m-i-k-a-e-l/gambit-unicode/blob/master/unicode.scm . Alvaro also made a nice --cond-expand-features=feature1:feature2 option to the syntactictower branch's bh tool. The is no action to move it to the main repo currently but can be found at https://github.com/alvatarc/blackhole/commit/d382bd615df996c6deddf4579eb8cf… and https://github.com/alvatarc/blackhole/commit/c342963f65c383f5667efb5090ebed… . Brgds, Mikael

1 0

bug in gsc -i ?
by Cyrille Duret 07 Mai '12

07 Mai '12

hello, I try to build some basic script wich use external macro with -i switch from gsc and I encounter an annoying error. Here is the simple test : @ ll total 6 -rw-r--r-- 1 cydu cydu 60 May 5 10:36 build.scm -rw-r--r-- 1 cydu cydu 39 May 5 10:36 test-macro.scm -rw-r--r-- 1 cydu cydu 55 May 5 10:36 test-simple.scm @ more test-macro.scm (define-macro (my-macro x) `(+ x 1)) @ more test-simple.scm (define my-func (lambda (x) (+ x (my-macro x)))) @ more build.scm (include "test-macro.scm") (compile-file "test-simple.scm") @ gsc-gambit -i build.scm @ gsi-gambit Gambit v4.6.4 > (load "test-simple") *** WARNING -- Variable "my-macro" used in module "test-simple.o1" is undefined "/usr/users/cydu/tmp/bug-test/test-simple.o1" > *** EOF again to exit @ rm test-simple.o1 @ gsc-gambit Gambit v4.6.4 > (include "test-macro.scm") > (compile-file "test-simple.scm") "/usr/users/cydu/tmp/bug-test/test-simple.o1" > *** EOF again to exit @ gsi-gambit Gambit v4.6.4 > (load "test-simple") "/usr/users/cydu/tmp/bug-test/test-simple.o1" > (my-func 3) 7 > It fails from the i switch and succeed when I launch gsc and type the commands by myself. It seems that the -i switch from gsc does not load the macro when it compile my file. Any idea about what might cause that annoying error ? thanks a lot cyrille

3 7

Gambit-C at 5th European Lisp Symposium
by Marco Benelli 03 Mai '12

03 Mai '12

Hi all, I have presented my experience in working with Gambit-C in the field of industrial automation at the 5th European Lisp Symposium. If someone is interested, paper and presentation are available for download here: http://mbenelli.github.com/klio Regards. --marco

3 2

Re: [gambit-list] Performance of different versions of gcc
by Marc Feeley 01 Mai '12

01 Mai '12

On 2012-04-29, at 4:40 AM, Frederick LeMaster wrote: > Wow, Marc, > Those are some thorough numbers! Thanks for testing all of this. Have > you tested compiling gambit with clang? I've compiled gambit on an > embedded arm platform (which ships with a faulty gcc...) but I haven't > done any testing n x86_64. > -Fred I repeated the experiment with clang version 2.6 to 3.0. I had some trouble getting all these clang versions working on linux (due to linking problems) so I installed the prebuilt compilers on a x86_64 Mac OS X machine. In case you want to compare the execution time in the original experiment with this experiment, please note that the Mac OS X machine is about 15% faster than the linux machine. Clang versions 2.7, 2.8 and 2.9 have bugs which prevent the Gambit "make" to complete. The details are given below. The build and execution times are given below. Note that the fastest execution speed is obtained with --enable-single-host (regardless of optimization level) and that clang 2.6 generates code that is about 40% faster than clang 3.0 . As for the build time, clang is very roughly the same speed as gcc when --enable-multiple-hosts is used. However, when --enable-single-host is used the build time increases dramatically (over 10 minutes for clang 2.6, and as much as 70 minutes for clang 3.0). Clang is probably using algorithms with a high algorithmic complexity. Strangely, with clang 3.0 it takes less time to compile with -O2 than with -O1. My guess is that clang 3.0 at -O2 must limit the size of functions which are optimized (i.e. the expensive optimizations are turned off when the functions are too big). Marc **** Execution time of tests/mix.scm when run by gsi | --enable-multiple-hosts | --enable-single-host | | -O1 | -O2 | -O1 | -O2 | clang | secs rel | secs rel | secs rel | secs rel | -------+----------------+----------------+----------------+----------------+ 2.6 | 4.35 ( 1.59) | 4.41 ( 1.61) | 2.74 ( 1.00) | 2.79 ( 1.02) | -------+----------------+----------------+----------------+----------------+ 3.0 | 3.83 ( 1.40) | 3.76 ( 1.37) | 4.49 ( 1.64) | 4.87 ( 1.78) | -------+----------------+----------------+----------------+----------------+ **** Elapsed time of "make" | --enable-multiple-hosts | --enable-single-host | | -O1 | -O2 | -O1 | -O2 | clang | secs rel | secs rel | secs rel | secs rel | -------+----------------+----------------+----------------+----------------+ 2.6 | 95.7 ( 1.00) | 96.0 ( 1.00) | 694.4 ( 7.26) | 699.1 ( 7.31) | -------+----------------+----------------+----------------+----------------+ 3.0 | 164.3 ( 1.72) | 127.2 ( 1.33) | 4313.0 (45.08) | 1825.3 (19.08) | -------+----------------+----------------+----------------+----------------+ **** Bugs in the clang compilers versions 2.7, 2.8 and 2.9: clang 2.7: /Users/feeley/clang/2.7/bin/clang -Wno-unused -Wno-write-strings -O1 -fno-math-errno -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -I"../include" -c -o "_t-c-2.o" -I. -DHAVE_CONFIG_H _t-c-2.c -D___LIBRARY clang: warning: argument unused during compilation: '-fwrapv' Assertion failed: (!isa<IndirectBrInst>(Preds[i]->getTerminator()) && "Cannot split an edge from an IndirectBrInst"), function SplitBlockPredecessors, file BasicBlockUtils.cpp, line 400. clang 2.8: /Users/feeley/clang/2.8/bin/clang -Wno-unused -Wno-write-strings -O1 -fno-math-errno -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -I"../include" -c -o "_num.o" -I. -DHAVE_CONFIG_H -D___GAMBCDIR="\"/Users/feeley/gambit-clang/clang/2.8/mhO1\"" -D___SYS_TYPE_CPU="\"i386\"" -D___SYS_TYPE_VENDOR="\"apple\"" -D___SYS_TYPE_OS="\"darwin11.3.0\"" -D___CONFIGURE_COMMAND="\"./configure '--prefix=/Users/feeley/gambit-clang/clang/2.8/mhO1' 'CC=/Users/feeley/clang/2.8/bin/clang' '--enable-multiple-hosts' '--enable-c-opt=-O1'"\" -D___OBJ_EXTENSION="\".o\"" -D___EXE_EXTENSION="\"\"" -D___BAT_EXTENSION="\"\"" -D___PRIMAL _num.c -D___LIBRARY ... Stack dump: 0. Program arguments: /Users/feeley/clang/2.8/bin/clang -cc1 -triple x86_64-apple-darwin11.0.0 -emit-obj -disable-free -disable-llvm-verifier -main-file-name _num.c -pic-level 2 -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 97.14 -resource-dir /Users/feeley/clang/2.8/lib/clang/2.8 -D HAVE_CONFIG_H -D ___GAMBCDIR="/Users/feeley/gambit-clang/clang/2.8/mhO1" -D ___SYS_TYPE_CPU="i386" -D ___SYS_TYPE_VENDOR="apple" -D ___SYS_TYPE_OS="darwin11.3.0" -D ___CONFIGURE_COMMAND="./configure '--prefix=/Users/feeley/gambit-clang/clang/2.8/mhO1' 'CC=/Users/feeley/clang/2.8/bin/clang' '--enable-multiple-hosts' '--enable-c-opt=-O1'" -D ___OBJ_EXTENSION=".o" -D ___EXE_EXTENSION="" -D ___BAT_EXTENSION="" -D ___PRIMAL -D ___LIBRARY -I ../include -I . -O1 -Wno-unused -Wno-write-strings -ferror-limit 19 -fmessage-length 80 -fwrapv -stack-protector 1 -fblocks -fno-common -fdiagnostics-show-option -o _num.o -x c _num.c 1. <eof> parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module '_num.c'. 4. Running pass 'Jump Threading' on function '@___H__3d_' clang: error: clang frontend command failed due to signal 11 (use -v to see invocation) clang 2.9: /Users/feeley/clang/2.9/bin/clang -Wno-unused -Wno-write-strings -O1 -fno-math-errno -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -I"../include" -c -o "_num.o" -I. -DHAVE_CONFIG_H -D___GAMBCDIR="\"/Users/feeley/gambit-clang/clang/2.9/mhO1\"" -D___SYS_TYPE_CPU="\"i386\"" -D___SYS_TYPE_VENDOR="\"apple\"" -D___SYS_TYPE_OS="\"darwin11.3.0\"" -D___CONFIGURE_COMMAND="\"./configure '--prefix=/Users/feeley/gambit-clang/clang/2.9/mhO1' 'CC=/Users/feeley/clang/2.9/bin/clang' '--enable-multiple-hosts' '--enable-c-opt=-O1'"\" -D___OBJ_EXTENSION="\".o\"" -D___EXE_EXTENSION="\"\"" -D___BAT_EXTENSION="\"\"" -D___PRIMAL _num.c -D___LIBRARY ... Stack dump: 0. Program arguments: /Users/feeley/clang/2.9/bin/clang -cc1 -triple x86_64-apple-darwin11.0.0 -emit-obj -disable-free -disable-llvm-verifier -main-file-name _num.c -pic-level 2 -relaxed-aliasing -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 97.14 -resource-dir /Users/feeley/clang/2.9/bin/../lib/clang/2.9 -D HAVE_CONFIG_H -D ___GAMBCDIR="/Users/feeley/gambit-clang/clang/2.9/mhO1" -D ___SYS_TYPE_CPU="i386" -D ___SYS_TYPE_VENDOR="apple" -D ___SYS_TYPE_OS="darwin11.3.0" -D ___CONFIGURE_COMMAND="./configure '--prefix=/Users/feeley/gambit-clang/clang/2.9/mhO1' 'CC=/Users/feeley/clang/2.9/bin/clang' '--enable-multiple-hosts' '--enable-c-opt=-O1'" -D ___OBJ_EXTENSION=".o" -D ___EXE_EXTENSION="" -D ___BAT_EXTENSION="" -D ___PRIMAL -D ___LIBRARY -I ../include -I . -O1 -Wno-unused -Wno-write-strings -ferror-limit 19 -fmessage-length 80 -fwrapv -stack-protector 1 -fblocks -fno-common -fdiagnostics-show-option -o _num.o -x c _num.c 1. <eof> parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module '_num.c'. 4. Running pass 'Loop Pass Manager' on function '@___H__23__23_bignum_2e__2a_' 5. Running pass 'Rotate Loops' on basic block '%2697' clang: error: unable to execute command: Segmentation fault: 11 clang: error: clang frontend command failed due to signal 1 (use -v to see invocation)

2 2

Algorithmic complexity of clang
by Marc Feeley 01 Mai '12

01 Mai '12

Concerning the algorithmic complexity of clang, I am forwarding to the list an analysis I did in January to better understand the build times of Gambit when compiled with gcc. Marc Begin forwarded message: > From: Marc Feeley <feeley(a)iro.umontreal.ca> > Subject: Re: gambit-c > Date: 24 January, 2012 10:38:28 AM EST > To: Jeremy Huddleston <jeremyhu(a)macports.org> > Cc: Jeremy Lavergne <jeremy(a)lavergne.gotdns.org>, Bradley Lucier <lucier(a)math.purdue.edu> > > > On 2012-01-23, at 7:36 PM, Jeremy Huddleston wrote: > >> Ok, I see the issue now. I've also created gcc-preprocessed versions for comparison with gcc (since gcc doesn't like clang's preprocessed sources). Recent clang trunk compiles _thread.c much faster than XCode 4.2's, but it's not nearly as fast as gcc and llvm-gcc. Now that I've been able to reproduce this, I've passed it along to our compiler team for analysis. There are really 2 issues here, however: one is the compilation time, and one is the resulting performance of the built executable. >> >> I think the bug report that I filed will be focusing on the compilation speed. I think we should hold off on the performance of the executable until after the compiler issues are worked out since they will certainly have an impact on the executable itself. > > I agree. > >> Thanks for your help, >> Jeremy >> >> $ time /Developer/usr/bin/clang -c -O1 -Wno-parentheses clang-preprocessed/_thread.preproc.c >> >> real 0m28.851s >> user 0m22.885s >> sys 0m0.728s >> >> $ time /opt/local/bin/clang-mp-3.1 -c -O1 -Wno-parentheses clang-preprocessed/_thread.preproc.c >> >> real 0m18.909s >> user 0m17.001s >> sys 0m0.778s >> >> $ time /Developer/usr/bin/llvm-gcc-4.2 -c -O1 gcc-preprocessed/_thread.preproc.c >> >> real 0m4.798s >> user 0m3.976s >> sys 0m0.127s >> >> $ time /opt/local/bin/gcc-apple-4.2 -c -O1 gcc-preprocessed/_thread.preproc.c >> >> real 0m3.558s >> user 0m3.062s >> sys 0m0.167s > > I repeated my experiment to compare clang 2.0 (from an old installation of Xcode), clang 3.0 (from Xcode 4.2) and clang 3.1 (built from the LLVM sources, installed in my /usr/local/bin). I did a "CC=the_c_compiler ./configure --enable-single-host;time make" for each C compiler. The transcript of each build is attached below. Here are the respective build times: > > % tail -3 transcript-clang-* > ==> transcript-clang-2_0.txt <== > real 16m4.946s > user 15m48.710s > sys 0m15.776s > > ==> transcript-clang-3_0.txt <== > real 107m2.396s > user 106m30.343s > sys 0m31.707s > > ==> transcript-clang-3_1.txt <== > real 16m9.004s > user 15m52.962s > sys 0m15.684s > > As you can see clang 3.0 has a much longer build time than clang 2.0 and clang 3.1 (which are very close). I'm convinced this is due to the use of very high complexity algorithms in the clang 3.0 compiler. To verify this conjecture I looked at the compile time for _io.c and _thread.c for clang 2.0 and clang 3.0. The times in seconds are: > > clang 2.0 clang 3.0 > _io.c 287.0 1948.0 > _thread.c 8.8 21.6 > > In terms of lines of code in the host C function, _io.c is about 3.1 times bigger than _thread.c . These numbers can be used to estimate the algorithmic complexity of the algorithms in these two compilers. > > Notice that for clang 2.0 the compile times of _io.c and _thread.c are related by a *cubic* function on the relative size of the host C function: > > 8.8 * 3.1^3 = 262 (which is close to 287) > > For clang 3.0 the compile times of _io.c and _thread.c are related by a *quartic* function on the relative size of the host C function: > > 21.6 * 3.1^4 = 1994 (which is close to 1948) > > So if n is the size of the code, for large n, clang 2.0 is O(n^3), which is terrible, and clang 3.0 is O(n^4), which is outright catastrophic for compiling machine generated code. To be practical (for machine generated code) the complexity should be O(n^2) at most. For the record, with GNU gcc the same experiment gives a ratio of 6.3 between the compile times of _io.c and _thread.c, which is less than O(n^2), it is roughly O(n^1.6). > > I hope something can be done about this. > > Marc > >

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 Mai 2012