<?xml version="1.0"?>
<?xml-stylesheet type="text/css" href="http://dynamo.iro.umontreal.ca/wiki/skins/common/feed.css?270"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php?title=Special:Contributions/Mikaelm&amp;feed=atom&amp;limit=50&amp;target=Mikaelm&amp;year=&amp;month=</id>
		<title>Gambit wiki - User contributions [en]</title>
		<link rel="self" type="application/atom+xml" href="http://dynamo.iro.umontreal.ca/wiki/index.php?title=Special:Contributions/Mikaelm&amp;feed=atom&amp;limit=50&amp;target=Mikaelm&amp;year=&amp;month="/>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Special:Contributions/Mikaelm"/>
		<updated>2013-06-19T08:16:34Z</updated>
		<subtitle>From Gambit wiki</subtitle>
		<generator>MediaWiki 1.16.4</generator>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds</id>
		<title>Dumping Grounds</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds"/>
				<updated>2013-05-04T00:36:12Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Here you will find packages of Gambit code contributed by users.  This page is meant as a simple repository where random code snippets as well as complex systems can easily be stored so that other users can get to them.  This is not a substitute for a repository that is closely coupled with the Gambit system's module system (which is under development).  It is meant to foster the sharing of code by making it extremely easy to publish code in a publicly accessible place.  Sharing a piece of code that is incomplete, undocumented, and unreliable is better than not sharing it, because others can correct the deficiencies, learn from the code, or avoid the bugs.  Hence the name '''Dumping Grounds''' for this page.&lt;br /&gt;
&lt;br /&gt;
The code need not follow a specific structure.  It could simply be a Scheme source file (with a '''.scm''' extension).  However, if you are packaging your code specifically for storing it here, it is best if the name of the package contains a revision number (so that many revisions can be stored) and is a gzip compressed tar file ('''.tgz''' extension) containing the code and documentation (for example file '''Sort-r1.tgz''' containing the files '''Sort-r1/Sort.scm''' and possibly '''Sort-r1/Sort.html''' and other related files).  For some reason the wiki insists on the package name starting with an upper-case letter.  The code is assumed to be in the public domain unless you add licensing information in the package itself or the documentation.&lt;br /&gt;
&lt;br /&gt;
To add a new package you must add an entry for it to this page (copy-paste an existing entry), update the file name in the &amp;lt;nowiki&amp;gt;[[media:Sort-r1.tgz|Sort-r1.tgz]]&amp;lt;/nowiki&amp;gt; link, save the page and click on the link to upload your file.  If you upload a new revision don't forget to change the revision number, and keep the link to the old revisions.&lt;br /&gt;
&lt;br /&gt;
A list of the packages and other files with statistics is available here: [[Special:Imagelist]]&lt;br /&gt;
&lt;br /&gt;
In case you find that a link to an external repository linked to from this page doesn't work anymore, please try to retrieve the latest version of the repo and upload it here, by a) contacting the author directly, b) enquiring for it on the mailing list, and/or c) trying to get it from archive.org.&lt;br /&gt;
&lt;br /&gt;
==Gambit packages==&lt;br /&gt;
These packages are in the present form created to run atop Gambit directly. They can generally easily be ported to any module system of choice.&lt;br /&gt;
===SRFI===&lt;br /&gt;
#'''SRFI-pack''': Many SRFIs ported to Gambit&lt;br /&gt;
#: Author: Guillaume Germain&lt;br /&gt;
#: Package: [[media:Srfi-pack-0.1.tar.gz|Srfi-pack-0.1.tar.gz]]&lt;br /&gt;
#: README: [[media:Srfi-pack-0.1-README.txt|Srfi-pack-0.1-README.txt]]&lt;br /&gt;
#'''SRFI-1''': SRFI-1 ported to Gambit&lt;br /&gt;
#: Author: Olin Shivers; ported by Bradley Lucier&lt;br /&gt;
#: Package [[media:Srfi1.scm|Srfi1.scm]]&lt;br /&gt;
#: Note: I did not extend map to allow list arguments of different lengths&lt;br /&gt;
&lt;br /&gt;
=== Language ===&lt;br /&gt;
# '''Gambit on LLVM''': Experimental partial back-end for Gambit using LLVM&lt;br /&gt;
#: Authors: Arnaud Bergeron and Mathieu Larose&lt;br /&gt;
#: Package: [[media:Gambit-LLVM.tgz|Gambit-LLVM.tgz]]&lt;br /&gt;
# '''Jss''': JavaScriptScheme: a multithreaded Scheme to JavaScript compiler&lt;br /&gt;
#: Author: Marc Feeley and Catherine Gaudron&lt;br /&gt;
#: Package: [[media:Jss-r2.tgz|Jss-r2.tgz]] (old: [[media:Jss-r1.tgz|Jss-r1.tgz]])&lt;br /&gt;
# '''R6RS on Gambit''':Allows R6RS programs to be run on Gambit. &lt;br /&gt;
#: Maintainer: Arthur Smyles&lt;br /&gt;
#: Package: (web page) http://smyles.com/projects/r6gambit/&lt;br /&gt;
# '''PICOBIT''': Very compact Scheme compiler and virtual machine suitable for microcontrollers.&lt;br /&gt;
#: Author: Marc Feeley and Vincent St-Amour&lt;br /&gt;
#: Package: (web page) http://repo.or.cz/w/picobit.git&lt;br /&gt;
# '''Alexpander''': A syntax-rules expander with support for DSSSL #!optional #!key and #!rest arguments.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:Alexpander-r1.tgz|Alexpander-r1.tgz]]&lt;br /&gt;
&lt;br /&gt;
===Module systems===&lt;br /&gt;
# '''Black Hole''': Module system, stable. Package handling features are in beta phase. Primary page at [[Black Hole]].&lt;br /&gt;
#: Package: (git repo) [https://github.com/pereckerdal/blackhole https://github.com/pereckerdal/blackhole]&lt;br /&gt;
#: Mirror for convenience, non-syntactictower Black Hole with bundled libs: [[media:2012-11-28-bh-non-syntactictower+bundled-libs.tar.gz|2012-11-28-bh-non-syntactictower+bundled-libs.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Object Systems===&lt;br /&gt;
# '''Oops''': Object Oriented Programming for Scheme -- Dylan/Clos-like but different&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:oops34.tgz|oops34.tgz]]&lt;br /&gt;
# '''TinyTalk''': Self-like object system with selector [Smalltalk like] dispatch.&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:gambitTT.tgz|gambitTT.tgz]]&lt;br /&gt;
# '''class.scm''': A simple CLOS-like object system written with a balance of performance, usability and runtime heap consumption. Comes bundled with a test suite which shows exemple of how the system can be used. Also can be used easily in a repl with (include &amp;quot;class.scm&amp;quot;). &lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: (web page/git repo) http://github.com/sthilaid/class/tree/master&lt;br /&gt;
# '''Meroon''': CLOS-like object system for Scheme.&lt;br /&gt;
#: Author: Christian Queinnec, now semi-maintained by Brad Lucier.  Licensed under the [http://opensource.franz.com/preamble.html Lisp Lesser General Public Licence].  Differs from CLOS in (among many other things) having single inheritance instead of multiple inheritance and a compile-time, not a run-time, MOP.  Can be compiled to be relatively fast code.  Would benefit from being reorganized in a &amp;quot;layered&amp;quot; style more appropriate for current ideas of Scheme modules.&lt;br /&gt;
#: Website: http://www.math.purdue.edu/~lucier/software/Meroon/&lt;br /&gt;
#: Package: [[media:MeroonV3-2012Jan20.tar.bz2|MeroonV3-2012Jan20.tar.bz2]]&lt;br /&gt;
&lt;br /&gt;
=== FFI ===&lt;br /&gt;
# '''ffi-related-modules''': various modules dealing with the FFI, and their dependencies (chjmodules, but someone might turn them to using bare namespaces or so; read the Readme file at the below URL)&lt;br /&gt;
#: Author: Christian Jaeger&lt;br /&gt;
#: Package: (web page/git repo) http://scheme.ch/gambit/preview/ffi-related-modules/&lt;br /&gt;
&lt;br /&gt;
===Parsing===&lt;br /&gt;
# '''SSAX-SXML''': SSAX-SXML library packaged for Gambit-C&lt;br /&gt;
#: Author: Kirill Lisovsky (updated by Dominique Boucher)&lt;br /&gt;
#: Package: (web page) [[media:ssax-sxml-gambit-20080402.tgz|ssax-sxml-gambit-20080402.tgz]]&lt;br /&gt;
# '''Mparser''': A combinatorial parser (added expression parser) (parser language rewrite)&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:Mparser-r3.tgz|Mparser-r3.tgz]] (old: [[media:Mparser-r1.tgz|Mparser-r1.tgz]], [[media:Mparser-r2.tgz|Mparser-r2.tgz]])&lt;br /&gt;
&lt;br /&gt;
===Physics===&lt;br /&gt;
#'''Ising''': Computer simulations of the Ising model of spins using the Metropolis algorithm or the Wolff algorithm.&lt;br /&gt;
#: Author: Marijn Schouten&lt;br /&gt;
#: Package: [[media:ising-20090315.scm]]&lt;br /&gt;
&lt;br /&gt;
===Compression===&lt;br /&gt;
#'''ZLib''': ZLib aka LibZ GZip compression library FFI&lt;br /&gt;
#: Author: Mikael&lt;br /&gt;
#: Package: [https://github.com/m-i-k-a-e-l/gambit-zlib https://github.com/m-i-k-a-e-l/gambit-zlib]&lt;br /&gt;
&lt;br /&gt;
===Math===&lt;br /&gt;
# '''Pi''': Compute pi to arbitrary precision.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [[media:Pi-r3.tgz|Pi-r3.tgz]] (old: [[media:Pi-r2.tgz|Pi-r2.tgz]]) (old: [[media:Pi-r1.tgz|Pi-r1.tgz]])&lt;br /&gt;
# '''BLAS''': Thin wrapper for level 1, 2 and 3 BLAS linear algebra routines for the Gambit Scheme system.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/blas&lt;br /&gt;
# '''LAPACK''': Thin wrapper for higher-level linear algebra routines for the Gambit Scheme system.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/lapack&lt;br /&gt;
# '''FFTW3''': A wrapper for some FFTW3 functions for the Gambit Scheme system. (real, complex, multi-dimensional FFT functions)&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/fftw3&lt;br /&gt;
# '''Random numbers''': High-quality random number generation. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=random http://snow.iro.umontreal.ca/?viewpkg=random]&lt;br /&gt;
# '''GUROBI FFI''': This is a FFI that includes the most necessary commands for operating GUROBI from GAMBIT.&lt;br /&gt;
#: Author: Magnus Andersson&lt;br /&gt;
#: Package: [https://github.com/angelrussher/gurobi-ffi https://github.com/angelrussher/gurobi-ffi]&lt;br /&gt;
&lt;br /&gt;
===Encryption===&lt;br /&gt;
# '''AES''' Message encryption and decryption based on the AES symmetric cipher. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=aes http://snow.iro.umontreal.ca/?viewpkg=aes]&lt;br /&gt;
# '''Cert''' Management of digital certificates, message signing and verification. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=cert http://snow.iro.umontreal.ca/?viewpkg=cert]&lt;br /&gt;
# '''RSA''' Message encryption and decryption based on the RSA asymmetric cipher. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=rsa http://snow.iro.umontreal.ca/?viewpkg=rsa]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- ===Networking=== --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===SQL===&lt;br /&gt;
# '''MySQL FFI''': FFI for mysql.  Unsure about thread-safety, and needs more work&lt;br /&gt;
#: Author: Jonathan Arkell&lt;br /&gt;
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/mysql/&lt;br /&gt;
# '''MySQL''': Socket level client for mysql. Supports dynamic SQL and now prepared statements. Also includes a SQL abstraction layer. This [http://andrewwhaley.blogspot.com/2009/04/gambit-mysql-client-02.html blog post] has more information. For a more developed version w UTF8 support pls contact the ml.&lt;br /&gt;
#: Author: Andrew Whaley&lt;br /&gt;
#: Package: [[media:Gambit-mysql.zip|Gambit-mysql.zip]]&lt;br /&gt;
# '''SQLite3''': a minimalistic interface to SQLite3.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:SQLite3-r1.tgz|SQLite3-r1.tgz]]&lt;br /&gt;
# '''Postgresql''': A socket level client for Postgresql&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:Postgresql-r1.tgz|Postgresql-r1.tgz]]&lt;br /&gt;
&lt;br /&gt;
===Graphics===&lt;br /&gt;
# '''Octave''': A simple plotting interface using octave (2.x) and gnuplot.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/octave/&lt;br /&gt;
# '''Schemeray''': A simple (and as of yet, unoptimized) raytracer&lt;br /&gt;
#: Author: James Long&lt;br /&gt;
#: Package: [[media:schemeray-0.2.tgz|schemeray-0.2.tgz]]&lt;br /&gt;
# '''Opengl FFI''': A simple opengl, glu and glut ffi which supports opengl up to version 1.1.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Opengl-ffi-r1.tgz|Opengl-ffi-r1.tgz]]&lt;br /&gt;
# '''Perlin Noise''': A simple opengl demonstration of a sub-optimal 2d Perlin noise implementation.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Perlin-noise-2d-r1.tgz|Perlin-noise-2d-r1.tgz]]&lt;br /&gt;
# '''Cairo''': Bindings for cairo graphics.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:Cairo-r3.tgz|Cairo-r3.tgz]] (old: [[media:Cairo-r2.tgz|Cairo-r2.tgz]])&lt;br /&gt;
# '''GLEW''': A wrapper for GLEW which provides all OpenGL functionality through version 2.1 and manages access to vendor extensions&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:Glew.tar.gz|glew.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Audio===&lt;br /&gt;
# '''mpg123''': A wrapper for the libmpg123 mpeg decoding library&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:mpg.tar.gz|mpg.tar.gz]]&lt;br /&gt;
# '''OpenAL''': A wrapper for the OpenAL audio output library&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:openAL.tar.gz|openAL.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Networking===&lt;br /&gt;
# '''gamsock''': Full socket library compatible with Scsh's socket API.&lt;br /&gt;
#: Author: Jeffrey T. Read&lt;br /&gt;
#: Package: [[media:gamsock-r1.tar.gz|gamsock-r1.tar.gz]]&lt;br /&gt;
#: Git: https://github.com/bitwize/gamsock&lt;br /&gt;
&lt;br /&gt;
===Utilities===&lt;br /&gt;
# '''Sort''': Provides a simple sorting procedure for lists and vectors.  The mergesort algorithm is used.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [[media:Sort-r1.tgz|Sort-r1.tgz]]&lt;br /&gt;
# '''Bunny Test''': A simple unit testing framework.  &lt;br /&gt;
#: Author: Jonathan Arkell&lt;br /&gt;
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/test/&lt;br /&gt;
# '''GetOpts''': A syntactic form (let-opts) to parse command line options&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:GetOpts-r1.tgz|GetOpts-r1.tgz]]&lt;br /&gt;
# '''Etags''': Script that generates Emacs TAGS files from Scheme files, and recognizes nested definitions.&lt;br /&gt;
#: Author: Vincent St-Amour&lt;br /&gt;
#: Package: http://www-etud.iro.umontreal.ca/~stamourv/etags.scm&lt;br /&gt;
# '''Win-control''': Library for controlling Internet Explorer and other Windows applications for scripting or automating testing.&lt;br /&gt;
#: Author: Andrew Whaley&lt;br /&gt;
#: Package: http://code.google.com/p/win-control&lt;br /&gt;
# '''repltest''': Small example which embeds a remotely accessible REPL into a standalone C program.&lt;br /&gt;
#: Web: https://mercure.iro.umontreal.ca/pipermail/gambit-list/2010-June/004500.html&lt;br /&gt;
#: Package: [[media:Repltest-20100604.tgz‎|Repltest-20100604.tgz‎]]&lt;br /&gt;
# '''objc-utility-macros''': Utility macros to help wrap Objective-C methods.&lt;br /&gt;
#: Author: Jeffrey T. Read&lt;br /&gt;
#: Package: [[media:objc-utility-macros.scm‎|objc-utility-macros.scm]]&lt;br /&gt;
# '''Sort''': Richard O'Keefe's sorting procedures for lists and vectors.  Four times as fast as other sort.&lt;br /&gt;
#: Author: Richard O'Keefe&lt;br /&gt;
#: Package: [[media:Sort-okeefe.tgz|Sort-okeefe.tgz]]&lt;br /&gt;
# '''Digest''': Computation of message digests (CRC32, MD5, SHA-1, ...). Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=digest http://snow.iro.umontreal.ca/?viewpkg=digest]&lt;br /&gt;
# '''Red-black tree''' implementation, Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=rbtree http://snow.iro.umontreal.ca/?viewpkg=rbtree]&lt;br /&gt;
# '''Unicode''': Unicode handling library 1.0, does string upper-/lowercasing and case insensitive comparison with Unicode character support. Essentially completes Gambit's support for the functionality described in [http://srfi.schemers.org/srfi-75/srfi-75.html SRFI 75: Unicode].&lt;br /&gt;
#: Author: Mikael More, Florian Loitsch&lt;br /&gt;
#: Package: [[media:Unicode.tar.gz|Unicode.tar.gz]] repo: [https://github.com/m-i-k-a-e-l/gambit-unicode https://github.com/m-i-k-a-e-l/gambit-unicode]&lt;br /&gt;
# '''Glass Table''': Interactive Development Environment. A REPL that lets you save your work.&lt;br /&gt;
#: Author: Jeffrey T. Read&lt;br /&gt;
#: Repo: https://github.com/bitwize/glasstable&lt;br /&gt;
#: Package: [[media:glasstable-0.1.tar.gz|glasstable-0.1.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
=== Full Applications ===&lt;br /&gt;
# '''Space-Invaders''': Space Invaders classical arcade game remake in scheme over either glut or SDL.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Space-invaders-src-v1.0.tgz|Space-invaders-src-v1.0.tgz]]&lt;br /&gt;
# '''Web Server''': a web server with sessions cookies and server pages.&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:WebServer-r2.tgz|WebServer-r2.tgz]] (old: [[media:WebServer-r1.tgz|WebServer-r1.tgz]])&lt;br /&gt;
#: Git: http://git.berlios.de/cgi-bin/gitweb.cgi?p=futhark;a=summary&lt;br /&gt;
# '''GUI-Toy''': Simple Direct Media Layer prototype code with examples in the raw and using TinyTalk and Oops object systems.&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:GUI-Toy.tgz|GUI-Toy.tgz]]&lt;br /&gt;
# '''Intelligent WTF''': Intelligent acronym decoder based on ''wtf'' from BSD Games&lt;br /&gt;
#: Author: Joel J. Adamson &lt;br /&gt;
#: Package: (web page) http://www.unc.edu/~adamsonj/software.html&lt;br /&gt;
# '''Genetic Canvas''': A polygon-based image renderer using genetic algorithms.&lt;br /&gt;
#: Author: James Long&lt;br /&gt;
#: Web: http://jlongster.com/blog/2009/05/25/mona-lisa-genetically-drawn-scheme/&lt;br /&gt;
&lt;br /&gt;
==Gambit Black Hole packages==&lt;br /&gt;
These packages are in their present form created to run on Gambit using the Black Hole module system. They can generally easily be made to run on Gambit directly as well. For more info see [[Black Hole]].&lt;br /&gt;
===SRFI===&lt;br /&gt;
# '''SRFIs package'''&lt;br /&gt;
#: Package: (git repo) [https://github.com/pereckerdal/srfi https://github.com/pereckerdal/srfi]&lt;br /&gt;
&lt;br /&gt;
===Networking===&lt;br /&gt;
# '''Sack''': Web server and HTTP client. BH module. [https://github.com/pereckerdal/sack https://github.com/pereckerdal/sack]&lt;br /&gt;
For convenience, mirror readily set up for non-syntactictower Black Hole: [[media:2012-11-28-sack-current-for-BH-non-syntactictower.tar.gz|2012-11-28-sack-current-for-BH-non-syntactictower.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Utilities===&lt;br /&gt;
# '''Mishmash of various utils''': xml&amp;lt;-&amp;gt;sxml, pregexp, digest, base64, uuid, fifo mailbox, rbtree, exception-handling, let-optionals and more. sxpath also available. These packages will be split out to individual packages. Ask on mailing list for updates.&lt;br /&gt;
#: Package: (git repo) https://github.com/pereckerdal/std&lt;br /&gt;
&lt;br /&gt;
==Documents==&lt;br /&gt;
===Scheme books===&lt;br /&gt;
# '''An Introduction to Scheme and its Implementation''': A pretty good book on how to learn Scheme, for people with a background in general programming languages.&lt;br /&gt;
#: Author: Paul R. Wilson&lt;br /&gt;
#: Package: [[media:An_Introduction_to_Scheme_and_its_Implementation.tar.gz|An_Introduction_to_Scheme_and_its_Implementation.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
[[Category: Code]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds</id>
		<title>Dumping Grounds</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds"/>
				<updated>2013-05-04T00:29:50Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Here you will find packages of Gambit code contributed by users.  This page is meant as a simple repository where random code snippets as well as complex systems can easily be stored so that other users can get to them.  This is not a substitute for a repository that is closely coupled with the Gambit system's module system (which is under development).  It is meant to foster the sharing of code by making it extremely easy to publish code in a publicly accessible place.  Sharing a piece of code that is incomplete, undocumented, and unreliable is better than not sharing it, because others can correct the deficiencies, learn from the code, or avoid the bugs.  Hence the name '''Dumping Grounds''' for this page.&lt;br /&gt;
&lt;br /&gt;
The code need not follow a specific structure.  It could simply be a Scheme source file (with a '''.scm''' extension).  However, if you are packaging your code specifically for storing it here, it is best if the name of the package contains a revision number (so that many revisions can be stored) and is a gzip compressed tar file ('''.tgz''' extension) containing the code and documentation (for example file '''Sort-r1.tgz''' containing the files '''Sort-r1/Sort.scm''' and possibly '''Sort-r1/Sort.html''' and other related files).  For some reason the wiki insists on the package name starting with an upper-case letter.  The code is assumed to be in the public domain unless you add licensing information in the package itself or the documentation.&lt;br /&gt;
&lt;br /&gt;
To add a new package you must add an entry for it to this page (copy-paste an existing entry), update the file name in the &amp;lt;nowiki&amp;gt;[[media:Sort-r1.tgz|Sort-r1.tgz]]&amp;lt;/nowiki&amp;gt; link, save the page and click on the link to upload your file.  If you upload a new revision don't forget to change the revision number, and keep the link to the old revisions.&lt;br /&gt;
&lt;br /&gt;
A list of the packages and other files with statistics is available here: [[Special:Imagelist]]&lt;br /&gt;
&lt;br /&gt;
In case you find that a link to an external repository linked to from this page doesn't work anymore, please try to retrieve the latest version of the repo and upload it here, by a) contacting the author directly, b) enquiring for it on the mailing list, and/or c) trying to get it from archive.org.&lt;br /&gt;
&lt;br /&gt;
==Gambit packages==&lt;br /&gt;
These packages are in the present form created to run atop Gambit directly. They can generally easily be ported to any module system of choice.&lt;br /&gt;
===SRFI===&lt;br /&gt;
#'''SRFI-pack''': Many SRFIs ported to Gambit&lt;br /&gt;
#: Author: Guillaume Germain&lt;br /&gt;
#: Package: [[media:Srfi-pack-0.1.tar.gz|Srfi-pack-0.1.tar.gz]]&lt;br /&gt;
#: README: [[media:Srfi-pack-0.1-README.txt|Srfi-pack-0.1-README.txt]]&lt;br /&gt;
#'''SRFI-1''': SRFI-1 ported to Gambit&lt;br /&gt;
#: Author: Olin Shivers; ported by Bradley Lucier&lt;br /&gt;
#: Package [[media:Srfi1.scm|Srfi1.scm]]&lt;br /&gt;
#: Note: I did not extend map to allow list arguments of different lengths&lt;br /&gt;
&lt;br /&gt;
=== Language ===&lt;br /&gt;
# '''Gambit on LLVM''': Experimental partial back-end for Gambit using LLVM&lt;br /&gt;
#: Authors: Arnaud Bergeron and Mathieu Larose&lt;br /&gt;
#: Package: [[media:Gambit-LLVM.tgz|Gambit-LLVM.tgz]]&lt;br /&gt;
# '''Jss''': JavaScriptScheme: a multithreaded Scheme to JavaScript compiler&lt;br /&gt;
#: Author: Marc Feeley and Catherine Gaudron&lt;br /&gt;
#: Package: [[media:Jss-r2.tgz|Jss-r2.tgz]] (old: [[media:Jss-r1.tgz|Jss-r1.tgz]])&lt;br /&gt;
# '''R6RS on Gambit''':Allows R6RS programs to be run on Gambit. &lt;br /&gt;
#: Maintainer: Arthur Smyles&lt;br /&gt;
#: Package: (web page) http://smyles.com/projects/r6gambit/&lt;br /&gt;
# '''PICOBIT''': Very compact Scheme compiler and virtual machine suitable for microcontrollers.&lt;br /&gt;
#: Author: Marc Feeley and Vincent St-Amour&lt;br /&gt;
#: Package: (web page) http://repo.or.cz/w/picobit.git&lt;br /&gt;
# '''Alexpander''': A syntax-rules expander with support for DSSSL #!optional #!key and #!rest arguments.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:Alexpander-r1.tgz|Alexpander-r1.tgz]]&lt;br /&gt;
&lt;br /&gt;
===Module systems===&lt;br /&gt;
# '''Black Hole''': Module system, stable. Package handling features are in beta phase. Primary page at [[Black Hole]].&lt;br /&gt;
#: Package: (git repo) [https://github.com/pereckerdal/blackhole https://github.com/pereckerdal/blackhole]&lt;br /&gt;
#: Mirror for convenience, non-syntactictower Black Hole with bundled libs: [[media:2012-11-28-bh-non-syntactictower+bundled-libs.tar.gz|2012-11-28-bh-non-syntactictower+bundled-libs.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Object Systems===&lt;br /&gt;
# '''Oops''': Object Oriented Programming for Scheme -- Dylan/Clos-like but different&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:oops34.tgz|oops34.tgz]]&lt;br /&gt;
# '''TinyTalk''': Self-like object system with selector [Smalltalk like] dispatch.&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:gambitTT.tgz|gambitTT.tgz]]&lt;br /&gt;
# '''class.scm''': A simple CLOS-like object system written with a balance of performance, usability and runtime heap consumption. Comes bundled with a test suite which shows exemple of how the system can be used. Also can be used easily in a repl with (include &amp;quot;class.scm&amp;quot;). &lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: (web page/git repo) http://github.com/sthilaid/class/tree/master&lt;br /&gt;
# '''Meroon''': CLOS-like object system for Scheme.&lt;br /&gt;
#: Author: Christian Queinnec, now semi-maintained by Brad Lucier.  Licensed under the [http://opensource.franz.com/preamble.html Lisp Lesser General Public Licence].  Differs from CLOS in (among many other things) having single inheritance instead of multiple inheritance and a compile-time, not a run-time, MOP.  Can be compiled to be relatively fast code.  Would benefit from being reorganized in a &amp;quot;layered&amp;quot; style more appropriate for current ideas of Scheme modules.&lt;br /&gt;
#: Website: http://www.math.purdue.edu/~lucier/software/Meroon/&lt;br /&gt;
#: Package: [[media:MeroonV3-2012Jan20.tar.bz2|MeroonV3-2012Jan20.tar.bz2]]&lt;br /&gt;
&lt;br /&gt;
=== FFI ===&lt;br /&gt;
# '''ffi-related-modules''': various modules dealing with the FFI, and their dependencies (chjmodules, but someone might turn them to using bare namespaces or so; read the Readme file at the below URL)&lt;br /&gt;
#: Author: Christian Jaeger&lt;br /&gt;
#: Package: (web page/git repo) http://scheme.ch/gambit/preview/ffi-related-modules/&lt;br /&gt;
&lt;br /&gt;
===Parsing===&lt;br /&gt;
# '''SSAX-SXML''': SSAX-SXML library packaged for Gambit-C&lt;br /&gt;
#: Author: Kirill Lisovsky (updated by Dominique Boucher)&lt;br /&gt;
#: Package: (web page) [[media:ssax-sxml-gambit-20080402.tgz|ssax-sxml-gambit-20080402.tgz]]&lt;br /&gt;
# '''Mparser''': A combinatorial parser (added expression parser) (parser language rewrite)&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:Mparser-r3.tgz|Mparser-r3.tgz]] (old: [[media:Mparser-r1.tgz|Mparser-r1.tgz]], [[media:Mparser-r2.tgz|Mparser-r2.tgz]])&lt;br /&gt;
&lt;br /&gt;
===Physics===&lt;br /&gt;
#'''Ising''': Computer simulations of the Ising model of spins using the Metropolis algorithm or the Wolff algorithm.&lt;br /&gt;
#: Author: Marijn Schouten&lt;br /&gt;
#: Package: [[media:ising-20090315.scm]]&lt;br /&gt;
&lt;br /&gt;
===Compression===&lt;br /&gt;
#'''ZLib''': ZLib aka LibZ GZip compression library FFI&lt;br /&gt;
#: Author: Mikael&lt;br /&gt;
#: Package: [[media:libz.scm]]&lt;br /&gt;
&lt;br /&gt;
===Math===&lt;br /&gt;
# '''Pi''': Compute pi to arbitrary precision.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [[media:Pi-r3.tgz|Pi-r3.tgz]] (old: [[media:Pi-r2.tgz|Pi-r2.tgz]]) (old: [[media:Pi-r1.tgz|Pi-r1.tgz]])&lt;br /&gt;
# '''BLAS''': Thin wrapper for level 1, 2 and 3 BLAS linear algebra routines for the Gambit Scheme system.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/blas&lt;br /&gt;
# '''LAPACK''': Thin wrapper for higher-level linear algebra routines for the Gambit Scheme system.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/lapack&lt;br /&gt;
# '''FFTW3''': A wrapper for some FFTW3 functions for the Gambit Scheme system. (real, complex, multi-dimensional FFT functions)&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/fftw3&lt;br /&gt;
# '''Random numbers''': High-quality random number generation. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=random http://snow.iro.umontreal.ca/?viewpkg=random]&lt;br /&gt;
# '''GUROBI FFI''': This is a FFI that includes the most necessary commands for operating GUROBI from GAMBIT.&lt;br /&gt;
#: Author: Magnus Andersson&lt;br /&gt;
#: Package: [https://github.com/angelrussher/gurobi-ffi https://github.com/angelrussher/gurobi-ffi]&lt;br /&gt;
&lt;br /&gt;
===Encryption===&lt;br /&gt;
# '''AES''' Message encryption and decryption based on the AES symmetric cipher. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=aes http://snow.iro.umontreal.ca/?viewpkg=aes]&lt;br /&gt;
# '''Cert''' Management of digital certificates, message signing and verification. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=cert http://snow.iro.umontreal.ca/?viewpkg=cert]&lt;br /&gt;
# '''RSA''' Message encryption and decryption based on the RSA asymmetric cipher. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=rsa http://snow.iro.umontreal.ca/?viewpkg=rsa]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- ===Networking=== --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===SQL===&lt;br /&gt;
# '''MySQL FFI''': FFI for mysql.  Unsure about thread-safety, and needs more work&lt;br /&gt;
#: Author: Jonathan Arkell&lt;br /&gt;
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/mysql/&lt;br /&gt;
# '''MySQL''': Socket level client for mysql. Supports dynamic SQL and now prepared statements. Also includes a SQL abstraction layer. This [http://andrewwhaley.blogspot.com/2009/04/gambit-mysql-client-02.html blog post] has more information. For a more developed version w UTF8 support pls contact the ml.&lt;br /&gt;
#: Author: Andrew Whaley&lt;br /&gt;
#: Package: [[media:Gambit-mysql.zip|Gambit-mysql.zip]]&lt;br /&gt;
# '''SQLite3''': a minimalistic interface to SQLite3.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:SQLite3-r1.tgz|SQLite3-r1.tgz]]&lt;br /&gt;
# '''Postgresql''': A socket level client for Postgresql&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:Postgresql-r1.tgz|Postgresql-r1.tgz]]&lt;br /&gt;
&lt;br /&gt;
===Graphics===&lt;br /&gt;
# '''Octave''': A simple plotting interface using octave (2.x) and gnuplot.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/octave/&lt;br /&gt;
# '''Schemeray''': A simple (and as of yet, unoptimized) raytracer&lt;br /&gt;
#: Author: James Long&lt;br /&gt;
#: Package: [[media:schemeray-0.2.tgz|schemeray-0.2.tgz]]&lt;br /&gt;
# '''Opengl FFI''': A simple opengl, glu and glut ffi which supports opengl up to version 1.1.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Opengl-ffi-r1.tgz|Opengl-ffi-r1.tgz]]&lt;br /&gt;
# '''Perlin Noise''': A simple opengl demonstration of a sub-optimal 2d Perlin noise implementation.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Perlin-noise-2d-r1.tgz|Perlin-noise-2d-r1.tgz]]&lt;br /&gt;
# '''Cairo''': Bindings for cairo graphics.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:Cairo-r3.tgz|Cairo-r3.tgz]] (old: [[media:Cairo-r2.tgz|Cairo-r2.tgz]])&lt;br /&gt;
# '''GLEW''': A wrapper for GLEW which provides all OpenGL functionality through version 2.1 and manages access to vendor extensions&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:Glew.tar.gz|glew.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Audio===&lt;br /&gt;
# '''mpg123''': A wrapper for the libmpg123 mpeg decoding library&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:mpg.tar.gz|mpg.tar.gz]]&lt;br /&gt;
# '''OpenAL''': A wrapper for the OpenAL audio output library&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:openAL.tar.gz|openAL.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Networking===&lt;br /&gt;
# '''gamsock''': Full socket library compatible with Scsh's socket API.&lt;br /&gt;
#: Author: Jeffrey T. Read&lt;br /&gt;
#: Package: [[media:gamsock-r1.tar.gz|gamsock-r1.tar.gz]]&lt;br /&gt;
#: Git: https://github.com/bitwize/gamsock&lt;br /&gt;
&lt;br /&gt;
===Utilities===&lt;br /&gt;
# '''Sort''': Provides a simple sorting procedure for lists and vectors.  The mergesort algorithm is used.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [[media:Sort-r1.tgz|Sort-r1.tgz]]&lt;br /&gt;
# '''Bunny Test''': A simple unit testing framework.  &lt;br /&gt;
#: Author: Jonathan Arkell&lt;br /&gt;
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/test/&lt;br /&gt;
# '''GetOpts''': A syntactic form (let-opts) to parse command line options&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:GetOpts-r1.tgz|GetOpts-r1.tgz]]&lt;br /&gt;
# '''Etags''': Script that generates Emacs TAGS files from Scheme files, and recognizes nested definitions.&lt;br /&gt;
#: Author: Vincent St-Amour&lt;br /&gt;
#: Package: http://www-etud.iro.umontreal.ca/~stamourv/etags.scm&lt;br /&gt;
# '''Win-control''': Library for controlling Internet Explorer and other Windows applications for scripting or automating testing.&lt;br /&gt;
#: Author: Andrew Whaley&lt;br /&gt;
#: Package: http://code.google.com/p/win-control&lt;br /&gt;
# '''repltest''': Small example which embeds a remotely accessible REPL into a standalone C program.&lt;br /&gt;
#: Web: https://mercure.iro.umontreal.ca/pipermail/gambit-list/2010-June/004500.html&lt;br /&gt;
#: Package: [[media:Repltest-20100604.tgz‎|Repltest-20100604.tgz‎]]&lt;br /&gt;
# '''objc-utility-macros''': Utility macros to help wrap Objective-C methods.&lt;br /&gt;
#: Author: Jeffrey T. Read&lt;br /&gt;
#: Package: [[media:objc-utility-macros.scm‎|objc-utility-macros.scm]]&lt;br /&gt;
# '''Sort''': Richard O'Keefe's sorting procedures for lists and vectors.  Four times as fast as other sort.&lt;br /&gt;
#: Author: Richard O'Keefe&lt;br /&gt;
#: Package: [[media:Sort-okeefe.tgz|Sort-okeefe.tgz]]&lt;br /&gt;
# '''Digest''': Computation of message digests (CRC32, MD5, SHA-1, ...). Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=digest http://snow.iro.umontreal.ca/?viewpkg=digest]&lt;br /&gt;
# '''Red-black tree''' implementation, Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=rbtree http://snow.iro.umontreal.ca/?viewpkg=rbtree]&lt;br /&gt;
# '''Unicode''': Unicode handling library 1.0, does string upper-/lowercasing and case insensitive comparison with Unicode character support. Essentially completes Gambit's support for the functionality described in [http://srfi.schemers.org/srfi-75/srfi-75.html SRFI 75: Unicode].&lt;br /&gt;
#: Author: Mikael More, Florian Loitsch&lt;br /&gt;
#: Package: [[media:Unicode.tar.gz|Unicode.tar.gz]] repo: [https://github.com/m-i-k-a-e-l/gambit-unicode https://github.com/m-i-k-a-e-l/gambit-unicode]&lt;br /&gt;
# '''Glass Table''': Interactive Development Environment. A REPL that lets you save your work.&lt;br /&gt;
#: Author: Jeffrey T. Read&lt;br /&gt;
#: Repo: https://github.com/bitwize/glasstable&lt;br /&gt;
#: Package: [[media:glasstable-0.1.tar.gz|glasstable-0.1.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
=== Full Applications ===&lt;br /&gt;
# '''Space-Invaders''': Space Invaders classical arcade game remake in scheme over either glut or SDL.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Space-invaders-src-v1.0.tgz|Space-invaders-src-v1.0.tgz]]&lt;br /&gt;
# '''Web Server''': a web server with sessions cookies and server pages.&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:WebServer-r2.tgz|WebServer-r2.tgz]] (old: [[media:WebServer-r1.tgz|WebServer-r1.tgz]])&lt;br /&gt;
#: Git: http://git.berlios.de/cgi-bin/gitweb.cgi?p=futhark;a=summary&lt;br /&gt;
# '''GUI-Toy''': Simple Direct Media Layer prototype code with examples in the raw and using TinyTalk and Oops object systems.&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:GUI-Toy.tgz|GUI-Toy.tgz]]&lt;br /&gt;
# '''Intelligent WTF''': Intelligent acronym decoder based on ''wtf'' from BSD Games&lt;br /&gt;
#: Author: Joel J. Adamson &lt;br /&gt;
#: Package: (web page) http://www.unc.edu/~adamsonj/software.html&lt;br /&gt;
# '''Genetic Canvas''': A polygon-based image renderer using genetic algorithms.&lt;br /&gt;
#: Author: James Long&lt;br /&gt;
#: Web: http://jlongster.com/blog/2009/05/25/mona-lisa-genetically-drawn-scheme/&lt;br /&gt;
&lt;br /&gt;
==Gambit Black Hole packages==&lt;br /&gt;
These packages are in their present form created to run on Gambit using the Black Hole module system. They can generally easily be made to run on Gambit directly as well. For more info see [[Black Hole]].&lt;br /&gt;
===SRFI===&lt;br /&gt;
# '''SRFIs package'''&lt;br /&gt;
#: Package: (git repo) [https://github.com/pereckerdal/srfi https://github.com/pereckerdal/srfi]&lt;br /&gt;
&lt;br /&gt;
===Networking===&lt;br /&gt;
# '''Sack''': Web server and HTTP client. BH module. [https://github.com/pereckerdal/sack https://github.com/pereckerdal/sack]&lt;br /&gt;
For convenience, mirror readily set up for non-syntactictower Black Hole: [[media:2012-11-28-sack-current-for-BH-non-syntactictower.tar.gz|2012-11-28-sack-current-for-BH-non-syntactictower.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Utilities===&lt;br /&gt;
# '''Mishmash of various utils''': xml&amp;lt;-&amp;gt;sxml, pregexp, digest, base64, uuid, fifo mailbox, rbtree, exception-handling, let-optionals and more. sxpath also available. These packages will be split out to individual packages. Ask on mailing list for updates.&lt;br /&gt;
#: Package: (git repo) https://github.com/pereckerdal/std&lt;br /&gt;
&lt;br /&gt;
==Documents==&lt;br /&gt;
===Scheme books===&lt;br /&gt;
# '''An Introduction to Scheme and its Implementation''': A pretty good book on how to learn Scheme, for people with a background in general programming languages.&lt;br /&gt;
#: Author: Paul R. Wilson&lt;br /&gt;
#: Package: [[media:An_Introduction_to_Scheme_and_its_Implementation.tar.gz|An_Introduction_to_Scheme_and_its_Implementation.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
[[Category: Code]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Main_Page</id>
		<title>Main Page</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Main_Page"/>
				<updated>2013-03-12T18:07:21Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: Copyright year update&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__ __NOEDITSECTION__&lt;br /&gt;
The Gambit Scheme system is a complete, portable, efficient and reliable implementation&lt;br /&gt;
of the [[Scheme | Scheme programming language]].&lt;br /&gt;
&lt;br /&gt;
This web site is intended for users of the Gambit Scheme system.  It is a place where various&lt;br /&gt;
resources are collected and where users can exchange information related to Gambit.&lt;br /&gt;
&lt;br /&gt;
'''Download latest release (v4.6.7):'''&lt;br /&gt;
[http://www.iro.umontreal.ca/~gambit/download/gambit/v4.6/source/gambc-v4_6_7-devel.tgz Development Sources],&lt;br /&gt;
[http://www.iro.umontreal.ca/~gambit/download/gambit/v4.6/prebuilt/gambc-v4_6_7-macosx-intel32.dmg Mac OS X installer (for Intel 32)],&lt;br /&gt;
[http://itunes.apple.com/us/app/gambit-repl/id434534076?mt=8&amp;amp;ls=1 iPhone/iPod touch/iPad],&lt;br /&gt;
[http://www.iro.umontreal.ca/~gambit/download/gambit/v4.6/prebuilt/gambc-v4_6_7-windows-mingw.exe Windows installer MinGW]&lt;br /&gt;
[http://www.iro.umontreal.ca/~gambit/download/gambit/v4.6/prebuilt/gambc-v4_6_7-windows-visualc.exe VC]&lt;br /&gt;
(for other releases see the [[distributions]]). Libraries and module systems are installed separately.&lt;br /&gt;
&lt;br /&gt;
==What's Gambit?==&lt;br /&gt;
&lt;br /&gt;
Gambit consists of two main programs: '''gsi''', the Gambit Scheme interpreter, and '''gsc''', the Gambit Scheme compiler.&lt;br /&gt;
The interpreter contains the complete execution and debugging environment. The compiler is the interpreter extended with the capability of generating executable files. The compiler can produce standalone executables or compiled modules which can be loaded at run time.  Interpreted code and compiled code can be freely mixed.&lt;br /&gt;
&lt;br /&gt;
Gambit-C is a version of the Gambit programming system in which the&lt;br /&gt;
compiler generates portable C code.  The main features of Gambit-C are:&lt;br /&gt;
&lt;br /&gt;
* '''Conformance.'''  The Gambit-C system conforms to the R4RS, R5RS and IEEE Scheme standards and implements all optional features.  Tail calls and first class continuations conform to the Scheme semantics.  The full numeric tower is implemented, including: arbitrary precision integers (bignums), rationals, inexact reals (floating point numbers), and complex numbers.  Several extensions to Scheme are provided, including: lightweight threads, a foreign-function interface (FFI), and extended I/O capabilities (Unicode, networking, subprocesses, ...).&lt;br /&gt;
* '''Portability.'''  Because the system is mostly written in Scheme and the compiler generates portable C code, it is easy to port the system as well as programs compiled with it to any platform with a decent C or C++ compiler.  There is no reliance on a particular C compiler, although the system can take advantage of some '''gcc'''-specific constructs.  The C code generated is oblivious to the endianness and word size of the target environment (32 and 64 bit architectures are currently supported). There are no external library dependencies, and OS API dependencies can be removed so as to run directly on the bare metal. The system includes high-performance bignum support utilizing sophisticated algorithms, implemented in Scheme.&lt;br /&gt;
* '''Performance.'''  The compiler includes several powerful program transformations such as user procedure inlining, partial-evaluation, and lambda-lifting.  With appropriate declarations in the source code the executable programs generated by the compiler run roughly as fast as equivalent C programs.  Programs containing no declarations are also optimized without compromising the Scheme semantics by speculatively inlining predefined procedures (see the [[benchmarks]] page for a comparison with other Scheme implementations and other languages).  Thanks to an efficient implementation of continuations, the thread system is very efficient and can support millions of concurrent threads.&lt;br /&gt;
* '''Reliability.'''  Stable releases typically have very few bugs.  Bug tracking is done with [http://www.bugzilla.org/ bugzilla].  Gambit-C has been used to develop large-scale [[Real-world software and services | real-world software and services]] in academic and commercial settings.&lt;br /&gt;
&lt;br /&gt;
An overview of the Gambit system was presented by Marc Feeley at the [http://www.international-lisp-conference.org/2010/index 2010 International Lisp Conference].  The slides of the &amp;quot;Gambit Scheme: Inside Out&amp;quot; talk are [http://www.iro.umontreal.ca/~gambit/Gambit-inside-out.pdf here].&lt;br /&gt;
&lt;br /&gt;
==Getting Gambit==&lt;br /&gt;
&lt;br /&gt;
Gambit is available as prebuilt and source code [[distributions]].  There are prebuilt distributions for Mac OS X, iPhone/iPod touch/iPad (on Apple App Store), Microsoft Windows, and other operating systems.  The source code distributions must be compiled with a C or C++ compiler.  The latest sources are available in the [[Source code repository | source code repository]]. It can be accessed using&lt;br /&gt;
the [http://git.or.cz/ git] distributed version control system.&lt;br /&gt;
&lt;br /&gt;
==Documentation==&lt;br /&gt;
&lt;br /&gt;
[[Documentation]] is available.&lt;br /&gt;
&lt;br /&gt;
==Support==&lt;br /&gt;
&lt;br /&gt;
Come chat with us in the #gambit channel on [http://www.mibbit.com Freenode IRC].&lt;br /&gt;
&lt;br /&gt;
==Contributing==&lt;br /&gt;
&lt;br /&gt;
Learn [[how to contribute]] to Gambit's development.&lt;br /&gt;
&lt;br /&gt;
===Reporting bugs===&lt;br /&gt;
&lt;br /&gt;
[http://www.iro.umontreal.ca/~gambit/bugzilla/ Gambit bugzilla]&lt;br /&gt;
&lt;br /&gt;
===Source repository===&lt;br /&gt;
&lt;br /&gt;
[[Source code repository | Gambit Git repo]]&lt;br /&gt;
&lt;br /&gt;
==License==&lt;br /&gt;
&lt;br /&gt;
Gambit is Copyright &amp;amp;copy; 1994-2013 by Marc Feeley.&lt;br /&gt;
It is released under a dual LGPL and Apache 2 license. You&lt;br /&gt;
can choose whichever license you prefer:&lt;br /&gt;
&lt;br /&gt;
* [http://www.gnu.org/copyleft/lesser.html LGPL version 2.1 license]&lt;br /&gt;
* [http://www.apache.org/licenses/LICENSE-2.0.html Apache version 2.0 license]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Main_Page</id>
		<title>Main Page</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Main_Page"/>
				<updated>2013-03-12T18:06:58Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: Minor tweak to What's Gambit?&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__ __NOEDITSECTION__&lt;br /&gt;
The Gambit Scheme system is a complete, portable, efficient and reliable implementation&lt;br /&gt;
of the [[Scheme | Scheme programming language]].&lt;br /&gt;
&lt;br /&gt;
This web site is intended for users of the Gambit Scheme system.  It is a place where various&lt;br /&gt;
resources are collected and where users can exchange information related to Gambit.&lt;br /&gt;
&lt;br /&gt;
'''Download latest release (v4.6.7):'''&lt;br /&gt;
[http://www.iro.umontreal.ca/~gambit/download/gambit/v4.6/source/gambc-v4_6_7-devel.tgz Development Sources],&lt;br /&gt;
[http://www.iro.umontreal.ca/~gambit/download/gambit/v4.6/prebuilt/gambc-v4_6_7-macosx-intel32.dmg Mac OS X installer (for Intel 32)],&lt;br /&gt;
[http://itunes.apple.com/us/app/gambit-repl/id434534076?mt=8&amp;amp;ls=1 iPhone/iPod touch/iPad],&lt;br /&gt;
[http://www.iro.umontreal.ca/~gambit/download/gambit/v4.6/prebuilt/gambc-v4_6_7-windows-mingw.exe Windows installer MinGW]&lt;br /&gt;
[http://www.iro.umontreal.ca/~gambit/download/gambit/v4.6/prebuilt/gambc-v4_6_7-windows-visualc.exe VC]&lt;br /&gt;
(for other releases see the [[distributions]]). Libraries and module systems are installed separately.&lt;br /&gt;
&lt;br /&gt;
==What's Gambit?==&lt;br /&gt;
&lt;br /&gt;
Gambit consists of two main programs: '''gsi''', the Gambit Scheme interpreter, and '''gsc''', the Gambit Scheme compiler.&lt;br /&gt;
The interpreter contains the complete execution and debugging environment. The compiler is the interpreter extended with the capability of generating executable files. The compiler can produce standalone executables or compiled modules which can be loaded at run time.  Interpreted code and compiled code can be freely mixed.&lt;br /&gt;
&lt;br /&gt;
Gambit-C is a version of the Gambit programming system in which the&lt;br /&gt;
compiler generates portable C code.  The main features of Gambit-C are:&lt;br /&gt;
&lt;br /&gt;
* '''Conformance.'''  The Gambit-C system conforms to the R4RS, R5RS and IEEE Scheme standards and implements all optional features.  Tail calls and first class continuations conform to the Scheme semantics.  The full numeric tower is implemented, including: arbitrary precision integers (bignums), rationals, inexact reals (floating point numbers), and complex numbers.  Several extensions to Scheme are provided, including: lightweight threads, a foreign-function interface (FFI), and extended I/O capabilities (Unicode, networking, subprocesses, ...).&lt;br /&gt;
* '''Portability.'''  Because the system is mostly written in Scheme and the compiler generates portable C code, it is easy to port the system as well as programs compiled with it to any platform with a decent C or C++ compiler.  There is no reliance on a particular C compiler, although the system can take advantage of some '''gcc'''-specific constructs.  The C code generated is oblivious to the endianness and word size of the target environment (32 and 64 bit architectures are currently supported). There are no external library dependencies, and OS API dependencies can be removed so as to run directly on the bare metal. The system includes high-performance bignum support utilizing sophisticated algorithms, implemented in Scheme.&lt;br /&gt;
* '''Performance.'''  The compiler includes several powerful program transformations such as user procedure inlining, partial-evaluation, and lambda-lifting.  With appropriate declarations in the source code the executable programs generated by the compiler run roughly as fast as equivalent C programs.  Programs containing no declarations are also optimized without compromising the Scheme semantics by speculatively inlining predefined procedures (see the [[benchmarks]] page for a comparison with other Scheme implementations and other languages).  Thanks to an efficient implementation of continuations, the thread system is very efficient and can support millions of concurrent threads.&lt;br /&gt;
* '''Reliability.'''  Stable releases typically have very few bugs.  Bug tracking is done with [http://www.bugzilla.org/ bugzilla].  Gambit-C has been used to develop large-scale [[Real-world software and services | real-world software and services]] in academic and commercial settings.&lt;br /&gt;
&lt;br /&gt;
An overview of the Gambit system was presented by Marc Feeley at the [http://www.international-lisp-conference.org/2010/index 2010 International Lisp Conference].  The slides of the &amp;quot;Gambit Scheme: Inside Out&amp;quot; talk are [http://www.iro.umontreal.ca/~gambit/Gambit-inside-out.pdf here].&lt;br /&gt;
&lt;br /&gt;
==Getting Gambit==&lt;br /&gt;
&lt;br /&gt;
Gambit is available as prebuilt and source code [[distributions]].  There are prebuilt distributions for Mac OS X, iPhone/iPod touch/iPad (on Apple App Store), Microsoft Windows, and other operating systems.  The source code distributions must be compiled with a C or C++ compiler.  The latest sources are available in the [[Source code repository | source code repository]]. It can be accessed using&lt;br /&gt;
the [http://git.or.cz/ git] distributed version control system.&lt;br /&gt;
&lt;br /&gt;
==Documentation==&lt;br /&gt;
&lt;br /&gt;
[[Documentation]] is available.&lt;br /&gt;
&lt;br /&gt;
==Support==&lt;br /&gt;
&lt;br /&gt;
Come chat with us in the #gambit channel on [http://www.mibbit.com Freenode IRC].&lt;br /&gt;
&lt;br /&gt;
==Contributing==&lt;br /&gt;
&lt;br /&gt;
Learn [[how to contribute]] to Gambit's development.&lt;br /&gt;
&lt;br /&gt;
===Reporting bugs===&lt;br /&gt;
&lt;br /&gt;
[http://www.iro.umontreal.ca/~gambit/bugzilla/ Gambit bugzilla]&lt;br /&gt;
&lt;br /&gt;
===Source repository===&lt;br /&gt;
&lt;br /&gt;
[[Source code repository | Gambit Git repo]]&lt;br /&gt;
&lt;br /&gt;
==License==&lt;br /&gt;
&lt;br /&gt;
Gambit is Copyright &amp;amp;copy; 1994-2008 by Marc Feeley.&lt;br /&gt;
It is released under a dual LGPL and Apache 2 license. You&lt;br /&gt;
can choose whichever license you prefer:&lt;br /&gt;
&lt;br /&gt;
* [http://www.gnu.org/copyleft/lesser.html LGPL version 2.1 license]&lt;br /&gt;
* [http://www.apache.org/licenses/LICENSE-2.0.html Apache version 2.0 license]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Design_guide</id>
		<title>Design guide</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Design_guide"/>
				<updated>2013-02-03T00:53:03Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: /* The compiler */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
This document is intended to convey the understanding of Gambit that cannot be gotten from its manual, looking at its sourcecode, or reading the papers that underly its construction.&lt;br /&gt;
&lt;br /&gt;
Thus, the scope of this document is in contrast with and complementary to the manual's scope, which is to describe how Gambit is intended to be used by its user, to the sourcecode's scope, which is to describe the detail mechanics of Gambit at the highest level only, and to the papers and any other reference document, which each have a conceptually limited scope.&lt;br /&gt;
&lt;br /&gt;
The purpose of documenting this understanding of Gambit is general and multifacettated, and includes but is not limited to:&lt;br /&gt;
&lt;br /&gt;
* To convey why Gambit is a stable, working and robust software, for any uninterrupted short or long term use.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as it's reasonable that any user has a basic demand of 'getting it' about how Gambit works internally, as to be clear that the involved mechanisms are optimal and thus can be trusted to function well in any intended target environment and for any task; there indeed exists a lot of 'woo woo' technologies whose use bring with them all kinds of more or less predictable penalties, and it's of a general importance to clarify what game and league Gambit is in in this respect.)&lt;br /&gt;
&lt;br /&gt;
* To enable the user to adapt or extend Gambit himself, in the great majority of respects.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as Scheme's purpose is that of a language language, and thus it's expectable that use cases come up where customizations or extensions at any level of Gambit's architecture are needed. Most generally this would be about making Gambit work in a new operating environment, making customizations or tweaks to the io system, threads, numbers, and so on, or importantly, implementing some new or customized data type or operator.)&lt;br /&gt;
&lt;br /&gt;
* To enable the user to debug Gambit programs and Gambit itself at any level.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as while commercial or open source support may be available, it is several times key for a project to know that it is self-sustained and not dependent on contributions that are beyond its control, thus the need of making it feasible for anyone to dig into and understand Gambit internals, as to fix any unexpected behavior, in the very rare case that anything in this direction would manifest.)&lt;br /&gt;
&lt;br /&gt;
* To make digging into Gambit's sourcecode an as quick process as possible&lt;br /&gt;
&lt;br /&gt;
* To give the programmer clarity about how Gambit optimizes code / what optimizations Gambit applies / roughly what kind of machine code will be produced from a given Scheme code, and thus be able to write optimal code&lt;br /&gt;
&lt;br /&gt;
As to convey this understanding in the most effective way, it's written in the form of a conversation between the user (you) and the designer (Marc). This is as Gambit is a complex, holistic system that may possibly appear a bit nonlinear, where understanding of the involved concepts and how things fit together is of primary priority, and this is best made in the form of a conversation where for instance difference depths of detail can be used interchangably and crossreferences to other topics can be made quite liberally, rather than in the form of a monolithic final implementation reference over every involved bit and byte.&lt;br /&gt;
&lt;br /&gt;
At points the converation form between user and designer is rather to maintain a lingual clarity than a result of that it was actually a/the user or designer who wrote the respective text. The user's text is highlighted in yellow and the designer's text is in normal style.&lt;br /&gt;
&lt;br /&gt;
This document is intended to be for the current version of Gambit (this doc was started at version 4.6.8), though obviously an answer may be for a previous Gambit version and there could be the need for an update of some section, in which case you are free to correct it yourself, and to enquire for clarifications on the mailing list.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Generally though, Gambit's sources are changed extremely rarely, so this ought to be a completely minor issue.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For now this document is in one piece only, which is this document, possibly it could be split into sections if it'd turn unnavigably large.&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
In this document we mean..&lt;br /&gt;
Gambit: The entire Gambit environment, including BSy and RTL (below).&lt;br /&gt;
BSy: The base Gambit system without the RTL. This is the most bare form Gambit can easily be stripped down to and still work.&lt;br /&gt;
RTL or runtime: The runtime library; please note that we use this term only because it's a well established term in the programming world – we use it to refer to all of Gambit beyond the BSy, and this obviously includes the evaluator, compiler, threading system and so on, which are of a much higher complexity than a typical RTL.&lt;br /&gt;
Compiler: Gambit's compilation mechanism, including the Scheme to GVM compiler and all backends.&lt;br /&gt;
GVM / Gambit VM: The particular design of C/binary code generated by the Gambit compiler backend as regards code execution flow within and between modules, and in relation with certain lowlevel runtime functionality as to make the stack model and thread interrupts spin.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Also, GVM is the intermediary format that Gambit compiles Scheme code to, and which the respective compiler backend takes as input for binary generation.&amp;lt;/div&amp;gt;&lt;br /&gt;
[Thread] interrupts: Checkpoints spread across Gambit-generated code, at which stack and heap(???) overflow conditions are checked for, and switches of activity into the threading system is made, if applicable. Also the GC may be invoked here??&lt;br /&gt;
&lt;br /&gt;
==Taking it down to earth: What complexity is involved in Gambit really==&lt;br /&gt;
&lt;br /&gt;
Compared with a general programming language such as, say, C or Java, the workings of a Scheme environment may appear to the unintroduced as unclear and abstract, and thus not really something to trust (as per the way of conduct, that what you don't want to use mechanisms that you don't understand – nonsimplistic, nonoptimal or otherwise 'woo woo' mechanisms could lead to all kinds of dire penalties down the road, and thus we better get clarity about this while at the introductory step).&lt;br /&gt;
&lt;br /&gt;
Let's dig into this topic as to bring an overview-level clarity on what complexity is involved in Gambit.&lt;br /&gt;
&lt;br /&gt;
First, let's get clear about the components involved in Gambit as a system, in contrast with those of a typical general programming system:&lt;br /&gt;
&lt;br /&gt;
Both the C and Java programming systems have the following design: The essential components are the shell, compiler, loader and the execution with the runtime.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell as provided by the OS, or other functional equivalent, is the tool for invoking the compiler and loader-execution.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The compiler is a separate application that compiles language sourcecode to a binary object form. The compiler can but does not need to be implemented in the language itself.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The loader is either part of the parent operating system (which is the case in C), or an application that loads and boostraps binary code generated by the compiler (which is the case in Java). Execution is performed atop the OS, possibly atop a VM application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The runtime is a library written in the language (and possibly some code in a lower-level language i.e. assembly/C), that provides some bootstrap code for any application, and elementary procedures and type definitions that are of general use for application implementors, as not to need to reimplement elementary functionality like data type handling, and routines for interfacing common mechanisms in the underlying operating system such as console and file I/O, OS threads and networking.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell and compiler are separate binary files (with dependencies), the loader and execution possibly performed by a separate binary file (with dependencies), and the runtime library is a separate set of binary files. Compiler-generated binaries are separate binary files.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit as a holistic Scheme system has a slightly different design: (As a side note, Gambit's design in these respects is basically the same as many earlier Lisp and Scheme systems – i.e. Gambit is traditional in this respect.)&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The Scheme system [Gambit] is a separate application. It is rather typically running as a process within a host operating system, but can also run as a operating system image itself, directly on the host processor.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Gambit (the system) performs both the shell, compilation, loading and the execution step and itself contains the runtime, and the steps are performed without any need for restart or other interruption of the system. Thus, at the level of concept, Gambit as a programming system also has the characteristics of an operating system. This kind of adds to its holisticness – it's an application-level programming operating-system-environment.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;(If using the C backend, the C compiler of the host operating system is invoked by Gambit, though that's a detail – during this phase Gambit is running and actively waiting in the backround for the C compiler to finish, as to continue to the next step.) (Loading of C-backend-generated binaries is done by Gambit invoking the underlying operating system's functionality for dynamic library loading, though this is a detail too.)&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In Gambit, the compiler is implemented as part of the RTL and generally invoked as a procedure. Loading and execution are procedures too, and all of these procedures are accessed directly from the shell, called the Read-Eval-Print Loop.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The user is free to make individual executions of Gambit for each compilation or other task the user wants Gambit to perform, for instance for the task of compiling a source file to a binary file, which is how compilation is done in C and Java. The point here though is that this optional, not required.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell, compiler, loader, execution mechanism and runtime are generally all combined in one and the same binary file. (There is a version without the compiler.) Compiler-generated binaries are by default separate files, and can be merged with the compiler file thus generating a single executable binary for a compiled application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Thus, to sum this up:&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In C and Java programming systems, the compiler is a separately invoked application (possibly launched by the loader), the loader and execution are handled in a separate step, and both of these are invoked from the OS shell being another separate application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In Gambit, there is one centerpiece application namely the entire system itself, which performs the shell, compiling, loading and execution steps in one piece.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
So now we're clear about how the programming environment is set up and that this way of doing things is indeed straightforward, and the next thing for us to look at is, what kind of complexity is needed to make this spin.&lt;br /&gt;
&lt;br /&gt;
Gambit is comparable in terms of complexity, with any general garbage collected language such as Java, with its stack model being the big exception: while the general programming languages tend to have a direct style stack that is implemented directly atop the underlying C/assembly-level stack mechanism.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Due to that the additional stack handling required by these languages is zero or very small, beyond what's provided already by the OS and the assembly language, and that the concepts of OS&amp;amp;asm mechanisms are so basic in all cases, the stack is generally viewed as a noncomplex matter in these languages.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;(By direct style stack, we mean that there's procedure calls stored on a fixed-size stack, every call should conceptually be neutralized by by a procedure return as for the app not to eventually run out of stack space, and returns generally return to the stack level directly below it in the stack, or in the case of exceptions, multiple steps, until the place of the closest exception handler, or in the case of application termination, the application terminates and the entire stack is discarded.)&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Gambit is stackless. The stack functionality is performed through stack frame objects, that are linked together in a tree (or web) that's possibly cyclical. To make code in this environment execute run with an optimal speed (the as that of C code doing approx the same thing), extensive optimizations are applied to the stack handling.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;While the concepts of stacklessness and stack frame objects ought to be straightforward enough, the details of how Gambit actually performs this, may be a very complex matter, and therefore we will explore this topic in detail below.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit's threading and exception handling mechanisms are, given that the Gambit stack is already in place,  quite non-complex matters, they're essentially simple applications of use of the stack model.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The threading needs interrupt hooks at regular intervals in the application code in order to function, which the compiler sugars the code with – this is a delicate topic that we will explore further below.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit's IO model is based on an event dispatcher loop centered around a select() OS call and use interrrupt timer functionality from the host OS. While Gambit does this in a particularly elegant way, in-application central IO/event dispatcher loops have been in a quite wide use since very long – since the inception of Unix systems, say – and has been refined into simple to use API:s in libraries such as libevent and libuv.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Therefore, even while lots of effort and exactitude is required for implementing this in a way that really spins uncompromisingly, we relate to this functionality as noncomplex.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Beyond the stack model, making Scheme code execute at speeds comparable with that of C, a careful design of the compiler – including extensive, complex optimizations – and of the VM/runtime system (type and object handling etc) are required. We discuss this in more detail below.&lt;br /&gt;
&lt;br /&gt;
Thus, we can now sum up complexity in Gambit, beyond that of a general programming environment such as that of Java, as being focalized to the design of the stack handling and to how the matters of how very high performance of code execution is achieved, which are dealed with by the compiler and the tuning of the details of the VM/runtime system design.&lt;br /&gt;
&lt;br /&gt;
==The C-level anatomy of Gambit and a Gambit-based application==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When having Gambit or a Gambit-based application in sourcecode form only, what steps are required to compile it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(running the configure script – the configure script generates ./Makefile *only* or other files too? - the Makefile as for use by make without parameters just as to compile the program, essentially only invokes the C compiler and linker for the different C files in the appropriate order? C files generated out of Gambit's runtime's scheme files, required to make compilation out of C code only work. ./configure and running make on the makefile is all needed to produce the C binaries? For distributing an application implemented in Gambit, only distributing the C files generated by Gambit for the application's Scheme files, is sufficient. Thus for such an application, add to the configure script/Makefile instructions to compile also the application's bundled C files, and include those in the linking process. Any advice on how to prepare such an Gambit application from C files distribution as easily as possible, are there any examples anywhere available?)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Conceptually, what does the configure script check for and what output files does it produce?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In what order are Gambit's source files compiled and linked? This order is functionally significant right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In what areas are there differences in what C/asm code of Gambit is used, between processors and platforms?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(the select loop and files and networking, how interrupt signals are made, more?  Native bit size of values of course.)&lt;br /&gt;
==The C-level anatomy of starting Gambit or a Gambit-based application==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When Gambit or a Gambit application is started, what is approximately the code path of the initiation all way up to that Scheme code starts to execute? (roughly locations of the different functions in Gambit's C code, that are invoked) Where is the main/WinMain procedure? What OS calls are made/state for the Gambit OS process with the OS is set up, and what information is acquired from the host OS? What code is run to initialize the heap? What code is run to initialize the stack handling with its first  stack frame (perhaps this q should rather be put in the section about stack handling)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Structures==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Internally, are structures just special-type vectors?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is there any inheritance between structures, i.e. can I create a structure of type car and then make a subtype structure of type volvo? If so, how does this inheritance work – is it just that when making a volvo object, a vector is created with slots for all of a car's properties and appended to that is slots for all of volvo's properties too – how does the car property access procedures typecheck for if it's a car or a volvo?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Where in Gambit's code is the structure type handled, and what's the anotomy of this code?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==The ports/IO system==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Gambit has a variety of port types. Are the primary groupings/super-types of these, byte ports, character ports, and object ports? Is there some kind of strict inheritance between these, that each character ports is or contains a byte port too, and that every object port is or contains a character port too?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the IO/ports system and its sourcecode? At what places in Gambit's code is data sent/calls/mutations done to the OS as for Gambit to feed it with data, at what places in Gambit's code are things for Gambit to listen for events for (file handles, sockets, interrupt timeout?) inserted? How is the core IO-time scheduling done (on all platforms), is it by a select() or select()-equivalent call only, or is there any alternative return path from the OS into Gambit, during wait for timer timeout or IO input from the OS? (we discuss the reception and handling of timer interrupts separately in the section on threading.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the IO/ports system's sourcecode – which are the main procedures and code sites, approximately how does it fit together?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of a port, it's a structure with approx what properties, it has a will so it's shut down the right way when GC:ed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the code path for a |display| or |write| or |write-subu8vector| to a port, for various port types, all the way up to the end destination for the operation (the network device/OS file/target string buffer/etc).&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;At what points is the ports/IO system copying (both by function and by location in the sourcecode)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When select() has given an event for a file handle/socket, what is the code path that is invoked to propagate this event into the Scheme world?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does Gambit support select()-ing for more than 64 sockets on Windows? (this is a limit in Windows' select)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Console interaction and REPL==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Where is the sourcecode for the console interaction (incl libreadline kind of functionality) and REPL code, and what is the anatomy of this code?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What parts are in Scheme and what in C (I understand this would all better have been done in C but due to historic reasons right now some are in C)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If one would want to pipe REPL:s elsewhere than to the console, what hooks would be used? The place that spawns a REPL for uncaught exceptions, where is it so that one could direct those REPL:s to elsewhere than to the console REPL?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==The threading system==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How and where is the threading system bootstrapped? Where is the primordial thread initialized, and what makes it be the code that is actually the first to be run (except for, that at the time it's the only thread that exists)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is each thread a structure only? Roughly what properties does this structure have? How many bytes in size is this structure, on different architectures (32bit or 64bit)? Does Gambit provide any global state where threads and thread groups are stored, if so which is this structure and where is it declared, or does the caller need to keep references for them as not to GC?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How does Gambit ensure that interrupt checks are distributed in the code at such locations that smooth execution across threads is guaranteed, while the overhead for interrupt checking is kept low enough? How many % of code execution time is taken up by interrupt checks? The mechanism that puts interrupt checks in code is calibrated in such a way that there is no place in the code, no loop and so on, that is exempted from interrupt checks, in such a way that &amp;gt;1-2ms of code execution would happen without any interrupt check being made? So, (let loop ((at 0)) (if (##fx&amp;lt; at 1000000000) (loop (##fx+ at0)))) will never cause any issues with threading smoothness, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What principle is applied by Gambit when choosing what next thread to invoke? Where in Gambit's code are these therad switches made? If there's any particular complexity to the subject of making thread switches, please describe (such as, invoking the right trampolines or leaving the C/asm stack in the right condition or sth .. perhaps this is taken care of by the stack handling and that's it)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the thread switching mechanism: so first off, while not executing code but waiting for IO or timeouts from the OS, Gambit has a timer interrupt signal scheduled with the host OS (are these rescheduled all the time by Gambit, or is the OS set to recurringly make such interrupts at a certain interval forever)? Then, all Gambit-generated code is sugared all over with interrupt checks, so the interrupt signal handler procedure does something like mutating a global variable has_interrupt to true, and these interrupt checks do sth like if (has_interrupt) goto handle_interrupt or handle_interrupt(); depending on if the code is single-host or multiple-host? Then, does this handle_interrupt always check for stack overflow? What about heap overflow, or trigging a GC? How does it check if it's time to switch to another thread now? Does it do anything more? In case of switch to another thread, how is the current point of execution left in a way that maintains application/stack/etc integrity (perhaps that's a stack handling-section question)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Where/how is it configured for how long a thread should run before a switch is made to the next one? Is this a global or a per-thread configuration?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;While code can have (declare (not interrupts-enabled)) as not to accept any interrupts, the RTL is mostly compiled with interrupts enabled, so while inlined procedures such as + fall within the same interrupts-enabled setting as the code where it's used, non-inlined procedures such as assq do produce interrupts, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What's the anatomy of Gambit's threading system sourcecode, in what source files and locations are the threading system and the threading interrupts represented (I suppose the latter is in the compiler)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does the threading system schedule between threads based on the number of thread interrupts passed, or based on the amount of wall clock time passed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the dynamics of the priority, quantum and priority boost parameters to the threads, perhaps this is described completely enough in the specification document (don't remember its name or url right now)? If I want one thread to be of high priority and one of low, what parameters are needed? If I want one thread to get double or half as much CPU time as another, what parameters are needed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Beyond what has been covered above, is there any additional complexity to the threading system, or notable details not obvious from looking at its sourcecode?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Exceptions==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is the basic anatomy of the exceptions system, that first and foremost there is a |raise| procedure that takes one argument which is the exception value and which can be of any type, and, that in the dynamic environment there's a current exception handler parameter, that is a procedure, that is invoked on exception, and this is what with-exception-catcher and with-exception-handler uses to implement its functionality? So, the exception object type/-s is really a matter completely separated from the basic exception raising and catching mechanisms, and are only used as containers for conveying the content or message of each respective raised exception?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Gambit has a number of different exception types: os-exception, wrong-number-of-arguments-exception etc. etc.. Are these arranged in any kind of hierarchy? Are they all sub-structure-types of the exception type? Is there any way to get any kind of group type out of these?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Do any particular precautions need to be taken in order for a heap overflow exception to be handled 'safely', i.e. for the exception handling code not to unintendedly trig a new heap overflow exception in turn, that would terminate the program or cause otherwise unintended behavior?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Memory handling==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Beyond freedom from bugs, were any particular strategies assumed in making Gambit free of buffer overflows and memory corruption bugs? (I'm clear this might be a pointless question)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does Gambit have any quick reclaim mechanism for quickly discarding (GC:ing) objects that are not in use? Sth like, (define (a) (let ((b 1) (c 2.99999999999999) (d (make-string 1))) (+ b c)) – right at the point when a returns, is the memory for all of b, c and d immediately freed? Perhaps only b, because the compiler knew it took space only within the current stack frame and not otherwise on the heap so presuming the compiler knew to discard that stack frame quickly, it did. Does it discard c too (even while it occupies a little bit of heap space outside of the stack frame, no?) but not d, because b it knows what type it is of, but d was generated by an external procedure so quick freeing cannot be done but it will wait until the next GC?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;There is no central index of all objects on the heap, they're just allocated space for in the chunks of system memory allocated by the memory handling mechanism right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is any particular design of the heap or stacks required, for there to be support for concurrent garbage collection? (in same cpu core or multicore)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==GC (the default stop &amp;amp; copy implementation)==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Which are the variables used for determining if it's time to perform a GC, and where is the code that maintains those counters?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the anatomy of a garbage collection, including what kind of state structures are used during the process (for the markings and for keeping track of finalizers). What state does the garbage collector keep between gc:s? The state structures (for keeping track of finalizers for instance), are they such that they expand dynamically during the GC, if so are those just malloc/free:ed or is there any special design for their allocation/freeing to be as fast as possible?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the entry point for making GC iterations, the ___gc() C procedure? Does the garbage collector have more entry points than this, if so what are they used for?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How are finalizers handled? Because, I suppose, the finalizer needs to finish before the object is discarded. So, when an object with a finalizer ends up not marked by a GC process, then the GC makes a note of that object in some kind of list, and each such object has some kind of status flag that can be either of “finalizer not invoked”, “finalizer running” and “finalizer done”, and if it's “finalizer done” then the object is GC:ed,  and after each GC all entries with “finalizer not invoked”  are invoked? Please describe the possible states in here, where this state is stored, and which the state changes are and when the changes take place.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;On a GC, does Gambit always allocate memory for the target of the copy anew, and free() all allocations for the old copy at the end of GC? Or is there some keeping of memory allocations to not need to spend time on all new malloc() calls on each GC call?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Data types==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Every variable value in Scheme is represented internally as an integer, and has a tag about what fundamental data type the respective value is, right? What are the bit patterns in use for describing datatypes here? Where in Gambit's code is the basis for and use of those bit patterns implemented (as to know how to add or edit a type)? (I'm aware that fixnum is described by the two lowest bits being 0.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Whenever a variable value has a payload – some kind of object contents – a pointer to the memory address at which this payload is located, is included in every object reference on the heap for that object, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What was the motivation for using the lower bits in the variable values for the tag rather than the upper ones?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Hashtables==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;The hashtable and there used hashing algorithm, how does it work? Is there a paper anywhere that describes it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In what components/elements are hashtables stored internally (some kind of chain or tree I'd suppose, but what)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;By what reason is it that a table must not be mutated during table-for-each, what's the worstcase outcome if one mutates a table during it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is it possible to implement hashtables that fit together in a tree kind of shape, so that if I make table-set! on a parent then that one is visible to all child and grandchild etc. hashtables but not the other way around?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Numbers==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What are the rules for automatic type changes of numbers on number operations? Say, fixnum + flonum gives a flonum, that's obvious, but what about more complex cases – when are bignums generated, when are bignums scaled down to fixnums, and so on?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How are bignum structures stored internally, each such value is an object reference to a “bignum object”, and that object is a vector of integers that each contains a couple of decimals of the bignum value? With what procedures can I introspect and manipulate the element parts of a bignum value?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If one would want to change the structure format for the bignums, for instance for plugging in another bignum library, how would one go about for that?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==The compiler==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the basic anatomy of the compiler's sourcecode, and what is the basic code path that any compilation process takes? In all cases, I'm clear already there's two steps, a Scheme to GVM step, and a GVM to native code step (with the C backend or the native backend).&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the different phases that a compilation process takes (including any loops), and what form the sourcecode is stored in and what information form the compilation output is in, and what intermediary forms between sourcecode and compilation output are there and what's the purpose of those, in the different phases.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Approximately what optimizations are made by the compiler in the Scheme to GVM step and the GVM to C or native code steps respectively? (Let's define optimization as any logics that make the output code neater or faster than if that logics would not have been there, or if that logics would have been less well designed/thought through.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does the compiler look up all call/cc:s, and make a CPS conversion of all the code, during the compilation process? What is done with the CPS-converted code in order to generate the fastest or otherwise slimmest resultant code (if this is what the compiler does)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please list the academic papers and algorithm names that describe /something like/ what Gambit does during compilation.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If I wanted to implement a new primitive function that requires special (inlined) compiler output, say ##sysmem-byteref , where in the Scheme to GVM compiler's code and where in the C backend would a change need to be made, and approximately what kind of change would need to be made? &amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If I wanted to implement a new primitive conditional that requires special (inlined) compiler output, say a variant of |or| or |if| that we call |or/0| or |if/0| that treats fixnum 0 as #f, where in the Scheme to GVM compiler's code and where in the C backend would a change need to be made, and approximately what kind of change would need to be made? &amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Secondarily, I may want a first-class variant of this primitive too, for use both in compiled code and by the interpreter. What is a suitable place in Gambit's code to put a “wrapper” of the compiled version of ##sysmem-byteref to a first-class version of it, and how should that code look?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the general nature of the GVM language, and more specifically what kind of operations the GVM code language contains. Basically the GVM language describes procedures and their execution flows (stack operations, conditionals of the execution flow, jumps/invocations to procedures, trampolines?), and other than that it's invocations of primitives (+ etc)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the GVM code for a closure.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the GVM code for a conditional.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the GVM code for an invocation of a procedure with one or more arguments, and for its return.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What state structures are needed to run a GVM (within C backend)? (both for the stack and to maintain the execution state needed to handle the juggling of host functions) Please describe with some detail – what's on the C stack, what's the structure of the processor struct and stack structures and so on.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the kind of functionality/functions needed by a GVM. So for instance, it needs to have a GC. What more? Some kind of stack handling machinery including dynamic addition and removal of slots to stack frames? (I suppose the entire concept of host procedures is within the C backend's architecture only, the GVM design in itself has nothing to do with those?)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In many places, exceptions are raised from a really low level point, say that + was applied to the wrong data type and now there's a type exception. How does the GVM code look for such handling, and how is this implemented in the C backend?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Exactly, what is the extent of (declare (not interrupts-enabled)), as in, if a piece of code is compiled with this, then what Gambit forms, primitives and procedures can it call in such a way that the thread scheduler to is _guaranteed_ not to switch running thread meanwhile?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&lt;br /&gt;
==The [GVM code to] C backend and the resultant object file==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the general anatomy of the C code output. (It is clear that each C file has some kind of headers and information structures inlined as constants, that are for somehow instructing the parent Gambit process what globals or alike the object file contains, rather than just code)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the basic execution flow of the C code in an object file? Right when it's loaded by the OS, which code in it is run? What is done? To feed the parent process with globals would, I suppose, be one. It is the parent process that then invokes an initialization routine in the object file, that invokes its top level code, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;The C code seems to be a pretty hardcore example of macro use. Is there any higher level of understanding or structure in all the macros that, if understood, makes it easier to understand the macro definitions and how the macros and their use fit together? What is the anatomy of the files with macro definitions?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When the host procedore returns (which happens basically between every evaluation step in code compiled with the safe declare), to what code in Gambit's runtime does it return then, what does that code do and in what condition does it jump back into the host procedore?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the C code for a closure.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the C code for a conditional.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the C code for an invocation of a procedure with one or more arguments, and for its return.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Stack handling and related code generation aspects (including for GC traversibility, safety of stack overflows and call/cc) and trampolines==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Are stack frames the highest level of granularity that Gambit deals with stacks at, or do they have subcomponents (except for the slots for the individual contained values of course)? What about the code (define (a) (let ((b [value])) (let ((c [value])) [code1]) [code2])), what happens in the stack as code1 completes and code2 is started to be executed and c thus is disposed from the stack?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How many bytes does a stack frame occupy?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What contents does a continuation value or a continuation object value have, beyond (being) a reference to the stack frame to be executed on its invocation?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the dynamic environment and parameter values implemented? When invoking a continuation or there is a change of active thread, how is the switch of dynamic environment done?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the stack layout designed, as to be traversible by the GC? Were any particular considerations needed for this, to maintain the platform independentness of Gambit's C backend?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the stack layout designed, as to suit call/cc? What is the full mechanism of a call/cc, and what is the anatomy in site of a call/cc call, and, does it have any dependencies otherwise in the RTL?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;For the Gambit-generated native code to be safe for stack and heap overflows, it appears to me that there is basically some handling code between each step of every evaluation that involves the return of the host function. Why is this? Say that there is a processing loop, (let loop ((i 0)) (if (##fx&amp;lt; i 1000) (begin (##u8vector-set! u i (+ (u8vector-ref u i) 1) (loop (##fxnum+ i 1))))) say, why can't it just be one solid piece of code that executes through the loop just like that? What is the proof that stack overflow will never happen unless malloc fails? Within Gambit, is by stack overflow, always overflow of the C-level stack meant?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How much C stack space does a Gambit process make use of? Can it be adjusted?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Debugging==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If a lowlevel crash would happen in a Gambit program, say somewhere outside the application's object files, what are the steps you normally would take/recommend as to determine the source of the error?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Using_Gambit_with_External_Libraries</id>
		<title>Using Gambit with External Libraries</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Using_Gambit_with_External_Libraries"/>
				<updated>2013-02-03T00:50:29Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: /* Accessing Scheme vectors within a C function */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== The return strategy required by Gambit apps on Scheme-&amp;gt;C-&amp;gt;Scheme calls ==&lt;br /&gt;
How Gambit integrates the Scheme heap with the C stack is described in the section &amp;quot;19.7 Continuations and the C-interface&amp;quot; in the manual, and also in section 3 of the paper [http://www.iro.umontreal.ca/~feeley/papers/FeeleySW00.pdf A Portable Implementation of First-Class Continuations for Unrestricted Interoperaibility with C in a Multithreaded Scheme]. Here is a clarification though, which was detailed 28 march 2011 on the mailing list:&lt;br /&gt;
&lt;br /&gt;
If you have several C stack frames (produced by a Scheme-&amp;gt;C call which made a C-&amp;gt;Scheme call that made a Scheme-&amp;gt;C call in turn) at the same time, you must return them in the same sequence as you'd have needed to do ordinarily in C, i.e. from the last to the first in sequence.&lt;br /&gt;
&lt;br /&gt;
I.e., if you have the Scheme procedures A, C, E and G, and the C procedures b, d and f, and they invoke each other A -&amp;gt; b -&amp;gt; C -&amp;gt; d -&amp;gt; E -&amp;gt; f -&amp;gt; G, then you must ensure that G will return to f, f to E, E to d, d to C, C to b and b to A.&lt;br /&gt;
&lt;br /&gt;
If you return them in another order - i.e. for example G to d etc. - there will be a runtime error, which terminates the application silently.&lt;br /&gt;
&lt;br /&gt;
Note that anytime during a program's execution in the Scheme world, Gambit's thread multitasker may switch the running thread. If several threads do Scheme-&amp;gt;C-&amp;gt;Scheme calls at the same time, then in the ordinary case, thread switching may happen such that the C stack is rewinded invalidly (i.e. in another order than as described above), which at some point (not necessarily on the first invalid return) will cause the abovementioned runtime error. You can fix this by&lt;br /&gt;
* keeping all Scheme-&amp;gt;C-&amp;gt;Scheme calls in your app to one thread in total,&lt;br /&gt;
* by rewriting your code to do what you wanted to achieve through making a C-&amp;gt;Scheme call some other way instead (for instance by using advanced C programming techniques that are beyond the scope of this document),&lt;br /&gt;
* or by going with the &amp;quot;Ensuring singlethreaded behavior&amp;quot; described below.&lt;br /&gt;
&lt;br /&gt;
(Advanced note: Actually Gambit allows you to skip returning procedures, i.e. A -&amp;gt; b -&amp;gt; C -&amp;gt; d -&amp;gt; E, and then E returns directly to b, works. On the call to b, d's C stack frame is rewinded though, and returning to d would cause the abovementioned runtime error. This works because Gambit on the call to b makes a longjump that simply disposes of d's stack frame. This strategy could cause stack memory leaks though.&lt;br /&gt;
If you by any reason explore how use of this side of the FFI can be made use of, please document it here and on the mailing list.)&lt;br /&gt;
&lt;br /&gt;
== Ensuring singlethreaded behaviour ==&lt;br /&gt;
In certain situations, it's vital to ensure a single thread of execution.&lt;br /&gt;
&lt;br /&gt;
One way may be to create one thread to which you send closures containing code to be executed, and which returns the responses through a mailbox mechanism, there's an example implementation in the Gambit manual.&lt;br /&gt;
&lt;br /&gt;
Ways to get Gambit execute completely single-threaded is:&lt;br /&gt;
&lt;br /&gt;
* Use (thread-quantum-set! (current-thread) +inf.0)&lt;br /&gt;
&lt;br /&gt;
* Use (##disable-interrupts) and (##enable-interrupts) in Scheme or ___EXT(___disable_interrupts)() and ___EXT(___enable_interrupts)() from C.&lt;br /&gt;
&lt;br /&gt;
Please note that Gambit's I/O system makes use of the scheduler, and threading routines do this also, so don't do read, write, thread-sleep!, thread-yield! etc. in code you intended to execute single-threaded.&lt;br /&gt;
&lt;br /&gt;
== Export and import C symbols ==&lt;br /&gt;
Gambit's gambit.h provides helper macros for exporting functions and variables. They are  ___EXPORT_FUNC(type,name) and ___EXPORT_DATA(type,name), and are used like ___EXPORT_FUNC(int,five) () { return 5; } . Grep lib/*.c of the Gambit sources for EXP_FUNC and EXP_DATA to see examples.&lt;br /&gt;
&lt;br /&gt;
On Windows, exporting and importing functions and variables from C code may be particularly tricky. Check out the Microsoft-provided __declspec(dllexport) and __declspec(dllimport).&lt;br /&gt;
&lt;br /&gt;
== Using gsc to compile and link a dynamically loadable object file that uses external libraries ==&lt;br /&gt;
&lt;br /&gt;
Here is an example of building a dynamically loadable Gambit object file that uses [http://www.fftw.org FFTW].  This example is on Red Hat Enterprise Linux 4.2 on x86-64.&lt;br /&gt;
&lt;br /&gt;
The program uses the FFTW version 2 API, so we downloaded fftw-2.1.5.tar.gz, untarred it and configured it with&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
./configure --enable-shared --prefix=/export/users/lucier/local/fftw-2.1.5&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
You need the &amp;lt;tt&amp;gt;--enable-shared&amp;lt;/tt&amp;gt; option because shared Gambit modules must be linked to shared external libraries.  I set the &amp;lt;tt&amp;gt;--prefix&amp;lt;/tt&amp;gt; to install the final FFTW libraries and header files in my home directory.&lt;br /&gt;
&lt;br /&gt;
The file &amp;lt;tt&amp;gt;fftbasics.scm&amp;lt;/tt&amp;gt; provides the basic interface between the Scheme code and FFTW; it is as follows:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(c-declare&lt;br /&gt;
&amp;quot;&lt;br /&gt;
#include \&amp;quot;fftw.h\&amp;quot;&lt;br /&gt;
&lt;br /&gt;
fftwnd_plan p;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;)&lt;br /&gt;
&lt;br /&gt;
(define fftw2d_create_plan_backward&lt;br /&gt;
  (c-lambda ()&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;p = fftw2d_create_plan(64,&lt;br /&gt;
                                    64,&lt;br /&gt;
                                    FFTW_BACKWARD,&lt;br /&gt;
                                    FFTW_ESTIMATE | FFTW_IN_PLACE);&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&lt;br /&gt;
(define fftw2d_create_plan_forward&lt;br /&gt;
  (c-lambda ()&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;p = fftw2d_create_plan(64,&lt;br /&gt;
                                    64,&lt;br /&gt;
                                    FFTW_FORWARD,&lt;br /&gt;
                                    FFTW_ESTIMATE | FFTW_IN_PLACE);&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&lt;br /&gt;
;;; Both forward and backward ffts, depends on which way the plan was created.&lt;br /&gt;
&lt;br /&gt;
(define fftwc&lt;br /&gt;
  (c-lambda (scheme-object)&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;&lt;br /&gt;
int j; double *fp = (double *)((___WORD)___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
  fftwnd_one(p,&lt;br /&gt;
             (fftw_complex *)(fp),&lt;br /&gt;
             NULL);&lt;br /&gt;
  for (j = 0; j &amp;lt; 64 * 64 * 2; j++)&lt;br /&gt;
    fp[j] *= .015625;&lt;br /&gt;
&amp;quot;))&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
We need to pass special options to gsc to compile this file, namely&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
gsc -cc-options &amp;quot;-I/export/users/lucier/local/fftw-2.1.5/include&amp;quot; \&lt;br /&gt;
    -ld-options &amp;quot;-L/export/users/lucier/local/fftw-2.1.5/lib/ -Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/ -lfftw&amp;quot; fftbasic.scm&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
The first option (&amp;lt;tt&amp;gt;-I/export/users/lucier/local/fftw-2.1.5/include&amp;lt;/tt&amp;gt;) tells gcc where to find the header file &amp;lt;tt&amp;gt;fftw.h&amp;lt;/tt&amp;gt; at compile time.  The second option (&amp;lt;tt&amp;gt;-L/export/users/lucier/local/fftw-2.1.5/lib/&amp;lt;/tt&amp;gt;) tells the linker where to find the FFTW library (&amp;lt;tt&amp;gt;-lfftw&amp;lt;/tt&amp;gt;) at link time (i.e., when building the file &amp;lt;tt&amp;gt;fftwbasic.o1&amp;lt;/tt&amp;gt; from &amp;lt;tt&amp;gt;fftwbasic.o&amp;lt;/tt&amp;gt;), and the third option (&amp;lt;tt&amp;gt;-Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/&amp;lt;/tt&amp;gt;) tells the dynamic loader &amp;lt;tt&amp;gt;ldd&amp;lt;/tt&amp;gt; where to find the FFTW library when &amp;lt;tt&amp;gt;fftwbasic.o1&amp;lt;/tt&amp;gt; is loaded into gsc.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Aside&amp;lt;/b&amp;gt;: Note that if the headers and libraries are in a standard place known to gcc, and the location of the shared library is already in the path of the dynamic loader, then these options may not be necessary.  In many GNU/Linux systems, for examples, nearly all packages are installed in &amp;lt;tt&amp;gt;/usr/{bin,include,lib}&amp;lt;/tt&amp;gt;, and you may not need to pass these special options to gsc.&lt;br /&gt;
&lt;br /&gt;
Then we can do&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-316% gsc&lt;br /&gt;
Gambit v4.2.8&lt;br /&gt;
&lt;br /&gt;
&amp;gt; (load &amp;quot;fftbasic&amp;quot;)&lt;br /&gt;
&amp;quot;/export/users/lucier/programs/gambc-v4_2_8/test-load-options/fftbasic.o1&amp;quot;&lt;br /&gt;
&amp;gt; fftwc&lt;br /&gt;
#&amp;lt;procedure #2 fftwc&amp;gt;&lt;br /&gt;
&amp;gt;&lt;br /&gt;
*** EOF again to exit&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
We can check that &amp;lt;tt&amp;gt;fftbasic.o1&amp;lt;/tt&amp;gt; links to the right libraries:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-317% ldd fftbasic.o1&lt;br /&gt;
        libfftw.so.2 =&amp;gt; /export/users/lucier/local/fftw-2.1.5/lib/libfftw.so.2 (0x0000002a9565a000)&lt;br /&gt;
        libc.so.6 =&amp;gt; /lib64/tls/libc.so.6 (0x0000002a957aa000)&lt;br /&gt;
        libm.so.6 =&amp;gt; /lib64/tls/libm.so.6 (0x0000002a959df000)&lt;br /&gt;
        /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Finally, recall from the the [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#SEC21 Gambit manual] that anything you can do with gsc on the command line you can do with one of the gsc-specific scheme procedures &amp;lt;tt&amp;gt;compile-file&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;compile-file-to-c&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;link-incremental&amp;lt;/tt&amp;gt;, or &amp;lt;tt&amp;gt;link-flat&amp;lt;/tt&amp;gt;.  Thus, one could build &amp;lt;tt&amp;gt;fftbasic.o1&amp;lt;/tt&amp;gt; by&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-352% gsc&lt;br /&gt;
Gambit v4.2.8&lt;br /&gt;
&lt;br /&gt;
&amp;gt; (compile-file &amp;quot;fftbasic.scm&amp;quot; cc-options: &amp;quot;-I/export/users/lucier/local/fftw-2.1.5/include&amp;quot;&lt;br /&gt;
 ld-options: &amp;quot;-L/export/users/lucier/local/fftw-2.1.5/lib/ -Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/ -lfftw&amp;quot;)&lt;br /&gt;
#t&lt;br /&gt;
&amp;gt; (load &amp;quot;fftbasic&amp;quot;)&lt;br /&gt;
&amp;quot;/export/users/lucier/programs/gambc-v4_2_8/test-load-options/fftbasic.o1&amp;quot;&lt;br /&gt;
&amp;gt; fftwc&lt;br /&gt;
#&amp;lt;procedure #2 fftwc&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Accessing Scheme vectors within a C function ==&lt;br /&gt;
&lt;br /&gt;
Example. Get the pointer to the beginning of a u8vector Scheme object:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(define ffi-with-scheme-vectors&lt;br /&gt;
  (c-lambda (scheme-object int) ; scheme-object : the vector , int : the vector size&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,&amp;amp;___FETCH_U8(___BODY(___arg1),___INT(0)));&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,&amp;amp;___FETCH_U8(___arg1,0));&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,___BODY(___arg1));&lt;br /&gt;
//void *u8vectorptr = ___CAST(___U8*,___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
&lt;br /&gt;
// Of course, you can cast directly to uchar* if you plan to work with that&lt;br /&gt;
unsigned char *u8vectorptr = ___CAST(___U8*,___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
&lt;br /&gt;
/* Then here do your work with *u8vectorptr, you have its size as the ___arg2 argument */&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
(Note: There are macros also to get vector length. Note that some of the vector-related deal with vector size in bytes not elements, and that they may return the length as a Gambit fixnum so you need to run it through the ___INT macro to get it in C int format.)&lt;br /&gt;
&lt;br /&gt;
Look for examples in &amp;quot;gambit.h&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Caveat: the C compiler does not know that the GC might move objects, so the C code must be written to avoid calling the GC either directly or indirectly. Remember that the pointer is only to be kept until the next return to Scheme.&lt;br /&gt;
&lt;br /&gt;
== Practices in FFI development ==&lt;br /&gt;
(There are a couple of posts from September 2008 in the mailing list archive on this subject. Someone please cut and paste them over here.)&lt;br /&gt;
   https://mercure.iro.umontreal.ca/pipermail/gambit-list/2008-September/002572.html&lt;br /&gt;
&lt;br /&gt;
[[Category: FFI]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds</id>
		<title>Dumping Grounds</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds"/>
				<updated>2012-11-28T21:52:54Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Here you will find packages of Gambit code contributed by users.  This page is meant as a simple repository where random code snippets as well as complex systems can easily be stored so that other users can get to them.  This is not a substitute for a repository that is closely coupled with the Gambit system's module system (which is under development).  It is meant to foster the sharing of code by making it extremely easy to publish code in a publicly accessible place.  Sharing a piece of code that is incomplete, undocumented, and unreliable is better than not sharing it, because others can correct the deficiencies, learn from the code, or avoid the bugs.  Hence the name '''Dumping Grounds''' for this page.&lt;br /&gt;
&lt;br /&gt;
The code need not follow a specific structure.  It could simply be a Scheme source file (with a '''.scm''' extension).  However, if you are packaging your code specifically for storing it here, it is best if the name of the package contains a revision number (so that many revisions can be stored) and is a gzip compressed tar file ('''.tgz''' extension) containing the code and documentation (for example file '''Sort-r1.tgz''' containing the files '''Sort-r1/Sort.scm''' and possibly '''Sort-r1/Sort.html''' and other related files).  For some reason the wiki insists on the package name starting with an upper-case letter.  The code is assumed to be in the public domain unless you add licensing information in the package itself or the documentation.&lt;br /&gt;
&lt;br /&gt;
To add a new package you must add an entry for it to this page (copy-paste an existing entry), update the file name in the &amp;lt;nowiki&amp;gt;[[media:Sort-r1.tgz|Sort-r1.tgz]]&amp;lt;/nowiki&amp;gt; link, save the page and click on the link to upload your file.  If you upload a new revision don't forget to change the revision number, and keep the link to the old revisions.&lt;br /&gt;
&lt;br /&gt;
A list of the packages and other files with statistics is available here: [[Special:Imagelist]]&lt;br /&gt;
&lt;br /&gt;
In case you find that a link to an external repository linked to from this page doesn't work anymore, please try to retrieve the latest version of the repo and upload it here, by a) contacting the author directly, b) enquiring for it on the mailing list, and/or c) trying to get it from archive.org.&lt;br /&gt;
&lt;br /&gt;
==Gambit packages==&lt;br /&gt;
These packages are in the present form created to run atop Gambit directly. They can generally easily be ported to any module system of choice.&lt;br /&gt;
===SRFI===&lt;br /&gt;
#'''SRFI-pack''': Many SRFIs ported to Gambit&lt;br /&gt;
#: Author: Guillaume Germain&lt;br /&gt;
#: Package: [[media:Srfi-pack-0.1.tar.gz|Srfi-pack-0.1.tar.gz]]&lt;br /&gt;
#: README: [[media:Srfi-pack-0.1-README.txt|Srfi-pack-0.1-README.txt]]&lt;br /&gt;
#'''SRFI-1''': SRFI-1 ported to Gambit&lt;br /&gt;
#: Author: Olin Shivers; ported by Bradley Lucier&lt;br /&gt;
#: Package [[media:Srfi1.scm|Srfi1.scm]]&lt;br /&gt;
#: Note: I did not extend map to allow list arguments of different lengths&lt;br /&gt;
&lt;br /&gt;
=== Language ===&lt;br /&gt;
# '''Gambit on LLVM''': Experimental partial back-end for Gambit using LLVM&lt;br /&gt;
#: Authors: Arnaud Bergeron and Mathieu Larose&lt;br /&gt;
#: Package: [[media:Gambit-LLVM.tgz|Gambit-LLVM.tgz]]&lt;br /&gt;
# '''Jss''': JavaScriptScheme: a multithreaded Scheme to JavaScript compiler&lt;br /&gt;
#: Author: Marc Feeley and Catherine Gaudron&lt;br /&gt;
#: Package: [[media:Jss-r2.tgz|Jss-r2.tgz]] (old: [[media:Jss-r1.tgz|Jss-r1.tgz]])&lt;br /&gt;
# '''R6RS on Gambit''':Allows R6RS programs to be run on Gambit. &lt;br /&gt;
#: Maintainer: Arthur Smyles&lt;br /&gt;
#: Package: (web page) http://smyles.com/projects/r6gambit/&lt;br /&gt;
# '''PICOBIT''': Very compact Scheme compiler and virtual machine suitable for microcontrollers.&lt;br /&gt;
#: Author: Marc Feeley and Vincent St-Amour&lt;br /&gt;
#: Package: (web page) http://repo.or.cz/w/picobit.git&lt;br /&gt;
# '''Alexpander''': A syntax-rules expander with support for DSSSL #!optional #!key and #!rest arguments.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:Alexpander-r1.tgz|Alexpander-r1.tgz]]&lt;br /&gt;
&lt;br /&gt;
===Module systems===&lt;br /&gt;
# '''Black Hole''': Module system, stable. Package handling features are in beta phase. Primary page at [[Black Hole]].&lt;br /&gt;
#: Package: (git repo) [https://github.com/pereckerdal/blackhole https://github.com/pereckerdal/blackhole]&lt;br /&gt;
#: Mirror for convenience, non-syntactictower Black Hole with bundled libs: [[media:2012-11-28-bh-non-syntactictower+bundled-libs.tar.gz|2012-11-28-bh-non-syntactictower+bundled-libs.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Object Systems===&lt;br /&gt;
# '''Oops''': Object Oriented Programming for Scheme -- Dylan/Clos-like but different&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:oops34.tgz|oops34.tgz]]&lt;br /&gt;
# '''TinyTalk''': Self-like object system with selector [Smalltalk like] dispatch.&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:gambitTT.tgz|gambitTT.tgz]]&lt;br /&gt;
# '''class.scm''': A simple CLOS-like object system written with a balance of performance, usability and runtime heap consumption. Comes bundled with a test suite which shows exemple of how the system can be used. Also can be used easily in a repl with (include &amp;quot;class.scm&amp;quot;). &lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: (web page/git repo) http://github.com/sthilaid/class/tree/master&lt;br /&gt;
# '''Meroon''': CLOS-like object system for Scheme.&lt;br /&gt;
#: Author: Christian Queinnec, now semi-maintained by Brad Lucier.  Licensed under the [http://opensource.franz.com/preamble.html Lisp Lesser General Public Licence].  Differs from CLOS in (among many other things) having single inheritance instead of multiple inheritance and a compile-time, not a run-time, MOP.  Can be compiled to be relatively fast code.  Would benefit from being reorganized in a &amp;quot;layered&amp;quot; style more appropriate for current ideas of Scheme modules.&lt;br /&gt;
#: Website: http://www.math.purdue.edu/~lucier/software/Meroon/&lt;br /&gt;
#: Package: [[media:MeroonV3-2012Jan20.tar.bz2|MeroonV3-2012Jan20.tar.bz2]]&lt;br /&gt;
&lt;br /&gt;
=== FFI ===&lt;br /&gt;
# '''ffi-related-modules''': various modules dealing with the FFI, and their dependencies (chjmodules, but someone might turn them to using bare namespaces or so; read the Readme file at the below URL)&lt;br /&gt;
#: Author: Christian Jaeger&lt;br /&gt;
#: Package: (web page/git repo) http://scheme.ch/gambit/preview/ffi-related-modules/&lt;br /&gt;
&lt;br /&gt;
===Parsing===&lt;br /&gt;
# '''SSAX-SXML''': SSAX-SXML library packaged for Gambit-C&lt;br /&gt;
#: Author: Kirill Lisovsky (updated by Dominique Boucher)&lt;br /&gt;
#: Package: (web page) [[media:ssax-sxml-gambit-20080402.tgz|ssax-sxml-gambit-20080402.tgz]]&lt;br /&gt;
# '''Mparser''': A combinatorial parser (added expression parser) (parser language rewrite)&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:Mparser-r3.tgz|Mparser-r3.tgz]] (old: [[media:Mparser-r1.tgz|Mparser-r1.tgz]], [[media:Mparser-r2.tgz|Mparser-r2.tgz]])&lt;br /&gt;
&lt;br /&gt;
===Physics===&lt;br /&gt;
#'''Ising''': Computer simulations of the Ising model of spins using the Metropolis algorithm or the Wolff algorithm.&lt;br /&gt;
#: Author: Marijn Schouten&lt;br /&gt;
#: Package: [[media:ising-20090315.scm]]&lt;br /&gt;
&lt;br /&gt;
===Math===&lt;br /&gt;
# '''Pi''': Compute pi to arbitrary precision.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [[media:Pi-r3.tgz|Pi-r3.tgz]] (old: [[media:Pi-r2.tgz|Pi-r2.tgz]]) (old: [[media:Pi-r1.tgz|Pi-r1.tgz]])&lt;br /&gt;
# '''BLAS''': Thin wrapper for level 1, 2 and 3 BLAS linear algebra routines for the Gambit Scheme system.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/blas&lt;br /&gt;
# '''LAPACK''': Thin wrapper for higher-level linear algebra routines for the Gambit Scheme system.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/lapack&lt;br /&gt;
# '''FFTW3''': A wrapper for some FFTW3 functions for the Gambit Scheme system. (real, complex, multi-dimensional FFT functions)&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/fftw3&lt;br /&gt;
#: '''Random numbers''': High-quality random number generation. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=random http://snow.iro.umontreal.ca/?viewpkg=random]&lt;br /&gt;
# '''GUROBI FFI''': This is a FFI that includes the most necessary commands for operating GUROBI from GAMBIT.&lt;br /&gt;
#: Author: Magnus Andersson&lt;br /&gt;
#: Package: [https://github.com/angelrussher/gurobi-ffi https://github.com/angelrussher/gurobi-ffi]&lt;br /&gt;
&lt;br /&gt;
===Encryption===&lt;br /&gt;
# '''AES''' Message encryption and decryption based on the AES symmetric cipher. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=aes http://snow.iro.umontreal.ca/?viewpkg=aes]&lt;br /&gt;
# '''Cert''' Management of digital certificates, message signing and verification. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=cert http://snow.iro.umontreal.ca/?viewpkg=cert]&lt;br /&gt;
# '''RSA''' Message encryption and decryption based on the RSA asymmetric cipher. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=rsa http://snow.iro.umontreal.ca/?viewpkg=rsa]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- ===Networking=== --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===SQL===&lt;br /&gt;
# '''MySQL FFI''': FFI for mysql.  Unsure about thread-safety, and needs more work&lt;br /&gt;
#: Author: Jonathan Arkell&lt;br /&gt;
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/mysql/&lt;br /&gt;
# '''MySQL''': Socket level client for mysql. Supports dynamic SQL and now prepared statements. Also includes a SQL abstraction layer. This [http://andrewwhaley.blogspot.com/2009/04/gambit-mysql-client-02.html blog post] has more information. For a more developed version w UTF8 support pls contact the ml.&lt;br /&gt;
#: Author: Andrew Whaley&lt;br /&gt;
#: Package: [[media:Gambit-mysql.zip|Gambit-mysql.zip]]&lt;br /&gt;
# '''SQLite3''': a minimalistic interface to SQLite3.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:SQLite3-r1.tgz|SQLite3-r1.tgz]]&lt;br /&gt;
# '''Postgresql''': A socket level client for Postgresql&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:Postgresql-r1.tgz|Postgresql-r1.tgz]]&lt;br /&gt;
&lt;br /&gt;
===Graphics===&lt;br /&gt;
# '''Octave''': A simple plotting interface using octave (2.x) and gnuplot.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/octave/&lt;br /&gt;
# '''Schemeray''': A simple (and as of yet, unoptimized) raytracer&lt;br /&gt;
#: Author: James Long&lt;br /&gt;
#: Package: [[media:schemeray-0.2.tgz|schemeray-0.2.tgz]]&lt;br /&gt;
# '''Opengl FFI''': A simple opengl, glu and glut ffi which supports opengl up to version 1.1.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Opengl-ffi-r1.tgz|Opengl-ffi-r1.tgz]]&lt;br /&gt;
# '''Perlin Noise''': A simple opengl demonstration of a sub-optimal 2d Perlin noise implementation.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Perlin-noise-2d-r1.tgz|Perlin-noise-2d-r1.tgz]]&lt;br /&gt;
# '''Cairo''': Bindings for cairo graphics.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:Cairo-r3.tgz|Cairo-r3.tgz]] (old: [[media:Cairo-r2.tgz|Cairo-r2.tgz]])&lt;br /&gt;
# '''GLEW''': A wrapper for GLEW which provides all OpenGL functionality through version 2.1 and manages access to vendor extensions&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:Glew.tar.gz|glew.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Audio===&lt;br /&gt;
# '''mpg123''': A wrapper for the libmpg123 mpeg decoding library&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:mpg.tar.gz|mpg.tar.gz]]&lt;br /&gt;
# '''OpenAL''': A wrapper for the OpenAL audio output library&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:openAL.tar.gz|openAL.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Networking===&lt;br /&gt;
# '''gamsock''': Full socket library compatible with Scsh's socket API.&lt;br /&gt;
#: Author: Jeffrey T. Read&lt;br /&gt;
#: Package: [[media:gamsock-r1.tar.gz|gamsock-r1.tar.gz]]&lt;br /&gt;
#: Git: https://github.com/bitwize/gamsock&lt;br /&gt;
&lt;br /&gt;
===Utilities===&lt;br /&gt;
# '''Sort''': Provides a simple sorting procedure for lists and vectors.  The mergesort algorithm is used.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [[media:Sort-r1.tgz|Sort-r1.tgz]]&lt;br /&gt;
# '''Bunny Test''': A simple unit testing framework.  &lt;br /&gt;
#: Author: Jonathan Arkell&lt;br /&gt;
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/test/&lt;br /&gt;
# '''GetOpts''': A syntactic form (let-opts) to parse command line options&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:GetOpts-r1.tgz|GetOpts-r1.tgz]]&lt;br /&gt;
# '''Etags''': Script that generates Emacs TAGS files from Scheme files, and recognizes nested definitions.&lt;br /&gt;
#: Author: Vincent St-Amour&lt;br /&gt;
#: Package: http://www-etud.iro.umontreal.ca/~stamourv/etags.scm&lt;br /&gt;
# '''Win-control''': Library for controlling Internet Explorer and other Windows applications for scripting or automating testing.&lt;br /&gt;
#: Author: Andrew Whaley&lt;br /&gt;
#: Package: http://code.google.com/p/win-control&lt;br /&gt;
# '''repltest''': Small example which embeds a remotely accessible REPL into a standalone C program.&lt;br /&gt;
#: Web: https://mercure.iro.umontreal.ca/pipermail/gambit-list/2010-June/004500.html&lt;br /&gt;
#: Package: [[media:Repltest-20100604.tgz‎|Repltest-20100604.tgz‎]]&lt;br /&gt;
# '''objc-utility-macros''': Utility macros to help wrap Objective-C methods.&lt;br /&gt;
#: Author: Jeffrey T. Read&lt;br /&gt;
#: Package: [[media:objc-utility-macros.scm‎|objc-utility-macros.scm]]&lt;br /&gt;
# '''Sort''': Richard O'Keefe's sorting procedures for lists and vectors.  Four times as fast as other sort.&lt;br /&gt;
#: Author: Richard O'Keefe&lt;br /&gt;
#: Package: [[media:Sort-okeefe.tgz|Sort-okeefe.tgz]]&lt;br /&gt;
# '''Digest''': Computation of message digests (CRC32, MD5, SHA-1, ...). Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=digest http://snow.iro.umontreal.ca/?viewpkg=digest]&lt;br /&gt;
# '''Red-black tree''' implementation, Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=rbtree http://snow.iro.umontreal.ca/?viewpkg=rbtree]&lt;br /&gt;
# '''Unicode''': Unicode handling library 1.0, does string upper-/lowercasing and case insensitive comparison with Unicode character support. Essentially completes Gambit's support for the functionality described in [http://srfi.schemers.org/srfi-75/srfi-75.html SRFI 75: Unicode].&lt;br /&gt;
#: Author: Mikael More, Florian Loitsch&lt;br /&gt;
#: Package: [[media:Unicode.tar.gz|Unicode.tar.gz]] repo: [https://github.com/m-i-k-a-e-l/gambit-unicode https://github.com/m-i-k-a-e-l/gambit-unicode]&lt;br /&gt;
# '''Glass Table''': Interactive Development Environment. A REPL that lets you save your work.&lt;br /&gt;
#: Author: Jeffrey T. Read&lt;br /&gt;
#: Repo: https://github.com/bitwize/glasstable&lt;br /&gt;
#: Package: [[media:glasstable-0.1.tar.gz|glasstable-0.1.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
=== Full Applications ===&lt;br /&gt;
# '''Space-Invaders''': Space Invaders classical arcade game remake in scheme over either glut or SDL.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Space-invaders-src-v1.0.tgz|Space-invaders-src-v1.0.tgz]]&lt;br /&gt;
# '''Web Server''': a web server with sessions cookies and server pages.&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:WebServer-r2.tgz|WebServer-r2.tgz]] (old: [[media:WebServer-r1.tgz|WebServer-r1.tgz]])&lt;br /&gt;
#: Git: http://git.berlios.de/cgi-bin/gitweb.cgi?p=futhark;a=summary&lt;br /&gt;
# '''GUI-Toy''': Simple Direct Media Layer prototype code with examples in the raw and using TinyTalk and Oops object systems.&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:GUI-Toy.tgz|GUI-Toy.tgz]]&lt;br /&gt;
# '''Intelligent WTF''': Intelligent acronym decoder based on ''wtf'' from BSD Games&lt;br /&gt;
#: Author: Joel J. Adamson &lt;br /&gt;
#: Package: (web page) http://www.unc.edu/~adamsonj/software.html&lt;br /&gt;
# '''Genetic Canvas''': A polygon-based image renderer using genetic algorithms.&lt;br /&gt;
#: Author: James Long&lt;br /&gt;
#: Web: http://jlongster.com/blog/2009/05/25/mona-lisa-genetically-drawn-scheme/&lt;br /&gt;
&lt;br /&gt;
==Gambit Black Hole packages==&lt;br /&gt;
These packages are in their present form created to run on Gambit using the Black Hole module system. They can generally easily be made to run on Gambit directly as well. For more info see [[Black Hole]].&lt;br /&gt;
===SRFI===&lt;br /&gt;
# '''SRFIs package'''&lt;br /&gt;
#: Package: (git repo) [https://github.com/pereckerdal/srfi https://github.com/pereckerdal/srfi]&lt;br /&gt;
&lt;br /&gt;
===Networking===&lt;br /&gt;
# '''Sack''': Web server and HTTP client. BH module. [https://github.com/pereckerdal/sack https://github.com/pereckerdal/sack]&lt;br /&gt;
For convenience, mirror readily set up for non-syntactictower Black Hole: [[media:2012-11-28-sack-current-for-BH-non-syntactictower.tar.gz|2012-11-28-sack-current-for-BH-non-syntactictower.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Utilities===&lt;br /&gt;
# '''Mishmash of various utils''': xml&amp;lt;-&amp;gt;sxml, pregexp, digest, base64, uuid, fifo mailbox, rbtree, exception-handling, let-optionals and more. sxpath also available. These packages will be split out to individual packages. Ask on mailing list for updates.&lt;br /&gt;
#: Package: (git repo) https://github.com/pereckerdal/std&lt;br /&gt;
&lt;br /&gt;
==Documents==&lt;br /&gt;
===Scheme books===&lt;br /&gt;
# '''An Introduction to Scheme and its Implementation''': A pretty good book on how to learn Scheme, for people with a background in general programming languages.&lt;br /&gt;
#: Author: Paul R. Wilson&lt;br /&gt;
#: Package: [[media:An_Introduction_to_Scheme_and_its_Implementation.tar.gz|An_Introduction_to_Scheme_and_its_Implementation.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
[[Category: Code]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/File:2012-11-28-bh-non-syntactictower%2Bbundled-libs.tar.gz</id>
		<title>File:2012-11-28-bh-non-syntactictower+bundled-libs.tar.gz</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/File:2012-11-28-bh-non-syntactictower%2Bbundled-libs.tar.gz"/>
				<updated>2012-11-28T21:52:23Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/File:2012-11-28-sack-current-for-BH-non-syntactictower.tar.gz</id>
		<title>File:2012-11-28-sack-current-for-BH-non-syntactictower.tar.gz</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/File:2012-11-28-sack-current-for-BH-non-syntactictower.tar.gz"/>
				<updated>2012-11-28T21:49:35Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds</id>
		<title>Dumping Grounds</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds"/>
				<updated>2012-10-17T02:32:31Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Here you will find packages of Gambit code contributed by users.  This page is meant as a simple repository where random code snippets as well as complex systems can easily be stored so that other users can get to them.  This is not a substitute for a repository that is closely coupled with the Gambit system's module system (which is under development).  It is meant to foster the sharing of code by making it extremely easy to publish code in a publicly accessible place.  Sharing a piece of code that is incomplete, undocumented, and unreliable is better than not sharing it, because others can correct the deficiencies, learn from the code, or avoid the bugs.  Hence the name '''Dumping Grounds''' for this page.&lt;br /&gt;
&lt;br /&gt;
The code need not follow a specific structure.  It could simply be a Scheme source file (with a '''.scm''' extension).  However, if you are packaging your code specifically for storing it here, it is best if the name of the package contains a revision number (so that many revisions can be stored) and is a gzip compressed tar file ('''.tgz''' extension) containing the code and documentation (for example file '''Sort-r1.tgz''' containing the files '''Sort-r1/Sort.scm''' and possibly '''Sort-r1/Sort.html''' and other related files).  For some reason the wiki insists on the package name starting with an upper-case letter.  The code is assumed to be in the public domain unless you add licensing information in the package itself or the documentation.&lt;br /&gt;
&lt;br /&gt;
To add a new package you must add an entry for it to this page (copy-paste an existing entry), update the file name in the &amp;lt;nowiki&amp;gt;[[media:Sort-r1.tgz|Sort-r1.tgz]]&amp;lt;/nowiki&amp;gt; link, save the page and click on the link to upload your file.  If you upload a new revision don't forget to change the revision number, and keep the link to the old revisions.&lt;br /&gt;
&lt;br /&gt;
A list of the packages and other files with statistics is available here: [[Special:Imagelist]]&lt;br /&gt;
&lt;br /&gt;
In case you find that a link to an external repository linked to from this page doesn't work anymore, please try to retrieve the latest version of the repo and upload it here, by a) contacting the author directly, b) enquiring for it on the mailing list, and/or c) trying to get it from archive.org.&lt;br /&gt;
&lt;br /&gt;
==Gambit packages==&lt;br /&gt;
These packages are in the present form created to run atop Gambit directly. They can generally easily be ported to any module system of choice.&lt;br /&gt;
===SRFI===&lt;br /&gt;
#'''SRFI-pack''': Many SRFIs ported to Gambit&lt;br /&gt;
#: Author: Guillaume Germain&lt;br /&gt;
#: Package: [[media:Srfi-pack-0.1.tar.gz|Srfi-pack-0.1.tar.gz]]&lt;br /&gt;
#: README: [[media:Srfi-pack-0.1-README.txt|Srfi-pack-0.1-README.txt]]&lt;br /&gt;
#'''SRFI-1''': SRFI-1 ported to Gambit&lt;br /&gt;
#: Author: Olin Shivers; ported by Bradley Lucier&lt;br /&gt;
#: Package [[media:Srfi1.scm|Srfi1.scm]]&lt;br /&gt;
#: Note: I did not extend map to allow list arguments of different lengths&lt;br /&gt;
&lt;br /&gt;
=== Language ===&lt;br /&gt;
# '''Gambit on LLVM''': Experimental partial back-end for Gambit using LLVM&lt;br /&gt;
#: Authors: Arnaud Bergeron and Mathieu Larose&lt;br /&gt;
#: Package: [[media:Gambit-LLVM.tgz|Gambit-LLVM.tgz]]&lt;br /&gt;
# '''Jss''': JavaScriptScheme: a multithreaded Scheme to JavaScript compiler&lt;br /&gt;
#: Author: Marc Feeley and Catherine Gaudron&lt;br /&gt;
#: Package: [[media:Jss-r2.tgz|Jss-r2.tgz]] (old: [[media:Jss-r1.tgz|Jss-r1.tgz]])&lt;br /&gt;
# '''R6RS on Gambit''':Allows R6RS programs to be run on Gambit. &lt;br /&gt;
#: Maintainer: Arthur Smyles&lt;br /&gt;
#: Package: (web page) http://smyles.com/projects/r6gambit/&lt;br /&gt;
# '''PICOBIT''': Very compact Scheme compiler and virtual machine suitable for microcontrollers.&lt;br /&gt;
#: Author: Marc Feeley and Vincent St-Amour&lt;br /&gt;
#: Package: (web page) http://repo.or.cz/w/picobit.git&lt;br /&gt;
# '''Alexpander''': A syntax-rules expander with support for DSSSL #!optional #!key and #!rest arguments.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:Alexpander-r1.tgz|Alexpander-r1.tgz]]&lt;br /&gt;
&lt;br /&gt;
===Module systems===&lt;br /&gt;
# '''Black Hole''': Module system, stable. Package handling features are in beta phase. Primary page at [[Black Hole]].&lt;br /&gt;
#: Package: (git repo) [https://github.com/pereckerdal/blackhole https://github.com/pereckerdal/blackhole]&lt;br /&gt;
&lt;br /&gt;
===Object Systems===&lt;br /&gt;
# '''Oops''': Object Oriented Programming for Scheme -- Dylan/Clos-like but different&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:oops34.tgz|oops34.tgz]]&lt;br /&gt;
# '''TinyTalk''': Self-like object system with selector [Smalltalk like] dispatch.&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:gambitTT.tgz|gambitTT.tgz]]&lt;br /&gt;
# '''class.scm''': A simple CLOS-like object system written with a balance of performance, usability and runtime heap consumption. Comes bundled with a test suite which shows exemple of how the system can be used. Also can be used easily in a repl with (include &amp;quot;class.scm&amp;quot;). &lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: (web page/git repo) http://github.com/sthilaid/class/tree/master&lt;br /&gt;
# '''Meroon''': CLOS-like object system for Scheme.&lt;br /&gt;
#: Author: Christian Queinnec, now semi-maintained by Brad Lucier.  Licensed under the [http://opensource.franz.com/preamble.html Lisp Lesser General Public Licence].  Differs from CLOS in (among many other things) having single inheritance instead of multiple inheritance and a compile-time, not a run-time, MOP.  Can be compiled to be relatively fast code.  Would benefit from being reorganized in a &amp;quot;layered&amp;quot; style more appropriate for current ideas of Scheme modules.&lt;br /&gt;
#: Website: http://www.math.purdue.edu/~lucier/software/Meroon/&lt;br /&gt;
#: Package: [[media:MeroonV3-2012Jan20.tar.bz2|MeroonV3-2012Jan20.tar.bz2]]&lt;br /&gt;
&lt;br /&gt;
=== FFI ===&lt;br /&gt;
# '''ffi-related-modules''': various modules dealing with the FFI, and their dependencies (chjmodules, but someone might turn them to using bare namespaces or so; read the Readme file at the below URL)&lt;br /&gt;
#: Author: Christian Jaeger&lt;br /&gt;
#: Package: (web page/git repo) http://scheme.ch/gambit/preview/ffi-related-modules/&lt;br /&gt;
&lt;br /&gt;
===Parsing===&lt;br /&gt;
# '''SSAX-SXML''': SSAX-SXML library packaged for Gambit-C&lt;br /&gt;
#: Author: Kirill Lisovsky (updated by Dominique Boucher)&lt;br /&gt;
#: Package: (web page) [[media:ssax-sxml-gambit-20080402.tgz|ssax-sxml-gambit-20080402.tgz]]&lt;br /&gt;
# '''Mparser''': A combinatorial parser (added expression parser) (parser language rewrite)&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:Mparser-r3.tgz|Mparser-r3.tgz]] (old: [[media:Mparser-r1.tgz|Mparser-r1.tgz]], [[media:Mparser-r2.tgz|Mparser-r2.tgz]])&lt;br /&gt;
&lt;br /&gt;
===Physics===&lt;br /&gt;
#'''Ising''': Computer simulations of the Ising model of spins using the Metropolis algorithm or the Wolff algorithm.&lt;br /&gt;
#: Author: Marijn Schouten&lt;br /&gt;
#: Package: [[media:ising-20090315.scm]]&lt;br /&gt;
&lt;br /&gt;
===Math===&lt;br /&gt;
# '''Pi''': Compute pi to arbitrary precision.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [[media:Pi-r3.tgz|Pi-r3.tgz]] (old: [[media:Pi-r2.tgz|Pi-r2.tgz]]) (old: [[media:Pi-r1.tgz|Pi-r1.tgz]])&lt;br /&gt;
# '''BLAS''': Thin wrapper for level 1, 2 and 3 BLAS linear algebra routines for the Gambit Scheme system.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/blas&lt;br /&gt;
# '''LAPACK''': Thin wrapper for higher-level linear algebra routines for the Gambit Scheme system.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/lapack&lt;br /&gt;
# '''FFTW3''': A wrapper for some FFTW3 functions for the Gambit Scheme system. (real, complex, multi-dimensional FFT functions)&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/fftw3&lt;br /&gt;
#: '''Random numbers''': High-quality random number generation. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=random http://snow.iro.umontreal.ca/?viewpkg=random]&lt;br /&gt;
# '''GUROBI FFI''': This is a FFI that includes the most necessary commands for operating GUROBI from GAMBIT.&lt;br /&gt;
#: Author: Magnus Andersson&lt;br /&gt;
#: Package: [https://github.com/angelrussher/gurobi-ffi https://github.com/angelrussher/gurobi-ffi]&lt;br /&gt;
&lt;br /&gt;
===Encryption===&lt;br /&gt;
# '''AES''' Message encryption and decryption based on the AES symmetric cipher. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=aes http://snow.iro.umontreal.ca/?viewpkg=aes]&lt;br /&gt;
# '''Cert''' Management of digital certificates, message signing and verification. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=cert http://snow.iro.umontreal.ca/?viewpkg=cert]&lt;br /&gt;
# '''RSA''' Message encryption and decryption based on the RSA asymmetric cipher. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=rsa http://snow.iro.umontreal.ca/?viewpkg=rsa]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- ===Networking=== --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===SQL===&lt;br /&gt;
# '''MySQL FFI''': FFI for mysql.  Unsure about thread-safety, and needs more work&lt;br /&gt;
#: Author: Jonathan Arkell&lt;br /&gt;
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/mysql/&lt;br /&gt;
# '''MySQL''': Socket level client for mysql. Supports dynamic SQL and now prepared statements. Also includes a SQL abstraction layer. This [http://andrewwhaley.blogspot.com/2009/04/gambit-mysql-client-02.html blog post] has more information. For a more developed version w UTF8 support pls contact the ml.&lt;br /&gt;
#: Author: Andrew Whaley&lt;br /&gt;
#: Package: [[media:Gambit-mysql.zip|Gambit-mysql.zip]]&lt;br /&gt;
# '''SQLite3''': a minimalistic interface to SQLite3.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:SQLite3-r1.tgz|SQLite3-r1.tgz]]&lt;br /&gt;
# '''Postgresql''': A socket level client for Postgresql&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:Postgresql-r1.tgz|Postgresql-r1.tgz]]&lt;br /&gt;
&lt;br /&gt;
===Graphics===&lt;br /&gt;
# '''Octave''': A simple plotting interface using octave (2.x) and gnuplot.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/octave/&lt;br /&gt;
# '''Schemeray''': A simple (and as of yet, unoptimized) raytracer&lt;br /&gt;
#: Author: James Long&lt;br /&gt;
#: Package: [[media:schemeray-0.2.tgz|schemeray-0.2.tgz]]&lt;br /&gt;
# '''Opengl FFI''': A simple opengl, glu and glut ffi which supports opengl up to version 1.1.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Opengl-ffi-r1.tgz|Opengl-ffi-r1.tgz]]&lt;br /&gt;
# '''Perlin Noise''': A simple opengl demonstration of a sub-optimal 2d Perlin noise implementation.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Perlin-noise-2d-r1.tgz|Perlin-noise-2d-r1.tgz]]&lt;br /&gt;
# '''Cairo''': Bindings for cairo graphics.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:Cairo-r3.tgz|Cairo-r3.tgz]] (old: [[media:Cairo-r2.tgz|Cairo-r2.tgz]])&lt;br /&gt;
# '''GLEW''': A wrapper for GLEW which provides all OpenGL functionality through version 2.1 and manages access to vendor extensions&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:Glew.tar.gz|glew.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Audio===&lt;br /&gt;
# '''mpg123''': A wrapper for the libmpg123 mpeg decoding library&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:mpg.tar.gz|mpg.tar.gz]]&lt;br /&gt;
# '''OpenAL''': A wrapper for the OpenAL audio output library&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:openAL.tar.gz|openAL.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Utilities===&lt;br /&gt;
# '''Sort''': Provides a simple sorting procedure for lists and vectors.  The mergesort algorithm is used.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [[media:Sort-r1.tgz|Sort-r1.tgz]]&lt;br /&gt;
# '''Bunny Test''': A simple unit testing framework.  &lt;br /&gt;
#: Author: Jonathan Arkell&lt;br /&gt;
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/test/&lt;br /&gt;
# '''GetOpts''': A syntactic form (let-opts) to parse command line options&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:GetOpts-r1.tgz|GetOpts-r1.tgz]]&lt;br /&gt;
# '''Etags''': Script that generates Emacs TAGS files from Scheme files, and recognizes nested definitions.&lt;br /&gt;
#: Author: Vincent St-Amour&lt;br /&gt;
#: Package: http://www-etud.iro.umontreal.ca/~stamourv/etags.scm&lt;br /&gt;
# '''Win-control''': Library for controlling Internet Explorer and other Windows applications for scripting or automating testing.&lt;br /&gt;
#: Author: Andrew Whaley&lt;br /&gt;
#: Package: http://code.google.com/p/win-control&lt;br /&gt;
# '''repltest''': Small example which embeds a remotely accessible REPL into a standalone C program.&lt;br /&gt;
#: Web: https://mercure.iro.umontreal.ca/pipermail/gambit-list/2010-June/004500.html&lt;br /&gt;
#: Package: [[media:Repltest-20100604.tgz‎|Repltest-20100604.tgz‎]]&lt;br /&gt;
# '''objc-utility-macros''': Utility macros to help wrap Objective-C methods.&lt;br /&gt;
#: Author: Jeffrey T. Read&lt;br /&gt;
#: Package: [[media:objc-utility-macros.scm‎|objc-utility-macros.scm]]&lt;br /&gt;
# '''Sort''': Richard O'Keefe's sorting procedures for lists and vectors.  Four times as fast as other sort.&lt;br /&gt;
#: Author: Richard O'Keefe&lt;br /&gt;
#: Package: [[media:Sort-okeefe.tgz|Sort-okeefe.tgz]]&lt;br /&gt;
# '''Digest''': Computation of message digests (CRC32, MD5, SHA-1, ...). Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=digest http://snow.iro.umontreal.ca/?viewpkg=digest]&lt;br /&gt;
# '''Red-black tree''' implementation, Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=rbtree http://snow.iro.umontreal.ca/?viewpkg=rbtree]&lt;br /&gt;
# '''Unicode''': Unicode handling library 1.0, does string upper-/lowercasing and case insensitive comparison with Unicode character support. Essentially completes Gambit's support for the functionality described in [http://srfi.schemers.org/srfi-75/srfi-75.html SRFI 75: Unicode].&lt;br /&gt;
#: Author: Mikael More, Florian Loitsch&lt;br /&gt;
#: Package: [[media:Unicode.tar.gz|Unicode.tar.gz]] repo: [https://github.com/m-i-k-a-e-l/gambit-unicode https://github.com/m-i-k-a-e-l/gambit-unicode]&lt;br /&gt;
# '''Glass Table''': Interactive Development Environment. A REPL that lets you save your work.&lt;br /&gt;
#: Author: Jeffrey T. Read&lt;br /&gt;
#: Repo: https://github.com/bitwize/glasstable&lt;br /&gt;
#: Package: [[media:glasstable-0.1.tar.gz|glasstable-0.1.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
=== Full Applications ===&lt;br /&gt;
# '''Space-Invaders''': Space Invaders classical arcade game remake in scheme over either glut or SDL.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Space-invaders-src-v1.0.tgz|Space-invaders-src-v1.0.tgz]]&lt;br /&gt;
# '''Web Server''': a web server with sessions cookies and server pages.&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:WebServer-r2.tgz|WebServer-r2.tgz]] (old: [[media:WebServer-r1.tgz|WebServer-r1.tgz]])&lt;br /&gt;
#: Git: http://git.berlios.de/cgi-bin/gitweb.cgi?p=futhark;a=summary&lt;br /&gt;
# '''GUI-Toy''': Simple Direct Media Layer prototype code with examples in the raw and using TinyTalk and Oops object systems.&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:GUI-Toy.tgz|GUI-Toy.tgz]]&lt;br /&gt;
# '''Intelligent WTF''': Intelligent acronym decoder based on ''wtf'' from BSD Games&lt;br /&gt;
#: Author: Joel J. Adamson &lt;br /&gt;
#: Package: (web page) http://www.unc.edu/~adamsonj/software.html&lt;br /&gt;
# '''Genetic Canvas''': A polygon-based image renderer using genetic algorithms.&lt;br /&gt;
#: Author: James Long&lt;br /&gt;
#: Web: http://jlongster.com/blog/2009/05/25/mona-lisa-genetically-drawn-scheme/&lt;br /&gt;
&lt;br /&gt;
==Gambit Black Hole packages==&lt;br /&gt;
These packages are in their present form created to run on Gambit using the Black Hole module system. They can generally easily be made to run on Gambit directly as well. For more info see [[Black Hole]].&lt;br /&gt;
===SRFI===&lt;br /&gt;
# '''SRFIs package'''&lt;br /&gt;
#: Package: (git repo) [https://github.com/pereckerdal/srfi https://github.com/pereckerdal/srfi]&lt;br /&gt;
&lt;br /&gt;
===Networking===&lt;br /&gt;
# '''Sack''': Web server and HTTP client. BH module. [https://github.com/pereckerdal/sack https://github.com/pereckerdal/sack]&lt;br /&gt;
&lt;br /&gt;
===Utilities===&lt;br /&gt;
# '''Mishmash of various utils''': xml&amp;lt;-&amp;gt;sxml, pregexp, digest, base64, uuid, fifo mailbox, rbtree, exception-handling, let-optionals and more. sxpath also available. These packages will be split out to individual packages. Ask on mailing list for updates.&lt;br /&gt;
#: Package: (git repo) https://github.com/pereckerdal/std&lt;br /&gt;
&lt;br /&gt;
==Documents==&lt;br /&gt;
===Scheme books===&lt;br /&gt;
# '''An Introduction to Scheme and its Implementation''': A pretty good book on how to learn Scheme, for people with a background in general programming languages.&lt;br /&gt;
#: Author: Paul R. Wilson&lt;br /&gt;
#: Package: [[media:An_Introduction_to_Scheme_and_its_Implementation.tar.gz|An_Introduction_to_Scheme_and_its_Implementation.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
[[Category: Code]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Design_guide</id>
		<title>Design guide</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Design_guide"/>
				<updated>2012-08-15T14:27:04Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
This document is intended to convey the understanding of Gambit that cannot be gotten from its manual, looking at its sourcecode, or reading the papers that underly its construction.&lt;br /&gt;
&lt;br /&gt;
Thus, the scope of this document is in contrast with and complementary to the manual's scope, which is to describe how Gambit is intended to be used by its user, to the sourcecode's scope, which is to describe the detail mechanics of Gambit at the highest level only, and to the papers and any other reference document, which each have a conceptually limited scope.&lt;br /&gt;
&lt;br /&gt;
The purpose of documenting this understanding of Gambit is general and multifacettated, and includes but is not limited to:&lt;br /&gt;
&lt;br /&gt;
* To convey why Gambit is a stable, working and robust software, for any uninterrupted short or long term use.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as it's reasonable that any user has a basic demand of 'getting it' about how Gambit works internally, as to be clear that the involved mechanisms are optimal and thus can be trusted to function well in any intended target environment and for any task; there indeed exists a lot of 'woo woo' technologies whose use bring with them all kinds of more or less predictable penalties, and it's of a general importance to clarify what game and league Gambit is in in this respect.)&lt;br /&gt;
&lt;br /&gt;
* To enable the user to adapt or extend Gambit himself, in the great majority of respects.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as Scheme's purpose is that of a language language, and thus it's expectable that use cases come up where customizations or extensions at any level of Gambit's architecture are needed. Most generally this would be about making Gambit work in a new operating environment, making customizations or tweaks to the io system, threads, numbers, and so on, or importantly, implementing some new or customized data type or operator.)&lt;br /&gt;
&lt;br /&gt;
* To enable the user to debug Gambit programs and Gambit itself at any level.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as while commercial or open source support may be available, it is several times key for a project to know that it is self-sustained and not dependent on contributions that are beyond its control, thus the need of making it feasible for anyone to dig into and understand Gambit internals, as to fix any unexpected behavior, in the very rare case that anything in this direction would manifest.)&lt;br /&gt;
&lt;br /&gt;
* To make digging into Gambit's sourcecode an as quick process as possible&lt;br /&gt;
&lt;br /&gt;
* To give the programmer clarity about how Gambit optimizes code / what optimizations Gambit applies / roughly what kind of machine code will be produced from a given Scheme code, and thus be able to write optimal code&lt;br /&gt;
&lt;br /&gt;
As to convey this understanding in the most effective way, it's written in the form of a conversation between the user (you) and the designer (Marc). This is as Gambit is a complex, holistic system that may possibly appear a bit nonlinear, where understanding of the involved concepts and how things fit together is of primary priority, and this is best made in the form of a conversation where for instance difference depths of detail can be used interchangably and crossreferences to other topics can be made quite liberally, rather than in the form of a monolithic final implementation reference over every involved bit and byte.&lt;br /&gt;
&lt;br /&gt;
At points the converation form between user and designer is rather to maintain a lingual clarity than a result of that it was actually a/the user or designer who wrote the respective text. The user's text is highlighted in yellow and the designer's text is in normal style.&lt;br /&gt;
&lt;br /&gt;
This document is intended to be for the current version of Gambit (this doc was started at version 4.6.8), though obviously an answer may be for a previous Gambit version and there could be the need for an update of some section, in which case you are free to correct it yourself, and to enquire for clarifications on the mailing list.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Generally though, Gambit's sources are changed extremely rarely, so this ought to be a completely minor issue.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For now this document is in one piece only, which is this document, possibly it could be split into sections if it'd turn unnavigably large.&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
In this document we mean..&lt;br /&gt;
Gambit: The entire Gambit environment, including BSy and RTL (below).&lt;br /&gt;
BSy: The base Gambit system without the RTL. This is the most bare form Gambit can easily be stripped down to and still work.&lt;br /&gt;
RTL or runtime: The runtime library; please note that we use this term only because it's a well established term in the programming world – we use it to refer to all of Gambit beyond the BSy, and this obviously includes the evaluator, compiler, threading system and so on, which are of a much higher complexity than a typical RTL.&lt;br /&gt;
Compiler: Gambit's compilation mechanism, including the Scheme to GVM compiler and all backends.&lt;br /&gt;
GVM / Gambit VM: The particular design of C/binary code generated by the Gambit compiler backend as regards code execution flow within and between modules, and in relation with certain lowlevel runtime functionality as to make the stack model and thread interrupts spin.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Also, GVM is the intermediary format that Gambit compiles Scheme code to, and which the respective compiler backend takes as input for binary generation.&amp;lt;/div&amp;gt;&lt;br /&gt;
[Thread] interrupts: Checkpoints spread across Gambit-generated code, at which stack and heap(???) overflow conditions are checked for, and switches of activity into the threading system is made, if applicable. Also the GC may be invoked here??&lt;br /&gt;
&lt;br /&gt;
==Taking it down to earth: What complexity is involved in Gambit really==&lt;br /&gt;
&lt;br /&gt;
Compared with a general programming language such as, say, C or Java, the workings of a Scheme environment may appear to the unintroduced as unclear and abstract, and thus not really something to trust (as per the way of conduct, that what you don't want to use mechanisms that you don't understand – nonsimplistic, nonoptimal or otherwise 'woo woo' mechanisms could lead to all kinds of dire penalties down the road, and thus we better get clarity about this while at the introductory step).&lt;br /&gt;
&lt;br /&gt;
Let's dig into this topic as to bring an overview-level clarity on what complexity is involved in Gambit.&lt;br /&gt;
&lt;br /&gt;
First, let's get clear about the components involved in Gambit as a system, in contrast with those of a typical general programming system:&lt;br /&gt;
&lt;br /&gt;
Both the C and Java programming systems have the following design: The essential components are the shell, compiler, loader and the execution with the runtime.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell as provided by the OS, or other functional equivalent, is the tool for invoking the compiler and loader-execution.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The compiler is a separate application that compiles language sourcecode to a binary object form. The compiler can but does not need to be implemented in the language itself.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The loader is either part of the parent operating system (which is the case in C), or an application that loads and boostraps binary code generated by the compiler (which is the case in Java). Execution is performed atop the OS, possibly atop a VM application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The runtime is a library written in the language (and possibly some code in a lower-level language i.e. assembly/C), that provides some bootstrap code for any application, and elementary procedures and type definitions that are of general use for application implementors, as not to need to reimplement elementary functionality like data type handling, and routines for interfacing common mechanisms in the underlying operating system such as console and file I/O, OS threads and networking.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell and compiler are separate binary files (with dependencies), the loader and execution possibly performed by a separate binary file (with dependencies), and the runtime library is a separate set of binary files. Compiler-generated binaries are separate binary files.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit as a holistic Scheme system has a slightly different design: (As a side note, Gambit's design in these respects is basically the same as many earlier Lisp and Scheme systems – i.e. Gambit is traditional in this respect.)&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The Scheme system [Gambit] is a separate application. It is rather typically running as a process within a host operating system, but can also run as a operating system image itself, directly on the host processor.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Gambit (the system) performs both the shell, compilation, loading and the execution step and itself contains the runtime, and the steps are performed without any need for restart or other interruption of the system. Thus, at the level of concept, Gambit as a programming system also has the characteristics of an operating system. This kind of adds to its holisticness – it's an application-level programming operating-system-environment.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;(If using the C backend, the C compiler of the host operating system is invoked by Gambit, though that's a detail – during this phase Gambit is running and actively waiting in the backround for the C compiler to finish, as to continue to the next step.) (Loading of C-backend-generated binaries is done by Gambit invoking the underlying operating system's functionality for dynamic library loading, though this is a detail too.)&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In Gambit, the compiler is implemented as part of the RTL and generally invoked as a procedure. Loading and execution are procedures too, and all of these procedures are accessed directly from the shell, called the Read-Eval-Print Loop.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The user is free to make individual executions of Gambit for each compilation or other task the user wants Gambit to perform, for instance for the task of compiling a source file to a binary file, which is how compilation is done in C and Java. The point here though is that this optional, not required.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell, compiler, loader, execution mechanism and runtime are generally all combined in one and the same binary file. (There is a version without the compiler.) Compiler-generated binaries are by default separate files, and can be merged with the compiler file thus generating a single executable binary for a compiled application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Thus, to sum this up:&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In C and Java programming systems, the compiler is a separately invoked application (possibly launched by the loader), the loader and execution are handled in a separate step, and both of these are invoked from the OS shell being another separate application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In Gambit, there is one centerpiece application namely the entire system itself, which performs the shell, compiling, loading and execution steps in one piece.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
So now we're clear about how the programming environment is set up and that this way of doing things is indeed straightforward, and the next thing for us to look at is, what kind of complexity is needed to make this spin.&lt;br /&gt;
&lt;br /&gt;
Gambit is comparable in terms of complexity, with any general garbage collected language such as Java, with its stack model being the big exception: while the general programming languages tend to have a direct style stack that is implemented directly atop the underlying C/assembly-level stack mechanism.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Due to that the additional stack handling required by these languages is zero or very small, beyond what's provided already by the OS and the assembly language, and that the concepts of OS&amp;amp;asm mechanisms are so basic in all cases, the stack is generally viewed as a noncomplex matter in these languages.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;(By direct style stack, we mean that there's procedure calls stored on a fixed-size stack, every call should conceptually be neutralized by by a procedure return as for the app not to eventually run out of stack space, and returns generally return to the stack level directly below it in the stack, or in the case of exceptions, multiple steps, until the place of the closest exception handler, or in the case of application termination, the application terminates and the entire stack is discarded.)&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Gambit is stackless. The stack functionality is performed through stack frame objects, that are linked together in a tree (or web) that's possibly cyclical. To make code in this environment execute run with an optimal speed (the as that of C code doing approx the same thing), extensive optimizations are applied to the stack handling.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;While the concepts of stacklessness and stack frame objects ought to be straightforward enough, the details of how Gambit actually performs this, may be a very complex matter, and therefore we will explore this topic in detail below.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit's threading and exception handling mechanisms are, given that the Gambit stack is already in place,  quite non-complex matters, they're essentially simple applications of use of the stack model.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The threading needs interrupt hooks at regular intervals in the application code in order to function, which the compiler sugars the code with – this is a delicate topic that we will explore further below.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit's IO model is based on an event dispatcher loop centered around a select() OS call and use interrrupt timer functionality from the host OS. While Gambit does this in a particularly elegant way, in-application central IO/event dispatcher loops have been in a quite wide use since very long – since the inception of Unix systems, say – and has been refined into simple to use API:s in libraries such as libevent and libuv.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Therefore, even while lots of effort and exactitude is required for implementing this in a way that really spins uncompromisingly, we relate to this functionality as noncomplex.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Beyond the stack model, making Scheme code execute at speeds comparable with that of C, a careful design of the compiler – including extensive, complex optimizations – and of the VM/runtime system (type and object handling etc) are required. We discuss this in more detail below.&lt;br /&gt;
&lt;br /&gt;
Thus, we can now sum up complexity in Gambit, beyond that of a general programming environment such as that of Java, as being focalized to the design of the stack handling and to how the matters of how very high performance of code execution is achieved, which are dealed with by the compiler and the tuning of the details of the VM/runtime system design.&lt;br /&gt;
&lt;br /&gt;
==The C-level anatomy of Gambit and a Gambit-based application==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When having Gambit or a Gambit-based application in sourcecode form only, what steps are required to compile it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(running the configure script – the configure script generates ./Makefile *only* or other files too? - the Makefile as for use by make without parameters just as to compile the program, essentially only invokes the C compiler and linker for the different C files in the appropriate order? C files generated out of Gambit's runtime's scheme files, required to make compilation out of C code only work. ./configure and running make on the makefile is all needed to produce the C binaries? For distributing an application implemented in Gambit, only distributing the C files generated by Gambit for the application's Scheme files, is sufficient. Thus for such an application, add to the configure script/Makefile instructions to compile also the application's bundled C files, and include those in the linking process. Any advice on how to prepare such an Gambit application from C files distribution as easily as possible, are there any examples anywhere available?)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Conceptually, what does the configure script check for and what output files does it produce?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In what order are Gambit's source files compiled and linked? This order is functionally significant right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In what areas are there differences in what C/asm code of Gambit is used, between processors and platforms?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(the select loop and files and networking, how interrupt signals are made, more?  Native bit size of values of course.)&lt;br /&gt;
==The C-level anatomy of starting Gambit or a Gambit-based application==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When Gambit or a Gambit application is started, what is approximately the code path of the initiation all way up to that Scheme code starts to execute? (roughly locations of the different functions in Gambit's C code, that are invoked) Where is the main/WinMain procedure? What OS calls are made/state for the Gambit OS process with the OS is set up, and what information is acquired from the host OS? What code is run to initialize the heap? What code is run to initialize the stack handling with its first  stack frame (perhaps this q should rather be put in the section about stack handling)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Structures==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Internally, are structures just special-type vectors?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is there any inheritance between structures, i.e. can I create a structure of type car and then make a subtype structure of type volvo? If so, how does this inheritance work – is it just that when making a volvo object, a vector is created with slots for all of a car's properties and appended to that is slots for all of volvo's properties too – how does the car property access procedures typecheck for if it's a car or a volvo?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Where in Gambit's code is the structure type handled, and what's the anotomy of this code?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==The ports/IO system==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Gambit has a variety of port types. Are the primary groupings/super-types of these, byte ports, character ports, and object ports? Is there some kind of strict inheritance between these, that each character ports is or contains a byte port too, and that every object port is or contains a character port too?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the IO/ports system and its sourcecode? At what places in Gambit's code is data sent/calls/mutations done to the OS as for Gambit to feed it with data, at what places in Gambit's code are things for Gambit to listen for events for (file handles, sockets, interrupt timeout?) inserted? How is the core IO-time scheduling done (on all platforms), is it by a select() or select()-equivalent call only, or is there any alternative return path from the OS into Gambit, during wait for timer timeout or IO input from the OS? (we discuss the reception and handling of timer interrupts separately in the section on threading.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the IO/ports system's sourcecode – which are the main procedures and code sites, approximately how does it fit together?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of a port, it's a structure with approx what properties, it has a will so it's shut down the right way when GC:ed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the code path for a |display| or |write| or |write-subu8vector| to a port, for various port types, all the way up to the end destination for the operation (the network device/OS file/target string buffer/etc).&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;At what points is the ports/IO system copying (both by function and by location in the sourcecode)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When select() has given an event for a file handle/socket, what is the code path that is invoked to propagate this event into the Scheme world?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does Gambit support select()-ing for more than 64 sockets on Windows? (this is a limit in Windows' select)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Console interaction and REPL==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Where is the sourcecode for the console interaction (incl libreadline kind of functionality) and REPL code, and what is the anatomy of this code?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What parts are in Scheme and what in C (I understand this would all better have been done in C but due to historic reasons right now some are in C)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If one would want to pipe REPL:s elsewhere than to the console, what hooks would be used? The place that spawns a REPL for uncaught exceptions, where is it so that one could direct those REPL:s to elsewhere than to the console REPL?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==The threading system==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How and where is the threading system bootstrapped? Where is the primordial thread initialized, and what makes it be the code that is actually the first to be run (except for, that at the time it's the only thread that exists)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is each thread a structure only? Roughly what properties does this structure have? How many bytes in size is this structure, on different architectures (32bit or 64bit)? Does Gambit provide any global state where threads and thread groups are stored, if so which is this structure and where is it declared, or does the caller need to keep references for them as not to GC?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How does Gambit ensure that interrupt checks are distributed in the code at such locations that smooth execution across threads is guaranteed, while the overhead for interrupt checking is kept low enough? How many % of code execution time is taken up by interrupt checks? The mechanism that puts interrupt checks in code is calibrated in such a way that there is no place in the code, no loop and so on, that is exempted from interrupt checks, in such a way that &amp;gt;1-2ms of code execution would happen without any interrupt check being made? So, (let loop ((at 0)) (if (##fx&amp;lt; at 1000000000) (loop (##fx+ at0)))) will never cause any issues with threading smoothness, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What principle is applied by Gambit when choosing what next thread to invoke? Where in Gambit's code are these therad switches made? If there's any particular complexity to the subject of making thread switches, please describe (such as, invoking the right trampolines or leaving the C/asm stack in the right condition or sth .. perhaps this is taken care of by the stack handling and that's it)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the thread switching mechanism: so first off, while not executing code but waiting for IO or timeouts from the OS, Gambit has a timer interrupt signal scheduled with the host OS (are these rescheduled all the time by Gambit, or is the OS set to recurringly make such interrupts at a certain interval forever)? Then, all Gambit-generated code is sugared all over with interrupt checks, so the interrupt signal handler procedure does something like mutating a global variable has_interrupt to true, and these interrupt checks do sth like if (has_interrupt) goto handle_interrupt or handle_interrupt(); depending on if the code is single-host or multiple-host? Then, does this handle_interrupt always check for stack overflow? What about heap overflow, or trigging a GC? How does it check if it's time to switch to another thread now? Does it do anything more? In case of switch to another thread, how is the current point of execution left in a way that maintains application/stack/etc integrity (perhaps that's a stack handling-section question)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Where/how is it configured for how long a thread should run before a switch is made to the next one? Is this a global or a per-thread configuration?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;While code can have (declare (not interrupts-enabled)) as not to accept any interrupts, the RTL is mostly compiled with interrupts enabled, so while inlined procedures such as + fall within the same interrupts-enabled setting as the code where it's used, non-inlined procedures such as assq do produce interrupts, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What's the anatomy of Gambit's threading system sourcecode, in what source files and locations are the threading system and the threading interrupts represented (I suppose the latter is in the compiler)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does the threading system schedule between threads based on the number of thread interrupts passed, or based on the amount of wall clock time passed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the dynamics of the priority, quantum and priority boost parameters to the threads, perhaps this is described completely enough in the specification document (don't remember its name or url right now)? If I want one thread to be of high priority and one of low, what parameters are needed? If I want one thread to get double or half as much CPU time as another, what parameters are needed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Beyond what has been covered above, is there any additional complexity to the threading system, or notable details not obvious from looking at its sourcecode?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Exceptions==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is the basic anatomy of the exceptions system, that first and foremost there is a |raise| procedure that takes one argument which is the exception value and which can be of any type, and, that in the dynamic environment there's a current exception handler parameter, that is a procedure, that is invoked on exception, and this is what with-exception-catcher and with-exception-handler uses to implement its functionality? So, the exception object type/-s is really a matter completely separated from the basic exception raising and catching mechanisms, and are only used as containers for conveying the content or message of each respective raised exception?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Gambit has a number of different exception types: os-exception, wrong-number-of-arguments-exception etc. etc.. Are these arranged in any kind of hierarchy? Are they all sub-structure-types of the exception type? Is there any way to get any kind of group type out of these?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Do any particular precautions need to be taken in order for a heap overflow exception to be handled 'safely', i.e. for the exception handling code not to unintendedly trig a new heap overflow exception in turn, that would terminate the program or cause otherwise unintended behavior?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Memory handling==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Beyond freedom from bugs, were any particular strategies assumed in making Gambit free of buffer overflows and memory corruption bugs? (I'm clear this might be a pointless question)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does Gambit have any quick reclaim mechanism for quickly discarding (GC:ing) objects that are not in use? Sth like, (define (a) (let ((b 1) (c 2.99999999999999) (d (make-string 1))) (+ b c)) – right at the point when a returns, is the memory for all of b, c and d immediately freed? Perhaps only b, because the compiler knew it took space only within the current stack frame and not otherwise on the heap so presuming the compiler knew to discard that stack frame quickly, it did. Does it discard c too (even while it occupies a little bit of heap space outside of the stack frame, no?) but not d, because b it knows what type it is of, but d was generated by an external procedure so quick freeing cannot be done but it will wait until the next GC?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;There is no central index of all objects on the heap, they're just allocated space for in the chunks of system memory allocated by the memory handling mechanism right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is any particular design of the heap or stacks required, for there to be support for concurrent garbage collection? (in same cpu core or multicore)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==GC (the default stop &amp;amp; copy implementation)==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Which are the variables used for determining if it's time to perform a GC, and where is the code that maintains those counters?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the anatomy of a garbage collection, including what kind of state structures are used during the process (for the markings and for keeping track of finalizers). What state does the garbage collector keep between gc:s? The state structures (for keeping track of finalizers for instance), are they such that they expand dynamically during the GC, if so are those just malloc/free:ed or is there any special design for their allocation/freeing to be as fast as possible?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the entry point for making GC iterations, the ___gc() C procedure? Does the garbage collector have more entry points than this, if so what are they used for?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How are finalizers handled? Because, I suppose, the finalizer needs to finish before the object is discarded. So, when an object with a finalizer ends up not marked by a GC process, then the GC makes a note of that object in some kind of list, and each such object has some kind of status flag that can be either of “finalizer not invoked”, “finalizer running” and “finalizer done”, and if it's “finalizer done” then the object is GC:ed,  and after each GC all entries with “finalizer not invoked”  are invoked? Please describe the possible states in here, where this state is stored, and which the state changes are and when the changes take place.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;On a GC, does Gambit always allocate memory for the target of the copy anew, and free() all allocations for the old copy at the end of GC? Or is there some keeping of memory allocations to not need to spend time on all new malloc() calls on each GC call?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Data types==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Every variable value in Scheme is represented internally as an integer, and has a tag about what fundamental data type the respective value is, right? What are the bit patterns in use for describing datatypes here? Where in Gambit's code is the basis for and use of those bit patterns implemented (as to know how to add or edit a type)? (I'm aware that fixnum is described by the two lowest bits being 0.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Whenever a variable value has a payload – some kind of object contents – a pointer to the memory address at which this payload is located, is included in every object reference on the heap for that object, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What was the motivation for using the lower bits in the variable values for the tag rather than the upper ones?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Hashtables==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;The hashtable and there used hashing algorithm, how does it work? Is there a paper anywhere that describes it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In what components/elements are hashtables stored internally (some kind of chain or tree I'd suppose, but what)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;By what reason is it that a table must not be mutated during table-for-each, what's the worstcase outcome if one mutates a table during it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is it possible to implement hashtables that fit together in a tree kind of shape, so that if I make table-set! on a parent then that one is visible to all child and grandchild etc. hashtables but not the other way around?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Numbers==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What are the rules for automatic type changes of numbers on number operations? Say, fixnum + flonum gives a flonum, that's obvious, but what about more complex cases – when are bignums generated, when are bignums scaled down to fixnums, and so on?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How are bignum structures stored internally, each such value is an object reference to a “bignum object”, and that object is a vector of integers that each contains a couple of decimals of the bignum value? With what procedures can I introspect and manipulate the element parts of a bignum value?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If one would want to change the structure format for the bignums, for instance for plugging in another bignum library, how would one go about for that?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==The compiler==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the basic anatomy of the compiler's sourcecode, and what is the basic code path that any compilation process takes? In all cases, I'm clear already there's two steps, a Scheme to GVM step, and a GVM to native code step (with the C backend or the native backend).&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the different phases that a compilation process takes (including any loops), and what form the sourcecode is stored in and what information form the compilation output is in, and what intermediary forms between sourcecode and compilation output are there and what's the purpose of those, in the different phases.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Approximately what optimizations are made by the compiler in the Scheme to GVM step and the GVM to C or native code steps respectively? (Let's define optimization as any logics that make the output code neater or faster than if that logics would not have been there, or if that logics would have been less well designed/thought through.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does the compiler look up all call/cc:s, and make a CPS conversion of all the code, during the compilation process? What is done with the CPS-converted code in order to generate the fastest or otherwise slimmest resultant code (if this is what the compiler does)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please list the academic papers and algorithm names that describe /something like/ what Gambit does during compilation.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If I wanted to implement a new primitive function that requires special (inlined) compiler output, say ##sysmem-byteref , where in the Scheme to GVM compiler's code and where in the C backend would a change need to be made, and approximately what kind of change would need to be made? &amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If I wanted to implement a new primitive conditional that requires special (inlined) compiler output, say a variant of |or| or |if| that we call |or/0| or |if/0| that treats fixnum 0 as #f, where in the Scheme to GVM compiler's code and where in the C backend would a change need to be made, and approximately what kind of change would need to be made? &amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Secondarily, I may want a first-class variant of this primitive too, for use both in compiled code and by the interpreter. What is a suitable place in Gambit's code to put a “wrapper” of the compiled version of ##sysmem-byteref to a first-class version of it, and how should that code look?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the general nature of the GVM language, and more specifically what kind of operations the GVM code language contains. Basically the GVM language describes procedures and their execution flows (stack operations, conditionals of the execution flow, jumps/invocations to procedures, trampolines?), and other than that it's invocations of primitives (+ etc)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the GVM code for a closure.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the GVM code for a conditional.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the GVM code for an invocation of a procedure with one or more arguments, and for its return.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What state structures are needed to run a GVM (within C backend)? (both for the stack and to maintain the execution state needed to handle the juggling of host functions) Please describe with some detail – what's on the C stack, what's the structure of the processor struct and stack structures and so on.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the kind of functionality/functions needed by a GVM. So for instance, it needs to have a GC. What more? Some kind of stack handling machinery including dynamic addition and removal of slots to stack frames? (I suppose the entire concept of host procedures is within the C backend's architecture only, the GVM design in itself has nothing to do with those?)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In many places, exceptions are raised from a really low level point, say that + was applied to the wrong data type and now there's a type exception. How does the GVM code look for such handling, and how is this implemented in the C backend?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==The [GVM code to] C backend and the resultant object file==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the general anatomy of the C code output. (It is clear that each C file has some kind of headers and information structures inlined as constants, that are for somehow instructing the parent Gambit process what globals or alike the object file contains, rather than just code)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the basic execution flow of the C code in an object file? Right when it's loaded by the OS, which code in it is run? What is done? To feed the parent process with globals would, I suppose, be one. It is the parent process that then invokes an initialization routine in the object file, that invokes its top level code, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;The C code seems to be a pretty hardcore example of macro use. Is there any higher level of understanding or structure in all the macros that, if understood, makes it easier to understand the macro definitions and how the macros and their use fit together? What is the anatomy of the files with macro definitions?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When the host procedore returns (which happens basically between every evaluation step in code compiled with the safe declare), to what code in Gambit's runtime does it return then, what does that code do and in what condition does it jump back into the host procedore?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the C code for a closure.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the C code for a conditional.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the C code for an invocation of a procedure with one or more arguments, and for its return.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Stack handling and related code generation aspects (including for GC traversibility, safety of stack overflows and call/cc) and trampolines==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Are stack frames the highest level of granularity that Gambit deals with stacks at, or do they have subcomponents (except for the slots for the individual contained values of course)? What about the code (define (a) (let ((b [value])) (let ((c [value])) [code1]) [code2])), what happens in the stack as code1 completes and code2 is started to be executed and c thus is disposed from the stack?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How many bytes does a stack frame occupy?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What contents does a continuation value or a continuation object value have, beyond (being) a reference to the stack frame to be executed on its invocation?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the dynamic environment and parameter values implemented? When invoking a continuation or there is a change of active thread, how is the switch of dynamic environment done?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the stack layout designed, as to be traversible by the GC? Were any particular considerations needed for this, to maintain the platform independentness of Gambit's C backend?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the stack layout designed, as to suit call/cc? What is the full mechanism of a call/cc, and what is the anatomy in site of a call/cc call, and, does it have any dependencies otherwise in the RTL?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;For the Gambit-generated native code to be safe for stack and heap overflows, it appears to me that there is basically some handling code between each step of every evaluation that involves the return of the host function. Why is this? Say that there is a processing loop, (let loop ((i 0)) (if (##fx&amp;lt; i 1000) (begin (##u8vector-set! u i (+ (u8vector-ref u i) 1) (loop (##fxnum+ i 1))))) say, why can't it just be one solid piece of code that executes through the loop just like that? What is the proof that stack overflow will never happen unless malloc fails? Within Gambit, is by stack overflow, always overflow of the C-level stack meant?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How much C stack space does a Gambit process make use of? Can it be adjusted?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Debugging==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If a lowlevel crash would happen in a Gambit program, say somewhere outside the application's object files, what are the steps you normally would take/recommend as to determine the source of the error?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Design_guide</id>
		<title>Design guide</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Design_guide"/>
				<updated>2012-08-14T01:19:16Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
This document is intended to convey the understanding of Gambit that cannot be gotten from its manual, looking at its sourcecode, or reading the papers that underly its construction.&lt;br /&gt;
&lt;br /&gt;
Thus, the scope of this document is in contrast with and complementary to the manual's scope, which is to describe how Gambit is intended to be used by its user, to the sourcecode's scope, which is to describe the detail mechanics of Gambit at the highest level only, and to the papers and any other reference document, which each have a conceptually limited scope.&lt;br /&gt;
&lt;br /&gt;
The purpose of documenting this understanding of Gambit is general and multifacettated, and includes but is not limited to:&lt;br /&gt;
&lt;br /&gt;
* To convey why Gambit is a stable, working and robust software, for any uninterrupted short or long term use.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as it's reasonable that any user has a basic demand of 'getting it' about how Gambit works internally, as to be clear that the involved mechanisms are optimal and thus can be trusted to function well in any intended target environment and for any task; there indeed exists a lot of 'woo woo' technologies whose use bring with them all kinds of more or less predictable penalties, and it's of a general importance to clarify what game and league Gambit is in in this respect.)&lt;br /&gt;
&lt;br /&gt;
* To enable the user to adapt or extend Gambit himself, in the great majority of respects.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as Scheme's purpose is that of a language language, and thus it's expectable that use cases come up where customizations or extensions at any level of Gambit's architecture are needed. Most generally this would be about making Gambit work in a new operating environment, making customizations or tweaks to the io system, threads, numbers, and so on, or importantly, implementing some new or customized data type or operator.)&lt;br /&gt;
&lt;br /&gt;
* To enable the user to debug Gambit programs and Gambit itself at any level.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as while commercial or open source support may be available, it is several times key for a project to know that it is self-sustained and not dependent on contributions that are beyond its control, thus the need of making it feasible for anyone to dig into and understand Gambit internals, as to fix any unexpected behavior, in the very rare case that anything in this direction would manifest.)&lt;br /&gt;
&lt;br /&gt;
* To make digging into Gambit's sourcecode an as quick process as possible&lt;br /&gt;
&lt;br /&gt;
* To give the programmer clarity about how Gambit optimizes code / what optimizations Gambit applies / roughly what kind of machine code will be produced from a given Scheme code, and thus be able to write optimal code&lt;br /&gt;
&lt;br /&gt;
As to convey this understanding in the most effective way, it's written in the form of a conversation between the user (you) and the designer (Marc). This is as Gambit is a complex, holistic system that may possibly appear a bit nonlinear, where understanding of the involved concepts and how things fit together is of primary priority, and this is best made in the form of a conversation where for instance difference depths of detail can be used interchangably and crossreferences to other topics can be made quite liberally, rather than in the form of a monolithic final implementation reference over every involved bit and byte.&lt;br /&gt;
&lt;br /&gt;
At points the converation form between user and designer is rather to maintain a lingual clarity than a result of that it was actually a/the user or designer who wrote the respective text. The user's text is highlighted in yellow and the designer's text is in normal style.&lt;br /&gt;
&lt;br /&gt;
This document is intended to be for the current version of Gambit (this doc was started at version 4.6.8), though obviously an answer may be for a previous Gambit version and there could be the need for an update of some section, in which case you are free to correct it yourself, and to enquire for clarifications on the mailing list.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Generally though, Gambit's sources are changed extremely rarely, so this ought to be a completely minor issue.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For now this document is in one piece only, which is this document, possibly it could be split into sections if it'd turn unnavigably large.&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
In this document we mean..&lt;br /&gt;
Gambit: The entire Gambit environment, including BSy and RTL (below).&lt;br /&gt;
BSy: The base Gambit system without the RTL. This is the most bare form Gambit can easily be stripped down to and still work.&lt;br /&gt;
RTL or runtime: The runtime library; please note that we use this term only because it's a well established term in the programming world – we use it to refer to all of Gambit beyond the BSy, and this obviously includes the evaluator, compiler, threading system and so on, which are of a much higher complexity than a typical RTL.&lt;br /&gt;
Compiler: Gambit's compilation mechanism, including the Scheme to GVM compiler and all backends.&lt;br /&gt;
GVM / Gambit VM: The particular design of C/binary code generated by the Gambit compiler backend as regards code execution flow within and between modules, and in relation with certain lowlevel runtime functionality as to make the stack model and thread interrupts spin.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Also, GVM is the intermediary format that Gambit compiles Scheme code to, and which the respective compiler backend takes as input for binary generation.&amp;lt;/div&amp;gt;&lt;br /&gt;
[Thread] interrupts: Checkpoints spread across Gambit-generated code, at which stack and heap(???) overflow conditions are checked for, and switches of activity into the threading system is made, if applicable. Also the GC may be invoked here??&lt;br /&gt;
&lt;br /&gt;
==Taking it down to earth: What complexity is involved in Gambit really==&lt;br /&gt;
&lt;br /&gt;
Compared with a general programming language such as, say, C or Java, the workings of a Scheme environment may appear to the unintroduced as unclear and abstract, and thus not really something to trust (as per the way of conduct, that what you don't want to use mechanisms that you don't understand – nonsimplistic, nonoptimal or otherwise 'woo woo' mechanisms could lead to all kinds of dire penalties down the road, and thus we better get clarity about this while at the introductory step).&lt;br /&gt;
&lt;br /&gt;
Let's dig into this topic as to bring an overview-level clarity on what complexity is involved in Gambit.&lt;br /&gt;
&lt;br /&gt;
First, let's get clear about the components involved in Gambit as a system, in contrast with those of a typical general programming system:&lt;br /&gt;
&lt;br /&gt;
Both the C and Java programming systems have the following design: The essential components are the shell, compiler, loader and the execution with the runtime.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell as provided by the OS, or other functional equivalent, is the tool for invoking the compiler and loader-execution.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The compiler is a separate application that compiles language sourcecode to a binary object form. The compiler can but does not need to be implemented in the language itself.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The loader is either part of the parent operating system (which is the case in C), or an application that loads and boostraps binary code generated by the compiler (which is the case in Java). Execution is performed atop the OS, possibly atop a VM application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The runtime is a library written in the language (and possibly some code in a lower-level language i.e. assembly/C), that provides some bootstrap code for any application, and elementary procedures and type definitions that are of general use for application implementors, as not to need to reimplement elementary functionality like data type handling, and routines for interfacing common mechanisms in the underlying operating system such as console and file I/O, OS threads and networking.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell and compiler are separate binary files (with dependencies), the loader and execution possibly performed by a separate binary file (with dependencies), and the runtime library is a separate set of binary files. Compiler-generated binaries are separate binary files.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit as a holistic Scheme system has a slightly different design: (As a side note, Gambit's design in these respects is basically the same as many earlier Lisp and Scheme systems – i.e. Gambit is traditional in this respect.)&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The Scheme system [Gambit] is a separate application. It is rather typically running as a process within a host operating system, but can also run as a operating system image itself, directly on the host processor.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Gambit (the system) performs both the shell, compilation, loading and the execution step and itself contains the runtime, and the steps are performed without any need for restart or other interruption of the system. Thus, at the level of concept, Gambit as a programming system also has the characteristics of an operating system. This kind of adds to its holisticness – it's an application-level programming operating-system-environment.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;(If using the C backend, the C compiler of the host operating system is invoked by Gambit, though that's a detail – during this phase Gambit is running and actively waiting in the backround for the C compiler to finish, as to continue to the next step.) (Loading of C-backend-generated binaries is done by Gambit invoking the underlying operating system's functionality for dynamic library loading, though this is a detail too.)&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In Gambit, the compiler is implemented as part of the RTL and generally invoked as a procedure. Loading and execution are procedures too, and all of these procedures are accessed directly from the shell, called the Read-Eval-Print Loop.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The user is free to make individual executions of Gambit for each compilation or other task the user wants Gambit to perform, for instance for the task of compiling a source file to a binary file, which is how compilation is done in C and Java. The point here though is that this optional, not required.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell, compiler, loader, execution mechanism and runtime are generally all combined in one and the same binary file. (There is a version without the compiler.) Compiler-generated binaries are by default separate files, and can be merged with the compiler file thus generating a single executable binary for a compiled application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Thus, to sum this up:&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In C and Java programming systems, the compiler is a separately invoked application (possibly launched by the loader), the loader and execution are handled in a separate step, and both of these are invoked from the OS shell being another separate application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In Gambit, there is one centerpiece application namely the entire system itself, which performs the shell, compiling, loading and execution steps in one piece.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
So now we're clear about how the programming environment is set up and that this way of doing things is indeed straightforward, and the next thing for us to look at is, what kind of complexity is needed to make this spin.&lt;br /&gt;
&lt;br /&gt;
Gambit is comparable in terms of complexity, with any general garbage collected language such as Java, with its stack model being the big exception: while the general programming languages tend to have a direct style stack that is implemented directly atop the underlying C/assembly-level stack mechanism.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Due to that the additional stack handling required by these languages is zero or very small, beyond what's provided already by the OS and the assembly language, and that the concepts of OS&amp;amp;asm mechanisms are so basic in all cases, the stack is generally viewed as a noncomplex matter in these languages.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;(By direct style stack, we mean that there's procedure calls stored on a fixed-size stack, every call should conceptually be neutralized by by a procedure return as for the app not to eventually run out of stack space, and returns generally return to the stack level directly below it in the stack, or in the case of exceptions, multiple steps, until the place of the closest exception handler, or in the case of application termination, the application terminates and the entire stack is discarded.)&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Gambit is stackless. The stack functionality is performed through stack frame objects, that are linked together in a tree (or web) that's possibly cyclical. To make code in this environment execute run with an optimal speed (the as that of C code doing approx the same thing), extensive optimizations are applied to the stack handling.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;While the concepts of stacklessness and stack frame objects ought to be straightforward enough, the details of how Gambit actually performs this, may be a very complex matter, and therefore we will explore this topic in detail below.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit's threading and exception handling mechanisms are, given that the Gambit stack is already in place,  quite non-complex matters, they're essentially simple applications of use of the stack model.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The threading needs interrupt hooks at regular intervals in the application code in order to function, which the compiler sugars the code with – this is a delicate topic that we will explore further below.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit's IO model is based on an event dispatcher loop centered around a select() OS call and use interrrupt timer functionality from the host OS. While Gambit does this in a particularly elegant way, in-application central IO/event dispatcher loops have been in a quite wide use since very long – since the inception of Unix systems, say – and has been refined into simple to use API:s in libraries such as libevent and libuv.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Therefore, even while lots of effort and exactitude is required for implementing this in a way that really spins uncompromisingly, we relate to this functionality as noncomplex.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Beyond the stack model, making Scheme code execute at speeds comparable with that of C, a careful design of the compiler – including extensive, complex optimizations – and of the VM/runtime system (type and object handling etc) are required. We discuss this in more detail below.&lt;br /&gt;
&lt;br /&gt;
Thus, we can now sum up complexity in Gambit, beyond that of a general programming environment such as that of Java, as being focalized to the design of the stack handling and to how the matters of how very high performance of code execution is achieved, which are dealed with by the compiler and the tuning of the details of the VM/runtime system design.&lt;br /&gt;
&lt;br /&gt;
==The C-level anatomy of Gambit and a Gambit-based application==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When having Gambit or a Gambit-based application in sourcecode form only, what steps are required to compile it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(running the configure script – the configure script generates ./Makefile *only* or other files too? - the Makefile as for use by make without parameters just as to compile the program, essentially only invokes the C compiler and linker for the different C files in the appropriate order? C files generated out of Gambit's runtime's scheme files, required to make compilation out of C code only work. ./configure and running make on the makefile is all needed to produce the C binaries? For distributing an application implemented in Gambit, only distributing the C files generated by Gambit for the application's Scheme files, is sufficient. Thus for such an application, add to the configure script/Makefile instructions to compile also the application's bundled C files, and include those in the linking process. Any advice on how to prepare such an Gambit application from C files distribution as easily as possible, are there any examples anywhere available?)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Conceptually, what does the configure script check for and what output files does it produce?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In what areas are there differences in what C/asm code of Gambit is used, between processors and platforms?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(the select loop and files and networking, how interrupt signals are made, more?  Native bit size of values of course.)&lt;br /&gt;
==The C-level anatomy of starting Gambit or a Gambit-based application==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When Gambit or a Gambit application is started, what is approximately the code flow of the initiation all way up to that Scheme code starts to execute? (roughly locations of the different functions in Gambit's C code, that are invoked) What OS calls are made/state for the Gambit OS process with the OS is set up, and what information is acquired from the host OS? What code is run to initialize the heap? What code is run to initialize the stack handling with its first  stack frame (perhaps this q should rather be put in the section about stack handling)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Structures==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Internally, are structures just special-type vectors?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is there any inheritance between structures, i.e. can I create a structure of type car and then make a subtype structure of type volvo? If so, how does this inheritance work – is it just that when making a volvo object, a vector is created with slots for all of a car's properties and appended to that is slots for all of volvo's properties too – how does the car property access procedures typecheck for if it's a car or a volvo?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Where in Gambit's code is the structure type handled, and what's the anotomy of this code?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==The ports/IO system==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Gambit has a variety of port types. Are the primary groupings/super-types of these, byte ports, character ports, and object ports? Is there some kind of strict inheritance between these, that each character ports is or contains a byte port too, and that every object port is or contains a character port too?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the IO/ports system and its sourcecode? At what places in Gambit's code is data sent/calls/mutations done to the OS as for Gambit to feed it with data, at what places in Gambit's code are things for Gambit to listen for events for (file handles, sockets, interrupt timeout?) inserted? How is the core IO-time scheduling done (on all platforms), is it by a select() or select()-equivalent call only, or is there any alternative return path from the OS into Gambit, during wait for timer timeout or IO input from the OS? (we discuss the reception and handling of timer interrupts separately in the section on threading.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the IO/ports system's sourcecode – which are the main procedures and code sites, approximately how does it fit together?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of a port, it's a structure with approx what properties, it has a will so it's shut down the right way when GC:ed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the code path for a |display| or |write| or |write-subu8vector| to a port, for various port types, all the way up to the end destination for the operation (the network device/OS file/target string buffer/etc).&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;At what points is the ports/IO system copying (both by function and by location in the sourcecode)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When select() has given an event for a file handle/socket, what is the code path that is invoked to propagate this event into the Scheme world?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does Gambit support select()-ing for more than 64 sockets on Windows? (this is a limit in Windows' select)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Console interaction and REPL==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Where is the sourcecode for the console interaction (incl libreadline kind of functionality) and REPL code, and what is the anatomy of this code?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What parts are in Scheme and what in C (I understand this would all better have been done in C but due to historic reasons right now some are in C)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If one would want to pipe REPL:s elsewhere than to the console, what hooks would be used? The place that spawns a REPL for uncaught exceptions, where is it so that one could direct those REPL:s to elsewhere than to the console REPL?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==The threading system==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How and where is the threading system bootstrapped? Where is the primordial thread initialized, and what makes it be the code that is actually the first to be run (except for, that at the time it's the only thread that exists)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is each thread a structure only? Roughly what properties does this structure have? How many bytes in size is this structure, on different architectures (32bit or 64bit)? Does Gambit provide any global state where threads and thread groups are stored, if so which is this structure and where is it declared, or does the caller need to keep references for them as not to GC?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How does Gambit ensure that interrupt checks are distributed in the code at such locations that smooth execution across threads is guaranteed, while the overhead for interrupt checking is kept low enough? How many % of code execution time is taken up by interrupt checks? The mechanism that puts interrupt checks in code is calibrated in such a way that there is no place in the code, no loop and so on, that is exempted from interrupt checks, in such a way that &amp;gt;1-2ms of code execution would happen without any interrupt check being made? So, (let loop ((at 0)) (if (##fx&amp;lt; at 1000000000) (loop (##fx+ at0)))) will never cause any issues with threading smoothness, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What principle is applied by Gambit when choosing what next thread to invoke? Where in Gambit's code are these therad switches made? If there's any particular complexity to the subject of making thread switches, please describe (such as, invoking the right trampolines or leaving the C/asm stack in the right condition or sth .. perhaps this is taken care of by the stack handling and that's it)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the thread switching mechanism: so first off, while not executing code but waiting for IO or timeouts from the OS, Gambit has a timer interrupt signal scheduled with the host OS (are these rescheduled all the time by Gambit, or is the OS set to recurringly make such interrupts at a certain interval forever)? Then, all Gambit-generated code is sugared all over with interrupt checks, so the interrupt signal handler procedure does something like mutating a global variable has_interrupt to true, and these interrupt checks do sth like if (has_interrupt) goto handle_interrupt or handle_interrupt(); depending on if the code is single-host or multiple-host? Then, does this handle_interrupt always check for stack overflow? What about heap overflow, or trigging a GC? How does it check if it's time to switch to another thread now? Does it do anything more? In case of switch to another thread, how is the current point of execution left in a way that maintains application/stack/etc integrity (perhaps that's a stack handling-section question)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Where/how is it configured for how long a thread should run before a switch is made to the next one? Is this a global or a per-thread configuration?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;While code can have (declare (not interrupts-enabled)) as not to accept any interrupts, the RTL is mostly compiled with interrupts enabled, so while inlined procedures such as + fall within the same interrupts-enabled setting as the code where it's used, non-inlined procedures such as assq do produce interrupts, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What's the anatomy of Gambit's threading system sourcecode, in what source files and locations are the threading system and the threading interrupts represented (I suppose the latter is in the compiler)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does the threading system schedule between threads based on the number of thread interrupts passed, or based on the amount of wall clock time passed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the dynamics of the priority, quantum and priority boost parameters to the threads, perhaps this is described completely enough in the specification document (don't remember its name or url right now)? If I want one thread to be of high priority and one of low, what parameters are needed? If I want one thread to get double or half as much CPU time as another, what parameters are needed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Beyond what has been covered above, is there any additional complexity to the threading system, or notable details not obvious from looking at its sourcecode?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Exceptions==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is the basic anatomy of the exceptions system, that first and foremost there is a |raise| procedure that takes one argument which is the exception value and which can be of any type, and, that in the dynamic environment there's a current exception handler parameter, that is a procedure, that is invoked on exception, and this is what with-exception-catcher and with-exception-handler uses to implement its functionality? So, the exception object type/-s is really a matter completely separated from the basic exception raising and catching mechanisms, and are only used as containers for conveying the content or message of each respective raised exception?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Gambit has a number of different exception types: os-exception, wrong-number-of-arguments-exception etc. etc.. Are these arranged in any kind of hierarchy? Are they all sub-structure-types of the exception type? Is there any way to get any kind of group type out of these?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Do any particular precautions need to be taken in order for a heap overflow exception to be handled 'safely', i.e. for the exception handling code not to unintendedly trig a new heap overflow exception in turn, that would terminate the program or cause otherwise unintended behavior?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Memory handling==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Beyond freedom from bugs, were any particular strategies assumed in making Gambit free of buffer overflows and memory corruption bugs? (I'm clear this might be a pointless question)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does Gambit have any quick reclaim mechanism for quickly discarding (GC:ing) objects that are not in use? Sth like, (define (a) (let ((b 1) (c 2.99999999999999) (d (make-string 1))) (+ b c)) – right at the point when a returns, is the memory for all of b, c and d immediately freed? Perhaps only b, because the compiler knew it took space only within the current stack frame and not otherwise on the heap so presuming the compiler knew to discard that stack frame quickly, it did. Does it discard c too (even while it occupies a little bit of heap space outside of the stack frame, no?) but not d, because b it knows what type it is of, but d was generated by an external procedure so quick freeing cannot be done but it will wait until the next GC?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;There is no central index of all objects on the heap, they're just allocated space for in the chunks of system memory allocated by the memory handling mechanism right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is any particular design of the heap or stacks required, for there to be support for concurrent garbage collection? (in same cpu core or multicore)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==GC (the default stop &amp;amp; copy implementation)==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Which are the variables used for determining if it's time to perform a GC, and where is the code that maintains those counters?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the anatomy of a garbage collection, including what kind of state structures are used during the process (for the markings and for keeping track of finalizers). What state does the garbage collector keep between gc:s?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the entry point for making GC iterations, the ___gc() C procedure? Does the garbage collector have more entry points than this, if so what are they used for?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How are finalizers handled? Because, I suppose, the finalizer needs to finish before the object is discarded. So, when an object with a finalizer ends up not marked by a GC process, then the GC makes a note of that object in some kind of list, and each such object has some kind of status flag that can be either of “finalizer not invoked”, “finalizer running” and “finalizer done”, and if it's “finalizer done” then the object is GC:ed,  and after each GC all entries with “finalizer not invoked”  are invoked? Please describe the possible states in here, where this state is stored, and which the state changes are and when the changes take place.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;On a GC, does Gambit always allocate memory for the target of the copy anew, and free() all allocations for the old copy at the end of GC? Or is there some keeping of memory allocations to not need to spend time on all new malloc() calls on each GC call?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Data types==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Every variable value in Scheme is represented internally as an integer, and has a tag about what fundamental data type the respective value is, right? What are the bit patterns in use for describing datatypes here? Where in Gambit's code is the basis for and use of those bit patterns implemented (as to know how to add or edit a type)? (I'm aware that fixnum is described by the two lowest bits being 0.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Whenever a variable value has a payload – some kind of object contents – a pointer to the memory address at which this payload is located, is included in every object reference on the heap for that object, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What was the motivation for using the lower bits in the variable values for the tag rather than the upper ones?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Hashtables==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;The hashtable and there used hashing algorithm, how does it work? Is there a paper anywhere that describes it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In what components/elements are hashtables stored internally (some kind of chain or tree I'd suppose, but what)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;By what reason is it that a table must not be mutated during table-for-each, what's the worstcase outcome if one mutates a table during it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is it possible to implement hashtables that fit together in a tree kind of shape, so that if I make table-set! on a parent then that one is visible to all child and grandchild etc. hashtables but not the other way around?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Numbers==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What are the rules for automatic type changes of numbers on number operations? Say, fixnum + flonum gives a flonum, that's obvious, but what about more complex cases – when are bignums generated, when are bignums scaled down to fixnums, and so on?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How are bignum structures stored internally, each such value is an object reference to a “bignum object”, and that object is a vector of integers that each contains a couple of decimals of the bignum value? With what procedures can I introspect and manipulate the element parts of a bignum value?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If one would want to change the structure format for the bignums, for instance for plugging in another bignum library, how would one go about for that?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==The compiler==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the basic anatomy of the compiler's sourcecode, and what is the basic code path that any compilation process takes? In all cases, I'm clear already there's two steps, a Scheme to GVM step, and a GVM to native code step (with the C backend or the native backend).&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the different phases that a compilation process takes (including any loops), and what form the sourcecode is stored in and what information form the compilation output is in, and what intermediary forms between sourcecode and compilation output are there and what's the purpose of those, in the different phases.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Approximately what optimizations are made by the compiler in the Scheme to GVM step and the GVM to C or native code steps respectively? (Let's define optimization as any logics that make the output code neater or faster than if that logics would not have been there, or if that logics would have been less well designed/thought through.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does the compiler look up all call/cc:s, and make a CPS conversion of all the code, during the compilation process? What is done with the CPS-converted code in order to generate the fastest or otherwise slimmest resultant code (if this is what the compiler does)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please list the academic papers and algorithm names that describe /something like/ what Gambit does during compilation.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If I wanted to implement a new primitive function that requires special (inlined) compiler output, say ##sysmem-byteref , where in the Scheme to GVM compiler's code and where in the C backend would a change need to be made, and approximately what kind of change would need to be made? &amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If I wanted to implement a new primitive conditional that requires special (inlined) compiler output, say a variant of |or| or |if| that we call |or/0| or |if/0| that treats fixnum 0 as #f, where in the Scheme to GVM compiler's code and where in the C backend would a change need to be made, and approximately what kind of change would need to be made? &amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Secondarily, I may want a first-class variant of this primitive too, for use both in compiled code and by the interpreter. What is a suitable place in Gambit's code to put a “wrapper” of the compiled version of ##sysmem-byteref to a first-class version of it, and how should that code look?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the general nature of the GVM language, and more specifically what kind of operations the GVM code language contains. Basically the GVM language describes procedures and their execution flows (stack operations, conditionals of the execution flow, jumps/invocations to procedures, trampolines?), and other than that it's invocations of primitives (+ etc)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please descrube the GVM code for a closure.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the GVM code for a conditional.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the GVM code for an invocation of a procedure with one or more arguments.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What state structures are needed to run a GVM (within C backend)? (both for the stack and to maintain the execution state needed to handle the juggling of host functions) Please describe with some detail – what's on the C stack, what's the structure of the processor struct and stack structures and so on.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the kind of functionality/functions needed by a GVM. So for instance, it needs to have a GC. What more? Some kind of stack handling machinery including dynamic addition and removal of slots to stack frames? (I suppose the entire concept of host procedures is within the C backend's architecture only, the GVM design in itself has nothing to do with those?)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In many places, exceptions are raised from a really low level point, say that + was applied to the wrong data type and now there's a type exception. How does the GVM code look for such handling, and how is this implemented in the C backend?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==The [GVM code to] C backend and the resultant object file==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the general anatomy of the C code output. (It is clear that each C file has some kind of headers and information structures inlined as constants, that are for somehow instructing the parent Gambit process what globals or alike the object file contains, rather than just code)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the basic execution flow of the C code in an object file? Right when it's loaded by the OS, which code in it is run? What is done? To feed the parent process with globals would, I suppose, be one. It is the parent process that then invokes an initialization routine in the object file, that invokes its top level code, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;The C code seems to be a pretty hardcore example of macro use. Is there any higher level of understanding or structure in all the macros that, if understood, makes it easier to understand the macro definitions and how the macros and their use fit together? What is the anatomy of the files with macro definitions?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When the host procedore returns (which happens basically between every evaluation step in code compiled with the safe declare), to what code in Gambit's runtime does it return then, what does that code do and in what condition does it jump back into the host procedore?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please descrube the C code for a closure.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the C code for a conditional.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the C code for an invocation of a procedure with one or more arguments.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Stack handling and related code generation aspects (including for GC traversibility, safety of stack overflows and call/cc) and trampolines==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Are stack frames the highest level of granularity that Gambit deals with stacks at, or do they have subcomponents (except for the slots for the individual contained values of course)? What about the code (define (a) (let ((b [value])) (let ((c [value])) [code1]) [code2])), what happens in the stack as code1 completes and code2 is started to be executed and c thus is disposed from the stack?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How many bytes does a stack frame occupy?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What contents does a continuation value or a continuation object value have, beyond (being) a reference to the stack frame to be executed on its invocation?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the dynamic environment and parameter values implemented? When invoking a continuation or there is a change of active thread, how is the switch of dynamic environment done?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the stack layout designed, as to be traversible by the GC? Were any particular considerations needed for this, to maintain the platform independentness of Gambit's C backend?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the stack layout designed, as to suit call/cc? What is the full mechanism of a call/cc, and what is the anatomy in site of a call/cc call, and, does it have any dependencies otherwise in the RTL?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;For the Gambit-generated native code to be safe for stack and heap overflows, it appears to me that there is basically some handling code between each step of every evaluation that involves the return of the host function. Why is this? Say that there is a processing loop, (let loop ((i 0)) (if (##fx&amp;lt; i 1000) (begin (##u8vector-set! u i (+ (u8vector-ref u i) 1) (loop (##fxnum+ i 1))))) say, why can't it just be one solid piece of code that executes through the loop just like that? What is the proof that stack overflow will never happen unless malloc fails?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How much C stack space does a Gambit process make use of? Can it be adjusted?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
==Debugging==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If a lowlevel crash would happen in a Gambit program, say somewhere outside the application's object files, what are the steps you normally would take/recommend as to determine the source of the error?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(Marc's answer here)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Design_guide</id>
		<title>Design guide</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Design_guide"/>
				<updated>2012-08-11T19:18:39Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
This document is intended to convey the understanding of Gambit that cannot be gotten from its manual, looking at its sourcecode, or reading the papers that underly its construction.&lt;br /&gt;
&lt;br /&gt;
Thus, the scope of this document is in contrast with and complementary to the manual's scope, which is to describe how Gambit is intended to be used by its user, to the sourcecode's scope, which is to describe the detail mechanics of Gambit at the highest level only, and to the papers and any other reference document, which each have a conceptually limited scope.&lt;br /&gt;
&lt;br /&gt;
The purpose of documenting this understanding of Gambit is general and multifacettated, and includes but is not limited to:&lt;br /&gt;
&lt;br /&gt;
* To convey why Gambit is a stable, working and robust software, for any uninterrupted short or long term use.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as it's reasonable that any user has a basic demand of 'getting it' about how Gambit works internally, as to be clear that the involved mechanisms are optimal and thus can be trusted to function well in any intended target environment and for any task; there indeed exists a lot of 'woo woo' technologies whose use bring with them all kinds of more or less predictable penalties, and it's of a general importance to clarify what game and league Gambit is in in this respect.)&lt;br /&gt;
&lt;br /&gt;
* To enable the user to adapt or extend Gambit himself, in the great majority of respects.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as Scheme's purpose is that of a language language, and thus it's expectable that use cases come up where customizations or extensions at any level of Gambit's architecture are needed. Most generally this would be about making Gambit work in a new operating environment, making customizations or tweaks to the io system, threads, numbers, and so on, or importantly, implementing some new or customized data type or operator.)&lt;br /&gt;
&lt;br /&gt;
* To enable the user to debug Gambit programs and Gambit itself at any level.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as while commercial or open source support may be available, it is several times key for a project to know that it is self-sustained and not dependent on contributions that are beyond its control, thus the need of making it feasible for anyone to dig into and understand Gambit internals, as to fix any unexpected behavior, in the very rare case that anything in this direction would manifest.)&lt;br /&gt;
&lt;br /&gt;
* To make digging into Gambit's sourcecode an as quick process as possible&lt;br /&gt;
&lt;br /&gt;
* To give the programmer clarity about how Gambit optimizes code / what optimizations Gambit applies / roughly what kind of machine code will be produced from a given Scheme code, and thus be able to write optimal code&lt;br /&gt;
&lt;br /&gt;
As to convey this understanding in the most effective way, it's written in the form of a conversation between the user (you) and the designer (Marc). This is as Gambit is a complex, holistic system that may possibly appear a bit nonlinear, where understanding of the involved concepts and how things fit together is of primary priority, and this is best made in the form of a conversation where for instance difference depths of detail can be used interchangably and crossreferences to other topics can be made quite liberally, rather than in the form of a monolithic final implementation reference over every involved bit and byte.&lt;br /&gt;
&lt;br /&gt;
At points the converation form between user and designer is rather to maintain a lingual clarity than a result of that it was actually a/the user or designer who wrote the respective text. The user's text is highlighted in yellow and the designer's text is in normal style.&lt;br /&gt;
&lt;br /&gt;
This document is intended to be for the current version of Gambit (this doc was started at version 4.6.8), though obviously an answer may be for a previous Gambit version and there could be the need for an update of some section, in which case you are free to correct it yourself, and to enquire for clarifications on the mailing list.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Generally though, Gambit's sources are changed extremely rarely, so this ought to be a completely minor issue.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For now this document is in one piece only, which is this document, possibly it could be split into sections if it'd turn unnavigably large.&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
In this document we mean..&lt;br /&gt;
Gambit: The entire Gambit environment, including BSy and RTL (below).&lt;br /&gt;
BSy: The base Gambit system without the RTL. This is the most bare form Gambit can easily be stripped down to and still work.&lt;br /&gt;
RTL or runtime: The runtime library; please note that we use this term only because it's a well established term in the programming world – we use it to refer to all of Gambit beyond the BSy, and this obviously includes the evaluator, compiler, threading system and so on, which are of a much higher complexity than a typical RTL.&lt;br /&gt;
Compiler: Gambit's compilation mechanism, including the Scheme to GVM compiler and all backends.&lt;br /&gt;
GVM / Gambit VM: The particular design of C/binary code generated by the Gambit compiler backend as regards code execution flow within and between modules, and in relation with certain lowlevel runtime functionality as to make the stack model and thread interrupts spin.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Also, GVM is the intermediary format that Gambit compiles Scheme code to, and which the respective compiler backend takes as input for binary generation.&amp;lt;/div&amp;gt;&lt;br /&gt;
[Thread] interrupts: Checkpoints spread across Gambit-generated code, at which stack and heap(???) overflow conditions are checked for, and switches of activity into the threading system is made, if applicable. Also the GC may be invoked here??&lt;br /&gt;
&lt;br /&gt;
==Taking it down to earth: What complexity is involved in Gambit really==&lt;br /&gt;
&lt;br /&gt;
Compared with a general programming language such as, say, C or Java, the workings of a Scheme environment may appear to the unintroduced as unclear and abstract, and thus not really something to trust (as per the way of conduct, that what you don't want to use mechanisms that you don't understand – nonsimplistic, nonoptimal or otherwise 'woo woo' mechanisms could lead to all kinds of dire penalties down the road, and thus we better get clarity about this while at the introductory step).&lt;br /&gt;
&lt;br /&gt;
Let's dig into this topic as to bring an overview-level clarity on what complexity is involved in Gambit.&lt;br /&gt;
&lt;br /&gt;
First, let's get clear about the components involved in Gambit as a system, in contrast with those of a typical general programming system:&lt;br /&gt;
&lt;br /&gt;
Both the C and Java programming systems have the following design: The essential components are the shell, compiler, loader and the execution with the runtime.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell as provided by the OS, or other functional equivalent, is the tool for invoking the compiler and loader-execution.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The compiler is a separate application that compiles language sourcecode to a binary object form. The compiler can but does not need to be implemented in the language itself.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The loader is either part of the parent operating system (which is the case in C), or an application that loads and boostraps binary code generated by the compiler (which is the case in Java). Execution is performed atop the OS, possibly atop a VM application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The runtime is a library written in the language (and possibly some code in a lower-level language i.e. assembly/C), that provides some bootstrap code for any application, and elementary procedures and type definitions that are of general use for application implementors, as not to need to reimplement elementary functionality like data type handling, and routines for interfacing common mechanisms in the underlying operating system such as console and file I/O, OS threads and networking.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell and compiler are separate binary files (with dependencies), the loader and execution possibly performed by a separate binary file (with dependencies), and the runtime library is a separate set of binary files. Compiler-generated binaries are separate binary files.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit as a holistic Scheme system has a slightly different design: (As a side note, Gambit's design in these respects is basically the same as many earlier Lisp and Scheme systems – i.e. Gambit is traditional in this respect.)&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The Scheme system [Gambit] is a separate application. It is rather typically running as a process within a host operating system, but can also run as a operating system image itself, directly on the host processor.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Gambit (the system) performs both the shell, compilation, loading and the execution step and itself contains the runtime, and the steps are performed without any need for restart or other interruption of the system. Thus, at the level of concept, Gambit as a programming system also has the characteristics of an operating system. This kind of adds to its holisticness – it's an application-level programming operating-system-environment.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;(If using the C backend, the C compiler of the host operating system is invoked by Gambit, though that's a detail – during this phase Gambit is running and actively waiting in the backround for the C compiler to finish, as to continue to the next step.) (Loading of C-backend-generated binaries is done by Gambit invoking the underlying operating system's functionality for dynamic library loading, though this is a detail too.)&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In Gambit, the compiler is implemented as part of the RTL and generally invoked as a procedure. Loading and execution are procedures too, and all of these procedures are accessed directly from the shell, called the Read-Eval-Print Loop.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The user is free to make individual executions of Gambit for each compilation or other task the user wants Gambit to perform, for instance for the task of compiling a source file to a binary file, which is how compilation is done in C and Java. The point here though is that this optional, not required.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell, compiler, loader, execution mechanism and runtime are generally all combined in one and the same binary file. (There is a version without the compiler.) Compiler-generated binaries are by default separate files, and can be merged with the compiler file thus generating a single executable binary for a compiled application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Thus, to sum this up:&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In C and Java programming systems, the compiler is a separately invoked application (possibly launched by the loader), the loader and execution are handled in a separate step, and both of these are invoked from the OS shell being another separate application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In Gambit, there is one centerpiece application namely the entire system itself, which performs the shell, compiling, loading and execution steps in one piece.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
So now we're clear about how the programming environment is set up and that this way of doing things is indeed straightforward, and the next thing for us to look at is, what kind of complexity is needed to make this spin.&lt;br /&gt;
&lt;br /&gt;
Gambit is comparable in terms of complexity, with any general garbage collected language such as Java, with its stack model being the big exception: while the general programming languages tend to have a direct style stack that is implemented directly atop the underlying C/assembly-level stack mechanism.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Due to that the additional stack handling required by these languages is zero or very small, beyond what's provided already by the OS and the assembly language, and that the concepts of OS&amp;amp;asm mechanisms are so basic in all cases, the stack is generally viewed as a noncomplex matter in these languages.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;(By direct style stack, we mean that there's procedure calls stored on a fixed-size stack, every call should conceptually be neutralized by by a procedure return as for the app not to eventually run out of stack space, and returns generally return to the stack level directly below it in the stack, or in the case of exceptions, multiple steps, until the place of the closest exception handler, or in the case of application termination, the application terminates and the entire stack is discarded.)&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Gambit is stackless. The stack functionality is performed through stack frame objects, that are linked together in a tree (or web) that's possibly cyclical. To make code in this environment execute run with an optimal speed (the as that of C code doing approx the same thing), extensive optimizations are applied to the stack handling.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;While the concepts of stacklessness and stack frame objects ought to be straightforward enough, the details of how Gambit actually performs this, may be a very complex matter, and therefore we will explore this topic in detail below.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit's threading and exception handling mechanisms are, given that the Gambit stack is already in place,  quite non-complex matters, they're essentially simple applications of use of the stack model.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The threading needs interrupt hooks at regular intervals in the application code in order to function, which the compiler sugars the code with – this is a delicate topic that we will explore further below.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit's IO model is based on an event dispatcher loop centered around a select() OS call and use interrrupt timer functionality from the host OS. While Gambit does this in a particularly elegant way, in-application central IO/event dispatcher loops have been in a quite wide use since very long – since the inception of Unix systems, say – and has been refined into simple to use API:s in libraries such as libevent and libuv.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Therefore, even while lots of effort and exactitude is required for implementing this in a way that really spins uncompromisingly, we relate to this functionality as noncomplex.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Beyond the stack model, making Scheme code execute at speeds comparable with that of C, a careful design of the compiler – including extensive, complex optimizations – and of the VM/runtime system (type and object handling etc) are required. We discuss this in more detail below.&lt;br /&gt;
&lt;br /&gt;
Thus, we can now sum up complexity in Gambit, beyond that of a general programming environment such as that of Java, as being focalized to the design of the stack handling and to how the matters of how very high performance of code execution is achieved, which are dealed with by the compiler and the tuning of the details of the VM/runtime system design.&lt;br /&gt;
&lt;br /&gt;
==The C-level anatomy of Gambit and a Gambit-based application==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When having Gambit or a Gambit-based application in sourcecode form only, what steps are required to compile it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(running the configure script – the configure script generates ./Makefile *only* or other files too? - the Makefile as for use by make without parameters just as to compile the program, essentially only invokes the C compiler and linker for the different C files in the appropriate order? C files generated out of Gambit's runtime's scheme files, required to make compilation out of C code only work. ./configure and running make on the makefile is all needed to produce the C binaries? For distributing an application implemented in Gambit, only distributing the C files generated by Gambit for the application's Scheme files, is sufficient. Thus for such an application, add to the configure script/Makefile instructions to compile also the application's bundled C files, and include those in the linking process. Any advice on how to prepare such an Gambit application from C files distribution as easily as possible, are there any examples anywhere available?)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Conceptually, what does the configure script check for and what output files does it produce?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In what areas are there differences in what C/asm code of Gambit is used, between processors and platforms?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(the select loop and files and networking, how interrupt signals are made, more?  Native bit size of values of course.)&lt;br /&gt;
==The C-level anatomy of starting Gambit or a Gambit-based application==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When Gambit or a Gambit application is started, what is approximately the code flow of the initiation all way up to that Scheme code starts to execute? (roughly locations of the different functions in Gambit's C code, that are invoked) What OS calls are made/state for the Gambit OS process with the OS is set up, and what information is acquired from the host OS? What code is run to initialize the heap? What code is run to initialize the stack handling with its first  stack frame (perhaps this q should rather be put in the section about stack handling)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Structures==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Internally, are structures just special-type vectors?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is there any inheritance between structures, i.e. can I create a structure of type car and then make a subtype structure of type volvo? If so, how does this inheritance work – is it just that when making a volvo object, a vector is created with slots for all of a car's properties and appended to that is slots for all of volvo's properties too – how does the car property access procedures typecheck for if it's a car or a volvo?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Where in Gambit's code is the structure type handled, and what's the anotomy of this code?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==The ports/IO system==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Gambit has a variety of port types. Are the primary groupings/super-types of these, byte ports, character ports, and object ports? Is there some kind of strict inheritance between these, that each character ports is or contains a byte port too, and that every object port is or contains a character port too?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the IO/ports system and its sourcecode? At what places in Gambit's code is data sent/calls/mutations done to the OS as for Gambit to feed it with data, at what places in Gambit's code are things for Gambit to listen for events for (file handles, sockets, interrupt timeout?) inserted? How is the core IO-time scheduling done (on all platforms), is it by a select() or select()-equivalent call only, or is there any alternative return path from the OS into Gambit, during wait for timer timeout or IO input from the OS? (we discuss the reception and handling of timer interrupts separately in the section on threading.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the IO/ports system's sourcecode – which are the main procedures and code sites, approximately how does it fit together?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of a port, it's a structure with approx what properties, it has a will so it's shut down the right way when GC:ed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the code path for a |display| or |write| or |write-subu8vector| to a port, for various port types, all the way up to the end destination for the operation (the network device/OS file/target string buffer/etc).&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;At what points is the ports/IO system copying (both by function and by location in the sourcecode)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When select() has given an event for a file handle/socket, what is the code path that is invoked to propagate this event into the Scheme world?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does Gambit support select()-ing for more than 64 sockets on Windows? (this is a limit in Windows' select)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Console interaction and REPL==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Where is the sourcecode for the console interaction (incl libreadline kind of functionality) and REPL code, and what is the anatomy of this code?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What parts are in Scheme and what in C (I understand this would all better have been done in C but due to historic reasons right now some are in C)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If one would want to pipe REPL:s elsewhere than to the console, what hooks would be used? The place that spawns a REPL for uncaught exceptions, where is it so that one could direct those REPL:s to elsewhere than to the console REPL?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==The threading system==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How and where is the threading system bootstrapped? Where is the primordial thread initialized, and what makes it be the code that is actually the first to be run (except for, that at the time it's the only thread that exists)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is each thread a structure only? Roughly what properties does this structure have? How many bytes in size is this structure, on different architectures (32bit or 64bit)? Does Gambit provide any global state where threads and thread groups are stored, if so which is this structure and where is it declared, or does the caller need to keep references for them as not to GC?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How does Gambit ensure that interrupt checks are distributed in the code at such locations that smooth execution across threads is guaranteed, while the overhead for interrupt checking is kept low enough? How many % of code execution time is taken up by interrupt checks? The mechanism that puts interrupt checks in code is calibrated in such a way that there is no place in the code, no loop and so on, that is exempted from interrupt checks, in such a way that &amp;gt;1-2ms of code execution would happen without any interrupt check being made? So, (let loop ((at 0)) (if (##fx&amp;lt; at 1000000000) (loop (##fx+ at0)))) will never cause any issues with threading smoothness, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What principle is applied by Gambit when choosing what next thread to invoke? Where in Gambit's code are these therad switches made? If there's any particular complexity to the subject of making thread switches, please describe (such as, invoking the right trampolines or leaving the C/asm stack in the right condition or sth .. perhaps this is taken care of by the stack handling and that's it)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the thread switching mechanism: so first off, while not executing code but waiting for IO or timeouts from the OS, Gambit has a timer interrupt signal scheduled with the host OS (are these rescheduled all the time by Gambit, or is the OS set to recurringly make such interrupts at a certain interval forever)? Then, all Gambit-generated code is sugared all over with interrupt checks, so the interrupt signal handler procedure does something like mutating a global variable has_interrupt to true, and these interrupt checks do sth like if (has_interrupt) goto handle_interrupt or handle_interrupt(); depending on if the code is single-host or multiple-host? Then, does this handle_interrupt always check for stack overflow? What about heap overflow, or trigging a GC? How does it check if it's time to switch to another thread now? Does it do anything more? In case of switch to another thread, how is the current point of execution left in a way that maintains application/stack/etc integrity (perhaps that's a stack handling-section question)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Where/how is it configured for how long a thread should run before a switch is made to the next one? Is this a global or a per-thread configuration?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;While code can have (declare (not interrupts-enabled)) as not to accept any interrupts, the RTL is mostly compiled with interrupts enabled, so while inlined procedures such as + fall within the same interrupts-enabled setting as the code where it's used, non-inlined procedures such as assq do produce interrupts, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What's the anatomy of Gambit's threading system sourcecode, in what source files and locations are the threading system and the threading interrupts represented (I suppose the latter is in the compiler)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does the threading system schedule between threads based on the number of thread interrupts passed, or based on the amount of wall clock time passed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the dynamics of the priority, quantum and priority boost parameters to the threads, perhaps this is described completely enough in the specification document (don't remember its name or url right now)? If I want one thread to be of high priority and one of low, what parameters are needed? If I want one thread to get double or half as much CPU time as another, what parameters are needed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Beyond what has been covered above, is there any additional complexity to the threading system, or notable details not obvious from looking at its sourcecode?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Exceptions==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is the basic anatomy of the exceptions system, that first and foremost there is a |raise| procedure that takes one argument which is the exception value and which can be of any type, and, that in the dynamic environment there's a current exception handler parameter, that is a procedure, that is invoked on exception, and this is what with-exception-catcher and with-exception-handler uses to implement its functionality? So, the exception object type/-s is really a matter completely separated from the basic exception raising and catching mechanisms, and are only used as containers for conveying the content or message of each respective raised exception?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Gambit has a number of different exception types: os-exception, wrong-number-of-arguments-exception etc. etc.. Are these arranged in any kind of hierarchy? Are they all sub-structure-types of the exception type? Is there any way to get any kind of group type out of these?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Do any particular precautions need to be taken in order for a heap overflow exception to be handled 'safely', i.e. for the exception handling code not to unintendedly trig a new heap overflow exception in turn, that would terminate the program or cause otherwise unintended behavior?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==GC and memory handling (here regarding the default stop &amp;amp; copy gc)==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Which are the variables used for determining if it's time to perform a GC, and where is the code that maintains those counters?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the anatomy of a garbage collection, including what kind of state structures are used during the process (for the markings and for keeping track of finalizers). What state does the garbage collector keep between gc:s?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the entry point for making GC iterations, the ___gc() C procedure? Does the garbage collector have more entry points than this, if so what are they used for?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does Gambit have any quick reclaim mechanism for quickly discarding (GC:ing) objects that are not in use? Sth like, (define (a) (let ((b 1) (c 2.99999999999999) (d (make-string 1))) (+ b c)) – right at the point when a returns, is the memory for all of b, c and d immediately freed? Perhaps only b, because the compiler knew it took space only within the current stack frame and not otherwise on the heap so presuming the compiler knew to discard that stack frame quickly, it did. Does it discard c too (even while it occupies a little bit of heap space outside of the stack frame, no?) but not d, because b it knows what type it is of, but d was generated by an external procedure so quick freeing cannot be done but it will wait until the next GC?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How are finalizers handled? Because, I suppose, the finalizer needs to finish before the object is discarded. So, when an object with a finalizer ends up not marked by a GC process, then the GC makes a note of that object in some kind of list, and each such object has some kind of status flag that can be either of “finalizer not invoked”, “finalizer running” and “finalizer done”, and if it's “finalizer done” then the object is GC:ed,  and after each GC all entries with “finalizer not invoked”  are invoked? Please describe the possible states in here, where this state is stored, and which the state changes are and when the changes take place.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;There is no central index of all objects on the heap, they're just allocated space for in the chunks of system memory allocated by the memory handling mechanism right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is any particular design of the heap or stacks required, for there to be support for concurrent garbage collection? (in same cpu core or multicore)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Beyond freedom of bugs, were any particular strategies assumed in making Gambit free of buffer overflows and memory corruption bugs? (I'm clear this might be a pointless question)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Data types==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Every variable value in Scheme is represented internally as an integer, and has a tag about what fundamental data type the respective value is, right? What are the bit patterns in use for describing datatypes here? Where in Gambit's code is the basis for and use of those bit patterns implemented (as to know how to add or edit a type)? (I'm aware that fixnum is described by the two lowest bits being 0.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Whenever a variable value has a payload – some kind of object contents – a pointer to the memory address at which this payload is located, is included in every object reference on the heap for that object, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What was the motivation for using the lower bits in the variable values for the tag rather than the upper ones?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Hashtables==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;The hashtable and there used hashing algorithm, how does it work? Is there a paper anywhere that describes it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In what components/elements are hashtables stored internally (some kind of chain or tree I'd suppose, but what)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;By what reason is it that a table must not be mutated during table-for-each, what's the worstcase outcome if one mutates a table during it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is it possible to implement hashtables that fit together in a tree kind of shape, so that if I make table-set! on a parent then that one is visible to all child and grandchild etc. hashtables but not the other way around?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Numbers==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What are the rules for automatic type changes of numbers on number operations? Say, fixnum + flonum gives a flonum, that's obvious, but what about more complex cases – when are bignums generated, when are bignums scaled down to fixnums, and so on?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How are bignum structures stored internally, each such value is an object reference to a “bignum object”, and that object is a vector of integers that each contains a couple of decimals of the bignum value? With what procedures can I introspect and manipulate the element parts of a bignum value?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If one would want to change the structure format for the bignums, for instance for plugging in another bignum library, how would one go about for that?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==The compiler==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the basic anatomy of the compiler's sourcecode, and what is the basic code path that any compilation process takes? In all cases, I'm clear already there's two steps, a Scheme to GVM step, and a GVM to native code step (with the C backend or the native backend).&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the different phases that a compilation process takes (including any loops), and what form the sourcecode is stored in and what information form the compilation output is in, and what intermediary forms between sourcecode and compilation output are there and what's the purpose of those, in the different phases.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Approximately what optimizations are made by the compiler in the Scheme to GVM step and the GVM to C or native code steps respectively? (Let's define optimization as any logics that make the output code neater or faster than if that logics would not have been there, or if that logics would have been less well designed/thought through.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does the compiler look up all call/cc:s, and make a CPS conversion of all the code, during the compilation process? What is done with the CPS-converted code in order to generate the fastest or otherwise slimmest resultant code (if this is what the compiler does)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please list the academic papers and algorithm names that describe /something like/ what Gambit does during compilation.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If I wanted to implement a new primitive function that requires special (inlined) compiler output, say ##sysmem-byteref , where in the Scheme to GVM compiler's code and where in the C backend would a change need to be made, and approximately what kind of change would need to be made? &amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If I wanted to implement a new primitive conditional that requires special (inlined) compiler output, say a variant of |or| or |if| that we call |or/0| or |if/0| that treats fixnum 0 as #f, where in the Scheme to GVM compiler's code and where in the C backend would a change need to be made, and approximately what kind of change would need to be made? &amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Secondarily, I may want a first-class variant of this primitive too, for use both in compiled code and by the interpreter. What is a suitable place in Gambit's code to put a “wrapper” of the compiled version of ##sysmem-byteref to a first-class version of it, and how should that code look?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the general nature of the GVM language, and more specifically what kind of operations the GVM code language contains. Basically the GVM language describes procedures and their execution flows (stack operations, conditionals of the execution flow, jumps/invocations to procedures, trampolines?), and other than that it's invocations of primitives (+ etc)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please descrube the GVM code for a closure.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the GVM code for a conditional.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the GVM code for an invocation of a procedure with one or more arguments.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What state structures are needed to run a GVM (within C backend)? (both for the stack and to maintain the execution state needed to handle the juggling of host functions) Please describe with some detail – what's on the C stack, what's the structure of the processor struct and stack structures and so on.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the kind of functionality/functions needed by a GVM. So for instance, it needs to have a GC. What more? Some kind of stack handling machinery including dynamic addition and removal of slots to stack frames? (I suppose the entire concept of host procedures is within the C backend's architecture only, the GVM design in itself has nothing to do with those?)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In many places, exceptions are raised from a really low level point, say that + was applied to the wrong data type and now there's a type exception. How does the GVM code look for such handling, and how is this implemented in the C backend?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==The [GVM code to] C backend and the resultant object file==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the general anatomy of the C code output. (It is clear that each C file has some kind of headers and information structures inlined as constants, that are for somehow instructing the parent Gambit process what globals or alike the object file contains, rather than just code)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the basic execution flow of the C code in an object file? Right when it's loaded by the OS, which code in it is run? What is done? To feed the parent process with globals would, I suppose, be one. It is the parent process that then invokes an initialization routine in the object file, that invokes its top level code, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;The C code seems to be a pretty hardcore example of macro use. Is there any higher level of understanding or structure in all the macros that, if understood, makes it easier to understand the macro definitions and how the macros and their use fit together? What is the anatomy of the files with macro definitions?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When the host procedore returns (which happens basically between every evaluation step in code compiled with the safe declare), to what code in Gambit's runtime does it return then, what does that code do and in what condition does it jump back into the host procedore?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please descrube the C code for a closure.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the C code for a conditional.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the C code for an invocation of a procedure with one or more arguments.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Stack handling and related code generation aspects (including for GC traversibility, safety of stack overflows and call/cc) and trampolines==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Are stack frames the highest level of granularity that Gambit deals with stacks at, or do they have subcomponents (except for the slots for the individual contained values of course)? What about the code (define (a) (let ((b [value])) (let ((c [value])) [code1]) [code2])), what happens in the stack as code1 completes and code2 is started to be executed and c thus is disposed from the stack?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How many bytes does a stack frame occupy?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What contents does a continuation value or a continuation object value have, beyond (being) a reference to the stack frame to be executed on its invocation?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the dynamic environment and parameter values implemented? When invoking a continuation or there is a change of active thread, how is the switch of dynamic environment done?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the stack layout designed, as to be traversible by the GC? Were any particular considerations needed for this, to maintain the platform independentness of Gambit's C backend?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the stack layout designed, as to suit call/cc? What is the full mechanism of a call/cc, and what is the anatomy in site of a call/cc call, and, does it have any dependencies otherwise in the RTL?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;For the Gambit-generated native code to be safe for stack and heap overflows, it appears to me that there is basically some handling code between each step of every evaluation that involves the return of the host function. Why is this? Say that there is a processing loop, (let loop ((i 0)) (if (##fx&amp;lt; i 1000) (begin (##u8vector-set! u i (+ (u8vector-ref u i) 1) (loop (##fxnum+ i 1))))) say, why can't it just be one solid piece of code that executes through the loop just like that? What is the proof that stack overflow will never happen unless malloc fails?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How much C stack space does a Gambit process make use of? Can it be adjusted?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Debugging==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If a lowlevel crash would happen in a Gambit program, say somewhere outside the application's object files, what are the steps you normally would take/recommend as to determine the source of the error?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Design_guide</id>
		<title>Design guide</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Design_guide"/>
				<updated>2012-08-11T19:16:24Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
This document is intended to convey the understanding of Gambit that cannot be gotten from its manual, looking at its sourcecode, or reading the papers that underly its construction.&lt;br /&gt;
&lt;br /&gt;
Thus, the scope of this document is in contrast with and complementary to the manual's scope, which is to describe how Gambit is intended to be used by its user, to the sourcecode's scope, which is to describe the detail mechanics of Gambit at the highest level only, and to the papers and any other reference document, which each have a conceptually limited scope.&lt;br /&gt;
&lt;br /&gt;
The purpose of documenting this understanding of Gambit is general and multifacettated, and includes but is not limited to:&lt;br /&gt;
&lt;br /&gt;
* To convey why Gambit is a stable, working and robust software, for any uninterrupted short or long term use.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as it's reasonable that any user has a basic demand of 'getting it' about how Gambit works internally, as to be clear that the involved mechanisms are optimal and thus can be trusted to function well in any intended target environment and for any task; there indeed exists a lot of 'woo woo' technologies whose use bring with them all kinds of more or less predictable penalties, and it's of a general importance to clarify what game and league Gambit is in in this respect.)&lt;br /&gt;
&lt;br /&gt;
* To enable the user to adapt or extend Gambit himself, in the great majority of respects.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as Scheme's purpose is that of a language language, and thus it's expectable that use cases come up where customizations or extensions at any level of Gambit's architecture are needed. Most generally this would be about making Gambit work in a new operating environment, making customizations or tweaks to the io system, threads, numbers, and so on, or importantly, implementing some new or customized data type or operator.)&lt;br /&gt;
&lt;br /&gt;
* To enable the user to debug Gambit programs and Gambit itself at any level.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as while commercial or open source support may be available, it is several times key for a project to know that it is self-sustained and not dependent on contributions that are beyond its control, thus the need of making it feasible for anyone to dig into and understand Gambit internals, as to fix any unexpected behavior, in the very rare case that anything in this direction would manifest.)&lt;br /&gt;
&lt;br /&gt;
* To make digging into Gambit's sourcecode an as quick process as possible&lt;br /&gt;
&lt;br /&gt;
* To give the programmer clarity about how Gambit optimizes code / what optimizations Gambit applies / roughly what kind of machine code will be produced from a given Scheme code, and thus be able to write optimal code&lt;br /&gt;
&lt;br /&gt;
As to convey this understanding in the most effective way, it's written in the form of a conversation between the user (you) and the designer (Marc). This is as Gambit is a complex, holistic system that may possibly appear a bit nonlinear, where understanding of the involved concepts and how things fit together is of primary priority, and this is best made in the form of a conversation where for instance difference depths of detail can be used interchangably and crossreferences to other topics can be made quite liberally, rather than in the form of a monolithic final implementation reference over every involved bit and byte.&lt;br /&gt;
&lt;br /&gt;
At points the converation form between user and designer is rather to maintain a lingual clarity than a result of that it was actually a/the user or designer who wrote the respective text. The user's text is in bold and the designer's text is in normal style.&lt;br /&gt;
&lt;br /&gt;
This document is intended to be for the current version of Gambit (this doc was started at version 4.6.8), though obviously an answer may be for a previous Gambit version and there could be the need for an update of some section, in which case you are free to correct it yourself, and to enquire for clarifications on the mailing list.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Generally though, Gambit's sources are changed extremely rarely, so this ought to be a completely minor issue.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For now this document is in one piece only, which is this document, possibly it could be split into sections if it'd turn unnavigably large.&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
In this document we mean..&lt;br /&gt;
Gambit: The entire Gambit environment, including BSy and RTL (below).&lt;br /&gt;
BSy: The base Gambit system without the RTL. This is the most bare form Gambit can easily be stripped down to and still work.&lt;br /&gt;
RTL or runtime: The runtime library; please note that we use this term only because it's a well established term in the programming world – we use it to refer to all of Gambit beyond the BSy, and this obviously includes the evaluator, compiler, threading system and so on, which are of a much higher complexity than a typical RTL.&lt;br /&gt;
Compiler: Gambit's compilation mechanism, including the Scheme to GVM compiler and all backends.&lt;br /&gt;
GVM / Gambit VM: The particular design of C/binary code generated by the Gambit compiler backend as regards code execution flow within and between modules, and in relation with certain lowlevel runtime functionality as to make the stack model and thread interrupts spin.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Also, GVM is the intermediary format that Gambit compiles Scheme code to, and which the respective compiler backend takes as input for binary generation.&amp;lt;/div&amp;gt;&lt;br /&gt;
[Thread] interrupts: Checkpoints spread across Gambit-generated code, at which stack and heap(???) overflow conditions are checked for, and switches of activity into the threading system is made, if applicable. Also the GC may be invoked here??&lt;br /&gt;
&lt;br /&gt;
==Taking it down to earth: What complexity is involved in Gambit really==&lt;br /&gt;
&lt;br /&gt;
Compared with a general programming language such as, say, C or Java, the workings of a Scheme environment may appear to the unintroduced as unclear and abstract, and thus not really something to trust (as per the way of conduct, that what you don't want to use mechanisms that you don't understand – nonsimplistic, nonoptimal or otherwise 'woo woo' mechanisms could lead to all kinds of dire penalties down the road, and thus we better get clarity about this while at the introductory step).&lt;br /&gt;
&lt;br /&gt;
Let's dig into this topic as to bring an overview-level clarity on what complexity is involved in Gambit.&lt;br /&gt;
&lt;br /&gt;
First, let's get clear about the components involved in Gambit as a system, in contrast with those of a typical general programming system:&lt;br /&gt;
&lt;br /&gt;
Both the C and Java programming systems have the following design: The essential components are the shell, compiler, loader and the execution with the runtime.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell as provided by the OS, or other functional equivalent, is the tool for invoking the compiler and loader-execution.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The compiler is a separate application that compiles language sourcecode to a binary object form. The compiler can but does not need to be implemented in the language itself.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The loader is either part of the parent operating system (which is the case in C), or an application that loads and boostraps binary code generated by the compiler (which is the case in Java). Execution is performed atop the OS, possibly atop a VM application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The runtime is a library written in the language (and possibly some code in a lower-level language i.e. assembly/C), that provides some bootstrap code for any application, and elementary procedures and type definitions that are of general use for application implementors, as not to need to reimplement elementary functionality like data type handling, and routines for interfacing common mechanisms in the underlying operating system such as console and file I/O, OS threads and networking.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell and compiler are separate binary files (with dependencies), the loader and execution possibly performed by a separate binary file (with dependencies), and the runtime library is a separate set of binary files. Compiler-generated binaries are separate binary files.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit as a holistic Scheme system has a slightly different design: (As a side note, Gambit's design in these respects is basically the same as many earlier Lisp and Scheme systems – i.e. Gambit is traditional in this respect.)&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The Scheme system [Gambit] is a separate application. It is rather typically running as a process within a host operating system, but can also run as a operating system image itself, directly on the host processor.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Gambit (the system) performs both the shell, compilation, loading and the execution step and itself contains the runtime, and the steps are performed without any need for restart or other interruption of the system. Thus, at the level of concept, Gambit as a programming system also has the characteristics of an operating system. This kind of adds to its holisticness – it's an application-level programming operating-system-environment.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;(If using the C backend, the C compiler of the host operating system is invoked by Gambit, though that's a detail – during this phase Gambit is running and actively waiting in the backround for the C compiler to finish, as to continue to the next step.) (Loading of C-backend-generated binaries is done by Gambit invoking the underlying operating system's functionality for dynamic library loading, though this is a detail too.)&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In Gambit, the compiler is implemented as part of the RTL and generally invoked as a procedure. Loading and execution are procedures too, and all of these procedures are accessed directly from the shell, called the Read-Eval-Print Loop.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The user is free to make individual executions of Gambit for each compilation or other task the user wants Gambit to perform, for instance for the task of compiling a source file to a binary file, which is how compilation is done in C and Java. The point here though is that this optional, not required.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell, compiler, loader, execution mechanism and runtime are generally all combined in one and the same binary file. (There is a version without the compiler.) Compiler-generated binaries are by default separate files, and can be merged with the compiler file thus generating a single executable binary for a compiled application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Thus, to sum this up:&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In C and Java programming systems, the compiler is a separately invoked application (possibly launched by the loader), the loader and execution are handled in a separate step, and both of these are invoked from the OS shell being another separate application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In Gambit, there is one centerpiece application namely the entire system itself, which performs the shell, compiling, loading and execution steps in one piece.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
So now we're clear about how the programming environment is set up and that this way of doing things is indeed straightforward, and the next thing for us to look at is, what kind of complexity is needed to make this spin.&lt;br /&gt;
&lt;br /&gt;
Gambit is comparable in terms of complexity, with any general garbage collected language such as Java, with its stack model being the big exception: while the general programming languages tend to have a direct style stack that is implemented directly atop the underlying C/assembly-level stack mechanism.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Due to that the additional stack handling required by these languages is zero or very small, beyond what's provided already by the OS and the assembly language, and that the concepts of OS&amp;amp;asm mechanisms are so basic in all cases, the stack is generally viewed as a noncomplex matter in these languages.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;(By direct style stack, we mean that there's procedure calls stored on a fixed-size stack, every call should conceptually be neutralized by by a procedure return as for the app not to eventually run out of stack space, and returns generally return to the stack level directly below it in the stack, or in the case of exceptions, multiple steps, until the place of the closest exception handler, or in the case of application termination, the application terminates and the entire stack is discarded.)&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Gambit is stackless. The stack functionality is performed through stack frame objects, that are linked together in a tree (or web) that's possibly cyclical. To make code in this environment execute run with an optimal speed (the as that of C code doing approx the same thing), extensive optimizations are applied to the stack handling.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;While the concepts of stacklessness and stack frame objects ought to be straightforward enough, the details of how Gambit actually performs this, may be a very complex matter, and therefore we will explore this topic in detail below.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit's threading and exception handling mechanisms are, given that the Gambit stack is already in place,  quite non-complex matters, they're essentially simple applications of use of the stack model.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The threading needs interrupt hooks at regular intervals in the application code in order to function, which the compiler sugars the code with – this is a delicate topic that we will explore further below.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit's IO model is based on an event dispatcher loop centered around a select() OS call and use interrrupt timer functionality from the host OS. While Gambit does this in a particularly elegant way, in-application central IO/event dispatcher loops have been in a quite wide use since very long – since the inception of Unix systems, say – and has been refined into simple to use API:s in libraries such as libevent and libuv.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Therefore, even while lots of effort and exactitude is required for implementing this in a way that really spins uncompromisingly, we relate to this functionality as noncomplex.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Beyond the stack model, making Scheme code execute at speeds comparable with that of C, a careful design of the compiler – including extensive, complex optimizations – and of the VM/runtime system (type and object handling etc) are required. We discuss this in more detail below.&lt;br /&gt;
&lt;br /&gt;
Thus, we can now sum up complexity in Gambit, beyond that of a general programming environment such as that of Java, as being focalized to the design of the stack handling and to how the matters of how very high performance of code execution is achieved, which are dealed with by the compiler and the tuning of the details of the VM/runtime system design.&lt;br /&gt;
&lt;br /&gt;
==The C-level anatomy of Gambit and a Gambit-based application==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When having Gambit or a Gambit-based application in sourcecode form only, what steps are required to compile it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(running the configure script – the configure script generates ./Makefile *only* or other files too? - the Makefile as for use by make without parameters just as to compile the program, essentially only invokes the C compiler and linker for the different C files in the appropriate order? C files generated out of Gambit's runtime's scheme files, required to make compilation out of C code only work. ./configure and running make on the makefile is all needed to produce the C binaries? For distributing an application implemented in Gambit, only distributing the C files generated by Gambit for the application's Scheme files, is sufficient. Thus for such an application, add to the configure script/Makefile instructions to compile also the application's bundled C files, and include those in the linking process. Any advice on how to prepare such an Gambit application from C files distribution as easily as possible, are there any examples anywhere available?)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Conceptually, what does the configure script check for and what output files does it produce?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In what areas are there differences in what C/asm code of Gambit is used, between processors and platforms?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(the select loop and files and networking, how interrupt signals are made, more?  Native bit size of values of course.)&lt;br /&gt;
==The C-level anatomy of starting Gambit or a Gambit-based application==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When Gambit or a Gambit application is started, what is approximately the code flow of the initiation all way up to that Scheme code starts to execute? (roughly locations of the different functions in Gambit's C code, that are invoked) What OS calls are made/state for the Gambit OS process with the OS is set up, and what information is acquired from the host OS? What code is run to initialize the heap? What code is run to initialize the stack handling with its first  stack frame (perhaps this q should rather be put in the section about stack handling)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Structures==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Internally, are structures just special-type vectors?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is there any inheritance between structures, i.e. can I create a structure of type car and then make a subtype structure of type volvo? If so, how does this inheritance work – is it just that when making a volvo object, a vector is created with slots for all of a car's properties and appended to that is slots for all of volvo's properties too – how does the car property access procedures typecheck for if it's a car or a volvo?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Where in Gambit's code is the structure type handled, and what's the anotomy of this code?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==The ports/IO system==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Gambit has a variety of port types. Are the primary groupings/super-types of these, byte ports, character ports, and object ports? Is there some kind of strict inheritance between these, that each character ports is or contains a byte port too, and that every object port is or contains a character port too?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the IO/ports system and its sourcecode? At what places in Gambit's code is data sent/calls/mutations done to the OS as for Gambit to feed it with data, at what places in Gambit's code are things for Gambit to listen for events for (file handles, sockets, interrupt timeout?) inserted? How is the core IO-time scheduling done (on all platforms), is it by a select() or select()-equivalent call only, or is there any alternative return path from the OS into Gambit, during wait for timer timeout or IO input from the OS? (we discuss the reception and handling of timer interrupts separately in the section on threading.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the IO/ports system's sourcecode – which are the main procedures and code sites, approximately how does it fit together?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of a port, it's a structure with approx what properties, it has a will so it's shut down the right way when GC:ed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the code path for a |display| or |write| or |write-subu8vector| to a port, for various port types, all the way up to the end destination for the operation (the network device/OS file/target string buffer/etc).&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;At what points is the ports/IO system copying (both by function and by location in the sourcecode)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When select() has given an event for a file handle/socket, what is the code path that is invoked to propagate this event into the Scheme world?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does Gambit support select()-ing for more than 64 sockets on Windows? (this is a limit in Windows' select)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Console interaction and REPL==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Where is the sourcecode for the console interaction (incl libreadline kind of functionality) and REPL code, and what is the anatomy of this code?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What parts are in Scheme and what in C (I understand this would all better have been done in C but due to historic reasons right now some are in C)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If one would want to pipe REPL:s elsewhere than to the console, what hooks would be used? The place that spawns a REPL for uncaught exceptions, where is it so that one could direct those REPL:s to elsewhere than to the console REPL?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==The threading system==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How and where is the threading system bootstrapped? Where is the primordial thread initialized, and what makes it be the code that is actually the first to be run (except for, that at the time it's the only thread that exists)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is each thread a structure only? Roughly what properties does this structure have? How many bytes in size is this structure, on different architectures (32bit or 64bit)? Does Gambit provide any global state where threads and thread groups are stored, if so which is this structure and where is it declared, or does the caller need to keep references for them as not to GC?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How does Gambit ensure that interrupt checks are distributed in the code at such locations that smooth execution across threads is guaranteed, while the overhead for interrupt checking is kept low enough? How many % of code execution time is taken up by interrupt checks? The mechanism that puts interrupt checks in code is calibrated in such a way that there is no place in the code, no loop and so on, that is exempted from interrupt checks, in such a way that &amp;gt;1-2ms of code execution would happen without any interrupt check being made? So, (let loop ((at 0)) (if (##fx&amp;lt; at 1000000000) (loop (##fx+ at0)))) will never cause any issues with threading smoothness, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What principle is applied by Gambit when choosing what next thread to invoke? Where in Gambit's code are these therad switches made? If there's any particular complexity to the subject of making thread switches, please describe (such as, invoking the right trampolines or leaving the C/asm stack in the right condition or sth .. perhaps this is taken care of by the stack handling and that's it)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the thread switching mechanism: so first off, while not executing code but waiting for IO or timeouts from the OS, Gambit has a timer interrupt signal scheduled with the host OS (are these rescheduled all the time by Gambit, or is the OS set to recurringly make such interrupts at a certain interval forever)? Then, all Gambit-generated code is sugared all over with interrupt checks, so the interrupt signal handler procedure does something like mutating a global variable has_interrupt to true, and these interrupt checks do sth like if (has_interrupt) goto handle_interrupt or handle_interrupt(); depending on if the code is single-host or multiple-host? Then, does this handle_interrupt always check for stack overflow? What about heap overflow, or trigging a GC? How does it check if it's time to switch to another thread now? Does it do anything more? In case of switch to another thread, how is the current point of execution left in a way that maintains application/stack/etc integrity (perhaps that's a stack handling-section question)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Where/how is it configured for how long a thread should run before a switch is made to the next one? Is this a global or a per-thread configuration?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;While code can have (declare (not interrupts-enabled)) as not to accept any interrupts, the RTL is mostly compiled with interrupts enabled, so while inlined procedures such as + fall within the same interrupts-enabled setting as the code where it's used, non-inlined procedures such as assq do produce interrupts, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What's the anatomy of Gambit's threading system sourcecode, in what source files and locations are the threading system and the threading interrupts represented (I suppose the latter is in the compiler)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does the threading system schedule between threads based on the number of thread interrupts passed, or based on the amount of wall clock time passed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the dynamics of the priority, quantum and priority boost parameters to the threads, perhaps this is described completely enough in the specification document (don't remember its name or url right now)? If I want one thread to be of high priority and one of low, what parameters are needed? If I want one thread to get double or half as much CPU time as another, what parameters are needed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Beyond what has been covered above, is there any additional complexity to the threading system, or notable details not obvious from looking at its sourcecode?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Exceptions==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is the basic anatomy of the exceptions system, that first and foremost there is a |raise| procedure that takes one argument which is the exception value and which can be of any type, and, that in the dynamic environment there's a current exception handler parameter, that is a procedure, that is invoked on exception, and this is what with-exception-catcher and with-exception-handler uses to implement its functionality? So, the exception object type/-s is really a matter completely separated from the basic exception raising and catching mechanisms, and are only used as containers for conveying the content or message of each respective raised exception?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Gambit has a number of different exception types: os-exception, wrong-number-of-arguments-exception etc. etc.. Are these arranged in any kind of hierarchy? Are they all sub-structure-types of the exception type? Is there any way to get any kind of group type out of these?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Do any particular precautions need to be taken in order for a heap overflow exception to be handled 'safely', i.e. for the exception handling code not to unintendedly trig a new heap overflow exception in turn, that would terminate the program or cause otherwise unintended behavior?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==GC and memory handling (here regarding the default stop &amp;amp; copy gc)==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Which are the variables used for determining if it's time to perform a GC, and where is the code that maintains those counters?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the anatomy of a garbage collection, including what kind of state structures are used during the process (for the markings and for keeping track of finalizers). What state does the garbage collector keep between gc:s?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the entry point for making GC iterations, the ___gc() C procedure? Does the garbage collector have more entry points than this, if so what are they used for?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does Gambit have any quick reclaim mechanism for quickly discarding (GC:ing) objects that are not in use? Sth like, (define (a) (let ((b 1) (c 2.99999999999999) (d (make-string 1))) (+ b c)) – right at the point when a returns, is the memory for all of b, c and d immediately freed? Perhaps only b, because the compiler knew it took space only within the current stack frame and not otherwise on the heap so presuming the compiler knew to discard that stack frame quickly, it did. Does it discard c too (even while it occupies a little bit of heap space outside of the stack frame, no?) but not d, because b it knows what type it is of, but d was generated by an external procedure so quick freeing cannot be done but it will wait until the next GC?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How are finalizers handled? Because, I suppose, the finalizer needs to finish before the object is discarded. So, when an object with a finalizer ends up not marked by a GC process, then the GC makes a note of that object in some kind of list, and each such object has some kind of status flag that can be either of “finalizer not invoked”, “finalizer running” and “finalizer done”, and if it's “finalizer done” then the object is GC:ed,  and after each GC all entries with “finalizer not invoked”  are invoked? Please describe the possible states in here, where this state is stored, and which the state changes are and when the changes take place.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;There is no central index of all objects on the heap, they're just allocated space for in the chunks of system memory allocated by the memory handling mechanism right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is any particular design of the heap or stacks required, for there to be support for concurrent garbage collection? (in same cpu core or multicore)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Beyond freedom of bugs, were any particular strategies assumed in making Gambit free of buffer overflows and memory corruption bugs? (I'm clear this might be a pointless question)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Data types==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Every variable value in Scheme is represented internally as an integer, and has a tag about what fundamental data type the respective value is, right? What are the bit patterns in use for describing datatypes here? Where in Gambit's code is the basis for and use of those bit patterns implemented (as to know how to add or edit a type)? (I'm aware that fixnum is described by the two lowest bits being 0.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Whenever a variable value has a payload – some kind of object contents – a pointer to the memory address at which this payload is located, is included in every object reference on the heap for that object, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What was the motivation for using the lower bits in the variable values for the tag rather than the upper ones?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Hashtables==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;The hashtable and there used hashing algorithm, how does it work? Is there a paper anywhere that describes it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In what components/elements are hashtables stored internally (some kind of chain or tree I'd suppose, but what)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;By what reason is it that a table must not be mutated during table-for-each, what's the worstcase outcome if one mutates a table during it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is it possible to implement hashtables that fit together in a tree kind of shape, so that if I make table-set! on a parent then that one is visible to all child and grandchild etc. hashtables but not the other way around?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Numbers==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What are the rules for automatic type changes of numbers on number operations? Say, fixnum + flonum gives a flonum, that's obvious, but what about more complex cases – when are bignums generated, when are bignums scaled down to fixnums, and so on?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How are bignum structures stored internally, each such value is an object reference to a “bignum object”, and that object is a vector of integers that each contains a couple of decimals of the bignum value? With what procedures can I introspect and manipulate the element parts of a bignum value?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If one would want to change the structure format for the bignums, for instance for plugging in another bignum library, how would one go about for that?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==The compiler==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the basic anatomy of the compiler's sourcecode, and what is the basic code path that any compilation process takes? In all cases, I'm clear already there's two steps, a Scheme to GVM step, and a GVM to native code step (with the C backend or the native backend).&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the different phases that a compilation process takes (including any loops), and what form the sourcecode is stored in and what information form the compilation output is in, and what intermediary forms between sourcecode and compilation output are there and what's the purpose of those, in the different phases.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Approximately what optimizations are made by the compiler in the Scheme to GVM step and the GVM to C or native code steps respectively? (Let's define optimization as any logics that make the output code neater or faster than if that logics would not have been there, or if that logics would have been less well designed/thought through.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does the compiler look up all call/cc:s, and make a CPS conversion of all the code, during the compilation process? What is done with the CPS-converted code in order to generate the fastest or otherwise slimmest resultant code (if this is what the compiler does)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please list the academic papers and algorithm names that describe /something like/ what Gambit does during compilation.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If I wanted to implement a new primitive function that requires special (inlined) compiler output, say ##sysmem-byteref , where in the Scheme to GVM compiler's code and where in the C backend would a change need to be made, and approximately what kind of change would need to be made? &amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If I wanted to implement a new primitive conditional that requires special (inlined) compiler output, say a variant of |or| or |if| that we call |or/0| or |if/0| that treats fixnum 0 as #f, where in the Scheme to GVM compiler's code and where in the C backend would a change need to be made, and approximately what kind of change would need to be made? &amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Secondarily, I may want a first-class variant of this primitive too, for use both in compiled code and by the interpreter. What is a suitable place in Gambit's code to put a “wrapper” of the compiled version of ##sysmem-byteref to a first-class version of it, and how should that code look?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the general nature of the GVM language, and more specifically what kind of operations the GVM code language contains. Basically the GVM language describes procedures and their execution flows (stack operations, conditionals of the execution flow, jumps/invocations to procedures, trampolines?), and other than that it's invocations of primitives (+ etc)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please descrube the GVM code for a closure.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the GVM code for a conditional.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the GVM code for an invocation of a procedure with one or more arguments.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What state structures are needed to run a GVM (within C backend)? (both for the stack and to maintain the execution state needed to handle the juggling of host functions) Please describe with some detail – what's on the C stack, what's the structure of the processor struct and stack structures and so on.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the kind of functionality/functions needed by a GVM. So for instance, it needs to have a GC. What more? Some kind of stack handling machinery including dynamic addition and removal of slots to stack frames? (I suppose the entire concept of host procedures is within the C backend's architecture only, the GVM design in itself has nothing to do with those?)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In many places, exceptions are raised from a really low level point, say that + was applied to the wrong data type and now there's a type exception. How does the GVM code look for such handling, and how is this implemented in the C backend?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==The [GVM code to] C backend and the resultant object file==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the general anatomy of the C code output. (It is clear that each C file has some kind of headers and information structures inlined as constants, that are for somehow instructing the parent Gambit process what globals or alike the object file contains, rather than just code)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the basic execution flow of the C code in an object file? Right when it's loaded by the OS, which code in it is run? What is done? To feed the parent process with globals would, I suppose, be one. It is the parent process that then invokes an initialization routine in the object file, that invokes its top level code, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;The C code seems to be a pretty hardcore example of macro use. Is there any higher level of understanding or structure in all the macros that, if understood, makes it easier to understand the macro definitions and how the macros and their use fit together? What is the anatomy of the files with macro definitions?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When the host procedore returns (which happens basically between every evaluation step in code compiled with the safe declare), to what code in Gambit's runtime does it return then, what does that code do and in what condition does it jump back into the host procedore?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please descrube the C code for a closure.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the C code for a conditional.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the C code for an invocation of a procedure with one or more arguments.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Stack handling and related code generation aspects (including for GC traversibility, safety of stack overflows and call/cc) and trampolines==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Are stack frames the highest level of granularity that Gambit deals with stacks at, or do they have subcomponents (except for the slots for the individual contained values of course)? What about the code (define (a) (let ((b [value])) (let ((c [value])) [code1]) [code2])), what happens in the stack as code1 completes and code2 is started to be executed and c thus is disposed from the stack?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How many bytes does a stack frame occupy?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What contents does a continuation value or a continuation object value have, beyond (being) a reference to the stack frame to be executed on its invocation?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the dynamic environment and parameter values implemented? When invoking a continuation or there is a change of active thread, how is the switch of dynamic environment done?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the stack layout designed, as to be traversible by the GC? Were any particular considerations needed for this, to maintain the platform independentness of Gambit's C backend?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the stack layout designed, as to suit call/cc? What is the full mechanism of a call/cc, and what is the anatomy in site of a call/cc call, and, does it have any dependencies otherwise in the RTL?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;For the Gambit-generated native code to be safe for stack and heap overflows, it appears to me that there is basically some handling code between each step of every evaluation that involves the return of the host function. Why is this? Say that there is a processing loop, (let loop ((i 0)) (if (##fx&amp;lt; i 1000) (begin (##u8vector-set! u i (+ (u8vector-ref u i) 1) (loop (##fxnum+ i 1))))) say, why can't it just be one solid piece of code that executes through the loop just like that? What is the proof that stack overflow will never happen unless malloc fails?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How much C stack space does a Gambit process make use of? Can it be adjusted?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Debugging==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If a lowlevel crash would happen in a Gambit program, say somewhere outside the application's object files, what are the steps you normally would take/recommend as to determine the source of the error?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Design_guide</id>
		<title>Design guide</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Design_guide"/>
				<updated>2012-08-11T19:13:30Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
This document is intended to convey the understanding of Gambit that cannot be gotten from its manual, looking at its sourcecode, or reading the papers that underly its construction.&lt;br /&gt;
&lt;br /&gt;
Thus, the scope of this document is in contrast with and complementary to the manual's scope, which is to describe how Gambit is intended to be used by its user, to the sourcecode's scope, which is to describe the detail mechanics of Gambit at the highest level only, and to the papers and any other reference document, which each have a conceptually limited scope.&lt;br /&gt;
&lt;br /&gt;
The purpose of documenting this understanding of Gambit is general and multifacettated, and includes but is not limited to:&lt;br /&gt;
&lt;br /&gt;
* To convey why Gambit is a stable, working and robust software, for any uninterrupted short or long term use.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as it's reasonable that any user has a basic demand of 'getting it' about how Gambit works internally, as to be clear that the involved mechanisms are optimal and thus can be trusted to function well in any intended target environment and for any task; there indeed exists a lot of 'woo woo' technologies whose use bring with them all kinds of more or less predictable penalties, and it's of a general importance to clarify what game and league Gambit is in in this respect.)&lt;br /&gt;
&lt;br /&gt;
* To enable the user to adapt or extend Gambit himself, in the great majority of respects.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as Scheme's purpose is that of a language language, and thus it's expectable that use cases come up where customizations or extensions at any level of Gambit's architecture are needed. Most generally this would be about making Gambit work in a new operating environment, making customizations or tweaks to the io system, threads, numbers, and so on, or importantly, implementing some new or customized data type or operator.)&lt;br /&gt;
&lt;br /&gt;
* To enable the user to debug Gambit programs and Gambit itself at any level.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as while commercial or open source support may be available, it is several times key for a project to know that it is self-sustained and not dependent on contributions that are beyond its control, thus the need of making it feasible for anyone to dig into and understand Gambit internals, as to fix any unexpected behavior, in the very rare case that anything in this direction would manifest.)&lt;br /&gt;
&lt;br /&gt;
* To make digging into Gambit's sourcecode an as quick process as possible&lt;br /&gt;
&lt;br /&gt;
* To give the programmer clarity about how Gambit optimizes code / what optimizations Gambit applies / roughly what kind of machine code will be produced from a given Scheme code, and thus be able to write optimal code&lt;br /&gt;
&lt;br /&gt;
As to convey this understanding in the most effective way, it's written in the form of a conversation between the user (you) and the designer (Marc). This is as Gambit is a complex, holistic system that may possibly appear a bit nonlinear, where understanding of the involved concepts and how things fit together is of primary priority, and this is best made in the form of a conversation where for instance difference depths of detail can be used interchangably and crossreferences to other topics can be made quite liberally, rather than in the form of a monolithic final implementation reference over every involved bit and byte.&lt;br /&gt;
&lt;br /&gt;
At points the converation form between user and designer is rather to maintain a lingual clarity than a result of that it was actually a/the user or designer who wrote the respective text. The user's text is in bold and the designer's text is in normal style.&lt;br /&gt;
&lt;br /&gt;
This document is intended to be for the current version of Gambit (this doc was started at version 4.6.8), though obviously an answer may be for a previous Gambit version and there could be the need for an update of some section, in which case you are free to correct it yourself, and to enquire for clarifications on the mailing list.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Generally though, Gambit's sources are changed extremely rarely, so this ought to be a completely minor issue.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For now this document is in one piece only, which is this document, possibly it could be split into sections if it'd turn unnavigably large.&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
In this document we mean..&lt;br /&gt;
Gambit: The entire Gambit environment, including BSy and RTL (below).&lt;br /&gt;
BSy: The base Gambit system without the RTL. This is the most bare form Gambit can easily be stripped down to and still work.&lt;br /&gt;
RTL or runtime: The runtime library; please note that we use this term only because it's a well established term in the programming world – we use it to refer to all of Gambit beyond the BSy, and this obviously includes the evaluator, compiler, threading system and so on, which are of a much higher complexity than a typical RTL.&lt;br /&gt;
Compiler: Gambit's compilation mechanism, including the Scheme to GVM compiler and all backends.&lt;br /&gt;
GVM / Gambit VM: The particular design of C/binary code generated by the Gambit compiler backend as regards code execution flow within and between modules, and in relation with certain lowlevel runtime functionality as to make the stack model and thread interrupts spin.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Also, GVM is the intermediary format that Gambit compiles Scheme code to, and which the respective compiler backend takes as input for binary generation.&amp;lt;/div&amp;gt;&lt;br /&gt;
[Thread] interrupts: Checkpoints spread across Gambit-generated code, at which stack and heap(???) overflow conditions are checked for, and switches of activity into the threading system is made, if applicable. Also the GC may be invoked here??&lt;br /&gt;
&lt;br /&gt;
==Taking it down to earth: What complexity is involved in Gambit really==&lt;br /&gt;
&lt;br /&gt;
Compared with a general programming language such as, say, C or Java, the workings of a Scheme environment may appear to the unintroduced as unclear and abstract, and thus not really something to trust (as per the way of conduct, that what you don't want to use mechanisms that you don't understand – nonsimplistic, nonoptimal or otherwise 'woo woo' mechanisms could lead to all kinds of dire penalties down the road, and thus we better get clarity about this while at the introductory step).&lt;br /&gt;
&lt;br /&gt;
Let's dig into this topic as to bring an overview-level clarity on what complexity is involved in Gambit.&lt;br /&gt;
&lt;br /&gt;
First, let's get clear about the components involved in Gambit as a system, in contrast with those of a typical general programming system:&lt;br /&gt;
&lt;br /&gt;
Both the C and Java programming systems have the following design: The essential components are the shell, compiler, loader and the execution with the runtime.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell as provided by the OS, or other functional equivalent, is the tool for invoking the compiler and loader-execution.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The compiler is a separate application that compiles language sourcecode to a binary object form. The compiler can but does not need to be implemented in the language itself.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The loader is either part of the parent operating system (which is the case in C), or an application that loads and boostraps binary code generated by the compiler (which is the case in Java). Execution is performed atop the OS, possibly atop a VM application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The runtime is a library written in the language (and possibly some code in a lower-level language i.e. assembly/C), that provides some bootstrap code for any application, and elementary procedures and type definitions that are of general use for application implementors, as not to need to reimplement elementary functionality like data type handling, and routines for interfacing common mechanisms in the underlying operating system such as console and file I/O, OS threads and networking.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell and compiler are separate binary files (with dependencies), the loader and execution possibly performed by a separate binary file (with dependencies), and the runtime library is a separate set of binary files. Compiler-generated binaries are separate binary files.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit as a holistic Scheme system has a slightly different design: (As a side note, Gambit's design in these respects is basically the same as many earlier Lisp and Scheme systems – i.e. Gambit is traditional in this respect.)&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The Scheme system [Gambit] is a separate application. It is rather typically running as a process within a host operating system, but can also run as a operating system image itself, directly on the host processor.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Gambit (the system) performs both the shell, compilation, loading and the execution step and itself contains the runtime, and the steps are performed without any need for restart or other interruption of the system. Thus, at the level of concept, Gambit as a programming system also has the characteristics of an operating system. This kind of adds to its holisticness – it's an application-level programming operating-system-environment.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;(If using the C backend, the C compiler of the host operating system is invoked by Gambit, though that's a detail – during this phase Gambit is running and actively waiting in the backround for the C compiler to finish, as to continue to the next step.) (Loading of C-backend-generated binaries is done by Gambit invoking the underlying operating system's functionality for dynamic library loading, though this is a detail too.)&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In Gambit, the compiler is implemented as part of the RTL and generally invoked as a procedure. Loading and execution are procedures too, and all of these procedures are accessed directly from the shell, called the Read-Eval-Print Loop.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The user is free to make individual executions of Gambit for each compilation or other task the user wants Gambit to perform, for instance for the task of compiling a source file to a binary file, which is how compilation is done in C and Java. The point here though is that this optional, not required.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell, compiler, loader, execution mechanism and runtime are generally all combined in one and the same binary file. (There is a version without the compiler.) Compiler-generated binaries are by default separate files, and can be merged with the compiler file thus generating a single executable binary for a compiled application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Thus, to sum this up:&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In C and Java programming systems, the compiler is a separately invoked application (possibly launched by the loader), the loader and execution are handled in a separate step, and both of these are invoked from the OS shell being another separate application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In Gambit, there is one centerpiece application namely the entire system itself, which performs the shell, compiling, loading and execution steps in one piece.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
So now we're clear about how the programming environment is set up and that this way of doing things is indeed straightforward, and the next thing for us to look at is, what kind of complexity is needed to make this spin.&lt;br /&gt;
&lt;br /&gt;
Gambit is comparable in terms of complexity, with any general garbage collected language such as Java, with its stack model being the big exception: while the general programming languages tend to have a direct style stack that is implemented directly atop the underlying C/assembly-level stack mechanism.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Due to that the additional stack handling required by these languages is zero or very small, beyond what's provided already by the OS and the assembly language, and that the concepts of OS&amp;amp;asm mechanisms are so basic in all cases, the stack is generally viewed as a noncomplex matter in these languages.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;(By direct style stack, we mean that there's procedure calls stored on a fixed-size stack, every call should conceptually be neutralized by by a procedure return as for the app not to eventually run out of stack space, and returns generally return to the stack level directly below it in the stack, or in the case of exceptions, multiple steps, until the place of the closest exception handler, or in the case of application termination, the application terminates and the entire stack is discarded.)&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Gambit is stackless. The stack functionality is performed through stack frame objects, that are linked together in a tree (or web) that's possibly cyclical. To make code in this environment execute run with an optimal speed (the as that of C code doing approx the same thing), extensive optimizations are applied to the stack handling.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;While the concepts of stacklessness and stack frame objects ought to be straightforward enough, the details of how Gambit actually performs this, may be a very complex matter, and therefore we will explore this topic in detail below.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit's threading and exception handling mechanisms are, given that the Gambit stack is already in place,  quite non-complex matters, they're essentially simple applications of use of the stack model.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The threading needs interrupt hooks at regular intervals in the application code in order to function, which the compiler sugars the code with – this is a delicate topic that we will explore further below.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit's IO model is based on an event dispatcher loop centered around a select() OS call and use interrrupt timer functionality from the host OS. While Gambit does this in a particularly elegant way, in-application central IO/event dispatcher loops have been in a quite wide use since very long – since the inception of Unix systems, say – and has been refined into simple to use API:s in libraries such as libevent and libuv.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Therefore, even while lots of effort and exactitude is required for implementing this in a way that really spins uncompromisingly, we relate to this functionality as noncomplex.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Beyond the stack model, making Scheme code execute at speeds comparable with that of C, a careful design of the compiler – including extensive, complex optimizations – and of the VM/runtime system (type and object handling etc) are required. We discuss this in more detail below.&lt;br /&gt;
&lt;br /&gt;
Thus, we can now sum up complexity in Gambit, beyond that of a general programming environment such as that of Java, as being focalized to the design of the stack handling and to how the matters of how very high performance of code execution is achieved, which are dealed with by the compiler and the tuning of the details of the VM/runtime system design.&lt;br /&gt;
&lt;br /&gt;
==The C-level anatomy of Gambit and a Gambit-based application==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When having Gambit or a Gambit-based application in sourcecode form only, what steps are required to compile it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(running the configure script – the configure script generates ./Makefile *only* or other files too? - the Makefile as for use by make without parameters just as to compile the program, essentially only invokes the C compiler and linker for the different C files in the appropriate order? C files generated out of Gambit's runtime's scheme files, required to make compilation out of C code only work. ./configure and running make on the makefile is all needed to produce the C binaries? For distributing an application implemented in Gambit, only distributing the C files generated by Gambit for the application's Scheme files, is sufficient. Thus for such an application, add to the configure script/Makefile instructions to compile also the application's bundled C files, and include those in the linking process. Any advice on how to prepare such an Gambit application from C files distribution as easily as possible, are there any examples anywhere available?)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Conceptually, what does the configure script check for and what output files does it produce?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In what areas are there differences in what C/asm code of Gambit is used, between processors and platforms?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(the select loop and files and networking, how interrupt signals are made, more?  Native bit size of values of course.)&lt;br /&gt;
==The C-level anatomy of starting Gambit or a Gambit-based application==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When Gambit or a Gambit application is started, what is approximately the code flow of the initiation all way up to that Scheme code starts to execute? (roughly locations of the different functions in Gambit's C code, that are invoked) What OS calls are made/state for the Gambit OS process with the OS is set up, and what information is acquired from the host OS? What code is run to initialize the heap? What code is run to initialize the stack handling with its first  stack frame (perhaps this q should rather be put in the section about stack handling)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Structures==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Internally, are structures just special-type vectors?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is there any inheritance between structures, i.e. can I create a structure of type car and then make a subtype structure of type volvo? If so, how does this inheritance work – is it just that when making a volvo object, a vector is created with slots for all of a car's properties and appended to that is slots for all of volvo's properties too – how does the car property access procedures typecheck for if it's a car or a volvo?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Where in Gambit's code is the structure type handled, and what's the anotomy of this code?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==The ports/IO system==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Gambit has a variety of port types. Are the primary groupings/super-types of these, byte ports, character ports, and object ports? Is there some kind of strict inheritance between these, that each character ports is or contains a byte port too, and that every object port is or contains a character port too?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the IO/ports system and its sourcecode? At what places in Gambit's code is data sent/calls/mutations done to the OS as for Gambit to feed it with data, at what places in Gambit's code are things for Gambit to listen for events for (file handles, sockets, interrupt timeout?) inserted? How is the core IO-time scheduling done (on all platforms), is it by a select() or select()-equivalent call only, or is there any alternative return path from the OS into Gambit, during wait for timer timeout or IO input from the OS? (we discuss the reception and handling of timer interrupts separately in the section on threading.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the IO/ports system's sourcecode – which are the main procedures and code sites, approximately how does it fit together?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of a port, it's a structure with approx what properties, it has a will so it's shut down the right way when GC:ed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the code path for a |display| or |write| or |write-subu8vector| to a port, for various port types, all the way up to the end destination for the operation (the network device/OS file/target string buffer/etc).&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;At what points is the ports/IO system copying (both by function and by location in the sourcecode)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When select() has given an event for a file handle/socket, what is the code path that is invoked to propagate this event into the Scheme world?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does Gambit support select()-ing for more than 64 sockets on Windows? (this is a limit in Windows' select)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Console interaction and REPL==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Where is the sourcecode for the console interaction (incl libreadline kind of functionality) and REPL code, and what is the anatomy of this code?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What parts are in Scheme and what in C (I understand this would all better have been done in C but due to historic reasons right now some are in C)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If one would want to pipe REPL:s elsewhere than to the console, what hooks would be used? The place that spawns a REPL for uncaught exceptions, where is it so that one could direct those REPL:s to elsewhere than to the console REPL?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==The threading system==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How and where is the threading system bootstrapped? Where is the primordial thread initialized, and what makes it be the code that is actually the first to be run (except for, that at the time it's the only thread that exists)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is each thread a structure only? Roughly what properties does this structure have? How many bytes in size is this structure, on different architectures (32bit or 64bit)? Does Gambit provide any global state where threads and thread groups are stored, if so which is this structure and where is it declared, or does the caller need to keep references for them as not to GC?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How does Gambit ensure that interrupt checks are distributed in the code at such locations that smooth execution across threads is guaranteed, while the overhead for interrupt checking is kept low enough? How many % of code execution time is taken up by interrupt checks? The mechanism that puts interrupt checks in code is calibrated in such a way that there is no place in the code, no loop and so on, that is exempted from interrupt checks, in such a way that &amp;gt;1-2ms of code execution would happen without any interrupt check being made? So, (let loop ((at 0)) (if (##fx&amp;lt; at 1000000000) (loop (##fx+ at0)))) will never cause any issues with threading smoothness, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What principle is applied by Gambit when choosing what next thread to invoke? Where in Gambit's code are these therad switches made? If there's any particular complexity to the subject of making thread switches, please describe (such as, invoking the right trampolines or leaving the C/asm stack in the right condition or sth .. perhaps this is taken care of by the stack handling and that's it)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the thread switching mechanism: so first off, while not executing code but waiting for IO or timeouts from the OS, Gambit has a timer interrupt signal scheduled with the host OS (are these rescheduled all the time by Gambit, or is the OS set to recurringly make such interrupts at a certain interval forever)? Then, all Gambit-generated code is sugared all over with interrupt checks, so the interrupt signal handler procedure does something like mutating a global variable has_interrupt to true, and these interrupt checks do sth like if (has_interrupt) goto handle_interrupt or handle_interrupt(); depending on if the code is single-host or multiple-host? Then, does this handle_interrupt always check for stack overflow? What about heap overflow, or trigging a GC? How does it check if it's time to switch to another thread now? Does it do anything more? In case of switch to another thread, how is the current point of execution left in a way that maintains application/stack/etc integrity (perhaps that's a stack handling-section question)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Where/how is it configured for how long a thread should run before a switch is made to the next one? Is this a global or a per-thread configuration?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;While code can have (declare (not interrupts-enabled)) as not to accept any interrupts, the RTL is mostly compiled with interrupts enabled, so while inlined procedures such as + fall within the same interrupts-enabled setting as the code where it's used, non-inlined procedures such as assq do produce interrupts, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What's the anatomy of Gambit's threading system sourcecode, in what source files and locations are the threading system and the threading interrupts represented (I suppose the latter is in the compiler)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does the threading system schedule between threads based on the number of thread interrupts passed, or based on the amount of wall clock time passed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the dynamics of the priority, quantum and priority boost parameters to the threads, perhaps this is described completely enough in the specification document (don't remember its name or url right now)? If I want one thread to be of high priority and one of low, what parameters are needed? If I want one thread to get double or half as much CPU time as another, what parameters are needed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Beyond what has been covered above, is there any additional complexity to the threading system, or notable details not obvious from looking at its sourcecode?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Exceptions==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is the basic anatomy of the exceptions system, that first and foremost there is a |raise| procedure that takes one argument which is the exception value and which can be of any type, and, that in the dynamic environment there's a current exception handler parameter, that is a procedure, that is invoked on exception, and this is what with-exception-catcher and with-exception-handler uses to implement its functionality? So, the exception object type/-s is really a matter completely separated from the basic exception raising and catching mechanisms, and are only used as containers for conveying the content or message of each respective raised exception?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Gambit has a number of different exception types: os-exception, wrong-number-of-arguments-exception etc. etc.. Are these arranged in any kind of hierarchy? Are they all sub-structure-types of the exception type? Is there any way to get any kind of group type out of these?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Do any particular precautions need to be taken in order for a heap overflow exception to be handled 'safely', i.e. for the exception handling code not to unintendedly trig a new heap overflow exception in turn, that would terminate the program or cause otherwise unintended behavior?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==GC and memory handling (here regarding the default stop &amp;amp; copy gc)==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Which are the variables used for determining if it's time to perform a GC, and where is the code that maintains those counters?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the anatomy of a garbage collection, including what kind of state structures are used during the process (for the markings and for keeping track of finalizers). What state does the garbage collector keep between gc:s?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the entry point for making GC iterations, the ___gc() C procedure? Does the garbage collector have more entry points than this, if so what are they used for?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does Gambit have any quick reclaim mechanism for quickly discarding (GC:ing) objects that are not in use? Sth like, (define (a) (let ((b 1) (c 2.99999999999999) (d (make-string 1))) (+ b c)) – right at the point when a returns, is the memory for all of b, c and d immediately freed? Perhaps only b, because the compiler knew it took space only within the current stack frame and not otherwise on the heap so presuming the compiler knew to discard that stack frame quickly, it did. Does it discard c too (even while it occupies a little bit of heap space outside of the stack frame, no?) but not d, because b it knows what type it is of, but d was generated by an external procedure so quick freeing cannot be done but it will wait until the next GC?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How are finalizers handled? Because, I suppose, the finalizer needs to finish before the object is discarded. So, when an object with a finalizer ends up not marked by a GC process, then the GC makes a note of that object in some kind of list, and each such object has some kind of status flag that can be either of “finalizer not invoked”, “finalizer running” and “finalizer done”, and if it's “finalizer done” then the object is GC:ed,  and after each GC all entries with “finalizer not invoked”  are invoked? Please describe the possible states in here, where this state is stored, and which the state changes are and when the changes take place.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;There is no central index of all objects on the heap, they're just allocated space for in the chunks of system memory allocated by the memory handling mechanism right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is any particular design of the heap or stacks required, for there to be support for concurrent garbage collection? (in same cpu core or multicore)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Beyond freedom of bugs, were any particular strategies assumed in making Gambit free of buffer overflows and memory corruption bugs? (I'm clear this might be a pointless question)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Data types==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Every variable value in Scheme is represented internally as an integer, and has a tag about what fundamental data type the respective value is, right? What are the bit patterns in use for describing datatypes here? Where in Gambit's code is the basis for and use of those bit patterns implemented (as to know how to add or edit a type)? (I'm aware that fixnum is described by the two lowest bits being 0.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Whenever a variable value has a payload – some kind of object contents – a pointer to the memory address at which this payload is located, is included in every object reference on the heap for that object, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What was the motivation for using the lower bits in the variable values for the tag rather than the upper ones?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Hashtables==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;The hashtable and there used hashing algorithm, how does it work? Is there a paper anywhere that describes it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In what components/elements are hashtables stored internally (some kind of chain or tree I'd suppose, but what)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;By what reason is it that a table must not be mutated during table-for-each, what's the worstcase outcome if one mutates a table during it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is it possible to implement hashtables that fit together in a tree kind of shape, so that if I make table-set! on a parent then that one is visible to all child and grandchild etc. hashtables but not the other way around?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Numbers==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What are the rules for automatic type changes of numbers on number operations? Say, fixnum + flonum gives a flonum, that's obvious, but what about more complex cases – when are bignums generated, when are bignums scaled down to fixnums, and so on?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How are bignum structures stored internally, each such value is an object reference to a “bignum object”, and that object is a vector of integers that each contains a couple of decimals of the bignum value? With what procedures can I introspect and manipulate the element parts of a bignum value?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If one would want to change the structure format for the bignums, for instance for plugging in another bignum library, how would one go about for that?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==The Compiler==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the basic anatomy of the compiler's sourcecode, and what is the basic code path that any compilation process takes? In all cases, I'm clear already there's two steps, a Scheme to GVM step, and a GVM to native code step (with the C backend or the native backend).&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the different phases that a compilation process takes (including any loops), and what form the sourcecode is stored in and what information form the compilation output is in, and what intermediary forms between sourcecode and compilation output are there and what's the purpose of those, in the different phases.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Approximately what optimizations are made by the compiler in the Scheme to GVM step and the GVM to C or native code steps respectively? (Let's define optimization as any logics that make the output code neater or faster than if that logics would not have been there, or if that logics would have been less well designed/thought through.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does the compiler look up all call/cc:s, and make a CPS conversion of all the code, during the compilation process? What is done with the CPS-converted code in order to generate the fastest or otherwise slimmest resultant code (if this is what the compiler does)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please list the academic papers and algorithm names that describe /something like/ what Gambit does during compilation.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If I wanted to implement a new primitive function that requires special (inlined) compiler output, say ##sysmem-byteref , where in the Scheme to GVM compiler's code and where in the C backend would a change need to be made, and approximately what kind of change would need to be made? &amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If I wanted to implement a new primitive conditional that requires special (inlined) compiler output, say a variant of |or| or |if| that we call |or/0| or |if/0| that treats fixnum 0 as #f, where in the Scheme to GVM compiler's code and where in the C backend would a change need to be made, and approximately what kind of change would need to be made? &amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Secondarily, I may want a first-class variant of this primitive too, for use both in compiled code and by the interpreter. What is a suitable place in Gambit's code to put a “wrapper” of the compiled version of ##sysmem-byteref to a first-class version of it, and how should that code look?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the general nature of the GVM language, and more specifically what kind of operations the GVM code language contains. Basically the GVM language describes procedures and their execution flows (stack operations, conditionals of the execution flow, jumps/invocations to procedures, trampolines?), and other than that it's invocations of primitives (+ etc)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please descrube the GVM code for a closure.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the GVM code for a conditional.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the GVM code for an invocation of a procedure with one or more arguments.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What state structures are needed to run a GVM (within C backend)? (both for the stack and to maintain the execution state needed to handle the juggling of host functions) Please describe with some detail – what's on the C stack, what's the structure of the processor struct and stack structures and so on.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the kind of functionality/functions needed by a GVM. So for instance, it needs to have a GC. What more? Some kind of stack handling machinery including dynamic addition and removal of slots to stack frames? (I suppose the entire concept of host procedures is within the C backend's architecture only, the GVM design in itself has nothing to do with those?)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In many places, exceptions are raised from a really low level point, say that + was applied to the wrong data type and now there's a type exception. How does the GVM code look for such handling, and how is this implemented in the C backend?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==The [GVM code to] C backend and the resultant object file==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the general anatomy of the C code output. (It is clear that each C file has some kind of headers and information structures inlined as constants, that are for somehow instructing the parent Gambit process what globals or alike the object file contains, rather than just code)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the basic execution flow of the C code in an object file? Right when it's loaded by the OS, which code in it is run? What is done? To feed the parent process with globals would, I suppose, be one. It is the parent process that then invokes an initialization routine in the object file, that invokes its top level code, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;The C code seems to be a pretty hardcore example of macro use. Is there any higher level of understanding or structure in all the macros that, if understood, makes it easier to understand the macro definitions and how the macros and their use fit together? What is the anatomy of the files with macro definitions?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When the host procedore returns (which happens basically between every evaluation step in code compiled with the safe declare), to what code in Gambit's runtime does it return then, what does that code do and in what condition does it jump back into the host procedore?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please descrube the C code for a closure.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the C code for a conditional.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the C code for an invocation of a procedure with one or more arguments.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Stack handling and related code generation aspects (including for GC traversibility, safety of stack overflows and call/cc) and trampolines==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Are stack frames the highest level of granularity that Gambit deals with stacks at, or do they have subcomponents (except for the slots for the individual contained values of course)? What about the code (define (a) (let ((b [value])) (let ((c [value])) [code1]) [code2])), what happens in the stack as code1 completes and code2 is started to be executed and c thus is disposed from the stack?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How many bytes does a stack frame occupy?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What contents does a continuation value or a continuation object value have, beyond (being) a reference to the stack frame to be executed on its invocation?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the dynamic environment and parameter values implemented? When invoking a continuation or there is a change of active thread, how is the switch of dynamic environment done?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the stack layout designed, as to be traversible by the GC? Were any particular considerations needed for this, to maintain the platform independentness of Gambit's C backend?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the stack layout designed, as to suit call/cc? What is the full mechanism of a call/cc, and what is the anatomy in site of a call/cc call, and, does it have any dependencies otherwise in the RTL?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;For the Gambit-generated native code to be safe for stack and heap overflows, it appears to me that there is basically some handling code between each step of every evaluation that involves the return of the host function. Why is this? Say that there is a processing loop, (let loop ((i 0)) (if (##fx&amp;lt; i 1000) (begin (##u8vector-set! u i (+ (u8vector-ref u i) 1) (loop (##fxnum+ i 1))))) say, why can't it just be one solid piece of code that executes through the loop just like that? What is the proof that stack overflow will never happen unless malloc fails?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How much C stack space does a Gambit process make use of? Can it be adjusted?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Debugging==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If a lowlevel crash would happen in a Gambit program, say somewhere outside the application's object files, what are the steps you normally would take/recommend as to determine the source of the error?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Design_guide</id>
		<title>Design guide</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Design_guide"/>
				<updated>2012-08-11T18:53:09Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: Created page with &amp;quot;==Introduction== This document is intended to convey the understanding of Gambit that cannot be gotten from its manual, looking at its sourcecode, or reading the papers that unde...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Introduction==&lt;br /&gt;
This document is intended to convey the understanding of Gambit that cannot be gotten from its manual, looking at its sourcecode, or reading the papers that underly its construction.&lt;br /&gt;
&lt;br /&gt;
Thus, the scope of this document is in contrast with and complementary to the manual's scope, which is to describe how Gambit is intended to be used by its user, to the sourcecode's scope, which is to describe the detail mechanics of Gambit at the highest level only, and to the papers and any other reference document, which each have a conceptually limited scope.&lt;br /&gt;
&lt;br /&gt;
The purpose of documenting this understanding of Gambit is general and multifacettated, and includes but is not limited to:&lt;br /&gt;
&lt;br /&gt;
* To convey why Gambit is a stable, working and robust software, for any uninterrupted short or long term use.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as it's reasonable that any user has a basic demand of 'getting it' about how Gambit works internally, as to be clear that the involved mechanisms are optimal and thus can be trusted to function well in any intended target environment and for any task; there indeed exists a lot of 'woo woo' technologies whose use bring with them all kinds of more or less predictable penalties, and it's of a general importance to clarify what game and league Gambit is in in this respect.)&lt;br /&gt;
&lt;br /&gt;
* To enable the user to adapt or extend Gambit himself, in the great majority of respects.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as Scheme's purpose is that of a language language, and thus it's expectable that use cases come up where customizations or extensions at any level of Gambit's architecture are needed. Most generally this would be about making Gambit work in a new operating environment, making customizations or tweaks to the io system, threads, numbers, and so on, or importantly, implementing some new or customized data type or operator.)&lt;br /&gt;
&lt;br /&gt;
* To enable the user to debug Gambit programs and Gambit itself at any level.&amp;lt;br/&amp;gt;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;(This is, as while commercial or open source support may be available, it is several times key for a project to know that it is self-sustained and not dependent on contributions that are beyond its control, thus the need of making it feasible for anyone to dig into and understand Gambit internals, as to fix any unexpected behavior, in the very rare case that anything in this direction would manifest.)&lt;br /&gt;
&lt;br /&gt;
* To make digging into Gambit's sourcecode an as quick process as possible&lt;br /&gt;
&lt;br /&gt;
* To give the programmer clarity about how Gambit optimizes code / what optimizations Gambit applies / roughly what kind of machine code will be produced from a given Scheme code, and thus be able to write optimal code&lt;br /&gt;
&lt;br /&gt;
As to convey this understanding in the most effective way, it's written in the form of a conversation between the user (you) and the designer (Marc). This is as Gambit is a complex, holistic system that may possibly appear a bit nonlinear, where understanding of the involved concepts and how things fit together is of primary priority, and this is best made in the form of a conversation where for instance difference depths of detail can be used interchangably and crossreferences to other topics can be made quite liberally, rather than in the form of a monolithic final implementation reference over every involved bit and byte.&lt;br /&gt;
&lt;br /&gt;
At points the converation form between user and designer is rather to maintain a lingual clarity than a result of that it was actually a/the user or designer who wrote the respective text. The user's text is in bold and the designer's text is in normal style.&lt;br /&gt;
&lt;br /&gt;
This document is intended to be for the current version of Gambit (this doc was started at version 4.6.8), though obviously an answer may be for a previous Gambit version and there could be the need for an update of some section, in which case you are free to correct it yourself, and to enquire for clarifications on the mailing list.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Generally though, Gambit's sources are changed extremely rarely, so this ought to be a completely minor issue.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For now this document is in one piece only, which is this document, possibly it could be split into sections if it'd turn unnavigably large.&lt;br /&gt;
&lt;br /&gt;
==Definitions==&lt;br /&gt;
In this document we mean..&lt;br /&gt;
Gambit: The entire Gambit environment, including BSy and RTL (below).&lt;br /&gt;
BSy: The base Gambit system without the RTL. This is the most bare form Gambit can easily be stripped down to and still work.&lt;br /&gt;
RTL or runtime: The runtime library; please note that we use this term only because it's a well established term in the programming world – we use it to refer to all of Gambit beyond the BSy, and this obviously includes the evaluator, compiler, threading system and so on, which are of a much higher complexity than a typical RTL.&lt;br /&gt;
Compiler: Gambit's compilation mechanism, including the Scheme to GVM compiler and all backends.&lt;br /&gt;
GVM / Gambit VM: The particular design of C/binary code generated by the Gambit compiler backend as regards code execution flow within and between modules, and in relation with certain lowlevel runtime functionality as to make the stack model and thread interrupts spin.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Also, GVM is the intermediary format that Gambit compiles Scheme code to, and which the respective compiler backend takes as input for binary generation.&amp;lt;/div&amp;gt;&lt;br /&gt;
[Thread] interrupts: Checkpoints spread across Gambit-generated code, at which stack and heap(???) overflow conditions are checked for, and switches of activity into the threading system is made, if applicable. Also the GC may be invoked here??&lt;br /&gt;
&lt;br /&gt;
==Taking it down to earth: What complexity is involved in Gambit really==&lt;br /&gt;
&lt;br /&gt;
Compared with a general programming language such as, say, C or Java, the workings of a Scheme environment may appear to the unintroduced as unclear and abstract, and thus not really something to trust (as per the way of conduct, that what you don't want to use mechanisms that you don't understand – nonsimplistic, nonoptimal or otherwise 'woo woo' mechanisms could lead to all kinds of dire penalties down the road, and thus we better get clarity about this while at the introductory step).&lt;br /&gt;
&lt;br /&gt;
Let's dig into this topic as to bring an overview-level clarity on what complexity is involved in Gambit.&lt;br /&gt;
&lt;br /&gt;
First, let's get clear about the components involved in Gambit as a system, in contrast with those of a typical general programming system:&lt;br /&gt;
&lt;br /&gt;
Both the C and Java programming systems have the following design: The essential components are the shell, compiler, loader and the execution with the runtime.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell as provided by the OS, or other functional equivalent, is the tool for invoking the compiler and loader-execution.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The compiler is a separate application that compiles language sourcecode to a binary object form. The compiler can but does not need to be implemented in the language itself.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The loader is either part of the parent operating system (which is the case in C), or an application that loads and boostraps binary code generated by the compiler (which is the case in Java). Execution is performed atop the OS, possibly atop a VM application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The runtime is a library written in the language (and possibly some code in a lower-level language i.e. assembly/C), that provides some bootstrap code for any application, and elementary procedures and type definitions that are of general use for application implementors, as not to need to reimplement elementary functionality like data type handling, and routines for interfacing common mechanisms in the underlying operating system such as console and file I/O, OS threads and networking.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell and compiler are separate binary files (with dependencies), the loader and execution possibly performed by a separate binary file (with dependencies), and the runtime library is a separate set of binary files. Compiler-generated binaries are separate binary files.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit as a holistic Scheme system has a slightly different design: (As a side note, Gambit's design in these respects is basically the same as many earlier Lisp and Scheme systems – i.e. Gambit is traditional in this respect.)&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The Scheme system [Gambit] is a separate application. It is rather typically running as a process within a host operating system, but can also run as a operating system image itself, directly on the host processor.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Gambit (the system) performs both the shell, compilation, loading and the execution step and itself contains the runtime, and the steps are performed without any need for restart or other interruption of the system. Thus, at the level of concept, Gambit as a programming system also has the characteristics of an operating system. This kind of adds to its holisticness – it's an application-level programming operating-system-environment.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;(If using the C backend, the C compiler of the host operating system is invoked by Gambit, though that's a detail – during this phase Gambit is running and actively waiting in the backround for the C compiler to finish, as to continue to the next step.) (Loading of C-backend-generated binaries is done by Gambit invoking the underlying operating system's functionality for dynamic library loading, though this is a detail too.)&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In Gambit, the compiler is implemented as part of the RTL and generally invoked as a procedure. Loading and execution are procedures too, and all of these procedures are accessed directly from the shell, called the Read-Eval-Print Loop.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The user is free to make individual executions of Gambit for each compilation or other task the user wants Gambit to perform, for instance for the task of compiling a source file to a binary file, which is how compilation is done in C and Java. The point here though is that this optional, not required.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The shell, compiler, loader, execution mechanism and runtime are generally all combined in one and the same binary file. (There is a version without the compiler.) Compiler-generated binaries are by default separate files, and can be merged with the compiler file thus generating a single executable binary for a compiled application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Thus, to sum this up:&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In C and Java programming systems, the compiler is a separately invoked application (possibly launched by the loader), the loader and execution are handled in a separate step, and both of these are invoked from the OS shell being another separate application.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;In Gambit, there is one centerpiece application namely the entire system itself, which performs the shell, compiling, loading and execution steps in one piece.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
So now we're clear about how the programming environment is set up and that this way of doing things is indeed straightforward, and the next thing for us to look at is, what kind of complexity is needed to make this spin.&lt;br /&gt;
&lt;br /&gt;
Gambit is comparable in terms of complexity, with any general garbage collected language such as Java, with its stack model being the big exception: while the general programming languages tend to have a direct style stack that is implemented directly atop the underlying C/assembly-level stack mechanism.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Due to that the additional stack handling required by these languages is zero or very small, beyond what's provided already by the OS and the assembly language, and that the concepts of OS&amp;amp;asm mechanisms are so basic in all cases, the stack is generally viewed as a noncomplex matter in these languages.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;(By direct style stack, we mean that there's procedure calls stored on a fixed-size stack, every call should conceptually be neutralized by by a procedure return as for the app not to eventually run out of stack space, and returns generally return to the stack level directly below it in the stack, or in the case of exceptions, multiple steps, until the place of the closest exception handler, or in the case of application termination, the application terminates and the entire stack is discarded.)&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Gambit is stackless. The stack functionality is performed through stack frame objects, that are linked together in a tree (or web) that's possibly cyclical. To make code in this environment execute run with an optimal speed (the as that of C code doing approx the same thing), extensive optimizations are applied to the stack handling.&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;While the concepts of stacklessness and stack frame objects ought to be straightforward enough, the details of how Gambit actually performs this, may be a very complex matter, and therefore we will explore this topic in detail below.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit's threading and exception handling mechanisms are, given that the Gambit stack is already in place,  quite non-complex matters, they're essentially simple applications of use of the stack model.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;The threading needs interrupt hooks at regular intervals in the application code in order to function, which the compiler sugars the code with – this is a delicate topic that we will explore further below.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Gambit's IO model is based on an event dispatcher loop centered around a select() OS call and use interrrupt timer functionality from the host OS. While Gambit does this in a particularly elegant way, in-application central IO/event dispatcher loops have been in a quite wide use since very long – since the inception of Unix systems, say – and has been refined into simple to use API:s in libraries such as libevent and libuv.&lt;br /&gt;
&amp;lt;div style=&amp;quot;text-indent: 1em;&amp;quot;&amp;gt;Therefore, even while lots of effort and exactitude is required for implementing this in a way that really spins uncompromisingly, we relate to this functionality as noncomplex.&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Beyond the stack model, making Scheme code execute at speeds comparable with that of C, a careful design of the compiler – including extensive, complex optimizations – and of the VM/runtime system (type and object handling etc) are required. We discuss this in more detail below.&lt;br /&gt;
&lt;br /&gt;
Thus, we can now sum up complexity in Gambit, beyond that of a general programming environment such as that of Java, as being focalized to the design of the stack handling and to how the matters of how very high performance of code execution is achieved, which are dealed with by the compiler and the tuning of the details of the VM/runtime system design.&lt;br /&gt;
&lt;br /&gt;
==The C-level anatomy of Gambit and a Gambit-based application==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When having Gambit or a Gambit-based application in sourcecode form only, what steps are required to compile it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(running the configure script – the configure script generates ./Makefile *only* or other files too? - the Makefile as for use by make without parameters just as to compile the program, essentially only invokes the C compiler and linker for the different C files in the appropriate order? C files generated out of Gambit's runtime's scheme files, required to make compilation out of C code only work. ./configure and running make on the makefile is all needed to produce the C binaries? For distributing an application implemented in Gambit, only distributing the C files generated by Gambit for the application's Scheme files, is sufficient. Thus for such an application, add to the configure script/Makefile instructions to compile also the application's bundled C files, and include those in the linking process. Any advice on how to prepare such an Gambit application from C files distribution as easily as possible, are there any examples anywhere available?)&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Conceptually, what does the configure script check for and what output files does it produce?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In what areas are there differences in what C/asm code of Gambit is used, between processors and platforms?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
(the select loop and files and networking, how interrupt signals are made, more?  Native bit size of values of course.)&lt;br /&gt;
==The C-level anatomy of starting Gambit or a Gambit-based application==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When Gambit or a Gambit application is started, what is approximately the code flow of the initiation all way up to that Scheme code starts to execute? (roughly locations of the different functions in Gambit's C code, that are invoked) What OS calls are made/state for the Gambit OS process with the OS is set up, and what information is acquired from the host OS? What code is run to initialize the heap? What code is run to initialize the stack handling with its first  stack frame (perhaps this q should rather be put in the section about stack handling)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Structures==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Internally, are structures just special-type vectors?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is there any inheritance between structures, i.e. can I create a structure of type car and then make a subtype structure of type volvo? If so, how does this inheritance work – is it just that when making a volvo object, a vector is created with slots for all of a car's properties and appended to that is slots for all of volvo's properties too – how does the car property access procedures typecheck for if it's a car or a volvo?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Where in Gambit's code is the structure type handled, and what's the anotomy of this code?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==The ports/IO system==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Gambit has a variety of port types. Are the primary groupings/super-types of these, byte ports, character ports, and object ports? Is there some kind of strict inheritance between these, that each character ports is or contains a byte port too, and that every object port is or contains a character port too?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the IO/ports system and its sourcecode? At what places in Gambit's code is data sent/calls/mutations done to the OS as for Gambit to feed it with data, at what places in Gambit's code are things for Gambit to listen for events for (file handles, sockets, interrupt timeout?) inserted? How is the core IO-time scheduling done (on all platforms), is it by a select() or select()-equivalent call only, or is there any alternative return path from the OS into Gambit, during wait for timer timeout or IO input from the OS? (we discuss the reception and handling of timer interrupts separately in the section on threading.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the IO/ports system's sourcecode – which are the main procedures and code sites, approximately how does it fit together?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of a port, it's a structure with approx what properties, it has a will so it's shut down the right way when GC:ed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the code path for a |display| or |write| or |write-subu8vector| to a port, for various port types, all the way up to the end destination for the operation (the network device/OS file/target string buffer/etc).&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;At what points is the ports/IO system copying (both by function and by location in the sourcecode)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When select() has given an event for a file handle/socket, what is the code path that is invoked to propagate this event into the Scheme world?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does Gambit support select()-ing for more than 64 sockets on Windows? (this is a limit in Windows' select)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==The threading system==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How and where is the threading system bootstrapped? Where is the primordial thread initialized, and what makes it be the code that is actually the first to be run (except for, that at the time it's the only thread that exists)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is each thread a structure only? Roughly what properties does this structure have? How many bytes in size is this structure, on different architectures (32bit or 64bit)? Does Gambit provide any global state where threads and thread groups are stored, if so which is this structure and where is it declared, or does the caller need to keep references for them as not to GC?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How does Gambit ensure that interrupt checks are distributed in the code at such locations that smooth execution across threads is guaranteed, while the overhead for interrupt checking is kept low enough? How many % of code execution time is taken up by interrupt checks? The mechanism that puts interrupt checks in code is calibrated in such a way that there is no place in the code, no loop and so on, that is exempted from interrupt checks, in such a way that &amp;gt;1-2ms of code execution would happen without any interrupt check being made? So, (let loop ((at 0)) (if (##fx&amp;lt; at 1000000000) (loop (##fx+ at0)))) will never cause any issues with threading smoothness, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What principle is applied by Gambit when choosing what next thread to invoke? Where in Gambit's code are these therad switches made? If there's any particular complexity to the subject of making thread switches, please describe (such as, invoking the right trampolines or leaving the C/asm stack in the right condition or sth .. perhaps this is taken care of by the stack handling and that's it)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the anatomy of the thread switching mechanism: so first off, while not executing code but waiting for IO or timeouts from the OS, Gambit has a timer interrupt signal scheduled with the host OS (are these rescheduled all the time by Gambit, or is the OS set to recurringly make such interrupts at a certain interval forever)? Then, all Gambit-generated code is sugared all over with interrupt checks, so the interrupt signal handler procedure does something like mutating a global variable has_interrupt to true, and these interrupt checks do sth like if (has_interrupt) goto handle_interrupt or handle_interrupt(); depending on if the code is single-host or multiple-host? Then, does this handle_interrupt always check for stack overflow? What about heap overflow, or trigging a GC? How does it check if it's time to switch to another thread now? Does it do anything more? In case of switch to another thread, how is the current point of execution left in a way that maintains application/stack/etc integrity (perhaps that's a stack handling-section question)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Where/how is it configured for how long a thread should run before a switch is made to the next one? Is this a global or a per-thread configuration?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;While code can have (declare (not interrupts-enabled)) as not to accept any interrupts, the RTL is mostly compiled with interrupts enabled, so while inlined procedures such as + fall within the same interrupts-enabled setting as the code where it's used, non-inlined procedures such as assq do produce interrupts, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What's the anatomy of Gambit's threading system sourcecode, in what source files and locations are the threading system and the threading interrupts represented (I suppose the latter is in the compiler)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does the threading system schedule between threads based on the number of thread interrupts passed, or based on the amount of wall clock time passed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the dynamics of the priority, quantum and priority boost parameters to the threads, perhaps this is described completely enough in the specification document (don't remember its name or url right now)? If I want one thread to be of high priority and one of low, what parameters are needed? If I want one thread to get double or half as much CPU time as another, what parameters are needed?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Beyond what has been covered above, is there any additional complexity to the threading system, or notable details not obvious from looking at its sourcecode?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Exceptions==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is the basic anatomy of the exceptions system, that first and foremost there is a |raise| procedure that takes one argument which is the exception value and which can be of any type, and, that in the dynamic environment there's a current exception handler parameter, that is a procedure, that is invoked on exception, and this is what with-exception-catcher and with-exception-handler uses to implement its functionality? So, the exception object type/-s is really a matter completely separated from the basic exception raising and catching mechanisms, and are only used as containers for conveying the content or message of each respective raised exception?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Gambit has a number of different exception types: os-exception, wrong-number-of-arguments-exception etc. etc.. Are these arranged in any kind of hierarchy? Are they all sub-structure-types of the exception type? Is there any way to get any kind of group type out of these?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Do any particular precautions need to be taken in order for a heap overflow exception to be handled 'safely', i.e. for the exception handling code not to unintendedly trig a new heap overflow exception in turn, that would terminate the program or cause otherwise unintended behavior?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==GC and memory handling (here regarding the default stop &amp;amp; copy gc)==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Which are the variables used for determining if it's time to perform a GC, and where is the code that maintains those counters?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the anatomy of a garbage collection, including what kind of state structures are used during the process (for the markings and for keeping track of finalizers). What state does the garbage collector keep between gc:s?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the entry point for making GC iterations, the ___gc() C procedure? Does the garbage collector have more entry points than this, if so what are they used for?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does Gambit have any quick reclaim mechanism for quickly discarding (GC:ing) objects that are not in use? Sth like, (define (a) (let ((b 1) (c 2.99999999999999) (d (make-string 1))) (+ b c)) – right at the point when a returns, is the memory for all of b, c and d immediately freed? Perhaps only b, because the compiler knew it took space only within the current stack frame and not otherwise on the heap so presuming the compiler knew to discard that stack frame quickly, it did. Does it discard c too (even while it occupies a little bit of heap space outside of the stack frame, no?) but not d, because b it knows what type it is of, but d was generated by an external procedure so quick freeing cannot be done but it will wait until the next GC?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How are finalizers handled? Because, I suppose, the finalizer needs to finish before the object is discarded. So, when an object with a finalizer ends up not marked by a GC process, then the GC makes a note of that object in some kind of list, and each such object has some kind of status flag that can be either of “finalizer not invoked”, “finalizer running” and “finalizer done”, and if it's “finalizer done” then the object is GC:ed,  and after each GC all entries with “finalizer not invoked”  are invoked? Please describe the possible states in here, where this state is stored, and which the state changes are and when the changes take place.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;There is no central index of all objects on the heap, they're just allocated space for in the chunks of system memory allocated by the memory handling mechanism right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is any particular design of the heap or stacks required, for there to be support for concurrent garbage collection? (in same cpu core or multicore)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Beyond freedom of bugs, were any particular strategies assumed in making Gambit free of buffer overflows and memory corruption bugs? (I'm clear this might be a pointless question)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Data types==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Every variable value in Scheme is represented internally as an integer, and has a tag about what fundamental data type the respective value is, right? What are the bit patterns in use for describing datatypes here? Where in Gambit's code is the basis for and use of those bit patterns implemented (as to know how to add or edit a type)? (I'm aware that fixnum is described by the two lowest bits being 0.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Whenever a variable value has a payload – some kind of object contents – a pointer to the memory address at which this payload is located, is included in every object reference on the heap for that object, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What was the motivation for using the lower bits in the variable values for the tag rather than the upper ones?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Hashtables==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;The hashtable and there used hashing algorithm, how does it work? Is there a paper anywhere that describes it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In what components/elements are hashtables stored internally (some kind of chain or tree I'd suppose, but what)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;By what reason is it that a table must not be mutated during table-for-each, what's the worstcase outcome if one mutates a table during it?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Is it possible to implement hashtables that fit together in a tree kind of shape, so that if I make table-set! on a parent then that one is visible to all child and grandchild etc. hashtables but not the other way around?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Numbers==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What are the rules for automatic type changes of numbers on number operations? Say, fixnum + flonum gives a flonum, that's obvious, but what about more complex cases – when are bignums generated, when are bignums scaled down to fixnums, and so on?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How are bignum structures stored internally, each such value is an object reference to a “bignum object”, and that object is a vector of integers that each contains a couple of decimals of the bignum value? With what procedures can I introspect and manipulate the element parts of a bignum value?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If one would want to change the structure format for the bignums, for instance for plugging in another bignum library, how would one go about for that?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==The Compiler==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the basic anatomy of the compiler's sourcecode, and what is the basic code path that any compilation process takes? In all cases, I'm clear already there's two steps, a Scheme to GVM step, and a GVM to native code step (with the C backend or the native backend).&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the different phases that a compilation process takes (including any loops), and what form the sourcecode is stored in and what information form the compilation output is in, and what intermediary forms between sourcecode and compilation output are there and what's the purpose of those, in the different phases.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Approximately what optimizations are made by the compiler in the Scheme to GVM step and the GVM to C or native code steps respectively? (Let's define optimization as any logics that make the output code neater or faster than if that logics would not have been there, or if that logics would have been less well designed/thought through.)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Does the compiler look up all call/cc:s, and make a CPS conversion of all the code, during the compilation process? What is done with the CPS-converted code in order to generate the fastest or otherwise slimmest resultant code (if this is what the compiler does)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please list the academic papers and algorithm names that describe /something like/ what Gambit does during compilation.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If I wanted to implement a new primitive function that requires special (inlined) compiler output, say ##sysmem-byteref , where in the Scheme to GVM compiler's code and where in the C backend would a change need to be made, and approximately what kind of change would need to be made? &amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If I wanted to implement a new primitive conditional that requires special (inlined) compiler output, say a variant of |or| or |if| that we call |or/0| or |if/0| that treats fixnum 0 as #f, where in the Scheme to GVM compiler's code and where in the C backend would a change need to be made, and approximately what kind of change would need to be made? &amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Secondarily, I may want a first-class variant of this primitive too, for use both in compiled code and by the interpreter. What is a suitable place in Gambit's code to put a “wrapper” of the compiled version of ##sysmem-byteref to a first-class version of it, and how should that code look?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the general nature of the GVM language, and more specifically what kind of operations the GVM code language contains. Basically the GVM language describes procedures and their execution flows (stack operations, conditionals of the execution flow, jumps/invocations to procedures, trampolines?), and other than that it's invocations of primitives (+ etc)?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please descrube the GVM code for a closure.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the GVM code for a conditional.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the GVM code for an invocation of a procedure with one or more arguments.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What state structures are needed to run a GVM (within C backend)? (both for the stack and to maintain the execution state needed to handle the juggling of host functions) Please describe with some detail – what's on the C stack, what's the structure of the processor struct and stack structures and so on.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the kind of functionality/functions needed by a GVM. So for instance, it needs to have a GC. What more? Some kind of stack handling machinery including dynamic addition and removal of slots to stack frames? (I suppose the entire concept of host procedures is within the C backend's architecture only, the GVM design in itself has nothing to do with those?)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;In many places, exceptions are raised from a really low level point, say that + was applied to the wrong data type and now there's a type exception. How does the GVM code look for such handling, and how is this implemented in the C backend?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==The [GVM code to] C backend and the resultant object file==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the general anatomy of the C code output. (It is clear that each C file has some kind of headers and information structures inlined as constants, that are for somehow instructing the parent Gambit process what globals or alike the object file contains, rather than just code)&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What is the basic execution flow of the C code in an object file? Right when it's loaded by the OS, which code in it is run? What is done? To feed the parent process with globals would, I suppose, be one. It is the parent process that then invokes an initialization routine in the object file, that invokes its top level code, right?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;The C code seems to be a pretty hardcore example of macro use. Is there any higher level of understanding or structure in all the macros that, if understood, makes it easier to understand the macro definitions and how the macros and their use fit together? What is the anatomy of the files with macro definitions?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;When the host procedore returns (which happens basically between every evaluation step in code compiled with the safe declare), to what code in Gambit's runtime does it return then, what does that code do and in what condition does it jump back into the host procedore?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please descrube the C code for a closure.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the C code for a conditional.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Please describe the C code for an invocation of a procedure with one or more arguments.&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Stack handling and related code generation aspects (including for GC traversibility, safety of stack overflows and call/cc) and trampolines==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;Are stack frames the highest level of granularity that Gambit deals with stacks at, or do they have subcomponents (except for the slots for the individual contained values of course)? What about the code (define (a) (let ((b [value])) (let ((c [value])) [code1]) [code2])), what happens in the stack as code1 completes and code2 is started to be executed and c thus is disposed from the stack?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How many bytes does a stack frame occupy?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;What contents does a continuation value or a continuation object value have, beyond (being) a reference to the stack frame to be executed on its invocation?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the dynamic environment and parameter values implemented? When invoking a continuation or there is a change of active thread, how is the switch of dynamic environment done?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the stack layout designed, as to be traversible by the GC? Were any particular considerations needed for this, to maintain the platform independentness of Gambit's C backend?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How is the stack layout designed, as to suit call/cc? What is the full mechanism of a call/cc, and what is the anatomy in site of a call/cc call, and, does it have any dependencies otherwise in the RTL?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;For the Gambit-generated native code to be safe for stack and heap overflows, it appears to me that there is basically some handling code between each step of every evaluation that involves the return of the host function. Why is this? Say that there is a processing loop, (let loop ((i 0)) (if (##fx&amp;lt; i 1000) (begin (##u8vector-set! u i (+ (u8vector-ref u i) 1) (loop (##fxnum+ i 1))))) say, why can't it just be one solid piece of code that executes through the loop just like that? What is the proof that stack overflow will never happen unless malloc fails?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;How much C stack space does a Gambit process make use of? Can it be adjusted?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
==Debugging==&lt;br /&gt;
&amp;lt;span style=&amp;quot;background-color:lightyellow;&amp;quot;&amp;gt;If a lowlevel crash would happen in a Gambit program, say somewhere outside the application's object files, what are the steps you normally would take/recommend as to determine the source of the error?&amp;lt;/span&amp;gt;&amp;lt;br/&amp;gt;&lt;br /&gt;
a&lt;br /&gt;
&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Documentation</id>
		<title>Documentation</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Documentation"/>
				<updated>2012-08-11T04:27:05Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: /* Internals Documentation */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== User Documentation ==&lt;br /&gt;
&lt;br /&gt;
There is a user manual for Gambit in [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html HTML]&lt;br /&gt;
and [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.pdf PDF] formats.&lt;br /&gt;
&lt;br /&gt;
See the [[Scheme]] page for documentation on Scheme in general.&lt;br /&gt;
&lt;br /&gt;
== Prebuilt Distributions ==&lt;br /&gt;
&lt;br /&gt;
Some prebuilt distributions are [[Distributions | available]].&lt;br /&gt;
&lt;br /&gt;
== Building Gambit from Source ==&lt;br /&gt;
&lt;br /&gt;
To build Gambit from source, one must first run the configure script, which has a number&lt;br /&gt;
of important [[Configure script options | options]].&lt;br /&gt;
&lt;br /&gt;
There are various [[Make targets | make targets]] of which you should be aware.&lt;br /&gt;
&lt;br /&gt;
== Packages, modules, libraries and driving systems ==&lt;br /&gt;
&lt;br /&gt;
See the [[Packages]] page.&lt;br /&gt;
&lt;br /&gt;
=== SRFI support ===&lt;br /&gt;
The Scheme community has accumulated a set of common libraries and conventions called Scheme Requests for Implementation, publicly collected on [http://srfi.schemers.org/ srfi.schemers.org].&lt;br /&gt;
&lt;br /&gt;
Gambit [[SRFI:s | natively implements]] a number of SRFIs.&lt;br /&gt;
[[Black Hole]] includes several popular SRFIs not natively supported,&lt;br /&gt;
while still others may be downloaded from [http://snow.iro.umontreal.ca/?listcat=srfi Snow].&lt;br /&gt;
&lt;br /&gt;
== Editor/IDE Support ==&lt;br /&gt;
&lt;br /&gt;
Gambit provides a powerful development environment through [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#Emacs-interface Emacs]. &lt;br /&gt;
&lt;br /&gt;
For those running MS Windows you can [http://ftp.gnu.org/pub/gnu/emacs/windows/ download Emacs here]. You may want to read the [http://www.gnu.org/software/emacs/windows/ntemacs.html Emacs FAQ for Windows] before customizing Emacs for use with Gambit. In order to use Emacs' inferior scheme mode on Windows, you may need to run gsi/gsc in raw stdin/stdout mode (see section &amp;quot;Emacs interface&amp;quot; in the manual for details).&lt;br /&gt;
&lt;br /&gt;
Editors such as [http://www.eclipse.org/ Eclipse] with the [http://schemeway.sourceforge.net/ SchemeWay] extension, or just about any text editor with Scheme syntax highlighting, such as [http://www.vim.org VIM or GVIM], may prove valuable as well.&lt;br /&gt;
&lt;br /&gt;
== Termite ==&lt;br /&gt;
&lt;br /&gt;
[http://code.google.com/p/termite/ Termite] is an Erlang-like distributed programming system written in Scheme.&lt;br /&gt;
&lt;br /&gt;
Distributed computing hot right now, and Termite has been noticed in blogs and elsewhere.&lt;br /&gt;
&lt;br /&gt;
Termite depends on specific features of Gambit, and at one time or another&lt;br /&gt;
the Termite source code has been distributed with Gambit, so we point to the Termite web site&lt;br /&gt;
from here.&lt;br /&gt;
&lt;br /&gt;
== Tutorials ==&lt;br /&gt;
[[A Tour of Scheme in Gambit]] gives a general introduction to Scheme and Gambit to people with experiences of general programming languages. Available in [[media:A_Tour_of_Scheme_in_Gambit.pdf|PDF]], [[media:A_Tour_of_Scheme_in_Gambit.odf|Open Office]] and [[media:A_Tour_of_Scheme_in_Gambit.doc|Microsoft Word]] formats.&lt;br /&gt;
&lt;br /&gt;
== Internals Documentation ==&lt;br /&gt;
[[Design guide]]&lt;br /&gt;
&lt;br /&gt;
People who want to [[How to Contribute | contribute]] to Gambit development will need to learn something about how the Gambit-C&lt;br /&gt;
runtime and compiler are organized.  While we intend that source code documentation be included in the source&lt;br /&gt;
itself (currently there is very little documentation), we intend that descriptions of program design&lt;br /&gt;
or algorithms used in the runtime and compiler could be included on the [[Internal Documentation]] page.&lt;br /&gt;
&lt;br /&gt;
== Working with External Libraries ==&lt;br /&gt;
&lt;br /&gt;
With Gambit's C FFI (Foreign Function Interface), one can easily use standard C and C++ libraries with your code; this wiki has some examples of and practices on using Gambit with external libraries. See [[Using Gambit with External Libraries]].&lt;br /&gt;
&lt;br /&gt;
== Debugging ==&lt;br /&gt;
&lt;br /&gt;
See the [[Debugging]] page.&lt;br /&gt;
&lt;br /&gt;
== More ==&lt;br /&gt;
The [http://mailman.iro.umontreal.ca/pipermail/gambit-list mailing list archive] covers many topics at depth. You can make Google search queries limited to the mailing list by clicking &amp;quot;advanced settings&amp;quot; on www.google.com.&lt;br /&gt;
&lt;br /&gt;
[[Dumping Grounds]]&lt;br /&gt;
&lt;br /&gt;
[[Compiling Gambit software for different target environments]]&lt;br /&gt;
&lt;br /&gt;
[[Wish list]]&lt;br /&gt;
&lt;br /&gt;
[[External links]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds</id>
		<title>Dumping Grounds</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds"/>
				<updated>2012-05-13T13:20:43Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: Added Unicode handling library&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Here you will find packages of Gambit code contributed by users.  This page is meant as a simple repository where random code snippets as well as complex systems can easily be stored so that other users can get to them.  This is not a substitute for a repository that is closely coupled with the Gambit system's module system (which is under development).  It is meant to foster the sharing of code by making it extremely easy to publish code in a publicly accessible place.  Sharing a piece of code that is incomplete, undocumented, and unreliable is better than not sharing it, because others can correct the deficiencies, learn from the code, or avoid the bugs.  Hence the name '''Dumping Grounds''' for this page.&lt;br /&gt;
&lt;br /&gt;
The code need not follow a specific structure.  It could simply be a Scheme source file (with a '''.scm''' extension).  However, if you are packaging your code specifically for storing it here, it is best if the name of the package contains a revision number (so that many revisions can be stored) and is a gzip compressed tar file ('''.tgz''' extension) containing the code and documentation (for example file '''Sort-r1.tgz''' containing the files '''Sort-r1/Sort.scm''' and possibly '''Sort-r1/Sort.html''' and other related files).  For some reason the wiki insists on the package name starting with an upper-case letter.  The code is assumed to be in the public domain unless you add licensing information in the package itself or the documentation.&lt;br /&gt;
&lt;br /&gt;
To add a new package you must add an entry for it to this page (copy-paste an existing entry), update the file name in the &amp;lt;nowiki&amp;gt;[[media:Sort-r1.tgz|Sort-r1.tgz]]&amp;lt;/nowiki&amp;gt; link, save the page and click on the link to upload your file.  If you upload a new revision don't forget to change the revision number, and keep the link to the old revisions.&lt;br /&gt;
&lt;br /&gt;
A list of the packages and other files with statistics is available here: [[Special:Imagelist]]&lt;br /&gt;
&lt;br /&gt;
In case you find that a link to an external repository linked to from this page doesn't work anymore, please try to retrieve the latest version of the repo and upload it here, by a) contacting the author directly, b) enquiring for it on the mailing list, and/or c) trying to get it from archive.org.&lt;br /&gt;
&lt;br /&gt;
==Gambit packages==&lt;br /&gt;
These packages are in the present form created to run atop Gambit directly. They can generally easily be ported to any module system of choice.&lt;br /&gt;
===SRFI===&lt;br /&gt;
#'''SRFI-pack''': Many SRFIs ported to Gambit&lt;br /&gt;
#: Author: Guillaume Germain&lt;br /&gt;
#: Package: [[media:Srfi-pack-0.1.tar.gz|Srfi-pack-0.1.tar.gz]]&lt;br /&gt;
#: README: [[media:Srfi-pack-0.1-README.txt|Srfi-pack-0.1-README.txt]]&lt;br /&gt;
#'''SRFI-1''': SRFI-1 ported to Gambit&lt;br /&gt;
#: Author: Olin Shivers; ported by Bradley Lucier&lt;br /&gt;
#: Package [[media:Srfi1.scm|Srfi1.scm]]&lt;br /&gt;
#: Note: I did not extend map to allow list arguments of different lengths&lt;br /&gt;
&lt;br /&gt;
=== Language ===&lt;br /&gt;
# '''Gambit on LLVM''': Experimental partial back-end for Gambit using LLVM&lt;br /&gt;
#: Authors: Arnaud Bergeron and Mathieu Larose&lt;br /&gt;
#: Package: [[media:Gambit-LLVM.tgz|Gambit-LLVM.tgz]]&lt;br /&gt;
# '''Jss''': JavaScriptScheme: a multithreaded Scheme to JavaScript compiler&lt;br /&gt;
#: Author: Marc Feeley and Catherine Gaudron&lt;br /&gt;
#: Package: [[media:Jss-r2.tgz|Jss-r2.tgz]] (old: [[media:Jss-r1.tgz|Jss-r1.tgz]])&lt;br /&gt;
# '''R6RS on Gambit''':Allows R6RS programs to be run on Gambit. &lt;br /&gt;
#: Maintainer: Arthur Smyles&lt;br /&gt;
#: Package: (web page) http://smyles.com/projects/r6gambit/&lt;br /&gt;
# '''PICOBIT''': Very compact Scheme compiler and virtual machine suitable for microcontrollers.&lt;br /&gt;
#: Author: Marc Feeley and Vincent St-Amour&lt;br /&gt;
#: Package: (web page) http://repo.or.cz/w/picobit.git&lt;br /&gt;
# '''Alexpander''': A syntax-rules expander with support for DSSSL #!optional #!key and #!rest arguments.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:Alexpander-r1.tgz|Alexpander-r1.tgz]]&lt;br /&gt;
&lt;br /&gt;
===Module systems===&lt;br /&gt;
# '''Black Hole''': Module system, stable. Package handling features are in beta phase. Primary page at [[Black Hole]].&lt;br /&gt;
#: Package: (git repo) [https://github.com/pereckerdal/blackhole https://github.com/pereckerdal/blackhole]&lt;br /&gt;
&lt;br /&gt;
===Object Systems===&lt;br /&gt;
# '''Oops''': Object Oriented Programming for Scheme -- Dylan/Clos-like but different&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:oops34.tgz|oops34.tgz]]&lt;br /&gt;
# '''TinyTalk''': Self-like object system with selector [Smalltalk like] dispatch.&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:gambitTT.tgz|gambitTT.tgz]]&lt;br /&gt;
# '''class.scm''': A simple CLOS-like object system written with a balance of performance, usability and runtime heap consumption. Comes bundled with a test suite which shows exemple of how the system can be used. Also can be used easily in a repl with (include &amp;quot;class.scm&amp;quot;). &lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: (web page/git repo) http://github.com/sthilaid/class/tree/master&lt;br /&gt;
# '''Meroon''': CLOS-like object system for Scheme.&lt;br /&gt;
#: Author: Christian Queinnec, now semi-maintained by Brad Lucier.  Licensed under the [http://opensource.franz.com/preamble.html Lisp Lesser General Public Licence].  Differs from CLOS in (among many other things) having single inheritance instead of multiple inheritance and a compile-time, not a run-time, MOP.  Can be compiled to be relatively fast code.  Would benefit from being reorganized in a &amp;quot;layered&amp;quot; style more appropriate for current ideas of Scheme modules.&lt;br /&gt;
#: Website: http://www.math.purdue.edu/~lucier/software/Meroon/&lt;br /&gt;
#: Package: [[media:MeroonV3-2012Jan20.tar.bz2|MeroonV3-2012Jan20.tar.bz2]]&lt;br /&gt;
&lt;br /&gt;
=== FFI ===&lt;br /&gt;
# '''ffi-related-modules''': various modules dealing with the FFI, and their dependencies (chjmodules, but someone might turn them to using bare namespaces or so; read the Readme file at the below URL)&lt;br /&gt;
#: Author: Christian Jaeger&lt;br /&gt;
#: Package: (web page/git repo) http://scheme.ch/gambit/preview/ffi-related-modules/&lt;br /&gt;
&lt;br /&gt;
===Parsing===&lt;br /&gt;
# '''SSAX-SXML''': SSAX-SXML library packaged for Gambit-C&lt;br /&gt;
#: Author: Kirill Lisovsky (updated by Dominique Boucher)&lt;br /&gt;
#: Package: (web page) [[media:ssax-sxml-gambit-20080402.tgz|ssax-sxml-gambit-20080402.tgz]]&lt;br /&gt;
# '''Mparser''': A combinatorial parser (added expression parser) (parser language rewrite)&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:Mparser-r3.tgz|Mparser-r3.tgz]] (old: [[media:Mparser-r1.tgz|Mparser-r1.tgz]], [[media:Mparser-r2.tgz|Mparser-r2.tgz]])&lt;br /&gt;
&lt;br /&gt;
===Physics===&lt;br /&gt;
#'''Ising''': Computer simulations of the Ising model of spins using the Metropolis algorithm or the Wolff algorithm.&lt;br /&gt;
#: Author: Marijn Schouten&lt;br /&gt;
#: Package: [[media:ising-20090315.scm]]&lt;br /&gt;
&lt;br /&gt;
===Math===&lt;br /&gt;
# '''Pi''': Compute pi to arbitrary precision.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [[media:Pi-r3.tgz|Pi-r3.tgz]] (old: [[media:Pi-r2.tgz|Pi-r2.tgz]]) (old: [[media:Pi-r1.tgz|Pi-r1.tgz]])&lt;br /&gt;
# '''BLAS''': Thin wrapper for level 1, 2 and 3 BLAS linear algebra routines for the Gambit Scheme system.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/blas&lt;br /&gt;
# '''LAPACK''': Thin wrapper for higher-level linear algebra routines for the Gambit Scheme system.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/lapack&lt;br /&gt;
# '''FFTW3''': A wrapper for some FFTW3 functions for the Gambit Scheme system. (real, complex, multi-dimensional FFT functions)&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/fftw3&lt;br /&gt;
#: '''Random numbers''': High-quality random number generation. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=random http://snow.iro.umontreal.ca/?viewpkg=random]&lt;br /&gt;
&lt;br /&gt;
===Encryption===&lt;br /&gt;
# '''AES''' Message encryption and decryption based on the AES symmetric cipher. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=aes http://snow.iro.umontreal.ca/?viewpkg=aes]&lt;br /&gt;
# '''Cert''' Management of digital certificates, message signing and verification. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=cert http://snow.iro.umontreal.ca/?viewpkg=cert]&lt;br /&gt;
# '''RSA''' Message encryption and decryption based on the RSA asymmetric cipher. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=rsa http://snow.iro.umontreal.ca/?viewpkg=rsa]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- ===Networking=== --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===SQL===&lt;br /&gt;
# '''MySQL FFI''': FFI for mysql.  Unsure about thread-safety, and needs more work&lt;br /&gt;
#: Author: Jonathan Arkell&lt;br /&gt;
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/mysql/&lt;br /&gt;
# '''MySQL''': Socket level client for mysql. Supports dynamic SQL and now prepared statements. Also includes a SQL abstraction layer. This [http://andrewwhaley.blogspot.com/2009/04/gambit-mysql-client-02.html blog post] has more information. For a more developed version w UTF8 support pls contact the ml.&lt;br /&gt;
#: Author: Andrew Whaley&lt;br /&gt;
#: Package: [[media:Gambit-mysql.zip|Gambit-mysql.zip]]&lt;br /&gt;
# '''SQLite3''': a minimalistic interface to SQLite3.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:SQLite3-r1.tgz|SQLite3-r1.tgz]]&lt;br /&gt;
# '''Postgresql''': A socket level client for Postgresql&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:Postgresql-r1.tgz|Postgresql-r1.tgz]]&lt;br /&gt;
&lt;br /&gt;
===Graphics===&lt;br /&gt;
# '''Octave''': A simple plotting interface using octave (2.x) and gnuplot.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/octave/&lt;br /&gt;
# '''Schemeray''': A simple (and as of yet, unoptimized) raytracer&lt;br /&gt;
#: Author: James Long&lt;br /&gt;
#: Package: [[media:schemeray-0.2.tgz|schemeray-0.2.tgz]]&lt;br /&gt;
# '''Opengl FFI''': A simple opengl, glu and glut ffi which supports opengl up to version 1.1.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Opengl-ffi-r1.tgz|Opengl-ffi-r1.tgz]]&lt;br /&gt;
# '''Perlin Noise''': A simple opengl demonstration of a sub-optimal 2d Perlin noise implementation.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Perlin-noise-2d-r1.tgz|Perlin-noise-2d-r1.tgz]]&lt;br /&gt;
# '''Cairo''': Bindings for cairo graphics.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:Cairo-r3.tgz|Cairo-r3.tgz]] (old: [[media:Cairo-r2.tgz|Cairo-r2.tgz]])&lt;br /&gt;
# '''GLEW''': A wrapper for GLEW which provides all OpenGL functionality through version 2.1 and manages access to vendor extensions&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:Glew.tar.gz|glew.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Audio===&lt;br /&gt;
# '''mpg123''': A wrapper for the libmpg123 mpeg decoding library&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:mpg.tar.gz|mpg.tar.gz]]&lt;br /&gt;
# '''OpenAL''': A wrapper for the OpenAL audio output library&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:openAL.tar.gz|openAL.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Utilities===&lt;br /&gt;
# '''Sort''': Provides a simple sorting procedure for lists and vectors.  The mergesort algorithm is used.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [[media:Sort-r1.tgz|Sort-r1.tgz]]&lt;br /&gt;
# '''Bunny Test''': A simple unit testing framework.  &lt;br /&gt;
#: Author: Jonathan Arkell&lt;br /&gt;
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/test/&lt;br /&gt;
# '''GetOpts''': A syntactic form (let-opts) to parse command line options&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:GetOpts-r1.tgz|GetOpts-r1.tgz]]&lt;br /&gt;
# '''Etags''': Script that generates Emacs TAGS files from Scheme files, and recognizes nested definitions.&lt;br /&gt;
#: Author: Vincent St-Amour&lt;br /&gt;
#: Package: http://www-etud.iro.umontreal.ca/~stamourv/etags.scm&lt;br /&gt;
# '''Win-control''': Library for controlling Internet Explorer and other Windows applications for scripting or automating testing.&lt;br /&gt;
#: Author: Andrew Whaley&lt;br /&gt;
#: Package: http://code.google.com/p/win-control&lt;br /&gt;
# '''repltest''': Small example which embeds a remotely accessible REPL into a standalone C program.&lt;br /&gt;
#: Web: https://mercure.iro.umontreal.ca/pipermail/gambit-list/2010-June/004500.html&lt;br /&gt;
#: Package: [[media:Repltest-20100604.tgz‎|Repltest-20100604.tgz‎]]&lt;br /&gt;
# '''objc-utility-macros''': Utility macros to help wrap Objective-C methods.&lt;br /&gt;
#: Author: Jeffrey T. Read&lt;br /&gt;
#: Package: [[media:objc-utility-macros.scm‎|objc-utility-macros.scm]]&lt;br /&gt;
# '''Sort''': Richard O'Keefe's sorting procedures for lists and vectors.  Four times as fast as other sort.&lt;br /&gt;
#: Author: Richard O'Keefe&lt;br /&gt;
#: Package: [[media:Sort-okeefe.tgz|Sort-okeefe.tgz]]&lt;br /&gt;
# '''Digest''': Computation of message digests (CRC32, MD5, SHA-1, ...). Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=digest http://snow.iro.umontreal.ca/?viewpkg=digest]&lt;br /&gt;
# '''Red-black tree''' implementation, Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=rbtree http://snow.iro.umontreal.ca/?viewpkg=rbtree]&lt;br /&gt;
# '''Unicode''': Unicode handling library 1.0, does string upper-/lowercasing and case insensitive comparison with Unicode character support&lt;br /&gt;
#: Author: Mikael More, Florian Loitsch&lt;br /&gt;
#: Package: [[media:Unicode.tar.gz|Unicode.tar.gz]] repo: [https://github.com/m-i-k-a-e-l/gambit-unicode https://github.com/m-i-k-a-e-l/gambit-unicode]&lt;br /&gt;
&lt;br /&gt;
=== Full Applications ===&lt;br /&gt;
# '''Space-Invaders''': Space Invaders classical arcade game remake in scheme over either glut or SDL.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Space-invaders-src-v1.0.tgz|Space-invaders-src-v1.0.tgz]]&lt;br /&gt;
# '''Web Server''': a web server with sessions cookies and server pages.&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:WebServer-r2.tgz|WebServer-r2.tgz]] (old: [[media:WebServer-r1.tgz|WebServer-r1.tgz]])&lt;br /&gt;
#: Git: http://git.berlios.de/cgi-bin/gitweb.cgi?p=futhark;a=summary&lt;br /&gt;
# '''GUI-Toy''': Simple Direct Media Layer prototype code with examples in the raw and using TinyTalk and Oops object systems.&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:GUI-Toy.tgz|GUI-Toy.tgz]]&lt;br /&gt;
# '''Intelligent WTF''': Intelligent acronym decoder based on ''wtf'' from BSD Games&lt;br /&gt;
#: Author: Joel J. Adamson &lt;br /&gt;
#: Package: (web page) http://www.unc.edu/~adamsonj/software.html&lt;br /&gt;
# '''Genetic Canvas''': A polygon-based image renderer using genetic algorithms.&lt;br /&gt;
#: Author: James Long&lt;br /&gt;
#: Web: http://jlongster.com/blog/2009/05/25/mona-lisa-genetically-drawn-scheme/&lt;br /&gt;
&lt;br /&gt;
==Gambit Black Hole packages==&lt;br /&gt;
These packages are in their present form created to run on Gambit using the Black Hole module system. They can generally easily be made to run on Gambit directly as well. For more info see [[Black Hole]].&lt;br /&gt;
===SRFI===&lt;br /&gt;
# '''SRFIs package'''&lt;br /&gt;
#: Package: (git repo) [https://github.com/pereckerdal/srfi https://github.com/pereckerdal/srfi]&lt;br /&gt;
&lt;br /&gt;
===Networking===&lt;br /&gt;
# '''Sack''': Web server and HTTP client. BH module. [https://github.com/pereckerdal/sack https://github.com/pereckerdal/sack]&lt;br /&gt;
&lt;br /&gt;
===Utilities===&lt;br /&gt;
# '''Mishmash of various utils''': xml&amp;lt;-&amp;gt;sxml, pregexp, digest, base64, uuid, fifo mailbox, rbtree, exception-handling, let-optionals and more. sxpath also available. These packages will be split out to individual packages. Ask on mailing list for updates.&lt;br /&gt;
#: Package: (git repo) https://github.com/pereckerdal/std&lt;br /&gt;
&lt;br /&gt;
==Documents==&lt;br /&gt;
===Scheme books===&lt;br /&gt;
# '''An Introduction to Scheme and its Implementation''': A pretty good book on how to learn Scheme, for people with a background in general programming languages.&lt;br /&gt;
#: Author: Paul R. Wilson&lt;br /&gt;
#: Package: [[media:An_Introduction_to_Scheme_and_its_Implementation.tar.gz|An_Introduction_to_Scheme_and_its_Implementation.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
[[Category: Code]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/File:Unicode.tar.gz</id>
		<title>File:Unicode.tar.gz</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/File:Unicode.tar.gz"/>
				<updated>2012-05-13T13:16:52Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: Gambit Unicode library 1.0&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Gambit Unicode library 1.0&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Compiling_Gambit_software_for_different_target_environments</id>
		<title>Compiling Gambit software for different target environments</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Compiling_Gambit_software_for_different_target_environments"/>
				<updated>2012-04-12T21:36:50Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=== How to build GUI apps for Win32 ===&lt;br /&gt;
The misc\vcexpress.bat file, used as described in INSTALL, both found in the source repo file are good sources of inspiration on how to build Gambit apps using MSVC.&lt;br /&gt;
&lt;br /&gt;
Here's a good GUI example app for win32, call it test.scm:&lt;br /&gt;
&lt;br /&gt;
:(c-declare &amp;quot;#include &amp;lt;windows.h&amp;gt;&amp;quot;)&lt;br /&gt;
:(define message-box (c-lambda (UTF-8-string) void &amp;quot;MessageBox(0,___arg1,\&amp;quot;Dbg\&amp;quot;,0);&amp;quot;))&lt;br /&gt;
:(message-box &amp;quot;Hi!&amp;quot;)&lt;br /&gt;
&lt;br /&gt;
In order to compile it, first run misc\vcexpress to get lib\libgambc.lib . Then do:&lt;br /&gt;
&lt;br /&gt;
:C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall&lt;br /&gt;
:gsc -link test&lt;br /&gt;
:cl.exe -Fetest.exe -nologo -Oityb1 -MT -D_CRT_SECURE_NO_DEPRECATE -c -I&amp;quot;C:\gambc-v4_3_2-devel\include&amp;quot; -I&amp;quot;C:\gambc-v4_3_2-devel\lib&amp;quot; -D___SINGLE_HOST -D_WINDOWS &amp;quot;test_.c&amp;quot; &amp;quot;test.c&amp;quot;&lt;br /&gt;
:cl -Fetest.exe test.obj test_.obj C:\gambc-v4_3_2-devel\lib\libgambc.lib Kernel32.Lib User32.Lib Gdi32.Lib WS2_32.Lib /link /subsystem:windows&lt;br /&gt;
&lt;br /&gt;
Voillas. The key recipe in here is to pass -D_WINDOWS to cl.exe, and /subsystem:windows to link.exe .&lt;br /&gt;
&lt;br /&gt;
Upon any (display) (force-output) you do, a console window will be allocated. This can be remedied by doing (current-output-port (open-dummy)) (current-input-port (open-dummy)) though.&lt;br /&gt;
&lt;br /&gt;
Pass -dr:- to force the app open a console.&lt;br /&gt;
&lt;br /&gt;
For more info see the ml thread around [https://mercure.iro.umontreal.ca/pipermail/gambit-list/2012-April/005879.html here].&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds</id>
		<title>Dumping Grounds</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds"/>
				<updated>2012-03-18T17:01:42Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Here you will find packages of Gambit code contributed by users.  This page is meant as a simple repository where random code snippets as well as complex systems can easily be stored so that other users can get to them.  This is not a substitute for a repository that is closely coupled with the Gambit system's module system (which is under development).  It is meant to foster the sharing of code by making it extremely easy to publish code in a publicly accessible place.  Sharing a piece of code that is incomplete, undocumented, and unreliable is better than not sharing it, because others can correct the deficiencies, learn from the code, or avoid the bugs.  Hence the name '''Dumping Grounds''' for this page.&lt;br /&gt;
&lt;br /&gt;
The code need not follow a specific structure.  It could simply be a Scheme source file (with a '''.scm''' extension).  However, if you are packaging your code specifically for storing it here, it is best if the name of the package contains a revision number (so that many revisions can be stored) and is a gzip compressed tar file ('''.tgz''' extension) containing the code and documentation (for example file '''Sort-r1.tgz''' containing the files '''Sort-r1/Sort.scm''' and possibly '''Sort-r1/Sort.html''' and other related files).  For some reason the wiki insists on the package name starting with an upper-case letter.  The code is assumed to be in the public domain unless you add licensing information in the package itself or the documentation.&lt;br /&gt;
&lt;br /&gt;
To add a new package you must add an entry for it to this page (copy-paste an existing entry), update the file name in the &amp;lt;nowiki&amp;gt;[[media:Sort-r1.tgz|Sort-r1.tgz]]&amp;lt;/nowiki&amp;gt; link, save the page and click on the link to upload your file.  If you upload a new revision don't forget to change the revision number, and keep the link to the old revisions.&lt;br /&gt;
&lt;br /&gt;
A list of the packages and other files with statistics is available here: [[Special:Imagelist]]&lt;br /&gt;
&lt;br /&gt;
In case you find that a link to an external repository linked to from this page doesn't work anymore, please try to retrieve the latest version of the repo and upload it here, by a) contacting the author directly, b) enquiring for it on the mailing list, and/or c) trying to get it from archive.org.&lt;br /&gt;
&lt;br /&gt;
==Gambit packages==&lt;br /&gt;
These packages are in the present form created to run atop Gambit directly. They can generally easily be ported to any module system of choice.&lt;br /&gt;
===SRFI===&lt;br /&gt;
#'''SRFI-pack''': Many SRFIs ported to Gambit&lt;br /&gt;
#: Author: Guillaume Germain&lt;br /&gt;
#: Package: [[media:Srfi-pack-0.1.tar.gz|Srfi-pack-0.1.tar.gz]]&lt;br /&gt;
#: README: [[media:Srfi-pack-0.1-README.txt|Srfi-pack-0.1-README.txt]]&lt;br /&gt;
#'''SRFI-1''': SRFI-1 ported to Gambit&lt;br /&gt;
#: Author: Olin Shivers; ported by Bradley Lucier&lt;br /&gt;
#: Package [[media:Srfi1.scm|Srfi1.scm]]&lt;br /&gt;
#: Note: I did not extend map to allow list arguments of different lengths&lt;br /&gt;
&lt;br /&gt;
=== Language ===&lt;br /&gt;
# '''Gambit on LLVM''': Experimental partial back-end for Gambit using LLVM&lt;br /&gt;
#: Authors: Arnaud Bergeron and Mathieu Larose&lt;br /&gt;
#: Package: [[media:Gambit-LLVM.tgz|Gambit-LLVM.tgz]]&lt;br /&gt;
# '''Jss''': JavaScriptScheme: a multithreaded Scheme to JavaScript compiler&lt;br /&gt;
#: Author: Marc Feeley and Catherine Gaudron&lt;br /&gt;
#: Package: [[media:Jss-r2.tgz|Jss-r2.tgz]] (old: [[media:Jss-r1.tgz|Jss-r1.tgz]])&lt;br /&gt;
# '''R6RS on Gambit''':Allows R6RS programs to be run on Gambit. &lt;br /&gt;
#: Maintainer: Arthur Smyles&lt;br /&gt;
#: Package: (web page) http://smyles.com/projects/r6gambit/&lt;br /&gt;
# '''PICOBIT''': Very compact Scheme compiler and virtual machine suitable for microcontrollers.&lt;br /&gt;
#: Author: Marc Feeley and Vincent St-Amour&lt;br /&gt;
#: Package: (web page) http://repo.or.cz/w/picobit.git&lt;br /&gt;
# '''Alexpander''': A syntax-rules expander with support for DSSSL #!optional #!key and #!rest arguments.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:Alexpander-r1.tgz|Alexpander-r1.tgz]]&lt;br /&gt;
&lt;br /&gt;
===Module systems===&lt;br /&gt;
# '''Black Hole''': Module system, stable. Package handling features are in beta phase. Primary page at [[Black Hole]].&lt;br /&gt;
#: Package: (git repo) [https://github.com/pereckerdal/blackhole https://github.com/pereckerdal/blackhole]&lt;br /&gt;
&lt;br /&gt;
===Object Systems===&lt;br /&gt;
# '''Oops''': Object Oriented Programming for Scheme -- Dylan/Clos-like but different&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:oops34.tgz|oops34.tgz]]&lt;br /&gt;
# '''TinyTalk''': Self-like object system with selector [Smalltalk like] dispatch.&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:gambitTT.tgz|gambitTT.tgz]]&lt;br /&gt;
# '''class.scm''': A simple CLOS-like object system written with a balance of performance, usability and runtime heap consumption. Comes bundled with a test suite which shows exemple of how the system can be used. Also can be used easily in a repl with (include &amp;quot;class.scm&amp;quot;). &lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: (web page/git repo) http://github.com/sthilaid/class/tree/master&lt;br /&gt;
# '''Meroon''': CLOS-like object system for Scheme.&lt;br /&gt;
#: Author: Christian Queinnec, now semi-maintained by Brad Lucier.  Licensed under the [http://opensource.franz.com/preamble.html Lisp Lesser General Public Licence].  Differs from CLOS in (among many other things) having single inheritance instead of multiple inheritance and a compile-time, not a run-time, MOP.  Can be compiled to be relatively fast code.  Would benefit from being reorganized in a &amp;quot;layered&amp;quot; style more appropriate for current ideas of Scheme modules.&lt;br /&gt;
#: Website: http://www.math.purdue.edu/~lucier/software/Meroon/&lt;br /&gt;
#: Package: [[media:MeroonV3-2012Jan20.tar.bz2|MeroonV3-2012Jan20.tar.bz2]]&lt;br /&gt;
&lt;br /&gt;
=== FFI ===&lt;br /&gt;
# '''ffi-related-modules''': various modules dealing with the FFI, and their dependencies (chjmodules, but someone might turn them to using bare namespaces or so; read the Readme file at the below URL)&lt;br /&gt;
#: Author: Christian Jaeger&lt;br /&gt;
#: Package: (web page/git repo) http://scheme.ch/gambit/preview/ffi-related-modules/&lt;br /&gt;
&lt;br /&gt;
===Parsing===&lt;br /&gt;
# '''SSAX-SXML''': SSAX-SXML library packaged for Gambit-C&lt;br /&gt;
#: Author: Kirill Lisovsky (updated by Dominique Boucher)&lt;br /&gt;
#: Package: (web page) [[media:ssax-sxml-gambit-20080402.tgz|ssax-sxml-gambit-20080402.tgz]]&lt;br /&gt;
# '''Mparser''': A combinatorial parser (added expression parser) (parser language rewrite)&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:Mparser-r3.tgz|Mparser-r3.tgz]] (old: [[media:Mparser-r1.tgz|Mparser-r1.tgz]], [[media:Mparser-r2.tgz|Mparser-r2.tgz]])&lt;br /&gt;
&lt;br /&gt;
===Physics===&lt;br /&gt;
#'''Ising''': Computer simulations of the Ising model of spins using the Metropolis algorithm or the Wolff algorithm.&lt;br /&gt;
#: Author: Marijn Schouten&lt;br /&gt;
#: Package: [[media:ising-20090315.scm]]&lt;br /&gt;
&lt;br /&gt;
===Math===&lt;br /&gt;
# '''Pi''': Compute pi to arbitrary precision.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [[media:Pi-r3.tgz|Pi-r3.tgz]] (old: [[media:Pi-r2.tgz|Pi-r2.tgz]]) (old: [[media:Pi-r1.tgz|Pi-r1.tgz]])&lt;br /&gt;
# '''BLAS''': Thin wrapper for level 1, 2 and 3 BLAS linear algebra routines for the Gambit Scheme system.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/blas&lt;br /&gt;
# '''LAPACK''': Thin wrapper for higher-level linear algebra routines for the Gambit Scheme system.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/lapack&lt;br /&gt;
# '''FFTW3''': A wrapper for some FFTW3 functions for the Gambit Scheme system. (real, complex, multi-dimensional FFT functions)&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/fftw3&lt;br /&gt;
#: '''Random numbers''': High-quality random number generation. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=random http://snow.iro.umontreal.ca/?viewpkg=random]&lt;br /&gt;
&lt;br /&gt;
===Encryption===&lt;br /&gt;
# '''AES''' Message encryption and decryption based on the AES symmetric cipher. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=aes http://snow.iro.umontreal.ca/?viewpkg=aes]&lt;br /&gt;
# '''Cert''' Management of digital certificates, message signing and verification. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=cert http://snow.iro.umontreal.ca/?viewpkg=cert]&lt;br /&gt;
# '''RSA''' Message encryption and decryption based on the RSA asymmetric cipher. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=rsa http://snow.iro.umontreal.ca/?viewpkg=rsa]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- ===Networking=== --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===SQL===&lt;br /&gt;
# '''MySQL FFI''': FFI for mysql.  Unsure about thread-safety, and needs more work&lt;br /&gt;
#: Author: Jonathan Arkell&lt;br /&gt;
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/mysql/&lt;br /&gt;
# '''MySQL''': Socket level client for mysql. Supports dynamic SQL and now prepared statements. Also includes a SQL abstraction layer. This [http://andrewwhaley.blogspot.com/2009/04/gambit-mysql-client-02.html blog post] has more information. For a more developed version w UTF8 support pls contact the ml.&lt;br /&gt;
#: Author: Andrew Whaley&lt;br /&gt;
#: Package: [[media:Gambit-mysql.zip|Gambit-mysql.zip]]&lt;br /&gt;
# '''SQLite3''': a minimalistic interface to SQLite3.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:SQLite3-r1.tgz|SQLite3-r1.tgz]]&lt;br /&gt;
# '''Postgresql''': A socket level client for Postgresql&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:Postgresql-r1.tgz|Postgresql-r1.tgz]]&lt;br /&gt;
&lt;br /&gt;
===Graphics===&lt;br /&gt;
# '''Octave''': A simple plotting interface using octave (2.x) and gnuplot.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/octave/&lt;br /&gt;
# '''Schemeray''': A simple (and as of yet, unoptimized) raytracer&lt;br /&gt;
#: Author: James Long&lt;br /&gt;
#: Package: [[media:schemeray-0.2.tgz|schemeray-0.2.tgz]]&lt;br /&gt;
# '''Opengl FFI''': A simple opengl, glu and glut ffi which supports opengl up to version 1.1.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Opengl-ffi-r1.tgz|Opengl-ffi-r1.tgz]]&lt;br /&gt;
# '''Perlin Noise''': A simple opengl demonstration of a sub-optimal 2d Perlin noise implementation.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Perlin-noise-2d-r1.tgz|Perlin-noise-2d-r1.tgz]]&lt;br /&gt;
# '''Cairo''': Bindings for cairo graphics.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:Cairo-r3.tgz|Cairo-r3.tgz]] (old: [[media:Cairo-r2.tgz|Cairo-r2.tgz]])&lt;br /&gt;
# '''GLEW''': A wrapper for GLEW which provides all OpenGL functionality through version 2.1 and manages access to vendor extensions&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:Glew.tar.gz|glew.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Audio===&lt;br /&gt;
# '''mpg123''': A wrapper for the libmpg123 mpeg decoding library&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:mpg.tar.gz|mpg.tar.gz]]&lt;br /&gt;
# '''OpenAL''': A wrapper for the OpenAL audio output library&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:openAL.tar.gz|openAL.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Utilities===&lt;br /&gt;
# '''Sort''': Provides a simple sorting procedure for lists and vectors.  The mergesort algorithm is used.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [[media:Sort-r1.tgz|Sort-r1.tgz]]&lt;br /&gt;
# '''Bunny Test''': A simple unit testing framework.  &lt;br /&gt;
#: Author: Jonathan Arkell&lt;br /&gt;
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/test/&lt;br /&gt;
# '''GetOpts''': A syntactic form (let-opts) to parse command line options&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:GetOpts-r1.tgz|GetOpts-r1.tgz]]&lt;br /&gt;
# '''Etags''': Script that generates Emacs TAGS files from Scheme files, and recognizes nested definitions.&lt;br /&gt;
#: Author: Vincent St-Amour&lt;br /&gt;
#: Package: http://www-etud.iro.umontreal.ca/~stamourv/etags.scm&lt;br /&gt;
# '''Win-control''': Library for controlling Internet Explorer and other Windows applications for scripting or automating testing.&lt;br /&gt;
#: Author: Andrew Whaley&lt;br /&gt;
#: Package: http://code.google.com/p/win-control&lt;br /&gt;
# '''repltest''': Small example which embeds a remotely accessible REPL into a standalone C program.&lt;br /&gt;
#: Web: https://mercure.iro.umontreal.ca/pipermail/gambit-list/2010-June/004500.html&lt;br /&gt;
#: Package: [[media:Repltest-20100604.tgz‎|Repltest-20100604.tgz‎]]&lt;br /&gt;
# '''objc-utility-macros''': Utility macros to help wrap Objective-C methods.&lt;br /&gt;
#: Author: Jeffrey T. Read&lt;br /&gt;
#: Package: [[media:objc-utility-macros.scm‎|objc-utility-macros.scm]]&lt;br /&gt;
# '''Sort''': Richard O'Keefe's sorting procedures for lists and vectors.  Four times as fast as other sort.&lt;br /&gt;
#: Author: Richard O'Keefe&lt;br /&gt;
#: Package: [[media:Sort-okeefe.tgz|Sort-okeefe.tgz]]&lt;br /&gt;
# '''Digest''': Computation of message digests (CRC32, MD5, SHA-1, ...). Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=digest http://snow.iro.umontreal.ca/?viewpkg=digest]&lt;br /&gt;
# '''Red-black tree''' implementation, Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=rbtree http://snow.iro.umontreal.ca/?viewpkg=rbtree]&lt;br /&gt;
&lt;br /&gt;
=== Full Applications ===&lt;br /&gt;
# '''Space-Invaders''': Space Invaders classical arcade game remake in scheme over either glut or SDL.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Space-invaders-src-v1.0.tgz|Space-invaders-src-v1.0.tgz]]&lt;br /&gt;
# '''Web Server''': a web server with sessions cookies and server pages.&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:WebServer-r2.tgz|WebServer-r2.tgz]] (old: [[media:WebServer-r1.tgz|WebServer-r1.tgz]])&lt;br /&gt;
#: Git: http://git.berlios.de/cgi-bin/gitweb.cgi?p=futhark;a=summary&lt;br /&gt;
# '''GUI-Toy''': Simple Direct Media Layer prototype code with examples in the raw and using TinyTalk and Oops object systems.&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:GUI-Toy.tgz|GUI-Toy.tgz]]&lt;br /&gt;
# '''Intelligent WTF''': Intelligent acronym decoder based on ''wtf'' from BSD Games&lt;br /&gt;
#: Author: Joel J. Adamson &lt;br /&gt;
#: Package: (web page) http://www.unc.edu/~adamsonj/software.html&lt;br /&gt;
# '''Genetic Canvas''': A polygon-based image renderer using genetic algorithms.&lt;br /&gt;
#: Author: James Long&lt;br /&gt;
#: Web: http://jlongster.com/blog/2009/05/25/mona-lisa-genetically-drawn-scheme/&lt;br /&gt;
&lt;br /&gt;
==Gambit Black Hole packages==&lt;br /&gt;
These packages are in their present form created to run on Gambit using the Black Hole module system. They can generally easily be made to run on Gambit directly as well. For more info see [[Black Hole]].&lt;br /&gt;
===SRFI===&lt;br /&gt;
# '''SRFIs package'''&lt;br /&gt;
#: Package: (git repo) [https://github.com/pereckerdal/srfi https://github.com/pereckerdal/srfi]&lt;br /&gt;
&lt;br /&gt;
===Networking===&lt;br /&gt;
# '''Sack''': Web server and HTTP client. BH module. [https://github.com/pereckerdal/sack https://github.com/pereckerdal/sack]&lt;br /&gt;
&lt;br /&gt;
===Utilities===&lt;br /&gt;
# '''Mishmash of various utils''': xml&amp;lt;-&amp;gt;sxml, pregexp, digest, base64, uuid, fifo mailbox, rbtree, exception-handling, let-optionals and more. sxpath also available. These packages will be split out to individual packages. Ask on mailing list for updates.&lt;br /&gt;
#: Package: (git repo) https://github.com/pereckerdal/std&lt;br /&gt;
&lt;br /&gt;
==Documents==&lt;br /&gt;
===Scheme books===&lt;br /&gt;
# '''An Introduction to Scheme and its Implementation''': A pretty good book on how to learn Scheme, for people with a background in general programming languages.&lt;br /&gt;
#: Author: Paul R. Wilson&lt;br /&gt;
#: Package: [[media:An_Introduction_to_Scheme_and_its_Implementation.tar.gz|An_Introduction_to_Scheme_and_its_Implementation.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
[[Category: Code]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Internal_Documentation</id>
		<title>Internal Documentation</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Internal_Documentation"/>
				<updated>2012-01-05T12:48:46Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: Added notes on how to safely dump a thread's state&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;People who want to [[Contributing Patches to Gambit Source Code | contribute]] to Gambit development will need to learn something about how the Gambit-C&lt;br /&gt;
runtime and compiler are organized.  While we intend that source code documentation be included in the source&lt;br /&gt;
itself (currently there is very little documentation), we intend that descriptions of program design&lt;br /&gt;
or algorithms used in the runtime and compiler could be included here.&lt;br /&gt;
&lt;br /&gt;
== Namespace handling ==&lt;br /&gt;
&lt;br /&gt;
See [[Namespaces]].&lt;br /&gt;
&lt;br /&gt;
== Runtime Library ==&lt;br /&gt;
&lt;br /&gt;
=== Memory Management ===&lt;br /&gt;
&lt;br /&gt;
General notes on internal object storage and memory consumption is on the [[Debugging]] page. Also see [[Notes on Memory Management]].&lt;br /&gt;
&lt;br /&gt;
=== Thread System ===&lt;br /&gt;
==== Safely dumping a thread's state ====&lt;br /&gt;
Summary: Dumping thread state needs to be done with care as ##thread-continuation-capture if run on threads where code execution didn't start yet, causes SIGSEGV.&lt;br /&gt;
&lt;br /&gt;
To safely dump a thread's state (for instance, one you got from thread-group-&amp;gt;thread-list), refer to the following routine, which reads out the thread's state, taking into consideration any possible state. (Thanks to Marc 16 dec 2011 while Gambit at v4.6.2.)&lt;br /&gt;
&lt;br /&gt;
The macros are from define-type thread of lib/_thread#.scm .&lt;br /&gt;
&lt;br /&gt;
XX While I think the following code is threadsafe, I have not got that confirmed. If you by any reason suspect the contrary, please let the ML know.&lt;br /&gt;
&lt;br /&gt;
 (let* ((end-condvar (macro-thread-end-condvar thread))&lt;br /&gt;
        (exception?  (macro-thread-exception?  thread))&lt;br /&gt;
        (result      (macro-thread-result      thread)))&lt;br /&gt;
   (cond ((not end-condvar)&lt;br /&gt;
          ;; thread has terminated&lt;br /&gt;
          (if exception?&lt;br /&gt;
              (begin&lt;br /&gt;
                ;; thread has terminated with exception&lt;br /&gt;
                (display &amp;quot;Terminated with exception:\n&amp;quot;)&lt;br /&gt;
                (display-exception result))&lt;br /&gt;
              (begin&lt;br /&gt;
                ;; thread has terminated with result&lt;br /&gt;
                (display &amp;quot;Terminated with result:\n&amp;quot;)&lt;br /&gt;
                (pretty-print result))))&lt;br /&gt;
         (exception?&lt;br /&gt;
          ;; thread has never run and is not terminated&lt;br /&gt;
          (if (not result)&lt;br /&gt;
              (begin&lt;br /&gt;
                ;; thread is not yet started&lt;br /&gt;
                (display &amp;quot;Not yet started\n&amp;quot;))&lt;br /&gt;
              (begin&lt;br /&gt;
                ;; thread is started but has not yet run&lt;br /&gt;
                (display &amp;quot;Started but has not yet run\n&amp;quot;))))&lt;br /&gt;
         (else&lt;br /&gt;
          (let ((c (##thread-continuation-capture thread))) ; See note above&lt;br /&gt;
            (cond ((and max-head max-tail)&lt;br /&gt;
                   (display-continuation-backtrace c (current-output-port) #f display-environment max-head max-tail))&lt;br /&gt;
                  (max-head&lt;br /&gt;
                   (display-continuation-backtrace c (current-output-port) #f display-environment max-head))&lt;br /&gt;
                  (else&lt;br /&gt;
                   (display-continuation-backtrace c (current-output-port) #f display-environment)))&lt;br /&gt;
             ))))&lt;br /&gt;
&lt;br /&gt;
=== I/O System ===&lt;br /&gt;
&lt;br /&gt;
=== Arithmetic implementation ===&lt;br /&gt;
&lt;br /&gt;
=== Eval ===&lt;br /&gt;
&lt;br /&gt;
====Continuation manipulation====&lt;br /&gt;
&lt;br /&gt;
The manual lists &amp;lt;code&amp;gt;continuation-graft&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;continuation-capture&amp;lt;/code&amp;gt;, and &amp;lt;code&amp;gt;continuation-return&amp;lt;/code&amp;gt; but doesn't describe them.  The REPL debugger, and possibly other things, use them.  See Marc Feeley's paper ''A Better API for First-Class Continuations''.&lt;br /&gt;
&lt;br /&gt;
=== REPL ===&lt;br /&gt;
&lt;br /&gt;
The REPL has some fairly interesting functions and variables, especially for hackers.&lt;br /&gt;
&lt;br /&gt;
==== Variables ====&lt;br /&gt;
;&amp;lt;code&amp;gt;##repl-location-relative&amp;lt;/code&amp;gt;&lt;br /&gt;
:Should the REPL give relative or absolute pathnames.  '''Note:''' When using emacs with gambit, it is useful to set it to #f, especially if you change the current-directory.&lt;br /&gt;
 &lt;br /&gt;
==== Functions ====&lt;br /&gt;
;&amp;lt;code&amp;gt;##cmd-&amp;lt;/code&amp;gt;''x''&lt;br /&gt;
:where ''x'' is a REPL command letter (typed after a comma from the REPL).  Executes that command as if it was executed inside of the REPL.  For instance &amp;lt;code&amp;gt;##cmd-b&amp;lt;/code&amp;gt; displays a backtrace.&lt;br /&gt;
&lt;br /&gt;
===Record system===&lt;br /&gt;
&lt;br /&gt;
That is, &amp;lt;code&amp;gt;define-type&amp;lt;/code&amp;gt;.  Based on SRFI-9, but extensions not documented. This email provides the best explanation [https://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20090226/af2ee44c/attachment-0001.txt]&lt;br /&gt;
&lt;br /&gt;
===Introspection===&lt;br /&gt;
====Symbol introspection====&lt;br /&gt;
To get list of interned symbols:&lt;br /&gt;
&lt;br /&gt;
 (define (symbol-table-&amp;gt;list st)&lt;br /&gt;
 &lt;br /&gt;
   (define (symbol-chain s syms)&lt;br /&gt;
     (let loop ((s s) (syms syms))&lt;br /&gt;
       (if (symbol? s)&lt;br /&gt;
           (loop (##vector-ref s 2) (cons s syms))&lt;br /&gt;
           syms)))&lt;br /&gt;
 &lt;br /&gt;
   (let loop ((lst (vector-&amp;gt;list st)) (syms '()))&lt;br /&gt;
     (if (pair? lst)&lt;br /&gt;
         (loop (cdr lst) (symbol-chain (car lst) syms))&lt;br /&gt;
         (reverse syms))))&lt;br /&gt;
 &lt;br /&gt;
 (define (interned-symbols)&lt;br /&gt;
   (symbol-table-&amp;gt;list (##symbol-table)))&lt;br /&gt;
 &lt;br /&gt;
 (pp (length (interned-symbols)))&lt;br /&gt;
&lt;br /&gt;
(From Gambit ML 2009-03-22)&lt;br /&gt;
&lt;br /&gt;
=== Program startup ===&lt;br /&gt;
&lt;br /&gt;
* The entry point function (either main(), winmain()...) will be generated (in linker file) to call either &amp;lt;code&amp;gt;___main()&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;___main_UCS_2&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;___winmain&amp;lt;/code&amp;gt;.&lt;br /&gt;
* These functions do very basic initialization (setup &amp;lt;code&amp;gt;___base_mod&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;___program_startup_info&amp;lt;/code&amp;gt;) then passes to &amp;lt;code&amp;gt;___main()&amp;lt;/code&amp;gt; in main.c. &lt;br /&gt;
* This function in turn calls &amp;lt;code&amp;gt;___setup()&amp;lt;/code&amp;gt;, which does&lt;br /&gt;
** sets up the VM&lt;br /&gt;
** Call linker&lt;br /&gt;
** Initialize tables (symbol, keyword, global variables, primitives)&lt;br /&gt;
** Kick off the kernel&lt;br /&gt;
&lt;br /&gt;
== Compiler ==&lt;br /&gt;
&lt;br /&gt;
Script igsc.scm inside gsc directory can be used to get REPL of compiler so you can inspect details.&lt;br /&gt;
&lt;br /&gt;
=== Frontend ===&lt;br /&gt;
&lt;br /&gt;
The frontend entry point is '''cf''', main function to do compilation is '''compile-parsed-program''', which generates GVM instructions. Some optimization is done by frontend via function '''normalize-program'''.&lt;br /&gt;
&lt;br /&gt;
TODO: Optimizations, program tree representation.&lt;br /&gt;
&lt;br /&gt;
=== Intermediate representation ===&lt;br /&gt;
&lt;br /&gt;
The closet document to describe Gambit Virtual Machine is probably [http://www.iro.umontreal.ca/~feeley/papers/pvm.ps.gz A Parallel Virtual Machine for Efficient Scheme Compilation].&lt;br /&gt;
&lt;br /&gt;
==== Operands ====&lt;br /&gt;
&lt;br /&gt;
There are 6 types of operands, described in _gvmadt.scm. All operands are encoded to a number. The following list is extracted from _gvmadt.scm:&lt;br /&gt;
&lt;br /&gt;
  reg(n)       n*8 + 0&lt;br /&gt;
  stk(n)       n*8 + 1&lt;br /&gt;
  lbl(n)       n*8 + 2&lt;br /&gt;
  glo(name)    index_in_operand_table*8 + 3&lt;br /&gt;
  clo(opnd,n)  index_in_operand_table*8 + 4&lt;br /&gt;
  obj(x)       index_in_operand_table*8 + 5&lt;br /&gt;
&lt;br /&gt;
Global variables (glo), closed variables (clo) and objects are saved in *opnd-table*. Reg, stk, lbl are respectively abbreviations of register, stack and label. All these operands can be created by make-X, where X is the abbreviation.&lt;br /&gt;
&lt;br /&gt;
In .gvm output, registers are prefixed by &amp;quot;+&amp;quot;, stack by &amp;quot;-&amp;quot;, objects by a single quote, labels by &amp;quot;#&amp;quot;. Global variables are displayed by variable name, closed variables are enclosed in brackets, objects &lt;br /&gt;
&lt;br /&gt;
==== Instructions ====&lt;br /&gt;
&lt;br /&gt;
GVM instructions include apply, copy, close, ifjump, switch,  jump, comment and label, in _gvm.scm, &amp;quot;Virtual machine instruction representation&amp;quot; section.&lt;br /&gt;
&lt;br /&gt;
Instructions in .gvm output are represented by their name. If it's a poll jump, the instruction will be followed by a star. If it's a safe jump, it is followed by a dollar.&lt;br /&gt;
&lt;br /&gt;
==== Optimization ====&lt;br /&gt;
&lt;br /&gt;
After GVM generation, dead code is removed by '''bbs-purify!'''.&lt;br /&gt;
&lt;br /&gt;
=== Backend ===&lt;br /&gt;
&lt;br /&gt;
Backend is selected by '''target-select!'''. All backend functions start with '''target.'''. The only supported backend is C, which explains the &amp;quot;C&amp;quot; part in &amp;quot;Gambit-C&amp;quot;, reside in _t-c-[1-3].scm.&lt;br /&gt;
&lt;br /&gt;
The initial state of a module includes global variables, symbols, keywords, subtypes, number of used labels and procedures. All are maintained during compilation (see &amp;quot;Object management&amp;quot; in _t-c-1.scm) and dumped out as C declaration. The entry point that does this is targ-heap-dump. C output is written in C macros only. '''gambit.h''' will actually produce C code suitable for each architecture.&lt;br /&gt;
&lt;br /&gt;
==== Linking ====&lt;br /&gt;
&lt;br /&gt;
Because each module contains each own global variables, symbols and keywords. All must be combined to produce single tables for those. Linking works by reading linker info in generated C files. Linker info is actually sexp embedded in C files (and be never read by C compiler as it is protected by #ifdef). Structure of linker info can be found in '''targ-read-linker-info''', which is a list of&lt;br /&gt;
&lt;br /&gt;
# Compiler version&lt;br /&gt;
# Module name&lt;br /&gt;
# Modules&lt;br /&gt;
# List of symbols&lt;br /&gt;
# List of keywords&lt;br /&gt;
# List of supplied and demanded globals&lt;br /&gt;
# List of supplied and not demanded globals&lt;br /&gt;
# List of not supplied globals&lt;br /&gt;
# Script line&lt;br /&gt;
&lt;br /&gt;
Linking is started with '''targ-linker'''. When incremental link is demanded, INCREMENTAL_LINKFILE will be defined in generated C file. gambit.h will handle the rest.&lt;br /&gt;
&lt;br /&gt;
[[Category: Internals]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Documentation</id>
		<title>Documentation</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Documentation"/>
				<updated>2011-11-26T14:00:10Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== User Documentation ==&lt;br /&gt;
&lt;br /&gt;
There is a user manual for Gambit in [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html HTML]&lt;br /&gt;
and [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.pdf PDF] formats.&lt;br /&gt;
&lt;br /&gt;
See the [[Scheme]] page for documentation on Scheme in general.&lt;br /&gt;
&lt;br /&gt;
== Prebuilt Distributions ==&lt;br /&gt;
&lt;br /&gt;
Some prebuilt distributions are [[Distributions | available]].&lt;br /&gt;
&lt;br /&gt;
== Building Gambit from Source ==&lt;br /&gt;
&lt;br /&gt;
To build Gambit from source, one must first run the configure script, which has a number&lt;br /&gt;
of important [[Configure script options | options]].&lt;br /&gt;
&lt;br /&gt;
There are various [[Make targets | make targets]] of which you should be aware.&lt;br /&gt;
&lt;br /&gt;
== Packages, modules, libraries and driving systems ==&lt;br /&gt;
&lt;br /&gt;
See the [[Packages]] page.&lt;br /&gt;
&lt;br /&gt;
=== SRFI support ===&lt;br /&gt;
The Scheme community has accumulated a set of common libraries and conventions called Scheme Requests for Implementation, publicly collected on [http://srfi.schemers.org/ srfi.schemers.org].&lt;br /&gt;
&lt;br /&gt;
Gambit [[SRFI:s | natively implements]] a number of SRFIs.&lt;br /&gt;
[[Black Hole]] includes several popular SRFIs not natively supported,&lt;br /&gt;
while still others may be downloaded from [http://snow.iro.umontreal.ca/?listcat=srfi Snow].&lt;br /&gt;
&lt;br /&gt;
== Editor/IDE Support ==&lt;br /&gt;
&lt;br /&gt;
Gambit provides a powerful development environment through [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#Emacs-interface Emacs]. &lt;br /&gt;
&lt;br /&gt;
For those running MS Windows you can [http://ftp.gnu.org/pub/gnu/emacs/windows/ download Emacs here]. You may want to read the [http://www.gnu.org/software/emacs/windows/ntemacs.html Emacs FAQ for Windows] before customizing Emacs for use with Gambit. In order to use Emacs' inferior scheme mode on Windows, you may need to run gsi/gsc in raw stdin/stdout mode (see section &amp;quot;Emacs interface&amp;quot; in the manual for details).&lt;br /&gt;
&lt;br /&gt;
Editors such as [http://www.eclipse.org/ Eclipse] with the [http://schemeway.sourceforge.net/ SchemeWay] extension, or just about any text editor with Scheme syntax highlighting, such as [http://www.vim.org VIM or GVIM], may prove valuable as well.&lt;br /&gt;
&lt;br /&gt;
== Termite ==&lt;br /&gt;
&lt;br /&gt;
[http://code.google.com/p/termite/ Termite] is an Erlang-like distributed programming system written in Scheme.&lt;br /&gt;
&lt;br /&gt;
Distributed computing hot right now, and Termite has been noticed in blogs and elsewhere.&lt;br /&gt;
&lt;br /&gt;
Termite depends on specific features of Gambit, and at one time or another&lt;br /&gt;
the Termite source code has been distributed with Gambit, so we point to the Termite web site&lt;br /&gt;
from here.&lt;br /&gt;
&lt;br /&gt;
== Tutorials ==&lt;br /&gt;
[[A Tour of Scheme in Gambit]] gives a general introduction to Scheme and Gambit to people with experiences of general programming languages. Available in [[media:A_Tour_of_Scheme_in_Gambit.pdf|PDF]], [[media:A_Tour_of_Scheme_in_Gambit.odf|Open Office]] and [[media:A_Tour_of_Scheme_in_Gambit.doc|Microsoft Word]] formats.&lt;br /&gt;
&lt;br /&gt;
== Internals Documentation ==&lt;br /&gt;
&lt;br /&gt;
People who want to [[How to Contribute | contribute]] to Gambit development will need to learn something about how the Gambit-C&lt;br /&gt;
runtime and compiler are organized.  While we intend that source code documentation be included in the source&lt;br /&gt;
itself (currently there is very little documentation), we intend that descriptions of program design&lt;br /&gt;
or algorithms used in the runtime and compiler could be included on the [[Internal Documentation]] page.&lt;br /&gt;
&lt;br /&gt;
== Working with External Libraries ==&lt;br /&gt;
&lt;br /&gt;
With Gambit's C FFI (Foreign Function Interface), one can easily use standard C and C++ libraries with your code; this wiki has some examples of and practices on using Gambit with external libraries. See [[Using Gambit with External Libraries]].&lt;br /&gt;
&lt;br /&gt;
== Debugging ==&lt;br /&gt;
&lt;br /&gt;
See the [[Debugging]] page.&lt;br /&gt;
&lt;br /&gt;
== More ==&lt;br /&gt;
The [http://mailman.iro.umontreal.ca/pipermail/gambit-list mailing list archive] covers many topics at depth. You can make Google search queries limited to the mailing list by clicking &amp;quot;advanced settings&amp;quot; on www.google.com.&lt;br /&gt;
&lt;br /&gt;
[[Dumping Grounds]]&lt;br /&gt;
&lt;br /&gt;
[[Compiling Gambit software for different target environments]]&lt;br /&gt;
&lt;br /&gt;
[[Wish list]]&lt;br /&gt;
&lt;br /&gt;
[[External links]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds</id>
		<title>Dumping Grounds</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds"/>
				<updated>2011-11-26T11:12:51Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Here you will find packages of Gambit code contributed by users.  This page is meant as a simple repository where random code snippets as well as complex systems can easily be stored so that other users can get to them.  This is not a substitute for a repository that is closely coupled with the Gambit system's module system (which is under development).  It is meant to foster the sharing of code by making it extremely easy to publish code in a publicly accessible place.  Sharing a piece of code that is incomplete, undocumented, and unreliable is better than not sharing it, because others can correct the deficiencies, learn from the code, or avoid the bugs.  Hence the name '''Dumping Grounds''' for this page.&lt;br /&gt;
&lt;br /&gt;
The code need not follow a specific structure.  It could simply be a Scheme source file (with a '''.scm''' extension).  However, if you are packaging your code specifically for storing it here, it is best if the name of the package contains a revision number (so that many revisions can be stored) and is a gzip compressed tar file ('''.tgz''' extension) containing the code and documentation (for example file '''Sort-r1.tgz''' containing the files '''Sort-r1/Sort.scm''' and possibly '''Sort-r1/Sort.html''' and other related files).  For some reason the wiki insists on the package name starting with an upper-case letter.  The code is assumed to be in the public domain unless you add licensing information in the package itself or the documentation.&lt;br /&gt;
&lt;br /&gt;
To add a new package you must add an entry for it to this page (copy-paste an existing entry), update the file name in the &amp;lt;nowiki&amp;gt;[[media:Sort-r1.tgz|Sort-r1.tgz]]&amp;lt;/nowiki&amp;gt; link, save the page and click on the link to upload your file.  If you upload a new revision don't forget to change the revision number, and keep the link to the old revisions.&lt;br /&gt;
&lt;br /&gt;
A list of the packages and other files with statistics is available here: [[Special:Imagelist]]&lt;br /&gt;
&lt;br /&gt;
In case you find that a link to an external repository linked to from this page doesn't work anymore, please try to retrieve the latest version of the repo and upload it here, by a) contacting the author directly, b) enquiring for it on the mailing list, and/or c) trying to get it from archive.org.&lt;br /&gt;
&lt;br /&gt;
==Gambit packages==&lt;br /&gt;
These packages are in the present form created to run atop Gambit directly. They can generally easily be ported to any module system of choice.&lt;br /&gt;
===SRFI===&lt;br /&gt;
#'''SRFI-pack''': Many SRFIs ported to Gambit&lt;br /&gt;
#: Author: Guillaume Germain&lt;br /&gt;
#: Package: [[media:Srfi-pack-0.1.tar.gz|Srfi-pack-0.1.tar.gz]]&lt;br /&gt;
#: README: [[media:Srfi-pack-0.1-README.txt|Srfi-pack-0.1-README.txt]]&lt;br /&gt;
#'''SRFI-1''': SRFI-1 ported to Gambit&lt;br /&gt;
#: Author: Olin Shivers; ported by Bradley Lucier&lt;br /&gt;
#: Package [[media:Srfi1.scm|Srfi1.scm]]&lt;br /&gt;
#: Note: I did not extend map to allow list arguments of different lengths&lt;br /&gt;
&lt;br /&gt;
=== Language ===&lt;br /&gt;
# '''Gambit on LLVM''': Experimental partial back-end for Gambit using LLVM&lt;br /&gt;
#: Authors: Arnaud Bergeron and Mathieu Larose&lt;br /&gt;
#: Package: [[media:Gambit-LLVM.tgz|Gambit-LLVM.tgz]]&lt;br /&gt;
# '''Jss''': JavaScriptScheme: a multithreaded Scheme to JavaScript compiler&lt;br /&gt;
#: Author: Marc Feeley and Catherine Gaudron&lt;br /&gt;
#: Package: [[media:Jss-r2.tgz|Jss-r2.tgz]] (old: [[media:Jss-r1.tgz|Jss-r1.tgz]])&lt;br /&gt;
# '''R6RS on Gambit''':Allows R6RS programs to be run on Gambit. &lt;br /&gt;
#: Maintainer: Arthur Smyles&lt;br /&gt;
#: Package: (web page) http://smyles.com/projects/r6gambit/&lt;br /&gt;
# '''PICOBIT''': Very compact Scheme compiler and virtual machine suitable for microcontrollers.&lt;br /&gt;
#: Author: Marc Feeley and Vincent St-Amour&lt;br /&gt;
#: Package: (web page) http://repo.or.cz/w/picobit.git&lt;br /&gt;
# '''Alexpander''': A syntax-rules expander with support for DSSSL #!optional #!key and #!rest arguments.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:Alexpander-r1.tgz|Alexpander-r1.tgz]]&lt;br /&gt;
&lt;br /&gt;
===Module systems===&lt;br /&gt;
# '''Black Hole''': Module system, stable. Package handling features are in beta phase. Primary page at [[Black Hole]].&lt;br /&gt;
#: Package: (git repo) [https://github.com/pereckerdal/blackhole https://github.com/pereckerdal/blackhole]&lt;br /&gt;
&lt;br /&gt;
===Object Systems===&lt;br /&gt;
# '''Oops''': Object Oriented Programming for Scheme -- Dylan/Clos-like but different&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:oops34.tgz|oops34.tgz]]&lt;br /&gt;
# '''TinyTalk''': Self-like object system with selector [Smalltalk like] dispatch.&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:gambitTT.tgz|gambitTT.tgz]]&lt;br /&gt;
# '''class.scm''': A simple CLOS-like object system written with a balance of performance, usability and runtime heap consumption. Comes bundled with a test suite which shows exemple of how the system can be used. Also can be used easily in a repl with (include &amp;quot;class.scm&amp;quot;). &lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: (web page/git repo) http://github.com/sthilaid/class/tree/master&lt;br /&gt;
# '''Meroon''': CLOS-like object system for Scheme.&lt;br /&gt;
#: Author: Christian Queinnec, now semi-maintained by Brad Lucier.  Licensed under the [http://opensource.franz.com/preamble.html Lisp Lesser General Public Licence].  Differs from CLOS in (among many other things) having single inheritance instead of multiple inheritance and a compile-time, not a run-time, MOP.  Can be compiled to be relatively fast code.  Would benefit from being reorganized in a &amp;quot;layered&amp;quot; style more appropriate for current ideas of Scheme modules.&lt;br /&gt;
#: Website: http://www.math.purdue.edu/~lucier/software/Meroon/&lt;br /&gt;
#: Package: [[media:MeroonV3-2008Mar01.tar.bz2‎|MeroonV3-2008Mar01.tar.bz2]]&lt;br /&gt;
&lt;br /&gt;
=== FFI ===&lt;br /&gt;
# '''ffi-related-modules''': various modules dealing with the FFI, and their dependencies (chjmodules, but someone might turn them to using bare namespaces or so; read the Readme file at the below URL)&lt;br /&gt;
#: Author: Christian Jaeger&lt;br /&gt;
#: Package: (web page/git repo) http://scheme.ch/gambit/preview/ffi-related-modules/&lt;br /&gt;
&lt;br /&gt;
===Parsing===&lt;br /&gt;
# '''SSAX-SXML''': SSAX-SXML library packaged for Gambit-C&lt;br /&gt;
#: Author: Kirill Lisovsky (updated by Dominique Boucher)&lt;br /&gt;
#: Package: (web page) [[media:ssax-sxml-gambit-20080402.tgz|ssax-sxml-gambit-20080402.tgz]]&lt;br /&gt;
# '''Mparser''': A combinatorial parser (added expression parser) (parser language rewrite)&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:Mparser-r3.tgz|Mparser-r3.tgz]] (old: [[media:Mparser-r1.tgz|Mparser-r1.tgz]], [[media:Mparser-r2.tgz|Mparser-r2.tgz]])&lt;br /&gt;
&lt;br /&gt;
===Physics===&lt;br /&gt;
#'''Ising''': Computer simulations of the Ising model of spins using the Metropolis algorithm or the Wolff algorithm.&lt;br /&gt;
#: Author: Marijn Schouten&lt;br /&gt;
#: Package: [[media:ising-20090315.scm]]&lt;br /&gt;
&lt;br /&gt;
===Math===&lt;br /&gt;
# '''Pi''': Compute pi to arbitrary precision.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [[media:Pi-r3.tgz|Pi-r3.tgz]] (old: [[media:Pi-r2.tgz|Pi-r2.tgz]]) (old: [[media:Pi-r1.tgz|Pi-r1.tgz]])&lt;br /&gt;
# '''BLAS''': Thin wrapper for level 1, 2 and 3 BLAS linear algebra routines for the Gambit Scheme system.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/blas&lt;br /&gt;
# '''LAPACK''': Thin wrapper for higher-level linear algebra routines for the Gambit Scheme system.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/lapack&lt;br /&gt;
# '''FFTW3''': A wrapper for some FFTW3 functions for the Gambit Scheme system. (real, complex, multi-dimensional FFT functions)&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/fftw3&lt;br /&gt;
#: '''Random numbers''': High-quality random number generation. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=random http://snow.iro.umontreal.ca/?viewpkg=random]&lt;br /&gt;
&lt;br /&gt;
===Encryption===&lt;br /&gt;
# '''AES''' Message encryption and decryption based on the AES symmetric cipher. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=aes http://snow.iro.umontreal.ca/?viewpkg=aes]&lt;br /&gt;
# '''Cert''' Management of digital certificates, message signing and verification. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=cert http://snow.iro.umontreal.ca/?viewpkg=cert]&lt;br /&gt;
# '''RSA''' Message encryption and decryption based on the RSA asymmetric cipher. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=rsa http://snow.iro.umontreal.ca/?viewpkg=rsa]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- ===Networking=== --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===SQL===&lt;br /&gt;
# '''MySQL FFI''': FFI for mysql.  Unsure about thread-safety, and needs more work&lt;br /&gt;
#: Author: Jonathan Arkell&lt;br /&gt;
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/mysql/&lt;br /&gt;
# '''MySQL''': Socket level client for mysql. Supports dynamic SQL and now prepared statements. Also includes a SQL abstraction layer. This [http://andrewwhaley.blogspot.com/2009/04/gambit-mysql-client-02.html blog post] has more information.&lt;br /&gt;
#: Author: Andrew Whaley&lt;br /&gt;
#: Package: [[media:Gambit-mysql.zip|Gambit-mysql.zip]]&lt;br /&gt;
# '''SQLite3''': a minimalistic interface to SQLite3.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:SQLite3-r1.tgz|SQLite3-r1.tgz]]&lt;br /&gt;
# '''Postgresql''': A socket level client for Postgresql&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:Postgresql-r1.tgz|Postgresql-r1.tgz]]&lt;br /&gt;
&lt;br /&gt;
===Graphics===&lt;br /&gt;
# '''Octave''': A simple plotting interface using octave (2.x) and gnuplot.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/octave/&lt;br /&gt;
# '''Schemeray''': A simple (and as of yet, unoptimized) raytracer&lt;br /&gt;
#: Author: James Long&lt;br /&gt;
#: Package: [[media:schemeray-0.2.tgz|schemeray-0.2.tgz]]&lt;br /&gt;
# '''Opengl FFI''': A simple opengl, glu and glut ffi which supports opengl up to version 1.1.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Opengl-ffi-r1.tgz|Opengl-ffi-r1.tgz]]&lt;br /&gt;
# '''Perlin Noise''': A simple opengl demonstration of a sub-optimal 2d Perlin noise implementation.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Perlin-noise-2d-r1.tgz|Perlin-noise-2d-r1.tgz]]&lt;br /&gt;
# '''Cairo''': Bindings for cairo graphics.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:Cairo-r3.tgz|Cairo-r3.tgz]] (old: [[media:Cairo-r2.tgz|Cairo-r2.tgz]])&lt;br /&gt;
# '''GLEW''': A wrapper for GLEW which provides all OpenGL functionality through version 2.1 and manages access to vendor extensions&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:Glew.tar.gz|glew.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Audio===&lt;br /&gt;
# '''mpg123''': A wrapper for the libmpg123 mpeg decoding library&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:mpg.tar.gz|mpg.tar.gz]]&lt;br /&gt;
# '''OpenAL''': A wrapper for the OpenAL audio output library&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:openAL.tar.gz|openAL.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Utilities===&lt;br /&gt;
# '''Sort''': Provides a simple sorting procedure for lists and vectors.  The mergesort algorithm is used.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [[media:Sort-r1.tgz|Sort-r1.tgz]]&lt;br /&gt;
# '''Bunny Test''': A simple unit testing framework.  &lt;br /&gt;
#: Author: Jonathan Arkell&lt;br /&gt;
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/test/&lt;br /&gt;
# '''GetOpts''': A syntactic form (let-opts) to parse command line options&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:GetOpts-r1.tgz|GetOpts-r1.tgz]]&lt;br /&gt;
# '''Etags''': Script that generates Emacs TAGS files from Scheme files, and recognizes nested definitions.&lt;br /&gt;
#: Author: Vincent St-Amour&lt;br /&gt;
#: Package: http://www-etud.iro.umontreal.ca/~stamourv/etags.scm&lt;br /&gt;
# '''Win-control''': Library for controlling Internet Explorer and other Windows applications for scripting or automating testing.&lt;br /&gt;
#: Author: Andrew Whaley&lt;br /&gt;
#: Package: http://code.google.com/p/win-control&lt;br /&gt;
# '''repltest''': Small example which embeds a remotely accessible REPL into a standalone C program.&lt;br /&gt;
#: Web: https://mercure.iro.umontreal.ca/pipermail/gambit-list/2010-June/004500.html&lt;br /&gt;
#: Package: [[media:Repltest-20100604.tgz‎|Repltest-20100604.tgz‎]]&lt;br /&gt;
# '''objc-utility-macros''': Utility macros to help wrap Objective-C methods.&lt;br /&gt;
#: Author: Jeffrey T. Read&lt;br /&gt;
#: Package: [[media:objc-utility-macros.scm‎|objc-utility-macros.scm]]&lt;br /&gt;
# '''Sort''': Richard O'Keefe's sorting procedures for lists and vectors.  Four times as fast as other sort.&lt;br /&gt;
#: Author: Richard O'Keefe&lt;br /&gt;
#: Package: [[media:Sort-okeefe.tgz|Sort-okeefe.tgz]]&lt;br /&gt;
# '''Digest''': Computation of message digests (CRC32, MD5, SHA-1, ...). Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=digest http://snow.iro.umontreal.ca/?viewpkg=digest]&lt;br /&gt;
# '''Red-black tree''' implementation, Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=rbtree http://snow.iro.umontreal.ca/?viewpkg=rbtree]&lt;br /&gt;
&lt;br /&gt;
=== Full Applications ===&lt;br /&gt;
# '''Space-Invaders''': Space Invaders classical arcade game remake in scheme over either glut or SDL.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Space-invaders-src-v1.0.tgz|Space-invaders-src-v1.0.tgz]]&lt;br /&gt;
# '''Web Server''': a web server with sessions cookies and server pages.&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:WebServer-r2.tgz|WebServer-r2.tgz]] (old: [[media:WebServer-r1.tgz|WebServer-r1.tgz]])&lt;br /&gt;
#: Git: http://git.berlios.de/cgi-bin/gitweb.cgi?p=futhark;a=summary&lt;br /&gt;
# '''GUI-Toy''': Simple Direct Media Layer prototype code with examples in the raw and using TinyTalk and Oops object systems.&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:GUI-Toy.tgz|GUI-Toy.tgz]]&lt;br /&gt;
# '''Intelligent WTF''': Intelligent acronym decoder based on ''wtf'' from BSD Games&lt;br /&gt;
#: Author: Joel J. Adamson &lt;br /&gt;
#: Package: (web page) http://www.unc.edu/~adamsonj/software.html&lt;br /&gt;
# '''Genetic Canvas''': A polygon-based image renderer using genetic algorithms.&lt;br /&gt;
#: Author: James Long&lt;br /&gt;
#: Web: http://jlongster.com/blog/2009/05/25/mona-lisa-genetically-drawn-scheme/&lt;br /&gt;
&lt;br /&gt;
==Gambit Black Hole packages==&lt;br /&gt;
These packages are in their present form created to run on Gambit using the Black Hole module system. They can generally easily be made to run on Gambit directly as well. For more info see [[Black Hole]].&lt;br /&gt;
===SRFI===&lt;br /&gt;
# '''SRFIs package'''&lt;br /&gt;
#: Package: (git repo) [https://github.com/pereckerdal/srfi https://github.com/pereckerdal/srfi]&lt;br /&gt;
&lt;br /&gt;
===Networking===&lt;br /&gt;
# '''Sack''': Web server and HTTP client. BH module. [https://github.com/pereckerdal/sack https://github.com/pereckerdal/sack]&lt;br /&gt;
&lt;br /&gt;
===Utilities===&lt;br /&gt;
# '''Mishmash of various utils''': xml&amp;lt;-&amp;gt;sxml, pregexp, digest, base64, uuid, fifo mailbox, rbtree, exception-handling, let-optionals and more. sxpath also available. These packages will be split out to individual packages. Ask on mailing list for updates.&lt;br /&gt;
#: Package: (git repo) https://github.com/pereckerdal/std&lt;br /&gt;
&lt;br /&gt;
==Documents==&lt;br /&gt;
===Scheme books===&lt;br /&gt;
# '''An Introduction to Scheme and its Implementation''': A pretty good book on how to learn Scheme, for people with a background in general programming languages.&lt;br /&gt;
#: Author: Paul R. Wilson&lt;br /&gt;
#: Package: [[media:An_Introduction_to_Scheme_and_its_Implementation.tar.gz|An_Introduction_to_Scheme_and_its_Implementation.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
[[Category: Code]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds</id>
		<title>Dumping Grounds</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds"/>
				<updated>2011-11-26T10:47:45Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Here you will find packages of Gambit code contributed by users.  This page is meant as a simple repository where random code snippets as well as complex systems can easily be stored so that other users can get to them.  This is not a substitute for a repository that is closely coupled with the Gambit system's module system (which is under development).  It is meant to foster the sharing of code by making it extremely easy to publish code in a publicly accessible place.  Sharing a piece of code that is incomplete, undocumented, and unreliable is better than not sharing it, because others can correct the deficiencies, learn from the code, or avoid the bugs.  Hence the name '''Dumping Grounds''' for this page.&lt;br /&gt;
&lt;br /&gt;
The code need not follow a specific structure.  It could simply be a Scheme source file (with a '''.scm''' extension).  However, if you are packaging your code specifically for storing it here, it is best if the name of the package contains a revision number (so that many revisions can be stored) and is a gzip compressed tar file ('''.tgz''' extension) containing the code and documentation (for example file '''Sort-r1.tgz''' containing the files '''Sort-r1/Sort.scm''' and possibly '''Sort-r1/Sort.html''' and other related files).  For some reason the wiki insists on the package name starting with an upper-case letter.  The code is assumed to be in the public domain unless you add licensing information in the package itself or the documentation.&lt;br /&gt;
&lt;br /&gt;
To add a new package you must add an entry for it to this page (copy-paste an existing entry), update the file name in the &amp;lt;nowiki&amp;gt;[[media:Sort-r1.tgz|Sort-r1.tgz]]&amp;lt;/nowiki&amp;gt; link, save the page and click on the link to upload your file.  If you upload a new revision don't forget to change the revision number, and keep the link to the old revisions.&lt;br /&gt;
&lt;br /&gt;
A list of the packages and other files with statistics is available here: [[Special:Imagelist]]&lt;br /&gt;
&lt;br /&gt;
In case you find that a link to an external repository linked to from this page doesn't work anymore, please try to retrieve the latest version of the repo and upload it here, by a) contacting the author directly, b) enquiring for it on the mailing list, and/or c) trying to get it from archive.org.&lt;br /&gt;
&lt;br /&gt;
==Packages==&lt;br /&gt;
===SRFI===&lt;br /&gt;
#'''SRFI-pack''': Many SRFIs ported to Gambit&lt;br /&gt;
#: Author: Guillaume Germain&lt;br /&gt;
#: Package: [[media:Srfi-pack-0.1.tar.gz|Srfi-pack-0.1.tar.gz]]&lt;br /&gt;
#: README: [[media:Srfi-pack-0.1-README.txt|Srfi-pack-0.1-README.txt]]&lt;br /&gt;
#'''SRFI-1''': SRFI-1 ported to Gambit&lt;br /&gt;
#: Author: Olin Shivers; ported by Bradley Lucier&lt;br /&gt;
#: Package [[media:Srfi1.scm|Srfi1.scm]]&lt;br /&gt;
#: Note: I did not extend map to allow list arguments of different lengths&lt;br /&gt;
# '''SRFIs Black Hole package''', see info at [[Black Hole]] page&lt;br /&gt;
#: Package: (git repo) [https://github.com/pereckerdal/srfi https://github.com/pereckerdal/srfi]&lt;br /&gt;
&lt;br /&gt;
=== Language ===&lt;br /&gt;
# '''Gambit on LLVM''': Experimental partial back-end for Gambit using LLVM&lt;br /&gt;
#: Authors: Arnaud Bergeron and Mathieu Larose&lt;br /&gt;
#: Package: [[media:Gambit-LLVM.tgz|Gambit-LLVM.tgz]]&lt;br /&gt;
# '''Jss''': JavaScriptScheme: a multithreaded Scheme to JavaScript compiler&lt;br /&gt;
#: Author: Marc Feeley and Catherine Gaudron&lt;br /&gt;
#: Package: [[media:Jss-r2.tgz|Jss-r2.tgz]] (old: [[media:Jss-r1.tgz|Jss-r1.tgz]])&lt;br /&gt;
# '''R6RS on Gambit''':Allows R6RS programs to be run on Gambit. &lt;br /&gt;
#: Maintainer: Arthur Smyles&lt;br /&gt;
#: Package: (web page) http://smyles.com/projects/r6gambit/&lt;br /&gt;
# '''PICOBIT''': Very compact Scheme compiler and virtual machine suitable for microcontrollers.&lt;br /&gt;
#: Author: Marc Feeley and Vincent St-Amour&lt;br /&gt;
#: Package: (web page) http://repo.or.cz/w/picobit.git&lt;br /&gt;
# '''Alexpander''': A syntax-rules expander with support for DSSSL #!optional #!key and #!rest arguments.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:Alexpander-r1.tgz|Alexpander-r1.tgz]]&lt;br /&gt;
&lt;br /&gt;
===Module systems===&lt;br /&gt;
# '''Black Hole''': Module system, stable. Package handling features are in beta phase. Primary page at [[Black Hole]].&lt;br /&gt;
#: Package: (git repo) [https://github.com/pereckerdal/blackhole https://github.com/pereckerdal/blackhole]&lt;br /&gt;
&lt;br /&gt;
===Object Systems===&lt;br /&gt;
# '''Oops''': Object Oriented Programming for Scheme -- Dylan/Clos-like but different&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:oops34.tgz|oops34.tgz]]&lt;br /&gt;
# '''TinyTalk''': Self-like object system with selector [Smalltalk like] dispatch.&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:gambitTT.tgz|gambitTT.tgz]]&lt;br /&gt;
# '''class.scm''': A simple CLOS-like object system written with a balance of performance, usability and runtime heap consumption. Comes bundled with a test suite which shows exemple of how the system can be used. Also can be used easily in a repl with (include &amp;quot;class.scm&amp;quot;). &lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: (web page/git repo) http://github.com/sthilaid/class/tree/master&lt;br /&gt;
# '''Meroon''': CLOS-like object system for Scheme.&lt;br /&gt;
#: Author: Christian Queinnec, now semi-maintained by Brad Lucier.  Licensed under the [http://opensource.franz.com/preamble.html Lisp Lesser General Public Licence].  Differs from CLOS in (among many other things) having single inheritance instead of multiple inheritance and a compile-time, not a run-time, MOP.  Can be compiled to be relatively fast code.  Would benefit from being reorganized in a &amp;quot;layered&amp;quot; style more appropriate for current ideas of Scheme modules.&lt;br /&gt;
#: Website: http://www.math.purdue.edu/~lucier/software/Meroon/&lt;br /&gt;
#: Package: [[media:MeroonV3-2008Mar01.tar.bz2‎|MeroonV3-2008Mar01.tar.bz2]]&lt;br /&gt;
&lt;br /&gt;
=== FFI ===&lt;br /&gt;
# '''ffi-related-modules''': various modules dealing with the FFI, and their dependencies (chjmodules, but someone might turn them to using bare namespaces or so; read the Readme file at the below URL)&lt;br /&gt;
#: Author: Christian Jaeger&lt;br /&gt;
#: Package: (web page/git repo) http://scheme.ch/gambit/preview/ffi-related-modules/&lt;br /&gt;
&lt;br /&gt;
===Parsing===&lt;br /&gt;
# '''SSAX-SXML''': SSAX-SXML library packaged for Gambit-C&lt;br /&gt;
#: Author: Kirill Lisovsky (updated by Dominique Boucher)&lt;br /&gt;
#: Package: (web page) [[media:ssax-sxml-gambit-20080402.tgz|ssax-sxml-gambit-20080402.tgz]]&lt;br /&gt;
# '''Mparser''': A combinatorial parser (added expression parser) (parser language rewrite)&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:Mparser-r3.tgz|Mparser-r3.tgz]] (old: [[media:Mparser-r1.tgz|Mparser-r1.tgz]], [[media:Mparser-r2.tgz|Mparser-r2.tgz]])&lt;br /&gt;
&lt;br /&gt;
===Physics===&lt;br /&gt;
#'''Ising''': Computer simulations of the Ising model of spins using the Metropolis algorithm or the Wolff algorithm.&lt;br /&gt;
#: Author: Marijn Schouten&lt;br /&gt;
#: Package: [[media:ising-20090315.scm]]&lt;br /&gt;
&lt;br /&gt;
===Math===&lt;br /&gt;
# '''Pi''': Compute pi to arbitrary precision.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [[media:Pi-r3.tgz|Pi-r3.tgz]] (old: [[media:Pi-r2.tgz|Pi-r2.tgz]]) (old: [[media:Pi-r1.tgz|Pi-r1.tgz]])&lt;br /&gt;
# '''BLAS''': Thin wrapper for level 1, 2 and 3 BLAS linear algebra routines for the Gambit Scheme system.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/blas&lt;br /&gt;
# '''LAPACK''': Thin wrapper for higher-level linear algebra routines for the Gambit Scheme system.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/lapack&lt;br /&gt;
# '''FFTW3''': A wrapper for some FFTW3 functions for the Gambit Scheme system. (real, complex, multi-dimensional FFT functions)&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/fftw3&lt;br /&gt;
#: '''Random numbers''': High-quality random number generation. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=random http://snow.iro.umontreal.ca/?viewpkg=random]&lt;br /&gt;
&lt;br /&gt;
===Encryption===&lt;br /&gt;
# '''AES''' Message encryption and decryption based on the AES symmetric cipher. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=aes http://snow.iro.umontreal.ca/?viewpkg=aes]&lt;br /&gt;
# '''Cert''' Management of digital certificates, message signing and verification. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=cert http://snow.iro.umontreal.ca/?viewpkg=cert]&lt;br /&gt;
# '''RSA''' Message encryption and decryption based on the RSA asymmetric cipher. Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=rsa http://snow.iro.umontreal.ca/?viewpkg=rsa]&lt;br /&gt;
&lt;br /&gt;
===Networking===&lt;br /&gt;
# '''Sack''': Web server and HTTP client. BH module. [https://github.com/pereckerdal/sack https://github.com/pereckerdal/sack]&lt;br /&gt;
&lt;br /&gt;
===SQL===&lt;br /&gt;
# '''MySQL FFI''': FFI for mysql.  Unsure about thread-safety, and needs more work&lt;br /&gt;
#: Author: Jonathan Arkell&lt;br /&gt;
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/mysql/&lt;br /&gt;
# '''MySQL''': Socket level client for mysql. Supports dynamic SQL and now prepared statements. Also includes a SQL abstraction layer. This [http://andrewwhaley.blogspot.com/2009/04/gambit-mysql-client-02.html blog post] has more information.&lt;br /&gt;
#: Author: Andrew Whaley&lt;br /&gt;
#: Package: [[media:Gambit-mysql.zip|Gambit-mysql.zip]]&lt;br /&gt;
# '''SQLite3''': a minimalistic interface to SQLite3.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:SQLite3-r1.tgz|SQLite3-r1.tgz]]&lt;br /&gt;
# '''Postgresql''': A socket level client for Postgresql&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:Postgresql-r1.tgz|Postgresql-r1.tgz]]&lt;br /&gt;
&lt;br /&gt;
===Graphics===&lt;br /&gt;
# '''Octave''': A simple plotting interface using octave (2.x) and gnuplot.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/octave/&lt;br /&gt;
# '''Schemeray''': A simple (and as of yet, unoptimized) raytracer&lt;br /&gt;
#: Author: James Long&lt;br /&gt;
#: Package: [[media:schemeray-0.2.tgz|schemeray-0.2.tgz]]&lt;br /&gt;
# '''Opengl FFI''': A simple opengl, glu and glut ffi which supports opengl up to version 1.1.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Opengl-ffi-r1.tgz|Opengl-ffi-r1.tgz]]&lt;br /&gt;
# '''Perlin Noise''': A simple opengl demonstration of a sub-optimal 2d Perlin noise implementation.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Perlin-noise-2d-r1.tgz|Perlin-noise-2d-r1.tgz]]&lt;br /&gt;
# '''Cairo''': Bindings for cairo graphics.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:Cairo-r3.tgz|Cairo-r3.tgz]] (old: [[media:Cairo-r2.tgz|Cairo-r2.tgz]])&lt;br /&gt;
# '''GLEW''': A wrapper for GLEW which provides all OpenGL functionality through version 2.1 and manages access to vendor extensions&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:Glew.tar.gz|glew.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Audio===&lt;br /&gt;
# '''mpg123''': A wrapper for the libmpg123 mpeg decoding library&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:mpg.tar.gz|mpg.tar.gz]]&lt;br /&gt;
# '''OpenAL''': A wrapper for the OpenAL audio output library&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:openAL.tar.gz|openAL.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Utilities===&lt;br /&gt;
# '''Sort''': Provides a simple sorting procedure for lists and vectors.  The mergesort algorithm is used.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [[media:Sort-r1.tgz|Sort-r1.tgz]]&lt;br /&gt;
# '''Bunny Test''': A simple unit testing framework.  &lt;br /&gt;
#: Author: Jonathan Arkell&lt;br /&gt;
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/test/&lt;br /&gt;
# '''GetOpts''': A syntactic form (let-opts) to parse command line options&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:GetOpts-r1.tgz|GetOpts-r1.tgz]]&lt;br /&gt;
# '''Etags''': Script that generates Emacs TAGS files from Scheme files, and recognizes nested definitions.&lt;br /&gt;
#: Author: Vincent St-Amour&lt;br /&gt;
#: Package: http://www-etud.iro.umontreal.ca/~stamourv/etags.scm&lt;br /&gt;
# '''Win-control''': Library for controlling Internet Explorer and other Windows applications for scripting or automating testing.&lt;br /&gt;
#: Author: Andrew Whaley&lt;br /&gt;
#: Package: http://code.google.com/p/win-control&lt;br /&gt;
# '''repltest''': Small example which embeds a remotely accessible REPL into a standalone C program.&lt;br /&gt;
#: Web: https://mercure.iro.umontreal.ca/pipermail/gambit-list/2010-June/004500.html&lt;br /&gt;
#: Package: [[media:Repltest-20100604.tgz‎|Repltest-20100604.tgz‎]]&lt;br /&gt;
# '''objc-utility-macros''': Utility macros to help wrap Objective-C methods.&lt;br /&gt;
#: Author: Jeffrey T. Read&lt;br /&gt;
#: Package: [[media:objc-utility-macros.scm‎|objc-utility-macros.scm]]&lt;br /&gt;
# '''Sort''': Richard O'Keefe's sorting procedures for lists and vectors.  Four times as fast as other sort.&lt;br /&gt;
#: Author: Richard O'Keefe&lt;br /&gt;
#: Package: [[media:Sort-okeefe.tgz|Sort-okeefe.tgz]]&lt;br /&gt;
# '''Digest''': Computation of message digests (CRC32, MD5, SHA-1, ...). Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=digest http://snow.iro.umontreal.ca/?viewpkg=digest]&lt;br /&gt;
# '''Red-black tree''' implementation, Snow package.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=rbtree http://snow.iro.umontreal.ca/?viewpkg=rbtree]&lt;br /&gt;
&lt;br /&gt;
=== Full Applications ===&lt;br /&gt;
# '''Space-Invaders''': Space Invaders classical arcade game remake in scheme over either glut or SDL.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Space-invaders-src-v1.0.tgz|Space-invaders-src-v1.0.tgz]]&lt;br /&gt;
# '''Web Server''': a web server with sessions cookies and server pages.&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:WebServer-r2.tgz|WebServer-r2.tgz]] (old: [[media:WebServer-r1.tgz|WebServer-r1.tgz]])&lt;br /&gt;
#: Git: http://git.berlios.de/cgi-bin/gitweb.cgi?p=futhark;a=summary&lt;br /&gt;
# '''GUI-Toy''': Simple Direct Media Layer prototype code with examples in the raw and using TinyTalk and Oops object systems.&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:GUI-Toy.tgz|GUI-Toy.tgz]]&lt;br /&gt;
# '''Intelligent WTF''': Intelligent acronym decoder based on ''wtf'' from BSD Games&lt;br /&gt;
#: Author: Joel J. Adamson &lt;br /&gt;
#: Package: (web page) http://www.unc.edu/~adamsonj/software.html&lt;br /&gt;
# '''Genetic Canvas''': A polygon-based image renderer using genetic algorithms.&lt;br /&gt;
#: Author: James Long&lt;br /&gt;
#: Web: http://jlongster.com/blog/2009/05/25/mona-lisa-genetically-drawn-scheme/&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Documents ==&lt;br /&gt;
=== Scheme books ===&lt;br /&gt;
# '''An Introduction to Scheme and its Implementation''': A pretty good book on how to learn Scheme, for people with a background in general programming languages.&lt;br /&gt;
#: Author: Paul R. Wilson&lt;br /&gt;
#: Package: [[media:An_Introduction_to_Scheme_and_its_Implementation.tar.gz|An_Introduction_to_Scheme_and_its_Implementation.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
[[Category: Code]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds</id>
		<title>Dumping Grounds</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds"/>
				<updated>2011-11-26T10:44:23Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Here you will find packages of Gambit code contributed by users.  This page is meant as a simple repository where random code snippets as well as complex systems can easily be stored so that other users can get to them.  This is not a substitute for a repository that is closely coupled with the Gambit system's module system (which is under development).  It is meant to foster the sharing of code by making it extremely easy to publish code in a publicly accessible place.  Sharing a piece of code that is incomplete, undocumented, and unreliable is better than not sharing it, because others can correct the deficiencies, learn from the code, or avoid the bugs.  Hence the name '''Dumping Grounds''' for this page.&lt;br /&gt;
&lt;br /&gt;
The code need not follow a specific structure.  It could simply be a Scheme source file (with a '''.scm''' extension).  However, if you are packaging your code specifically for storing it here, it is best if the name of the package contains a revision number (so that many revisions can be stored) and is a gzip compressed tar file ('''.tgz''' extension) containing the code and documentation (for example file '''Sort-r1.tgz''' containing the files '''Sort-r1/Sort.scm''' and possibly '''Sort-r1/Sort.html''' and other related files).  For some reason the wiki insists on the package name starting with an upper-case letter.  The code is assumed to be in the public domain unless you add licensing information in the package itself or the documentation.&lt;br /&gt;
&lt;br /&gt;
To add a new package you must add an entry for it to this page (copy-paste an existing entry), update the file name in the &amp;lt;nowiki&amp;gt;[[media:Sort-r1.tgz|Sort-r1.tgz]]&amp;lt;/nowiki&amp;gt; link, save the page and click on the link to upload your file.  If you upload a new revision don't forget to change the revision number, and keep the link to the old revisions.&lt;br /&gt;
&lt;br /&gt;
A list of the packages and other files with statistics is available here: [[Special:Imagelist]]&lt;br /&gt;
&lt;br /&gt;
In case you find that a link to an external repository linked to from this page doesn't work anymore, please try to retrieve the latest version of the repo and upload it here, by a) contacting the author directly, b) enquiring for it on the mailing list, and/or c) trying to get it from archive.org.&lt;br /&gt;
&lt;br /&gt;
==Packages==&lt;br /&gt;
===SRFI===&lt;br /&gt;
#'''SRFI-pack''': Many SRFIs ported to Gambit&lt;br /&gt;
#: Author: Guillaume Germain&lt;br /&gt;
#: Package: [[media:Srfi-pack-0.1.tar.gz|Srfi-pack-0.1.tar.gz]]&lt;br /&gt;
#: README: [[media:Srfi-pack-0.1-README.txt|Srfi-pack-0.1-README.txt]]&lt;br /&gt;
#'''SRFI-1''': SRFI-1 ported to Gambit&lt;br /&gt;
#: Author: Olin Shivers; ported by Bradley Lucier&lt;br /&gt;
#: Package [[media:Srfi1.scm|Srfi1.scm]]&lt;br /&gt;
#: Note: I did not extend map to allow list arguments of different lengths&lt;br /&gt;
# '''SRFIs Black Hole package''', see info at [[Black Hole]] page&lt;br /&gt;
#: Package: (git repo) [https://github.com/pereckerdal/srfi https://github.com/pereckerdal/srfi]&lt;br /&gt;
&lt;br /&gt;
=== Language ===&lt;br /&gt;
# '''Gambit on LLVM''': Experimental partial back-end for Gambit using LLVM&lt;br /&gt;
#: Authors: Arnaud Bergeron and Mathieu Larose&lt;br /&gt;
#: Package: [[media:Gambit-LLVM.tgz|Gambit-LLVM.tgz]]&lt;br /&gt;
# '''Jss''': JavaScriptScheme: a multithreaded Scheme to JavaScript compiler&lt;br /&gt;
#: Author: Marc Feeley and Catherine Gaudron&lt;br /&gt;
#: Package: [[media:Jss-r2.tgz|Jss-r2.tgz]] (old: [[media:Jss-r1.tgz|Jss-r1.tgz]])&lt;br /&gt;
# '''R6RS on Gambit''':Allows R6RS programs to be run on Gambit. &lt;br /&gt;
#: Maintainer: Arthur Smyles&lt;br /&gt;
#: Package: (web page) http://smyles.com/projects/r6gambit/&lt;br /&gt;
# '''PICOBIT''': Very compact Scheme compiler and virtual machine suitable for microcontrollers.&lt;br /&gt;
#: Author: Marc Feeley and Vincent St-Amour&lt;br /&gt;
#: Package: (web page) http://repo.or.cz/w/picobit.git&lt;br /&gt;
# '''Alexpander''': A syntax-rules expander with support for DSSSL #!optional #!key and #!rest arguments.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:Alexpander-r1.tgz|Alexpander-r1.tgz]]&lt;br /&gt;
&lt;br /&gt;
===Module systems===&lt;br /&gt;
# '''Black Hole''': Module system, stable. Package handling features are in beta phase. Primary page at [[Black Hole]].&lt;br /&gt;
#: Package: (git repo) [https://github.com/pereckerdal/blackhole https://github.com/pereckerdal/blackhole]&lt;br /&gt;
&lt;br /&gt;
===Object Systems===&lt;br /&gt;
# '''Oops''': Object Oriented Programming for Scheme -- Dylan/Clos-like but different&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:oops34.tgz|oops34.tgz]]&lt;br /&gt;
# '''TinyTalk''': Self-like object system with selector [Smalltalk like] dispatch.&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:gambitTT.tgz|gambitTT.tgz]]&lt;br /&gt;
# '''class.scm''': A simple CLOS-like object system written with a balance of performance, usability and runtime heap consumption. Comes bundled with a test suite which shows exemple of how the system can be used. Also can be used easily in a repl with (include &amp;quot;class.scm&amp;quot;). &lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: (web page/git repo) http://github.com/sthilaid/class/tree/master&lt;br /&gt;
# '''Meroon''': CLOS-like object system for Scheme.&lt;br /&gt;
#: Author: Christian Queinnec, now semi-maintained by Brad Lucier.  Licensed under the [http://opensource.franz.com/preamble.html Lisp Lesser General Public Licence].  Differs from CLOS in (among many other things) having single inheritance instead of multiple inheritance and a compile-time, not a run-time, MOP.  Can be compiled to be relatively fast code.  Would benefit from being reorganized in a &amp;quot;layered&amp;quot; style more appropriate for current ideas of Scheme modules.&lt;br /&gt;
#: Website: http://www.math.purdue.edu/~lucier/software/Meroon/&lt;br /&gt;
#: Package: [[media:MeroonV3-2008Mar01.tar.bz2‎|MeroonV3-2008Mar01.tar.bz2]]&lt;br /&gt;
&lt;br /&gt;
===Parsing===&lt;br /&gt;
# '''SSAX-SXML''': SSAX-SXML library packaged for Gambit-C&lt;br /&gt;
#: Author: Kirill Lisovsky (updated by Dominique Boucher)&lt;br /&gt;
#: Package: (web page) [[media:ssax-sxml-gambit-20080402.tgz|ssax-sxml-gambit-20080402.tgz]]&lt;br /&gt;
# '''Mparser''': A combinatorial parser (added expression parser) (parser language rewrite)&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:Mparser-r3.tgz|Mparser-r3.tgz]] (old: [[media:Mparser-r1.tgz|Mparser-r1.tgz]], [[media:Mparser-r2.tgz|Mparser-r2.tgz]])&lt;br /&gt;
&lt;br /&gt;
=== FFI ===&lt;br /&gt;
# '''ffi-related-modules''': various modules dealing with the FFI, and their dependencies (chjmodules, but someone might turn them to using bare namespaces or so; read the Readme file at the below URL)&lt;br /&gt;
#: Author: Christian Jaeger&lt;br /&gt;
#: Package: (web page/git repo) http://scheme.ch/gambit/preview/ffi-related-modules/&lt;br /&gt;
&lt;br /&gt;
===Physics===&lt;br /&gt;
#'''Ising''': Computer simulations of the Ising model of spins using the Metropolis algorithm or the Wolff algorithm.&lt;br /&gt;
#: Author: Marijn Schouten&lt;br /&gt;
#: Package: [[media:ising-20090315.scm]]&lt;br /&gt;
&lt;br /&gt;
===Math===&lt;br /&gt;
# '''Pi''': Compute pi to arbitrary precision.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [[media:Pi-r3.tgz|Pi-r3.tgz]] (old: [[media:Pi-r2.tgz|Pi-r2.tgz]]) (old: [[media:Pi-r1.tgz|Pi-r1.tgz]])&lt;br /&gt;
# '''BLAS''': Thin wrapper for level 1, 2 and 3 BLAS linear algebra routines for the Gambit Scheme system.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/blas&lt;br /&gt;
# '''LAPACK''': Thin wrapper for higher-level linear algebra routines for the Gambit Scheme system.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/lapack&lt;br /&gt;
# '''FFTW3''': A wrapper for some FFTW3 functions for the Gambit Scheme system. (real, complex, multi-dimensional FFT functions)&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/fftw3&lt;br /&gt;
&lt;br /&gt;
===Encryption===&lt;br /&gt;
# '''AES''' Message encryption and decryption based on the AES symmetric cipher. Snow package.&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=aes http://snow.iro.umontreal.ca/?viewpkg=aes]&lt;br /&gt;
# '''Cert''' Management of digital certificates, message signing and verification. Snow package.&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=cert http://snow.iro.umontreal.ca/?viewpkg=cert]&lt;br /&gt;
# '''RSA''' Message encryption and decryption based on the RSA asymmetric cipher. Snow package.&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=rsa http://snow.iro.umontreal.ca/?viewpkg=rsa]&lt;br /&gt;
&lt;br /&gt;
===Networking===&lt;br /&gt;
# '''Sack''': Web server and HTTP client. BH module. [https://github.com/pereckerdal/sack https://github.com/pereckerdal/sack]&lt;br /&gt;
&lt;br /&gt;
===SQL===&lt;br /&gt;
# '''MySQL FFI''': FFI for mysql.  Unsure about thread-safety, and needs more work&lt;br /&gt;
#: Author: Jonathan Arkell&lt;br /&gt;
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/mysql/&lt;br /&gt;
# '''MySQL''': Socket level client for mysql. Supports dynamic SQL and now prepared statements. Also includes a SQL abstraction layer. This [http://andrewwhaley.blogspot.com/2009/04/gambit-mysql-client-02.html blog post] has more information.&lt;br /&gt;
#: Author: Andrew Whaley&lt;br /&gt;
#: Package: [[media:Gambit-mysql.zip|Gambit-mysql.zip]]&lt;br /&gt;
# '''SQLite3''': a minimalistic interface to SQLite3.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:SQLite3-r1.tgz|SQLite3-r1.tgz]]&lt;br /&gt;
# '''Postgresql''': A socket level client for Postgresql&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:Postgresql-r1.tgz|Postgresql-r1.tgz]]&lt;br /&gt;
&lt;br /&gt;
===Graphics===&lt;br /&gt;
# '''Octave''': A simple plotting interface using octave (2.x) and gnuplot.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/octave/&lt;br /&gt;
# '''Schemeray''': A simple (and as of yet, unoptimized) raytracer&lt;br /&gt;
#: Author: James Long&lt;br /&gt;
#: Package: [[media:schemeray-0.2.tgz|schemeray-0.2.tgz]]&lt;br /&gt;
# '''Opengl FFI''': A simple opengl, glu and glut ffi which supports opengl up to version 1.1.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Opengl-ffi-r1.tgz|Opengl-ffi-r1.tgz]]&lt;br /&gt;
# '''Perlin Noise''': A simple opengl demonstration of a sub-optimal 2d Perlin noise implementation.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Perlin-noise-2d-r1.tgz|Perlin-noise-2d-r1.tgz]]&lt;br /&gt;
# '''Cairo''': Bindings for cairo graphics.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:Cairo-r3.tgz|Cairo-r3.tgz]] (old: [[media:Cairo-r2.tgz|Cairo-r2.tgz]])&lt;br /&gt;
# '''GLEW''': A wrapper for GLEW which provides all OpenGL functionality through version 2.1 and manages access to vendor extensions&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:Glew.tar.gz|glew.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Audio===&lt;br /&gt;
# '''mpg123''': A wrapper for the libmpg123 mpeg decoding library&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:mpg.tar.gz|mpg.tar.gz]]&lt;br /&gt;
# '''OpenAL''': A wrapper for the OpenAL audio output library&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:openAL.tar.gz|openAL.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Utilities===&lt;br /&gt;
# '''Sort''': Provides a simple sorting procedure for lists and vectors.  The mergesort algorithm is used.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [[media:Sort-r1.tgz|Sort-r1.tgz]]&lt;br /&gt;
# '''Bunny Test''': A simple unit testing framework.  &lt;br /&gt;
#: Author: Jonathan Arkell&lt;br /&gt;
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/test/&lt;br /&gt;
# '''GetOpts''': A syntactic form (let-opts) to parse command line options&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:GetOpts-r1.tgz|GetOpts-r1.tgz]]&lt;br /&gt;
# '''Etags''': Script that generates Emacs TAGS files from Scheme files, and recognizes nested definitions.&lt;br /&gt;
#: Author: Vincent St-Amour&lt;br /&gt;
#: Package: http://www-etud.iro.umontreal.ca/~stamourv/etags.scm&lt;br /&gt;
# '''Win-control''': Library for controlling Internet Explorer and other Windows applications for scripting or automating testing.&lt;br /&gt;
#: Author: Andrew Whaley&lt;br /&gt;
#: Package: http://code.google.com/p/win-control&lt;br /&gt;
# '''repltest''': Small example which embeds a remotely accessible REPL into a standalone C program.&lt;br /&gt;
#: Web: https://mercure.iro.umontreal.ca/pipermail/gambit-list/2010-June/004500.html&lt;br /&gt;
#: Package: [[media:Repltest-20100604.tgz‎|Repltest-20100604.tgz‎]]&lt;br /&gt;
# '''objc-utility-macros''': Utility macros to help wrap Objective-C methods.&lt;br /&gt;
#: Author: Jeffrey T. Read&lt;br /&gt;
#: Package: [[media:objc-utility-macros.scm‎|objc-utility-macros.scm]]&lt;br /&gt;
# '''Sort''': Richard O'Keefe's sorting procedures for lists and vectors.  Four times as fast as other sort.&lt;br /&gt;
#: Author: Richard O'Keefe&lt;br /&gt;
#: Package: [[media:Sort-okeefe.tgz|Sort-okeefe.tgz]]&lt;br /&gt;
# '''Digest''': MD5, CRC, SHA, Snow package&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=digest http://snow.iro.umontreal.ca/?viewpkg=digest]&lt;br /&gt;
# '''Red-black tree''' implementation, Snow package.&lt;br /&gt;
#: Package: [http://snow.iro.umontreal.ca/?viewpkg=rbtree http://snow.iro.umontreal.ca/?viewpkg=rbtree]&lt;br /&gt;
&lt;br /&gt;
=== Full Applications ===&lt;br /&gt;
# '''Space-Invaders''': Space Invaders classical arcade game remake in scheme over either glut or SDL.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Space-invaders-src-v1.0.tgz|Space-invaders-src-v1.0.tgz]]&lt;br /&gt;
# '''Web Server''': a web server with sessions cookies and server pages.&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:WebServer-r2.tgz|WebServer-r2.tgz]] (old: [[media:WebServer-r1.tgz|WebServer-r1.tgz]])&lt;br /&gt;
#: Git: http://git.berlios.de/cgi-bin/gitweb.cgi?p=futhark;a=summary&lt;br /&gt;
# '''GUI-Toy''': Simple Direct Media Layer prototype code with examples in the raw and using TinyTalk and Oops object systems.&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:GUI-Toy.tgz|GUI-Toy.tgz]]&lt;br /&gt;
# '''Intelligent WTF''': Intelligent acronym decoder based on ''wtf'' from BSD Games&lt;br /&gt;
#: Author: Joel J. Adamson &lt;br /&gt;
#: Package: (web page) http://www.unc.edu/~adamsonj/software.html&lt;br /&gt;
# '''Genetic Canvas''': A polygon-based image renderer using genetic algorithms.&lt;br /&gt;
#: Author: James Long&lt;br /&gt;
#: Web: http://jlongster.com/blog/2009/05/25/mona-lisa-genetically-drawn-scheme/&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Documents ==&lt;br /&gt;
=== Scheme books ===&lt;br /&gt;
# '''An Introduction to Scheme and its Implementation''': A pretty good book on how to learn Scheme, for people with a background in general programming languages.&lt;br /&gt;
#: Author: Paul R. Wilson&lt;br /&gt;
#: Package: [[media:An_Introduction_to_Scheme_and_its_Implementation.tar.gz|An_Introduction_to_Scheme_and_its_Implementation.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
[[Category: Code]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Main_Page</id>
		<title>Main Page</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Main_Page"/>
				<updated>2011-10-22T07:22:23Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: Added preliminary note that libraries and module systems are separate of Gambit and require separate installation.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__ __NOEDITSECTION__&lt;br /&gt;
The Gambit Scheme system is a complete, portable, efficient and reliable implementation&lt;br /&gt;
of the [[Scheme | Scheme programming language]].&lt;br /&gt;
&lt;br /&gt;
This web site is intended for users of the Gambit Scheme system.  It is a place where various&lt;br /&gt;
resources are collected and where users can exchange information related to Gambit.&lt;br /&gt;
&lt;br /&gt;
'''Download latest release (v4.6.2):'''&lt;br /&gt;
[http://www.iro.umontreal.ca/~gambit/download/gambit/v4.6/source/gambc-v4_6_2-devel.tgz Development Sources],&lt;br /&gt;
[http://www.iro.umontreal.ca/~gambit/download/gambit/v4.6/prebuilt/gambc-v4_6_2-macosx-intel32.dmg Mac OS X installer (for Intel 32)],&lt;br /&gt;
[http://itunes.apple.com/us/app/gambit-repl/id434534076?mt=8&amp;amp;ls=1 iPhone/iPod touch/iPad],&lt;br /&gt;
[http://www.iro.umontreal.ca/~gambit/download/gambit/v4.6/prebuilt/gambc-v4_6_2-windows-mingw.exe Windows installer MinGW]&lt;br /&gt;
[http://www.iro.umontreal.ca/~gambit/download/gambit/v4.6/prebuilt/gambc-v4_6_2-windows-visualc.exe VC]&lt;br /&gt;
(for other releases see the [[distributions]]). Libraries and module systems are installed separately.&lt;br /&gt;
&lt;br /&gt;
==What's Gambit?==&lt;br /&gt;
&lt;br /&gt;
Gambit consists of two main programs: '''gsi''', the Gambit Scheme interpreter, and '''gsc''', the Gambit Scheme compiler.&lt;br /&gt;
The interpreter contains the complete execution and debugging environment. The compiler is the interpreter extended with the capability of generating executable files. The compiler can produce standalone executables or compiled modules which can be loaded at run time.  Interpreted code and compiled code can be freely mixed.&lt;br /&gt;
&lt;br /&gt;
Gambit-C is a version of the Gambit programming system in which the&lt;br /&gt;
compiler generates portable C code.  The main features of Gambit-C are:&lt;br /&gt;
&lt;br /&gt;
* '''Conformance.'''  The Gambit-C system conforms to the R4RS, R5RS and IEEE Scheme standards and implements all optional features.  Tail calls and first class continuations conform to the Scheme semantics.  The full numeric tower is implemented, including: arbitrary precision integers (bignums), rationals, inexact reals (floating point numbers), and complex numbers.  Several extensions to Scheme are provided, including: lightweight threads, a foreign-function interface (FFI), and extended I/O capabilities (Unicode, networking, subprocesses, ...).&lt;br /&gt;
* '''Portability.'''  Because the system is mostly written in Scheme and the compiler generates portable C code, it is easy to port the system as well as programs compiled with it to any platform with a decent C or C++ compiler.  There is no reliance on a particular C compiler, although the system can take advantage of some '''gcc'''-specific constructs.  The C code generated is oblivious to the endianness and word size of the target environment (32 and 64 bit architectures are currently supported).&lt;br /&gt;
* '''Performance.'''  The compiler includes several powerful program transformations such as user procedure inlining, partial-evaluation, and lambda-lifting.  With appropriate declarations in the source code the executable programs generated by the compiler run roughly as fast as equivalent C programs.  Programs containing no declarations are also optimized without compromising the Scheme semantics by speculatively inlining predefined procedures (see the [[benchmarks]] page for a comparison with other Scheme implementations and other languages).  Thanks to an efficient implementation of continuations, the thread system is very efficient and can support millions of concurrent threads.  The bignum library uses sophisticated algorithms that are in some cases asymptotically faster than those of GMP (GNU Multiple Precision Arithmetic Library). [Note: With the release of GMP 4.3.0 in April 2009, this claim is no longer true; see the [[benchmarks]] page for some crude comparisons on large integers.]&lt;br /&gt;
* '''Reliability.'''  Stable releases typically have very few bugs.  Bug tracking is done with [http://www.bugzilla.org/ bugzilla].  Gambit-C has been used to develop large-scale [[Real-world software and services | real-world software and services]] in academic and commercial settings.&lt;br /&gt;
&lt;br /&gt;
An overview of the Gambit system was presented by Marc Feeley at the [http://www.international-lisp-conference.org/2010/index 2010 International Lisp Conference].  The slides of the &amp;quot;Gambit Scheme: Inside Out&amp;quot; talk are [http://www.iro.umontreal.ca/~gambit/Gambit-inside-out.pdf here].&lt;br /&gt;
&lt;br /&gt;
==Getting Gambit==&lt;br /&gt;
&lt;br /&gt;
Gambit is available as prebuilt and source code [[distributions]].  There are prebuilt distributions for Mac OS X, iPhone/iPod touch/iPad (on Apple App Store), Microsoft Windows, and other operating systems.  The source code distributions must be compiled with a C or C++ compiler.  The latest sources are available in the [[Source code repository | source code repository]]. It can be accessed using&lt;br /&gt;
the [http://git.or.cz/ git] distributed version control system.&lt;br /&gt;
&lt;br /&gt;
==Documentation==&lt;br /&gt;
&lt;br /&gt;
[[Documentation]] is available.&lt;br /&gt;
&lt;br /&gt;
==Support==&lt;br /&gt;
&lt;br /&gt;
Come chat with us in the #gambit channel on [http://www.mibbit.com Freenode IRC].&lt;br /&gt;
&lt;br /&gt;
==Contributing==&lt;br /&gt;
&lt;br /&gt;
Learn [[how to contribute]] to Gambit's development.&lt;br /&gt;
&lt;br /&gt;
===Reporting bugs===&lt;br /&gt;
&lt;br /&gt;
[http://www.iro.umontreal.ca/~gambit/bugzilla/ Gambit bugzilla]&lt;br /&gt;
&lt;br /&gt;
===Source repository===&lt;br /&gt;
&lt;br /&gt;
[[Source code repository | Gambit Git repo]]&lt;br /&gt;
&lt;br /&gt;
==License==&lt;br /&gt;
&lt;br /&gt;
Gambit is Copyright &amp;amp;copy; 1994-2008 by Marc Feeley.&lt;br /&gt;
It is released under a dual LGPL and Apache 2 license. You&lt;br /&gt;
can choose whichever license you prefer:&lt;br /&gt;
&lt;br /&gt;
* [http://www.gnu.org/copyleft/lesser.html LGPL version 2.1 license]&lt;br /&gt;
* [http://www.apache.org/licenses/LICENSE-2.0.html Apache version 2.0 license]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Main_Page</id>
		<title>Main Page</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Main_Page"/>
				<updated>2011-09-11T21:48:59Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: Added link to Visual C variant of Win version on main pg, as to decr. the mistake of users dl.ing the Mingw variant and trying to make it use MSVC for compilation. (Prev did this well, new not though)&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__ __NOEDITSECTION__&lt;br /&gt;
The Gambit Scheme system is a complete, portable, efficient and reliable implementation&lt;br /&gt;
of the [[Scheme | Scheme programming language]].&lt;br /&gt;
&lt;br /&gt;
This web site is intended for users of the Gambit Scheme system.  It is a place where various&lt;br /&gt;
resources are collected and where users can exchange information related to Gambit.&lt;br /&gt;
&lt;br /&gt;
'''Download latest release (v4.6.1):'''&lt;br /&gt;
[http://www.iro.umontreal.ca/~gambit/download/gambit/v4.6/source/gambc-v4_6_1-devel.tgz Development Sources],&lt;br /&gt;
[http://www.iro.umontreal.ca/~gambit/download/gambit/v4.6/prebuilt/gambc-v4_6_1-macosx-intel32.dmg Mac OS X installer (for Intel 32)],&lt;br /&gt;
[http://itunes.apple.com/us/app/gambit-repl/id434534076?mt=8&amp;amp;ls=1 iPhone/iPod touch/iPad],&lt;br /&gt;
[http://www.iro.umontreal.ca/~gambit/download/gambit/v4.6/prebuilt/gambc-v4_6_1-windows-mingw.exe Windows installer MinGW]&lt;br /&gt;
[http://www.iro.umontreal.ca/~gambit/download/gambit/v4.6/prebuilt/gambc-v4_6_1-windows-visualc.exe VC]&lt;br /&gt;
(for other releases see the [[distributions]]).&lt;br /&gt;
&lt;br /&gt;
==What's Gambit?==&lt;br /&gt;
&lt;br /&gt;
Gambit consists of two main programs: '''gsi''', the Gambit Scheme interpreter, and '''gsc''', the Gambit Scheme compiler.&lt;br /&gt;
The interpreter contains the complete execution and debugging environment. The compiler is the interpreter extended with the capability of generating executable files. The compiler can produce standalone executables or compiled modules which can be loaded at run time.  Interpreted code and compiled code can be freely mixed.&lt;br /&gt;
&lt;br /&gt;
Gambit-C is a version of the Gambit programming system in which the&lt;br /&gt;
compiler generates portable C code.  The main features of Gambit-C are:&lt;br /&gt;
&lt;br /&gt;
* '''Conformance.'''  The Gambit-C system conforms to the R4RS, R5RS and IEEE Scheme standards and implements all optional features.  Tail calls and first class continuations conform to the Scheme semantics.  The full numeric tower is implemented, including: arbitrary precision integers (bignums), rationals, inexact reals (floating point numbers), and complex numbers.  Several extensions to Scheme are provided, including: lightweight threads, a foreign-function interface (FFI), and extended I/O capabilities (Unicode, networking, subprocesses, ...).&lt;br /&gt;
* '''Portability.'''  Because the system is mostly written in Scheme and the compiler generates portable C code, it is easy to port the system as well as programs compiled with it to any platform with a decent C or C++ compiler.  There is no reliance on a particular C compiler, although the system can take advantage of some '''gcc'''-specific constructs.  The C code generated is oblivious to the endianness and word size of the target environment (32 and 64 bit architectures are currently supported).&lt;br /&gt;
* '''Performance.'''  The compiler includes several powerful program transformations such as user procedure inlining, partial-evaluation, and lambda-lifting.  With appropriate declarations in the source code the executable programs generated by the compiler run roughly as fast as equivalent C programs.  Programs containing no declarations are also optimized without compromising the Scheme semantics by speculatively inlining predefined procedures (see the [[benchmarks]] page for a comparison with other Scheme implementations and other languages).  Thanks to an efficient implementation of continuations, the thread system is very efficient and can support millions of concurrent threads.  The bignum library uses sophisticated algorithms that are in some cases asymptotically faster than those of GMP (GNU Multiple Precision Arithmetic Library). [Note: With the release of GMP 4.3.0 in April 2009, this claim is no longer true; see the [[benchmarks]] page for some crude comparisons on large integers.]&lt;br /&gt;
* '''Reliability.'''  Stable releases typically have very few bugs.  Bug tracking is done with [http://www.bugzilla.org/ bugzilla].  Gambit-C has been used to develop large-scale [[Real-world software and services | real-world software and services]] in academic and commercial settings.&lt;br /&gt;
&lt;br /&gt;
An overview of the Gambit system was presented by Marc Feeley at the [http://www.international-lisp-conference.org/2010/index 2010 International Lisp Conference].  The slides of the &amp;quot;Gambit Scheme: Inside Out&amp;quot; talk are [http://www.iro.umontreal.ca/~gambit/Gambit-inside-out.pdf here].&lt;br /&gt;
&lt;br /&gt;
==Getting Gambit==&lt;br /&gt;
&lt;br /&gt;
Gambit is available as prebuilt and source code [[distributions]].  There are prebuilt distributions for Mac OS X, iPhone/iPod touch/iPad (on Apple App Store), Microsoft Windows, and other operating systems.  The source code distributions must be compiled with a C or C++ compiler.  The latest sources are available in the [[Source code repository | source code repository]]. It can be accessed using&lt;br /&gt;
the [http://git.or.cz/ git] distributed version control system.&lt;br /&gt;
&lt;br /&gt;
==Documentation==&lt;br /&gt;
&lt;br /&gt;
[[Documentation]] is available.&lt;br /&gt;
&lt;br /&gt;
==Support==&lt;br /&gt;
&lt;br /&gt;
Come chat with us in the #gambit channel on [http://www.mibbit.com Freenode IRC].&lt;br /&gt;
&lt;br /&gt;
==Contributing==&lt;br /&gt;
&lt;br /&gt;
Learn [[how to contribute]] to Gambit's development.&lt;br /&gt;
&lt;br /&gt;
===Reporting bugs===&lt;br /&gt;
&lt;br /&gt;
[http://www.iro.umontreal.ca/~gambit/bugzilla/ Gambit bugzilla]&lt;br /&gt;
&lt;br /&gt;
===Source repository===&lt;br /&gt;
&lt;br /&gt;
[[Source code repository | Gambit Git repo]]&lt;br /&gt;
&lt;br /&gt;
==License==&lt;br /&gt;
&lt;br /&gt;
Gambit is Copyright &amp;amp;copy; 1994-2008 by Marc Feeley.&lt;br /&gt;
It is released under a dual LGPL and Apache 2 license. You&lt;br /&gt;
can choose whichever license you prefer:&lt;br /&gt;
&lt;br /&gt;
* [http://www.gnu.org/copyleft/lesser.html LGPL version 2.1 license]&lt;br /&gt;
* [http://www.apache.org/licenses/LICENSE-2.0.html Apache version 2.0 license]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds</id>
		<title>Dumping Grounds</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds"/>
				<updated>2011-06-13T14:16:06Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: Added the book An Introduction to Scheme and its Implementation&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Here you will find packages of Gambit code contributed by users.  This page is meant as a simple repository where random code snippets as well as complex systems can easily be stored so that other users can get to them.  This is not a substitute for a repository that is closely coupled with the Gambit system's module system (which is under development).  It is meant to foster the sharing of code by making it extremely easy to publish code in a publicly accessible place.  Sharing a piece of code that is incomplete, undocumented, and unreliable is better than not sharing it, because others can correct the deficiencies, learn from the code, or avoid the bugs.  Hence the name '''Dumping Grounds''' for this page.&lt;br /&gt;
&lt;br /&gt;
The code need not follow a specific structure.  It could simply be a Scheme source file (with a '''.scm''' extension).  However, if you are packaging your code specifically for storing it here, it is best if the name of the package contains a revision number (so that many revisions can be stored) and is a gzip compressed tar file ('''.tgz''' extension) containing the code and documentation (for example file '''Sort-r1.tgz''' containing the files '''Sort-r1/Sort.scm''' and possibly '''Sort-r1/Sort.html''' and other related files).  For some reason the wiki insists on the package name starting with an upper-case letter.  The code is assumed to be in the public domain unless you add licensing information in the package itself or the documentation.&lt;br /&gt;
&lt;br /&gt;
To add a new package you must add an entry for it to this page (copy-paste an existing entry), update the file name in the &amp;lt;nowiki&amp;gt;[[media:Sort-r1.tgz|Sort-r1.tgz]]&amp;lt;/nowiki&amp;gt; link, save the page and click on the link to upload your file.  If you upload a new revision don't forget to change the revision number, and keep the link to the old revisions.&lt;br /&gt;
&lt;br /&gt;
A list of the packages and other files with statistics is available here: [[Special:Imagelist]]&lt;br /&gt;
&lt;br /&gt;
==Packages==&lt;br /&gt;
===SRFI===&lt;br /&gt;
#'''SRFI-pack''': Many SRFIs ported to Gambit&lt;br /&gt;
#: Author: Guillaume Germain&lt;br /&gt;
#: Package: [[media:Srfi-pack-0.1.tar.gz|Srfi-pack-0.1.tar.gz]]&lt;br /&gt;
#: README: [[media:Srfi-pack-0.1-README.txt|Srfi-pack-0.1-README.txt]]&lt;br /&gt;
#'''SRFI-1''': SRFI-1 ported to Gambit&lt;br /&gt;
#: Author: Olin Shivers; ported by Bradley Lucier&lt;br /&gt;
#: Package [[media:Srfi1.scm|Srfi1.scm]]&lt;br /&gt;
#: Note: I did not extend map to allow list arguments of different lengths&lt;br /&gt;
&lt;br /&gt;
===Physics===&lt;br /&gt;
#'''Ising''': Computer simulations of the Ising model of spins using the Metropolis algorithm or the Wolff algorithm.&lt;br /&gt;
#: Author: Marijn Schouten&lt;br /&gt;
#: Package: [[media:ising-20090315.scm]]&lt;br /&gt;
&lt;br /&gt;
===Math===&lt;br /&gt;
# '''Pi''': Compute pi to arbitrary precision.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [[media:Pi-r3.tgz|Pi-r3.tgz]] (old: [[media:Pi-r2.tgz|Pi-r2.tgz]]) (old: [[media:Pi-r1.tgz|Pi-r1.tgz]])&lt;br /&gt;
# '''BLAS''': Thin wrapper for level 1, 2 and 3 BLAS linear algebra routines for the Gambit Scheme system.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/blas&lt;br /&gt;
# '''LAPACK''': Thin wrapper for higher-level linear algebra routines for the Gambit Scheme system.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/lapack&lt;br /&gt;
# '''FFTW3''': A wrapper for some FFTW3 functions for the Gambit Scheme system. (real, complex, multi-dimensional FFT functions)&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/fftw3&lt;br /&gt;
&lt;br /&gt;
===Object Systems===&lt;br /&gt;
# '''Oops''': Object Oriented Programming for Scheme -- Dylan/Clos-like but different&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:oops34.tgz|oops34.tgz]]&lt;br /&gt;
# '''TinyTalk''': Self-like object system with selector [Smalltalk like] dispatch.&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:gambitTT.tgz|gambitTT.tgz]]&lt;br /&gt;
# '''class.scm''': A simple CLOS-like object system written with a balance of performance, usability and runtime heap consumption. Comes bundled with a test suite which shows exemple of how the system can be used. Also can be used easily in a repl with (include &amp;quot;class.scm&amp;quot;). &lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: (web page/git repo) http://github.com/sthilaid/class/tree/master&lt;br /&gt;
# '''Meroon''': CLOS-like object system for Scheme.&lt;br /&gt;
#: Author: Christian Queinnec, now semi-maintained by Brad Lucier.  Licensed under the [http://opensource.franz.com/preamble.html Lisp Lesser General Public Licence].  Differs from CLOS in (among many other things) having single inheritance instead of multiple inheritance and a compile-time, not a run-time, MOP.  Can be compiled to be relatively fast code.  Would benefit from being reorganized in a &amp;quot;layered&amp;quot; style more appropriate for current ideas of Scheme modules.&lt;br /&gt;
#: Website: http://www.math.purdue.edu/~lucier/software/Meroon/&lt;br /&gt;
#: Package: [[media:MeroonV3-2008Mar01.tar.bz2‎|MeroonV3-2008Mar01.tar.bz2]]&lt;br /&gt;
&lt;br /&gt;
===Audio===&lt;br /&gt;
# '''mpg123''': A wrapper for the libmpg123 mpeg decoding library&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:mpg.tar.gz|mpg.tar.gz]]&lt;br /&gt;
# '''OpenAL''': A wrapper for the OpenAL audio output library&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:openAL.tar.gz|openAL.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===Graphics===&lt;br /&gt;
# '''Octave''': A simple plotting interface using octave (2.x) and gnuplot.&lt;br /&gt;
#: Author: Pierre-Alexandre Fournier&lt;br /&gt;
#: Package: (web page) http://carretechnologies.com/scheme/octave/&lt;br /&gt;
# '''Schemeray''': A simple (and as of yet, unoptimized) raytracer&lt;br /&gt;
#: Author: James Long&lt;br /&gt;
#: Package: [[media:schemeray-0.2.tgz|schemeray-0.2.tgz]]&lt;br /&gt;
# '''Opengl FFI''': A simple opengl, glu and glut ffi which supports opengl up to version 1.1.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Opengl-ffi-r1.tgz|Opengl-ffi-r1.tgz]]&lt;br /&gt;
# '''Perlin Noise''': A simple opengl demonstration of a sub-optimal 2d Perlin noise implementation.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Perlin-noise-2d-r1.tgz|Perlin-noise-2d-r1.tgz]]&lt;br /&gt;
# '''Cairo''': Bindings for cairo graphics.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:Cairo-r3.tgz|Cairo-r3.tgz]] (old: [[media:Cairo-r2.tgz|Cairo-r2.tgz]])&lt;br /&gt;
# '''GLEW''': A wrapper for GLEW which provides all OpenGL functionality through version 2.1 and manages access to vendor extensions&lt;br /&gt;
#: Author: Fred LeMaster&lt;br /&gt;
#: Package: [[media:Glew.tar.gz|glew.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
===SQL===&lt;br /&gt;
# '''MySQL FFI''': FFI for mysql.  Unsure about thread-safety, and needs more work&lt;br /&gt;
#: Author: Jonathan Arkell&lt;br /&gt;
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/mysql/&lt;br /&gt;
# '''MySQL''': Socket level client for mysql. Supports dynamic SQL and now prepared statements. Also includes a SQL abstraction layer. This [http://andrewwhaley.blogspot.com/2009/04/gambit-mysql-client-02.html blog post] has more information.&lt;br /&gt;
#: Author: Andrew Whaley&lt;br /&gt;
#: Package: [[media:Gambit-mysql.zip|Gambit-mysql.zip]]&lt;br /&gt;
# '''SQLite3''': a minimalistic interface to SQLite3.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:SQLite3-r1.tgz|SQLite3-r1.tgz]]&lt;br /&gt;
# '''Postgresql''': A socket level client for Postgresql&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:Postgresql-r1.tgz|Postgresql-r1.tgz]]&lt;br /&gt;
&lt;br /&gt;
===Parsing===&lt;br /&gt;
# '''SSAX-SXML''': SSAX-SXML library packaged for Gambit-C&lt;br /&gt;
#: Author: Kirill Lisovsky (updated by Dominique Boucher)&lt;br /&gt;
#: Package: (web page) [[media:ssax-sxml-gambit-20080402.tgz|ssax-sxml-gambit-20080402.tgz]]&lt;br /&gt;
# '''Mparser''': A combinatorial parser (added expression parser) (parser language rewrite)&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:Mparser-r3.tgz|Mparser-r3.tgz]] (old: [[media:Mparser-r1.tgz|Mparser-r1.tgz]], [[media:Mparser-r2.tgz|Mparser-r2.tgz]])&lt;br /&gt;
&lt;br /&gt;
=== Language ===&lt;br /&gt;
# '''Gambit on LLVM''': Experimental partial back-end for Gambit using LLVM&lt;br /&gt;
#: Authors: Arnaud Bergeron and Mathieu Larose&lt;br /&gt;
#: Package: [[media:Gambit-LLVM.tgz|Gambit-LLVM.tgz]]&lt;br /&gt;
# '''Jss''': JavaScriptScheme: a multithreaded Scheme to JavaScript compiler&lt;br /&gt;
#: Author: Marc Feeley and Catherine Gaudron&lt;br /&gt;
#: Package: [[media:Jss-r2.tgz|Jss-r2.tgz]] (old: [[media:Jss-r1.tgz|Jss-r1.tgz]])&lt;br /&gt;
# '''R6RS on Gambit''':Allows R6RS programs to be run on Gambit. &lt;br /&gt;
#: Maintainer: Arthur Smyles&lt;br /&gt;
#: Package: (web page) http://smyles.com/projects/r6gambit/&lt;br /&gt;
# '''PICOBIT''': Very compact Scheme compiler and virtual machine suitable for microcontrollers.&lt;br /&gt;
#: Author: Marc Feeley and Vincent St-Amour&lt;br /&gt;
#: Package: (web page) http://repo.or.cz/w/picobit.git&lt;br /&gt;
# '''Alexpander''': A syntax-rules expander with support for DSSSL #!optional #!key and #!rest arguments.&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:Alexpander-r1.tgz|Alexpander-r1.tgz]]&lt;br /&gt;
&lt;br /&gt;
=== FFI ===&lt;br /&gt;
# '''ffi-related-modules''': various modules dealing with the FFI, and their dependencies (chjmodules, but someone might turn them to using bare namespaces or so; read the Readme file at the below URL)&lt;br /&gt;
#: Author: Christian Jaeger&lt;br /&gt;
#: Package: (web page/git repo) http://scheme.ch/gambit/preview/ffi-related-modules/&lt;br /&gt;
&lt;br /&gt;
===Utilities===&lt;br /&gt;
# '''Sort''': Provides a simple sorting procedure for lists and vectors.  The mergesort algorithm is used.&lt;br /&gt;
#: Author: Marc Feeley&lt;br /&gt;
#: Package: [[media:Sort-r1.tgz|Sort-r1.tgz]]&lt;br /&gt;
# '''Bunny Test''': A simple unit testing framework.  &lt;br /&gt;
#: Author: Jonathan Arkell&lt;br /&gt;
#: Package: (svn repository) http://bunny.jonnay.net/zengarden/trunk/lib/test/&lt;br /&gt;
# '''GetOpts''': A syntactic form (let-opts) to parse command line options&lt;br /&gt;
#: Author: Marco Benelli&lt;br /&gt;
#: Package: [[media:GetOpts-r1.tgz|GetOpts-r1.tgz]]&lt;br /&gt;
# '''Etags''': Script that generates Emacs TAGS files from Scheme files, and recognizes nested definitions.&lt;br /&gt;
#: Author: Vincent St-Amour&lt;br /&gt;
#: Package: http://www-etud.iro.umontreal.ca/~stamourv/etags.scm&lt;br /&gt;
# '''Win-control''': Library for controlling Internet Explorer and other Windows applications for scripting or automating testing.&lt;br /&gt;
#: Author: Andrew Whaley&lt;br /&gt;
#: Package: http://code.google.com/p/win-control&lt;br /&gt;
# '''repltest''': Small example which embeds a remotely accessible REPL into a standalone C program.&lt;br /&gt;
#: Web: https://mercure.iro.umontreal.ca/pipermail/gambit-list/2010-June/004500.html&lt;br /&gt;
#: Package: [[media:Repltest-20100604.tgz‎|Repltest-20100604.tgz‎]]&lt;br /&gt;
# '''objc-utility-macros''': Utility macros to help wrap Objective-C methods.&lt;br /&gt;
#: Author: Jeffrey T. Read&lt;br /&gt;
#: Package: [[media:objc-utility-macros.scm‎|objc-utility-macros.scm]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Full Applications ===&lt;br /&gt;
# '''Space-Invaders''': Space Invaders classical arcade game remake in scheme over either glut or SDL.&lt;br /&gt;
#: Author: David St-Hilaire&lt;br /&gt;
#: Package: [[media:Space-invaders-src-v1.0.tgz|Space-invaders-src-v1.0.tgz]]&lt;br /&gt;
# '''Web Server''': a web server with sessions cookies and server pages.&lt;br /&gt;
#: Author: Francesco Bracchi&lt;br /&gt;
#: Package: [[media:WebServer-r2.tgz|WebServer-r2.tgz]] (old: [[media:WebServer-r1.tgz|WebServer-r1.tgz]])&lt;br /&gt;
#: Git: http://git.berlios.de/cgi-bin/gitweb.cgi?p=futhark;a=summary&lt;br /&gt;
# '''GUI-Toy''': Simple Direct Media Layer prototype code with examples in the raw and using TinyTalk and Oops object systems.&lt;br /&gt;
#: Author: Ken Dickey&lt;br /&gt;
#: Package: [[media:GUI-Toy.tgz|GUI-Toy.tgz]]&lt;br /&gt;
# '''Intelligent WTF''': Intelligent acronym decoder based on ''wtf'' from BSD Games&lt;br /&gt;
#: Author: Joel J. Adamson &lt;br /&gt;
#: Package: (web page) http://www.unc.edu/~adamsonj/software.html&lt;br /&gt;
# '''Genetic Canvas''': A polygon-based image renderer using genetic algorithms.&lt;br /&gt;
#: Author: James Long&lt;br /&gt;
#: Web: http://jlongster.com/blog/2009/05/25/mona-lisa-genetically-drawn-scheme/&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Documents ==&lt;br /&gt;
# '''An Introduction to Scheme and its Implementation''': A pretty good book on how to learn Scheme, for people with a background in general programming languages.&lt;br /&gt;
#: Author: Paul R. Wilson&lt;br /&gt;
#: Package: [[media:An_Introduction_to_Scheme_and_its_Implementation.tar.gz|An_Introduction_to_Scheme_and_its_Implementation.tar.gz]]&lt;br /&gt;
&lt;br /&gt;
[[Category: Code]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/File:An_Introduction_to_Scheme_and_its_Implementation.tar.gz</id>
		<title>File:An Introduction to Scheme and its Implementation.tar.gz</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/File:An_Introduction_to_Scheme_and_its_Implementation.tar.gz"/>
				<updated>2011-06-13T14:07:33Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: A pretty good book on how to learn Scheme, for people with a background in general programming languages.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A pretty good book on how to learn Scheme, for people with a background in general programming languages.&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Documentation</id>
		<title>Documentation</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Documentation"/>
				<updated>2011-06-13T14:03:55Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: Reintroduced the link to the Dumping grounds on the Documentation page&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== User Documentation ==&lt;br /&gt;
&lt;br /&gt;
There is a user manual for Gambit in [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html HTML]&lt;br /&gt;
and [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.pdf PDF] formats.&lt;br /&gt;
&lt;br /&gt;
See the [[Scheme]] page for documentation on Scheme in general.&lt;br /&gt;
&lt;br /&gt;
== Prebuilt Distributions ==&lt;br /&gt;
&lt;br /&gt;
Some prebuilt distributions are [[Distributions | available]].&lt;br /&gt;
&lt;br /&gt;
== Building Gambit from Source ==&lt;br /&gt;
&lt;br /&gt;
To build Gambit from source, one must first run the configure script, which has a number&lt;br /&gt;
of important [[Configure script options | options]].&lt;br /&gt;
&lt;br /&gt;
There are various [[Make targets | make targets]] of which you should be aware.&lt;br /&gt;
&lt;br /&gt;
== Packages, modules, libraries and driving systems ==&lt;br /&gt;
&lt;br /&gt;
See the [[Packages]] page.&lt;br /&gt;
&lt;br /&gt;
=== SRFI support ===&lt;br /&gt;
The Scheme community has accumulated a set of common libraries and conventions called Scheme Requests for Implementation, publicly collected on [http://srfi.schemers.org/ srfi.schemers.org].&lt;br /&gt;
&lt;br /&gt;
Gambit [[SRFI:s | natively implements]] a number of SRFIs.&lt;br /&gt;
[[Black Hole]] includes several popular SRFIs not natively supported,&lt;br /&gt;
while still others may be downloaded from [http://snow.iro.umontreal.ca/?listcat=srfi Snow].&lt;br /&gt;
&lt;br /&gt;
== Editor/IDE Support ==&lt;br /&gt;
&lt;br /&gt;
Gambit provides a powerful development environment through [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#Emacs-interface Emacs]. &lt;br /&gt;
&lt;br /&gt;
For those running MS Windows you can [http://ftp.gnu.org/pub/gnu/emacs/windows/ download Emacs here]. You may want to read the [http://www.gnu.org/software/emacs/windows/ntemacs.html Emacs FAQ for Windows] before customizing Emacs for use with Gambit. In order to use Emacs' inferior scheme mode on Windows, you may need to run gsi/gsc in raw stdin/stdout mode (see section &amp;quot;Emacs interface&amp;quot; in the manual for details).&lt;br /&gt;
&lt;br /&gt;
Editors such as [http://www.eclipse.org/ Eclipse] with the [http://schemeway.sourceforge.net/ SchemeWay] extension, or just about any text editor with Scheme syntax highlighting, such as [http://www.vim.org VIM or GVIM], may prove valuable as well.&lt;br /&gt;
&lt;br /&gt;
== Termite ==&lt;br /&gt;
&lt;br /&gt;
[http://code.google.com/p/termite/ Termite] is an Erlang-like distributed programming system written in Scheme.&lt;br /&gt;
&lt;br /&gt;
Distributed computing hot right now, and Termite has been noticed in blogs and elsewhere.&lt;br /&gt;
&lt;br /&gt;
Termite depends on specific features of Gambit, and at one time or another&lt;br /&gt;
the Termite source code has been distributed with Gambit, so we point to the Termite web site&lt;br /&gt;
from here.&lt;br /&gt;
&lt;br /&gt;
== Tutorials ==&lt;br /&gt;
[[A Tour of Scheme in Gambit]] gives a general introduction to Scheme and Gambit to people with experiences of general programming languages. Available in [[media:A_Tour_of_Scheme_in_Gambit.pdf|PDF]], [[media:A_Tour_of_Scheme_in_Gambit.odf|Open Office]] and [[media:A_Tour_of_Scheme_in_Gambit.doc|Microsoft Word]] formats.&lt;br /&gt;
&lt;br /&gt;
== Internals Documentation ==&lt;br /&gt;
&lt;br /&gt;
People who want to [[How to Contribute | contribute]] to Gambit development will need to learn something about how the Gambit-C&lt;br /&gt;
runtime and compiler are organized.  While we intend that source code documentation be included in the source&lt;br /&gt;
itself (currently there is very little documentation), we intend that descriptions of program design&lt;br /&gt;
or algorithms used in the runtime and compiler could be included on the [[Internal Documentation]] page.&lt;br /&gt;
&lt;br /&gt;
== Working with External Libraries ==&lt;br /&gt;
&lt;br /&gt;
With Gambit's C FFI (Foreign Function Interface), one can easily use standard C and C++ libraries with your code; this wiki has some examples of and practices on using Gambit with external libraries. See [[Using Gambit with External Libraries]].&lt;br /&gt;
&lt;br /&gt;
== Debugging ==&lt;br /&gt;
&lt;br /&gt;
See the [[Debugging]] page.&lt;br /&gt;
&lt;br /&gt;
== More ==&lt;br /&gt;
The [http://mailman.iro.umontreal.ca/pipermail/gambit-list mailing list archive] covers many topics at depth. You can make Google search queries limited to the mailing list by clicking &amp;quot;advanced settings&amp;quot; on www.google.com.&lt;br /&gt;
&lt;br /&gt;
[[Compiling Gambit software for different target environments]]&lt;br /&gt;
&lt;br /&gt;
[[Dumping Grounds]]&lt;br /&gt;
&lt;br /&gt;
[[Wish list]]&lt;br /&gt;
&lt;br /&gt;
[[External links]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Using_Gambit_with_External_Libraries</id>
		<title>Using Gambit with External Libraries</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Using_Gambit_with_External_Libraries"/>
				<updated>2011-03-28T16:10:03Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== The return strategy required by Gambit apps on Scheme-&amp;gt;C-&amp;gt;Scheme calls ==&lt;br /&gt;
How Gambit integrates the Scheme heap with the C stack is described in the section &amp;quot;19.7 Continuations and the C-interface&amp;quot; in the manual, and also in section 3 of the paper [http://www.iro.umontreal.ca/~feeley/papers/FeeleySW00.pdf A Portable Implementation of First-Class Continuations for Unrestricted Interoperaibility with C in a Multithreaded Scheme]. Here is a clarification though, which was detailed 28 march 2011 on the mailing list:&lt;br /&gt;
&lt;br /&gt;
If you have several C stack frames (produced by a Scheme-&amp;gt;C call which made a C-&amp;gt;Scheme call that made a Scheme-&amp;gt;C call in turn) at the same time, you must return them in the same sequence as you'd have needed to do ordinarily in C, i.e. from the last to the first in sequence.&lt;br /&gt;
&lt;br /&gt;
I.e., if you have the Scheme procedures A, C, E and G, and the C procedures b, d and f, and they invoke each other A -&amp;gt; b -&amp;gt; C -&amp;gt; d -&amp;gt; E -&amp;gt; f -&amp;gt; G, then you must ensure that G will return to f, f to E, E to d, d to C, C to b and b to A.&lt;br /&gt;
&lt;br /&gt;
If you return them in another order - i.e. for example G to d etc. - there will be a runtime error, which terminates the application silently.&lt;br /&gt;
&lt;br /&gt;
Note that anytime during a program's execution in the Scheme world, Gambit's thread multitasker may switch the running thread. If several threads do Scheme-&amp;gt;C-&amp;gt;Scheme calls at the same time, then in the ordinary case, thread switching may happen such that the C stack is rewinded invalidly (i.e. in another order than as described above), which at some point (not necessarily on the first invalid return) will cause the abovementioned runtime error. You can fix this by&lt;br /&gt;
* keeping all Scheme-&amp;gt;C-&amp;gt;Scheme calls in your app to one thread in total,&lt;br /&gt;
* by rewriting your code to do what you wanted to achieve through making a C-&amp;gt;Scheme call some other way instead (for instance by using advanced C programming techniques that are beyond the scope of this document),&lt;br /&gt;
* or by going with the &amp;quot;Ensuring singlethreaded behavior&amp;quot; described below.&lt;br /&gt;
&lt;br /&gt;
(Advanced note: Actually Gambit allows you to skip returning procedures, i.e. A -&amp;gt; b -&amp;gt; C -&amp;gt; d -&amp;gt; E, and then E returns directly to b, works. On the call to b, d's C stack frame is rewinded though, and returning to d would cause the abovementioned runtime error. This works because Gambit on the call to b makes a longjump that simply disposes of d's stack frame. This strategy could cause stack memory leaks though.&lt;br /&gt;
If you by any reason explore how use of this side of the FFI can be made use of, please document it here and on the mailing list.)&lt;br /&gt;
&lt;br /&gt;
== Ensuring singlethreaded behaviour ==&lt;br /&gt;
In certain situations, it's vital to ensure a single thread of execution.&lt;br /&gt;
&lt;br /&gt;
One way may be to create one thread to which you send closures containing code to be executed, and which returns the responses through a mailbox mechanism, there's an example implementation in the Gambit manual.&lt;br /&gt;
&lt;br /&gt;
Ways to get Gambit execute completely single-threaded is:&lt;br /&gt;
&lt;br /&gt;
* Use (thread-quantum-set! (current-thread) +inf.0)&lt;br /&gt;
&lt;br /&gt;
* Use (##disable-interrupts) and (##enable-interrupts) in Scheme or ___EXT(___disable_interrupts)() and ___EXT(___enable_interrupts)() from C.&lt;br /&gt;
&lt;br /&gt;
Please note that Gambit's I/O system makes use of the scheduler, and threading routines do this also, so don't do read, write, thread-sleep!, thread-yield! etc. in code you intended to execute single-threaded.&lt;br /&gt;
&lt;br /&gt;
== Export and import C symbols ==&lt;br /&gt;
Gambit's gambit.h provides helper macros for exporting functions and variables. They are  ___EXPORT_FUNC(type,name) and ___EXPORT_DATA(type,name), and are used like ___EXPORT_FUNC(int,five) () { return 5; } . Grep lib/*.c of the Gambit sources for EXP_FUNC and EXP_DATA to see examples.&lt;br /&gt;
&lt;br /&gt;
On Windows, exporting and importing functions and variables from C code may be particularly tricky. Check out the Microsoft-provided __declspec(dllexport) and __declspec(dllimport).&lt;br /&gt;
&lt;br /&gt;
== Using gsc to compile and link a dynamically loadable object file that uses external libraries ==&lt;br /&gt;
&lt;br /&gt;
Here is an example of building a dynamically loadable Gambit object file that uses [http://www.fftw.org FFTW].  This example is on Red Hat Enterprise Linux 4.2 on x86-64.&lt;br /&gt;
&lt;br /&gt;
The program uses the FFTW version 2 API, so we downloaded fftw-2.1.5.tar.gz, untarred it and configured it with&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
./configure --enable-shared --prefix=/export/users/lucier/local/fftw-2.1.5&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
You need the &amp;lt;tt&amp;gt;--enable-shared&amp;lt;/tt&amp;gt; option because shared Gambit modules must be linked to shared external libraries.  I set the &amp;lt;tt&amp;gt;--prefix&amp;lt;/tt&amp;gt; to install the final FFTW libraries and header files in my home directory.&lt;br /&gt;
&lt;br /&gt;
The file &amp;lt;tt&amp;gt;fftbasics.scm&amp;lt;/tt&amp;gt; provides the basic interface between the Scheme code and FFTW; it is as follows:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(c-declare&lt;br /&gt;
&amp;quot;&lt;br /&gt;
#include \&amp;quot;fftw.h\&amp;quot;&lt;br /&gt;
&lt;br /&gt;
fftwnd_plan p;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;)&lt;br /&gt;
&lt;br /&gt;
(define fftw2d_create_plan_backward&lt;br /&gt;
  (c-lambda ()&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;p = fftw2d_create_plan(64,&lt;br /&gt;
                                    64,&lt;br /&gt;
                                    FFTW_BACKWARD,&lt;br /&gt;
                                    FFTW_ESTIMATE | FFTW_IN_PLACE);&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&lt;br /&gt;
(define fftw2d_create_plan_forward&lt;br /&gt;
  (c-lambda ()&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;p = fftw2d_create_plan(64,&lt;br /&gt;
                                    64,&lt;br /&gt;
                                    FFTW_FORWARD,&lt;br /&gt;
                                    FFTW_ESTIMATE | FFTW_IN_PLACE);&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&lt;br /&gt;
;;; Both forward and backward ffts, depends on which way the plan was created.&lt;br /&gt;
&lt;br /&gt;
(define fftwc&lt;br /&gt;
  (c-lambda (scheme-object)&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;&lt;br /&gt;
int j; double *fp = (double *)((___WORD)___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
  fftwnd_one(p,&lt;br /&gt;
             (fftw_complex *)(fp),&lt;br /&gt;
             NULL);&lt;br /&gt;
  for (j = 0; j &amp;lt; 64 * 64 * 2; j++)&lt;br /&gt;
    fp[j] *= .015625;&lt;br /&gt;
&amp;quot;))&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
We need to pass special options to gsc to compile this file, namely&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
gsc -cc-options &amp;quot;-I/export/users/lucier/local/fftw-2.1.5/include&amp;quot; \&lt;br /&gt;
    -ld-options &amp;quot;-L/export/users/lucier/local/fftw-2.1.5/lib/ -Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/ -lfftw&amp;quot; fftbasic.scm&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
The first option (&amp;lt;tt&amp;gt;-I/export/users/lucier/local/fftw-2.1.5/include&amp;lt;/tt&amp;gt;) tells gcc where to find the header file &amp;lt;tt&amp;gt;fftw.h&amp;lt;/tt&amp;gt; at compile time.  The second option (&amp;lt;tt&amp;gt;-L/export/users/lucier/local/fftw-2.1.5/lib/&amp;lt;/tt&amp;gt;) tells the linker where to find the FFTW library (&amp;lt;tt&amp;gt;-lfftw&amp;lt;/tt&amp;gt;) at link time (i.e., when building the file &amp;lt;tt&amp;gt;fftwbasic.o1&amp;lt;/tt&amp;gt; from &amp;lt;tt&amp;gt;fftwbasic.o&amp;lt;/tt&amp;gt;), and the third option (&amp;lt;tt&amp;gt;-Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/&amp;lt;/tt&amp;gt;) tells the dynamic loader &amp;lt;tt&amp;gt;ldd&amp;lt;/tt&amp;gt; where to find the FFTW library when &amp;lt;tt&amp;gt;fftwbasic.o1&amp;lt;/tt&amp;gt; is loaded into gsc.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Aside&amp;lt;/b&amp;gt;: Note that if the headers and libraries are in a standard place known to gcc, and the location of the shared library is already in the path of the dynamic loader, then these options may not be necessary.  In many GNU/Linux systems, for examples, nearly all packages are installed in &amp;lt;tt&amp;gt;/usr/{bin,include,lib}&amp;lt;/tt&amp;gt;, and you may not need to pass these special options to gsc.&lt;br /&gt;
&lt;br /&gt;
Then we can do&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-316% gsc&lt;br /&gt;
Gambit v4.2.8&lt;br /&gt;
&lt;br /&gt;
&amp;gt; (load &amp;quot;fftbasic&amp;quot;)&lt;br /&gt;
&amp;quot;/export/users/lucier/programs/gambc-v4_2_8/test-load-options/fftbasic.o1&amp;quot;&lt;br /&gt;
&amp;gt; fftwc&lt;br /&gt;
#&amp;lt;procedure #2 fftwc&amp;gt;&lt;br /&gt;
&amp;gt;&lt;br /&gt;
*** EOF again to exit&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
We can check that &amp;lt;tt&amp;gt;fftbasic.o1&amp;lt;/tt&amp;gt; links to the right libraries:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-317% ldd fftbasic.o1&lt;br /&gt;
        libfftw.so.2 =&amp;gt; /export/users/lucier/local/fftw-2.1.5/lib/libfftw.so.2 (0x0000002a9565a000)&lt;br /&gt;
        libc.so.6 =&amp;gt; /lib64/tls/libc.so.6 (0x0000002a957aa000)&lt;br /&gt;
        libm.so.6 =&amp;gt; /lib64/tls/libm.so.6 (0x0000002a959df000)&lt;br /&gt;
        /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Finally, recall from the the [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#SEC21 Gambit manual] that anything you can do with gsc on the command line you can do with one of the gsc-specific scheme procedures &amp;lt;tt&amp;gt;compile-file&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;compile-file-to-c&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;link-incremental&amp;lt;/tt&amp;gt;, or &amp;lt;tt&amp;gt;link-flat&amp;lt;/tt&amp;gt;.  Thus, one could build &amp;lt;tt&amp;gt;fftbasic.o1&amp;lt;/tt&amp;gt; by&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-352% gsc&lt;br /&gt;
Gambit v4.2.8&lt;br /&gt;
&lt;br /&gt;
&amp;gt; (compile-file &amp;quot;fftbasic.scm&amp;quot; cc-options: &amp;quot;-I/export/users/lucier/local/fftw-2.1.5/include&amp;quot;&lt;br /&gt;
 ld-options: &amp;quot;-L/export/users/lucier/local/fftw-2.1.5/lib/ -Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/ -lfftw&amp;quot;)&lt;br /&gt;
#t&lt;br /&gt;
&amp;gt; (load &amp;quot;fftbasic&amp;quot;)&lt;br /&gt;
&amp;quot;/export/users/lucier/programs/gambc-v4_2_8/test-load-options/fftbasic.o1&amp;quot;&lt;br /&gt;
&amp;gt; fftwc&lt;br /&gt;
#&amp;lt;procedure #2 fftwc&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Accessing Scheme vectors within a C function ==&lt;br /&gt;
&lt;br /&gt;
Example. Get the pointer to the beginning of a u8vector Scheme object:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(define ffi-with-scheme-vectors&lt;br /&gt;
  (c-lambda (scheme-object int) ; scheme-object : the vector , int : the vector size&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,&amp;amp;___FETCH_U8(___BODY(___arg1),___INT(0)));&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,&amp;amp;___FETCH_U8(___arg1,0));&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,___BODY(___arg1));&lt;br /&gt;
//void *u8vectorptr = ___CAST(___U8*,___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
&lt;br /&gt;
// Of course, you can cast directly to uchar* if you plan to work with that&lt;br /&gt;
unsigned char *u8vectorptr = ___CAST(___U8*,___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
&lt;br /&gt;
/* Then here do your work with *u8vectorptr, you have its size as the ___arg2 argument */&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Look for examples in &amp;quot;gambit.h&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Caveat: the C compiler does not know that the GC might move objects, so the C code must be written to avoid calling the GC either directly or indirectly. Remember that the pointer is only to be kept until the next return to Scheme.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Practices in FFI development ==&lt;br /&gt;
(There are a couple of posts from September 2008 in the mailing list archive on this subject. Someone please cut and paste them over here.)&lt;br /&gt;
   https://mercure.iro.umontreal.ca/pipermail/gambit-list/2008-September/002572.html&lt;br /&gt;
&lt;br /&gt;
[[Category: FFI]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Using_Gambit_with_External_Libraries</id>
		<title>Using Gambit with External Libraries</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Using_Gambit_with_External_Libraries"/>
				<updated>2011-03-28T14:23:03Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== The return strategy required by Gambit apps on Scheme-&amp;gt;C-&amp;gt;Scheme calls ==&lt;br /&gt;
How Gambit integrates the Scheme heap with the C stack is described in the section &amp;quot;19.7 Continuations and the C-interface&amp;quot; in the manual, and also in section 3 of the paper [http://www.iro.umontreal.ca/~feeley/papers/FeeleySW00.pdf A Portable Implementation of First-Class Continuations for Unrestricted Interoperaibility with C in a Multithreaded Scheme]. Here is a clarification though, which was detailed 28 march 2011 on the mailing list:&lt;br /&gt;
&lt;br /&gt;
If you have several C stack frames (produced by a Scheme-&amp;gt;C call which made a C-&amp;gt;Scheme call that made a Scheme-&amp;gt;C call in turn) at the same time, you must return them in the same sequence as you'd have needed to do ordinarily in C, i.e. from the last to the first in sequence.&lt;br /&gt;
&lt;br /&gt;
I.e., if you have the Scheme procedures A, C, E and G, and the C procedures b, d and f, and they invoke each other A -&amp;gt; b -&amp;gt; C -&amp;gt; d -&amp;gt; E -&amp;gt; f -&amp;gt; G, then you must ensure that G will return to f, f to E, E to d, d to C, C to b and b to A.&lt;br /&gt;
&lt;br /&gt;
If you return them in another order - i.e. for example G to d etc. - there will be a runtime error, which terminates the application silently.&lt;br /&gt;
&lt;br /&gt;
Note that anytime during a program's execution in the Scheme world, Gambit's thread multitasker may switch the running thread. If several threads do Scheme-&amp;gt;C-&amp;gt;Scheme calls at the same time, then in the ordinary case, thread switching may happen such that the C stack is rewinded invalidly (i.e. in another order than as described above), which at some point (not necessarily on the first invalid return) will cause the abovementioned runtime error. You can fix this by&lt;br /&gt;
* keeping all Scheme-&amp;gt;C-&amp;gt;Scheme calls in your app to one thread in total,&lt;br /&gt;
* by rewriting your code to do what you wanted to achieve through making a C-&amp;gt;Scheme call some other way instead (for instance by using advanced C programming techniques that are beyond the scope of this document),&lt;br /&gt;
* or by going with the &amp;quot;Ensuring singlethreaded behavior&amp;quot; described below.&lt;br /&gt;
&lt;br /&gt;
== Ensuring singlethreaded behaviour ==&lt;br /&gt;
In certain situations, it's vital to ensure a single thread of execution.&lt;br /&gt;
&lt;br /&gt;
One way may be to create one thread to which you send closures containing code to be executed, and which returns the responses through a mailbox mechanism, there's an example implementation in the Gambit manual.&lt;br /&gt;
&lt;br /&gt;
Ways to get Gambit execute completely single-threaded is:&lt;br /&gt;
&lt;br /&gt;
* Use (thread-quantum-set! (current-thread) +inf.0)&lt;br /&gt;
&lt;br /&gt;
* Use (##disable-interrupts) and (##enable-interrupts) in Scheme or ___EXT(___disable_interrupts)() and ___EXT(___enable_interrupts)() from C.&lt;br /&gt;
&lt;br /&gt;
Please note that Gambit's I/O system makes use of the scheduler, and threading routines do this also, so don't do read, write, thread-sleep!, thread-yield! etc. in code you intended to execute single-threaded.&lt;br /&gt;
&lt;br /&gt;
== Export and import C symbols ==&lt;br /&gt;
Gambit's gambit.h provides helper macros for exporting functions and variables. They are  ___EXPORT_FUNC(type,name) and ___EXPORT_DATA(type,name), and are used like ___EXPORT_FUNC(int,five) () { return 5; } . Grep lib/*.c of the Gambit sources for EXP_FUNC and EXP_DATA to see examples.&lt;br /&gt;
&lt;br /&gt;
On Windows, exporting and importing functions and variables from C code may be particularly tricky. Check out the Microsoft-provided __declspec(dllexport) and __declspec(dllimport).&lt;br /&gt;
&lt;br /&gt;
== Using gsc to compile and link a dynamically loadable object file that uses external libraries ==&lt;br /&gt;
&lt;br /&gt;
Here is an example of building a dynamically loadable Gambit object file that uses [http://www.fftw.org FFTW].  This example is on Red Hat Enterprise Linux 4.2 on x86-64.&lt;br /&gt;
&lt;br /&gt;
The program uses the FFTW version 2 API, so we downloaded fftw-2.1.5.tar.gz, untarred it and configured it with&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
./configure --enable-shared --prefix=/export/users/lucier/local/fftw-2.1.5&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
You need the &amp;lt;tt&amp;gt;--enable-shared&amp;lt;/tt&amp;gt; option because shared Gambit modules must be linked to shared external libraries.  I set the &amp;lt;tt&amp;gt;--prefix&amp;lt;/tt&amp;gt; to install the final FFTW libraries and header files in my home directory.&lt;br /&gt;
&lt;br /&gt;
The file &amp;lt;tt&amp;gt;fftbasics.scm&amp;lt;/tt&amp;gt; provides the basic interface between the Scheme code and FFTW; it is as follows:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(c-declare&lt;br /&gt;
&amp;quot;&lt;br /&gt;
#include \&amp;quot;fftw.h\&amp;quot;&lt;br /&gt;
&lt;br /&gt;
fftwnd_plan p;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;)&lt;br /&gt;
&lt;br /&gt;
(define fftw2d_create_plan_backward&lt;br /&gt;
  (c-lambda ()&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;p = fftw2d_create_plan(64,&lt;br /&gt;
                                    64,&lt;br /&gt;
                                    FFTW_BACKWARD,&lt;br /&gt;
                                    FFTW_ESTIMATE | FFTW_IN_PLACE);&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&lt;br /&gt;
(define fftw2d_create_plan_forward&lt;br /&gt;
  (c-lambda ()&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;p = fftw2d_create_plan(64,&lt;br /&gt;
                                    64,&lt;br /&gt;
                                    FFTW_FORWARD,&lt;br /&gt;
                                    FFTW_ESTIMATE | FFTW_IN_PLACE);&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&lt;br /&gt;
;;; Both forward and backward ffts, depends on which way the plan was created.&lt;br /&gt;
&lt;br /&gt;
(define fftwc&lt;br /&gt;
  (c-lambda (scheme-object)&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;&lt;br /&gt;
int j; double *fp = (double *)((___WORD)___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
  fftwnd_one(p,&lt;br /&gt;
             (fftw_complex *)(fp),&lt;br /&gt;
             NULL);&lt;br /&gt;
  for (j = 0; j &amp;lt; 64 * 64 * 2; j++)&lt;br /&gt;
    fp[j] *= .015625;&lt;br /&gt;
&amp;quot;))&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
We need to pass special options to gsc to compile this file, namely&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
gsc -cc-options &amp;quot;-I/export/users/lucier/local/fftw-2.1.5/include&amp;quot; \&lt;br /&gt;
    -ld-options &amp;quot;-L/export/users/lucier/local/fftw-2.1.5/lib/ -Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/ -lfftw&amp;quot; fftbasic.scm&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
The first option (&amp;lt;tt&amp;gt;-I/export/users/lucier/local/fftw-2.1.5/include&amp;lt;/tt&amp;gt;) tells gcc where to find the header file &amp;lt;tt&amp;gt;fftw.h&amp;lt;/tt&amp;gt; at compile time.  The second option (&amp;lt;tt&amp;gt;-L/export/users/lucier/local/fftw-2.1.5/lib/&amp;lt;/tt&amp;gt;) tells the linker where to find the FFTW library (&amp;lt;tt&amp;gt;-lfftw&amp;lt;/tt&amp;gt;) at link time (i.e., when building the file &amp;lt;tt&amp;gt;fftwbasic.o1&amp;lt;/tt&amp;gt; from &amp;lt;tt&amp;gt;fftwbasic.o&amp;lt;/tt&amp;gt;), and the third option (&amp;lt;tt&amp;gt;-Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/&amp;lt;/tt&amp;gt;) tells the dynamic loader &amp;lt;tt&amp;gt;ldd&amp;lt;/tt&amp;gt; where to find the FFTW library when &amp;lt;tt&amp;gt;fftwbasic.o1&amp;lt;/tt&amp;gt; is loaded into gsc.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Aside&amp;lt;/b&amp;gt;: Note that if the headers and libraries are in a standard place known to gcc, and the location of the shared library is already in the path of the dynamic loader, then these options may not be necessary.  In many GNU/Linux systems, for examples, nearly all packages are installed in &amp;lt;tt&amp;gt;/usr/{bin,include,lib}&amp;lt;/tt&amp;gt;, and you may not need to pass these special options to gsc.&lt;br /&gt;
&lt;br /&gt;
Then we can do&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-316% gsc&lt;br /&gt;
Gambit v4.2.8&lt;br /&gt;
&lt;br /&gt;
&amp;gt; (load &amp;quot;fftbasic&amp;quot;)&lt;br /&gt;
&amp;quot;/export/users/lucier/programs/gambc-v4_2_8/test-load-options/fftbasic.o1&amp;quot;&lt;br /&gt;
&amp;gt; fftwc&lt;br /&gt;
#&amp;lt;procedure #2 fftwc&amp;gt;&lt;br /&gt;
&amp;gt;&lt;br /&gt;
*** EOF again to exit&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
We can check that &amp;lt;tt&amp;gt;fftbasic.o1&amp;lt;/tt&amp;gt; links to the right libraries:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-317% ldd fftbasic.o1&lt;br /&gt;
        libfftw.so.2 =&amp;gt; /export/users/lucier/local/fftw-2.1.5/lib/libfftw.so.2 (0x0000002a9565a000)&lt;br /&gt;
        libc.so.6 =&amp;gt; /lib64/tls/libc.so.6 (0x0000002a957aa000)&lt;br /&gt;
        libm.so.6 =&amp;gt; /lib64/tls/libm.so.6 (0x0000002a959df000)&lt;br /&gt;
        /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Finally, recall from the the [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#SEC21 Gambit manual] that anything you can do with gsc on the command line you can do with one of the gsc-specific scheme procedures &amp;lt;tt&amp;gt;compile-file&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;compile-file-to-c&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;link-incremental&amp;lt;/tt&amp;gt;, or &amp;lt;tt&amp;gt;link-flat&amp;lt;/tt&amp;gt;.  Thus, one could build &amp;lt;tt&amp;gt;fftbasic.o1&amp;lt;/tt&amp;gt; by&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-352% gsc&lt;br /&gt;
Gambit v4.2.8&lt;br /&gt;
&lt;br /&gt;
&amp;gt; (compile-file &amp;quot;fftbasic.scm&amp;quot; cc-options: &amp;quot;-I/export/users/lucier/local/fftw-2.1.5/include&amp;quot;&lt;br /&gt;
 ld-options: &amp;quot;-L/export/users/lucier/local/fftw-2.1.5/lib/ -Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/ -lfftw&amp;quot;)&lt;br /&gt;
#t&lt;br /&gt;
&amp;gt; (load &amp;quot;fftbasic&amp;quot;)&lt;br /&gt;
&amp;quot;/export/users/lucier/programs/gambc-v4_2_8/test-load-options/fftbasic.o1&amp;quot;&lt;br /&gt;
&amp;gt; fftwc&lt;br /&gt;
#&amp;lt;procedure #2 fftwc&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Accessing Scheme vectors within a C function ==&lt;br /&gt;
&lt;br /&gt;
Example. Get the pointer to the beginning of a u8vector Scheme object:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(define ffi-with-scheme-vectors&lt;br /&gt;
  (c-lambda (scheme-object int) ; scheme-object : the vector , int : the vector size&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,&amp;amp;___FETCH_U8(___BODY(___arg1),___INT(0)));&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,&amp;amp;___FETCH_U8(___arg1,0));&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,___BODY(___arg1));&lt;br /&gt;
//void *u8vectorptr = ___CAST(___U8*,___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
&lt;br /&gt;
// Of course, you can cast directly to uchar* if you plan to work with that&lt;br /&gt;
unsigned char *u8vectorptr = ___CAST(___U8*,___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
&lt;br /&gt;
/* Then here do your work with *u8vectorptr, you have its size as the ___arg2 argument */&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Look for examples in &amp;quot;gambit.h&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Caveat: the C compiler does not know that the GC might move objects, so the C code must be written to avoid calling the GC either directly or indirectly. Remember that the pointer is only to be kept until the next return to Scheme.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Practices in FFI development ==&lt;br /&gt;
(There are a couple of posts from September 2008 in the mailing list archive on this subject. Someone please cut and paste them over here.)&lt;br /&gt;
   https://mercure.iro.umontreal.ca/pipermail/gambit-list/2008-September/002572.html&lt;br /&gt;
&lt;br /&gt;
[[Category: FFI]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Using_Gambit_with_External_Libraries</id>
		<title>Using Gambit with External Libraries</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Using_Gambit_with_External_Libraries"/>
				<updated>2011-03-28T14:19:15Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== The return strategy required by Gambit apps on Scheme-&amp;gt;C-&amp;gt;Scheme calls ==&lt;br /&gt;
How Gambit integrates the Scheme heap with the C stack is described in the section &amp;quot;19.7 Continuations and the C-interface&amp;quot; in the manual, and also in the paper [http://www.iro.umontreal.ca/~feeley/papers/FeeleySW00.pdf A Portable Implementation of First-Class Continuations for Unrestricted Interoperaibility with C in a Multithreaded Scheme]. Here is a clarification though, which was detailed 28 march 2011 on the mailing list:&lt;br /&gt;
&lt;br /&gt;
If you have several C stack frames (produced by a Scheme-&amp;gt;C call which made a C-&amp;gt;Scheme call that made a Scheme-&amp;gt;C call in turn) at the same time, you must return them in the same sequence as you'd have needed to do ordinarily in C, i.e. from the last to the first in sequence.&lt;br /&gt;
&lt;br /&gt;
I.e., if you have the Scheme procedures A, C, E and G, and the C procedures b, d and f, and they invoke each other A -&amp;gt; b -&amp;gt; C -&amp;gt; d -&amp;gt; E -&amp;gt; f -&amp;gt; G, then you must ensure that G will return to f, f to E, E to d, d to C, C to b and b to A.&lt;br /&gt;
&lt;br /&gt;
If you return them in another order - i.e. for example G to d etc. - there will be a runtime error, which terminates the application silently.&lt;br /&gt;
&lt;br /&gt;
Note that anytime during a program's execution in the Scheme world, Gambit's thread multitasker may switch the running thread. If several threads do Scheme-&amp;gt;C-&amp;gt;Scheme calls at the same time, then in the ordinary case, thread switching may happen such that the C stack is rewinded invalidly (i.e. in another order than as described above), which at some point (not necessarily on the first invalid return) will cause the abovementioned runtime error. You can fix this by&lt;br /&gt;
* keeping all Scheme-&amp;gt;C-&amp;gt;Scheme calls in your app to one thread in total,&lt;br /&gt;
* by rewriting your code to do what you wanted to achieve through making a C-&amp;gt;Scheme call some other way instead (for instance by using advanced C programming techniques that are beyond the scope of this document),&lt;br /&gt;
* or by going with the &amp;quot;Ensuring singlethreaded behavior&amp;quot; described below.&lt;br /&gt;
&lt;br /&gt;
== Ensuring singlethreaded behaviour ==&lt;br /&gt;
In certain situations, it's vital to ensure a single thread of execution.&lt;br /&gt;
&lt;br /&gt;
One way may be to create one thread to which you send closures containing code to be executed, and which returns the responses through a mailbox mechanism, there's an example implementation in the Gambit manual.&lt;br /&gt;
&lt;br /&gt;
Ways to get Gambit execute completely single-threaded is:&lt;br /&gt;
&lt;br /&gt;
* Use (thread-quantum-set! (current-thread) +inf.0)&lt;br /&gt;
&lt;br /&gt;
* Use (##disable-interrupts) and (##enable-interrupts) in Scheme or ___EXT(___disable_interrupts)() and ___EXT(___enable_interrupts)() from C.&lt;br /&gt;
&lt;br /&gt;
Please note that Gambit's I/O system makes use of the scheduler, and threading routines do this also, so don't do read, write, thread-sleep!, thread-yield! etc. in code you intended to execute single-threaded.&lt;br /&gt;
&lt;br /&gt;
== Export and import C symbols ==&lt;br /&gt;
Gambit's gambit.h provides helper macros for exporting functions and variables. They are  ___EXPORT_FUNC(type,name) and ___EXPORT_DATA(type,name), and are used like ___EXPORT_FUNC(int,five) () { return 5; } . Grep lib/*.c of the Gambit sources for EXP_FUNC and EXP_DATA to see examples.&lt;br /&gt;
&lt;br /&gt;
On Windows, exporting and importing functions and variables from C code may be particularly tricky. Check out the Microsoft-provided __declspec(dllexport) and __declspec(dllimport).&lt;br /&gt;
&lt;br /&gt;
== Using gsc to compile and link a dynamically loadable object file that uses external libraries ==&lt;br /&gt;
&lt;br /&gt;
Here is an example of building a dynamically loadable Gambit object file that uses [http://www.fftw.org FFTW].  This example is on Red Hat Enterprise Linux 4.2 on x86-64.&lt;br /&gt;
&lt;br /&gt;
The program uses the FFTW version 2 API, so we downloaded fftw-2.1.5.tar.gz, untarred it and configured it with&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
./configure --enable-shared --prefix=/export/users/lucier/local/fftw-2.1.5&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
You need the &amp;lt;tt&amp;gt;--enable-shared&amp;lt;/tt&amp;gt; option because shared Gambit modules must be linked to shared external libraries.  I set the &amp;lt;tt&amp;gt;--prefix&amp;lt;/tt&amp;gt; to install the final FFTW libraries and header files in my home directory.&lt;br /&gt;
&lt;br /&gt;
The file &amp;lt;tt&amp;gt;fftbasics.scm&amp;lt;/tt&amp;gt; provides the basic interface between the Scheme code and FFTW; it is as follows:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(c-declare&lt;br /&gt;
&amp;quot;&lt;br /&gt;
#include \&amp;quot;fftw.h\&amp;quot;&lt;br /&gt;
&lt;br /&gt;
fftwnd_plan p;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;)&lt;br /&gt;
&lt;br /&gt;
(define fftw2d_create_plan_backward&lt;br /&gt;
  (c-lambda ()&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;p = fftw2d_create_plan(64,&lt;br /&gt;
                                    64,&lt;br /&gt;
                                    FFTW_BACKWARD,&lt;br /&gt;
                                    FFTW_ESTIMATE | FFTW_IN_PLACE);&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&lt;br /&gt;
(define fftw2d_create_plan_forward&lt;br /&gt;
  (c-lambda ()&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;p = fftw2d_create_plan(64,&lt;br /&gt;
                                    64,&lt;br /&gt;
                                    FFTW_FORWARD,&lt;br /&gt;
                                    FFTW_ESTIMATE | FFTW_IN_PLACE);&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&lt;br /&gt;
;;; Both forward and backward ffts, depends on which way the plan was created.&lt;br /&gt;
&lt;br /&gt;
(define fftwc&lt;br /&gt;
  (c-lambda (scheme-object)&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;&lt;br /&gt;
int j; double *fp = (double *)((___WORD)___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
  fftwnd_one(p,&lt;br /&gt;
             (fftw_complex *)(fp),&lt;br /&gt;
             NULL);&lt;br /&gt;
  for (j = 0; j &amp;lt; 64 * 64 * 2; j++)&lt;br /&gt;
    fp[j] *= .015625;&lt;br /&gt;
&amp;quot;))&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
We need to pass special options to gsc to compile this file, namely&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
gsc -cc-options &amp;quot;-I/export/users/lucier/local/fftw-2.1.5/include&amp;quot; \&lt;br /&gt;
    -ld-options &amp;quot;-L/export/users/lucier/local/fftw-2.1.5/lib/ -Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/ -lfftw&amp;quot; fftbasic.scm&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
The first option (&amp;lt;tt&amp;gt;-I/export/users/lucier/local/fftw-2.1.5/include&amp;lt;/tt&amp;gt;) tells gcc where to find the header file &amp;lt;tt&amp;gt;fftw.h&amp;lt;/tt&amp;gt; at compile time.  The second option (&amp;lt;tt&amp;gt;-L/export/users/lucier/local/fftw-2.1.5/lib/&amp;lt;/tt&amp;gt;) tells the linker where to find the FFTW library (&amp;lt;tt&amp;gt;-lfftw&amp;lt;/tt&amp;gt;) at link time (i.e., when building the file &amp;lt;tt&amp;gt;fftwbasic.o1&amp;lt;/tt&amp;gt; from &amp;lt;tt&amp;gt;fftwbasic.o&amp;lt;/tt&amp;gt;), and the third option (&amp;lt;tt&amp;gt;-Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/&amp;lt;/tt&amp;gt;) tells the dynamic loader &amp;lt;tt&amp;gt;ldd&amp;lt;/tt&amp;gt; where to find the FFTW library when &amp;lt;tt&amp;gt;fftwbasic.o1&amp;lt;/tt&amp;gt; is loaded into gsc.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Aside&amp;lt;/b&amp;gt;: Note that if the headers and libraries are in a standard place known to gcc, and the location of the shared library is already in the path of the dynamic loader, then these options may not be necessary.  In many GNU/Linux systems, for examples, nearly all packages are installed in &amp;lt;tt&amp;gt;/usr/{bin,include,lib}&amp;lt;/tt&amp;gt;, and you may not need to pass these special options to gsc.&lt;br /&gt;
&lt;br /&gt;
Then we can do&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-316% gsc&lt;br /&gt;
Gambit v4.2.8&lt;br /&gt;
&lt;br /&gt;
&amp;gt; (load &amp;quot;fftbasic&amp;quot;)&lt;br /&gt;
&amp;quot;/export/users/lucier/programs/gambc-v4_2_8/test-load-options/fftbasic.o1&amp;quot;&lt;br /&gt;
&amp;gt; fftwc&lt;br /&gt;
#&amp;lt;procedure #2 fftwc&amp;gt;&lt;br /&gt;
&amp;gt;&lt;br /&gt;
*** EOF again to exit&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
We can check that &amp;lt;tt&amp;gt;fftbasic.o1&amp;lt;/tt&amp;gt; links to the right libraries:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-317% ldd fftbasic.o1&lt;br /&gt;
        libfftw.so.2 =&amp;gt; /export/users/lucier/local/fftw-2.1.5/lib/libfftw.so.2 (0x0000002a9565a000)&lt;br /&gt;
        libc.so.6 =&amp;gt; /lib64/tls/libc.so.6 (0x0000002a957aa000)&lt;br /&gt;
        libm.so.6 =&amp;gt; /lib64/tls/libm.so.6 (0x0000002a959df000)&lt;br /&gt;
        /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Finally, recall from the the [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#SEC21 Gambit manual] that anything you can do with gsc on the command line you can do with one of the gsc-specific scheme procedures &amp;lt;tt&amp;gt;compile-file&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;compile-file-to-c&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;link-incremental&amp;lt;/tt&amp;gt;, or &amp;lt;tt&amp;gt;link-flat&amp;lt;/tt&amp;gt;.  Thus, one could build &amp;lt;tt&amp;gt;fftbasic.o1&amp;lt;/tt&amp;gt; by&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-352% gsc&lt;br /&gt;
Gambit v4.2.8&lt;br /&gt;
&lt;br /&gt;
&amp;gt; (compile-file &amp;quot;fftbasic.scm&amp;quot; cc-options: &amp;quot;-I/export/users/lucier/local/fftw-2.1.5/include&amp;quot;&lt;br /&gt;
 ld-options: &amp;quot;-L/export/users/lucier/local/fftw-2.1.5/lib/ -Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/ -lfftw&amp;quot;)&lt;br /&gt;
#t&lt;br /&gt;
&amp;gt; (load &amp;quot;fftbasic&amp;quot;)&lt;br /&gt;
&amp;quot;/export/users/lucier/programs/gambc-v4_2_8/test-load-options/fftbasic.o1&amp;quot;&lt;br /&gt;
&amp;gt; fftwc&lt;br /&gt;
#&amp;lt;procedure #2 fftwc&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Accessing Scheme vectors within a C function ==&lt;br /&gt;
&lt;br /&gt;
Example. Get the pointer to the beginning of a u8vector Scheme object:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(define ffi-with-scheme-vectors&lt;br /&gt;
  (c-lambda (scheme-object int) ; scheme-object : the vector , int : the vector size&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,&amp;amp;___FETCH_U8(___BODY(___arg1),___INT(0)));&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,&amp;amp;___FETCH_U8(___arg1,0));&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,___BODY(___arg1));&lt;br /&gt;
//void *u8vectorptr = ___CAST(___U8*,___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
&lt;br /&gt;
// Of course, you can cast directly to uchar* if you plan to work with that&lt;br /&gt;
unsigned char *u8vectorptr = ___CAST(___U8*,___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
&lt;br /&gt;
/* Then here do your work with *u8vectorptr, you have its size as the ___arg2 argument */&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Look for examples in &amp;quot;gambit.h&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Caveat: the C compiler does not know that the GC might move objects, so the C code must be written to avoid calling the GC either directly or indirectly. Remember that the pointer is only to be kept until the next return to Scheme.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Practices in FFI development ==&lt;br /&gt;
(There are a couple of posts from September 2008 in the mailing list archive on this subject. Someone please cut and paste them over here.)&lt;br /&gt;
   https://mercure.iro.umontreal.ca/pipermail/gambit-list/2008-September/002572.html&lt;br /&gt;
&lt;br /&gt;
[[Category: FFI]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Using_Gambit_with_External_Libraries</id>
		<title>Using Gambit with External Libraries</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Using_Gambit_with_External_Libraries"/>
				<updated>2011-03-28T14:17:32Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== The return strategy required by Gambit apps on Scheme-&amp;gt;C-&amp;gt;Scheme calls ==&lt;br /&gt;
How Gambit integrates the Scheme stack with the C stack is described in the section &amp;quot;19.7 Continuations and the C-interface&amp;quot; in the manual, and also in the paper [http://www.iro.umontreal.ca/~feeley/papers/FeeleySW00.pdf A Portable Implementation of First-Class Continuations for Unrestricted Interoperaibility with C in a Multithreaded Scheme]. Here is a clarification though, which was detailed 28 march 2011 on the mailing list:&lt;br /&gt;
&lt;br /&gt;
If you have several C stack frames (produced by a Scheme-&amp;gt;C call which made a C-&amp;gt;Scheme call that made a Scheme-&amp;gt;C call in turn) at the same time, you must return them in the same sequence as you'd have needed to do ordinarily in C, i.e. from the last to the first in sequence.&lt;br /&gt;
&lt;br /&gt;
I.e., if you have the Scheme procedures A, C, E and G, and the C procedures b, d and f, and they invoke each other A -&amp;gt; b -&amp;gt; C -&amp;gt; d -&amp;gt; E -&amp;gt; f -&amp;gt; G, then you must ensure that G will return to f, f to E, E to d, d to C, C to b and b to A.&lt;br /&gt;
&lt;br /&gt;
If you return them in another order - i.e. for example G to d etc. - there will be a runtime error, which terminates the application silently.&lt;br /&gt;
&lt;br /&gt;
Note that anytime during a program's execution in the Scheme world, Gambit's thread multitasker may switch the running thread. If several threads do Scheme-&amp;gt;C-&amp;gt;Scheme calls at the same time, then in the ordinary case, thread switching may happen such that the C stack is rewinded invalidly (i.e. in another order than as described above), which at some point (not necessarily on the first invalid return) will cause the abovementioned runtime error. You can fix this by&lt;br /&gt;
* keeping all Scheme-&amp;gt;C-&amp;gt;Scheme calls in your app to one thread in total,&lt;br /&gt;
* by rewriting your code to do what you wanted to achieve through making a C-&amp;gt;Scheme call some other way instead (for instance by using advanced C programming techniques that are beyond the scope of this document),&lt;br /&gt;
* or by going with the &amp;quot;Ensuring singlethreaded behavior&amp;quot; described below.&lt;br /&gt;
&lt;br /&gt;
== Ensuring singlethreaded behaviour ==&lt;br /&gt;
In certain situations, it's vital to ensure a single thread of execution.&lt;br /&gt;
&lt;br /&gt;
One way may be to create one thread to which you send closures containing code to be executed, and which returns the responses through a mailbox mechanism, there's an example implementation in the Gambit manual.&lt;br /&gt;
&lt;br /&gt;
Ways to get Gambit execute completely single-threaded is:&lt;br /&gt;
&lt;br /&gt;
* Use (thread-quantum-set! (current-thread) +inf.0)&lt;br /&gt;
&lt;br /&gt;
* Use (##disable-interrupts) and (##enable-interrupts) in Scheme or ___EXT(___disable_interrupts)() and ___EXT(___enable_interrupts)() from C.&lt;br /&gt;
&lt;br /&gt;
Please note that Gambit's I/O system makes use of the scheduler, and threading routines do this also, so don't do read, write, thread-sleep!, thread-yield! etc. in code you intended to execute single-threaded.&lt;br /&gt;
&lt;br /&gt;
== Export and import C symbols ==&lt;br /&gt;
Gambit's gambit.h provides helper macros for exporting functions and variables. They are  ___EXPORT_FUNC(type,name) and ___EXPORT_DATA(type,name), and are used like ___EXPORT_FUNC(int,five) () { return 5; } . Grep lib/*.c of the Gambit sources for EXP_FUNC and EXP_DATA to see examples.&lt;br /&gt;
&lt;br /&gt;
On Windows, exporting and importing functions and variables from C code may be particularly tricky. Check out the Microsoft-provided __declspec(dllexport) and __declspec(dllimport).&lt;br /&gt;
&lt;br /&gt;
== Using gsc to compile and link a dynamically loadable object file that uses external libraries ==&lt;br /&gt;
&lt;br /&gt;
Here is an example of building a dynamically loadable Gambit object file that uses [http://www.fftw.org FFTW].  This example is on Red Hat Enterprise Linux 4.2 on x86-64.&lt;br /&gt;
&lt;br /&gt;
The program uses the FFTW version 2 API, so we downloaded fftw-2.1.5.tar.gz, untarred it and configured it with&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
./configure --enable-shared --prefix=/export/users/lucier/local/fftw-2.1.5&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
You need the &amp;lt;tt&amp;gt;--enable-shared&amp;lt;/tt&amp;gt; option because shared Gambit modules must be linked to shared external libraries.  I set the &amp;lt;tt&amp;gt;--prefix&amp;lt;/tt&amp;gt; to install the final FFTW libraries and header files in my home directory.&lt;br /&gt;
&lt;br /&gt;
The file &amp;lt;tt&amp;gt;fftbasics.scm&amp;lt;/tt&amp;gt; provides the basic interface between the Scheme code and FFTW; it is as follows:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(c-declare&lt;br /&gt;
&amp;quot;&lt;br /&gt;
#include \&amp;quot;fftw.h\&amp;quot;&lt;br /&gt;
&lt;br /&gt;
fftwnd_plan p;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;)&lt;br /&gt;
&lt;br /&gt;
(define fftw2d_create_plan_backward&lt;br /&gt;
  (c-lambda ()&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;p = fftw2d_create_plan(64,&lt;br /&gt;
                                    64,&lt;br /&gt;
                                    FFTW_BACKWARD,&lt;br /&gt;
                                    FFTW_ESTIMATE | FFTW_IN_PLACE);&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&lt;br /&gt;
(define fftw2d_create_plan_forward&lt;br /&gt;
  (c-lambda ()&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;p = fftw2d_create_plan(64,&lt;br /&gt;
                                    64,&lt;br /&gt;
                                    FFTW_FORWARD,&lt;br /&gt;
                                    FFTW_ESTIMATE | FFTW_IN_PLACE);&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&lt;br /&gt;
;;; Both forward and backward ffts, depends on which way the plan was created.&lt;br /&gt;
&lt;br /&gt;
(define fftwc&lt;br /&gt;
  (c-lambda (scheme-object)&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;&lt;br /&gt;
int j; double *fp = (double *)((___WORD)___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
  fftwnd_one(p,&lt;br /&gt;
             (fftw_complex *)(fp),&lt;br /&gt;
             NULL);&lt;br /&gt;
  for (j = 0; j &amp;lt; 64 * 64 * 2; j++)&lt;br /&gt;
    fp[j] *= .015625;&lt;br /&gt;
&amp;quot;))&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
We need to pass special options to gsc to compile this file, namely&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
gsc -cc-options &amp;quot;-I/export/users/lucier/local/fftw-2.1.5/include&amp;quot; \&lt;br /&gt;
    -ld-options &amp;quot;-L/export/users/lucier/local/fftw-2.1.5/lib/ -Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/ -lfftw&amp;quot; fftbasic.scm&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
The first option (&amp;lt;tt&amp;gt;-I/export/users/lucier/local/fftw-2.1.5/include&amp;lt;/tt&amp;gt;) tells gcc where to find the header file &amp;lt;tt&amp;gt;fftw.h&amp;lt;/tt&amp;gt; at compile time.  The second option (&amp;lt;tt&amp;gt;-L/export/users/lucier/local/fftw-2.1.5/lib/&amp;lt;/tt&amp;gt;) tells the linker where to find the FFTW library (&amp;lt;tt&amp;gt;-lfftw&amp;lt;/tt&amp;gt;) at link time (i.e., when building the file &amp;lt;tt&amp;gt;fftwbasic.o1&amp;lt;/tt&amp;gt; from &amp;lt;tt&amp;gt;fftwbasic.o&amp;lt;/tt&amp;gt;), and the third option (&amp;lt;tt&amp;gt;-Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/&amp;lt;/tt&amp;gt;) tells the dynamic loader &amp;lt;tt&amp;gt;ldd&amp;lt;/tt&amp;gt; where to find the FFTW library when &amp;lt;tt&amp;gt;fftwbasic.o1&amp;lt;/tt&amp;gt; is loaded into gsc.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Aside&amp;lt;/b&amp;gt;: Note that if the headers and libraries are in a standard place known to gcc, and the location of the shared library is already in the path of the dynamic loader, then these options may not be necessary.  In many GNU/Linux systems, for examples, nearly all packages are installed in &amp;lt;tt&amp;gt;/usr/{bin,include,lib}&amp;lt;/tt&amp;gt;, and you may not need to pass these special options to gsc.&lt;br /&gt;
&lt;br /&gt;
Then we can do&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-316% gsc&lt;br /&gt;
Gambit v4.2.8&lt;br /&gt;
&lt;br /&gt;
&amp;gt; (load &amp;quot;fftbasic&amp;quot;)&lt;br /&gt;
&amp;quot;/export/users/lucier/programs/gambc-v4_2_8/test-load-options/fftbasic.o1&amp;quot;&lt;br /&gt;
&amp;gt; fftwc&lt;br /&gt;
#&amp;lt;procedure #2 fftwc&amp;gt;&lt;br /&gt;
&amp;gt;&lt;br /&gt;
*** EOF again to exit&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
We can check that &amp;lt;tt&amp;gt;fftbasic.o1&amp;lt;/tt&amp;gt; links to the right libraries:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-317% ldd fftbasic.o1&lt;br /&gt;
        libfftw.so.2 =&amp;gt; /export/users/lucier/local/fftw-2.1.5/lib/libfftw.so.2 (0x0000002a9565a000)&lt;br /&gt;
        libc.so.6 =&amp;gt; /lib64/tls/libc.so.6 (0x0000002a957aa000)&lt;br /&gt;
        libm.so.6 =&amp;gt; /lib64/tls/libm.so.6 (0x0000002a959df000)&lt;br /&gt;
        /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Finally, recall from the the [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#SEC21 Gambit manual] that anything you can do with gsc on the command line you can do with one of the gsc-specific scheme procedures &amp;lt;tt&amp;gt;compile-file&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;compile-file-to-c&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;link-incremental&amp;lt;/tt&amp;gt;, or &amp;lt;tt&amp;gt;link-flat&amp;lt;/tt&amp;gt;.  Thus, one could build &amp;lt;tt&amp;gt;fftbasic.o1&amp;lt;/tt&amp;gt; by&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-352% gsc&lt;br /&gt;
Gambit v4.2.8&lt;br /&gt;
&lt;br /&gt;
&amp;gt; (compile-file &amp;quot;fftbasic.scm&amp;quot; cc-options: &amp;quot;-I/export/users/lucier/local/fftw-2.1.5/include&amp;quot;&lt;br /&gt;
 ld-options: &amp;quot;-L/export/users/lucier/local/fftw-2.1.5/lib/ -Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/ -lfftw&amp;quot;)&lt;br /&gt;
#t&lt;br /&gt;
&amp;gt; (load &amp;quot;fftbasic&amp;quot;)&lt;br /&gt;
&amp;quot;/export/users/lucier/programs/gambc-v4_2_8/test-load-options/fftbasic.o1&amp;quot;&lt;br /&gt;
&amp;gt; fftwc&lt;br /&gt;
#&amp;lt;procedure #2 fftwc&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Accessing Scheme vectors within a C function ==&lt;br /&gt;
&lt;br /&gt;
Example. Get the pointer to the beginning of a u8vector Scheme object:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(define ffi-with-scheme-vectors&lt;br /&gt;
  (c-lambda (scheme-object int) ; scheme-object : the vector , int : the vector size&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,&amp;amp;___FETCH_U8(___BODY(___arg1),___INT(0)));&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,&amp;amp;___FETCH_U8(___arg1,0));&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,___BODY(___arg1));&lt;br /&gt;
//void *u8vectorptr = ___CAST(___U8*,___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
&lt;br /&gt;
// Of course, you can cast directly to uchar* if you plan to work with that&lt;br /&gt;
unsigned char *u8vectorptr = ___CAST(___U8*,___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
&lt;br /&gt;
/* Then here do your work with *u8vectorptr, you have its size as the ___arg2 argument */&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Look for examples in &amp;quot;gambit.h&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Caveat: the C compiler does not know that the GC might move objects, so the C code must be written to avoid calling the GC either directly or indirectly. Remember that the pointer is only to be kept until the next return to Scheme.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Practices in FFI development ==&lt;br /&gt;
(There are a couple of posts from September 2008 in the mailing list archive on this subject. Someone please cut and paste them over here.)&lt;br /&gt;
   https://mercure.iro.umontreal.ca/pipermail/gambit-list/2008-September/002572.html&lt;br /&gt;
&lt;br /&gt;
[[Category: FFI]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Using_Gambit_with_External_Libraries</id>
		<title>Using Gambit with External Libraries</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Using_Gambit_with_External_Libraries"/>
				<updated>2011-03-28T14:13:20Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== The return strategy required by Gambit apps on Scheme-&amp;gt;C-&amp;gt;Scheme calls ==&lt;br /&gt;
How Gambit integrates the Scheme stack with the C stack is described in the section &amp;quot;19.7 Continuations and the C-interface&amp;quot; in the manual, and also in the paper [http://www.iro.umontreal.ca/~feeley/papers/FeeleySW00.pdf|A Portable Implementation of First-Class Continuations for Unrestricted Interoperaibility with C in a Multithreaded Scheme]. Here is a clarification though, which was detailed 28 march 2011 on the mailing list:&lt;br /&gt;
&lt;br /&gt;
If you have several C stack frames (produced by a Scheme-&amp;gt;C call which made a C-&amp;gt;Scheme call that made a Scheme-&amp;gt;C call in turn) at the same time, you must return them in the same sequence as you'd have needed to do ordinarily in C, i.e. from the last to the first in sequence.&lt;br /&gt;
&lt;br /&gt;
I.e., if you have the Scheme procedures A, C, E and G, and the C procedures b, d and f, and they invoke each other A -&amp;gt; b -&amp;gt; C -&amp;gt; d -&amp;gt; E -&amp;gt; f -&amp;gt; G, then you must ensure that G will return to f, f to E, E to d, d to C, C to b and b to A.&lt;br /&gt;
&lt;br /&gt;
If you return them in another order - i.e. for example G to d etc. - there will be a runtime error, which terminates the application silently.&lt;br /&gt;
&lt;br /&gt;
Note that anytime during a program's execution in the Scheme world, Gambit's thread multitasker may switch the running thread. If several threads do Scheme-&amp;gt;C-&amp;gt;Scheme calls at the same time, then in the ordinary case, thread switching may happen such that the C stack is rewinded invalidly (i.e. in another order than as described above), which at some point (not necessarily on the first invalid return) will cause the abovementioned runtime error. You can fix this by&lt;br /&gt;
* keeping all Scheme-&amp;gt;C-&amp;gt;Scheme calls in your app to one thread in total,&lt;br /&gt;
* by rewriting your code to do what you wanted to achieve through making a C-&amp;gt;Scheme call some other way instead (for instance by using advanced C programming techniques that are beyond the scope of this document),&lt;br /&gt;
* or by going with the &amp;quot;Ensuring singlethreaded behavior&amp;quot; described below.&lt;br /&gt;
&lt;br /&gt;
== Ensuring singlethreaded behaviour ==&lt;br /&gt;
In certain situations, it's vital to ensure a single thread of execution.&lt;br /&gt;
&lt;br /&gt;
One way may be to create one thread to which you send closures containing code to be executed, and which returns the responses through a mailbox mechanism, there's an example implementation in the Gambit manual.&lt;br /&gt;
&lt;br /&gt;
Ways to get Gambit execute completely single-threaded is:&lt;br /&gt;
&lt;br /&gt;
* Use (thread-quantum-set! (current-thread) +inf.0)&lt;br /&gt;
&lt;br /&gt;
* Use (##disable-interrupts) and (##enable-interrupts) in Scheme or ___EXT(___disable_interrupts)() and ___EXT(___enable_interrupts)() from C.&lt;br /&gt;
&lt;br /&gt;
Please note that Gambit's I/O system makes use of the scheduler, and threading routines do this also, so don't do read, write, thread-sleep!, thread-yield! etc. in code you intended to execute single-threaded.&lt;br /&gt;
&lt;br /&gt;
== Export and import C symbols ==&lt;br /&gt;
Gambit's gambit.h provides helper macros for exporting functions and variables. They are  ___EXPORT_FUNC(type,name) and ___EXPORT_DATA(type,name), and are used like ___EXPORT_FUNC(int,five) () { return 5; } . Grep lib/*.c of the Gambit sources for EXP_FUNC and EXP_DATA to see examples.&lt;br /&gt;
&lt;br /&gt;
On Windows, exporting and importing functions and variables from C code may be particularly tricky. Check out the Microsoft-provided __declspec(dllexport) and __declspec(dllimport).&lt;br /&gt;
&lt;br /&gt;
== Using gsc to compile and link a dynamically loadable object file that uses external libraries ==&lt;br /&gt;
&lt;br /&gt;
Here is an example of building a dynamically loadable Gambit object file that uses [http://www.fftw.org FFTW].  This example is on Red Hat Enterprise Linux 4.2 on x86-64.&lt;br /&gt;
&lt;br /&gt;
The program uses the FFTW version 2 API, so we downloaded fftw-2.1.5.tar.gz, untarred it and configured it with&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
./configure --enable-shared --prefix=/export/users/lucier/local/fftw-2.1.5&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
You need the &amp;lt;tt&amp;gt;--enable-shared&amp;lt;/tt&amp;gt; option because shared Gambit modules must be linked to shared external libraries.  I set the &amp;lt;tt&amp;gt;--prefix&amp;lt;/tt&amp;gt; to install the final FFTW libraries and header files in my home directory.&lt;br /&gt;
&lt;br /&gt;
The file &amp;lt;tt&amp;gt;fftbasics.scm&amp;lt;/tt&amp;gt; provides the basic interface between the Scheme code and FFTW; it is as follows:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(c-declare&lt;br /&gt;
&amp;quot;&lt;br /&gt;
#include \&amp;quot;fftw.h\&amp;quot;&lt;br /&gt;
&lt;br /&gt;
fftwnd_plan p;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;)&lt;br /&gt;
&lt;br /&gt;
(define fftw2d_create_plan_backward&lt;br /&gt;
  (c-lambda ()&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;p = fftw2d_create_plan(64,&lt;br /&gt;
                                    64,&lt;br /&gt;
                                    FFTW_BACKWARD,&lt;br /&gt;
                                    FFTW_ESTIMATE | FFTW_IN_PLACE);&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&lt;br /&gt;
(define fftw2d_create_plan_forward&lt;br /&gt;
  (c-lambda ()&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;p = fftw2d_create_plan(64,&lt;br /&gt;
                                    64,&lt;br /&gt;
                                    FFTW_FORWARD,&lt;br /&gt;
                                    FFTW_ESTIMATE | FFTW_IN_PLACE);&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&lt;br /&gt;
;;; Both forward and backward ffts, depends on which way the plan was created.&lt;br /&gt;
&lt;br /&gt;
(define fftwc&lt;br /&gt;
  (c-lambda (scheme-object)&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;&lt;br /&gt;
int j; double *fp = (double *)((___WORD)___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
  fftwnd_one(p,&lt;br /&gt;
             (fftw_complex *)(fp),&lt;br /&gt;
             NULL);&lt;br /&gt;
  for (j = 0; j &amp;lt; 64 * 64 * 2; j++)&lt;br /&gt;
    fp[j] *= .015625;&lt;br /&gt;
&amp;quot;))&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
We need to pass special options to gsc to compile this file, namely&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
gsc -cc-options &amp;quot;-I/export/users/lucier/local/fftw-2.1.5/include&amp;quot; \&lt;br /&gt;
    -ld-options &amp;quot;-L/export/users/lucier/local/fftw-2.1.5/lib/ -Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/ -lfftw&amp;quot; fftbasic.scm&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
The first option (&amp;lt;tt&amp;gt;-I/export/users/lucier/local/fftw-2.1.5/include&amp;lt;/tt&amp;gt;) tells gcc where to find the header file &amp;lt;tt&amp;gt;fftw.h&amp;lt;/tt&amp;gt; at compile time.  The second option (&amp;lt;tt&amp;gt;-L/export/users/lucier/local/fftw-2.1.5/lib/&amp;lt;/tt&amp;gt;) tells the linker where to find the FFTW library (&amp;lt;tt&amp;gt;-lfftw&amp;lt;/tt&amp;gt;) at link time (i.e., when building the file &amp;lt;tt&amp;gt;fftwbasic.o1&amp;lt;/tt&amp;gt; from &amp;lt;tt&amp;gt;fftwbasic.o&amp;lt;/tt&amp;gt;), and the third option (&amp;lt;tt&amp;gt;-Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/&amp;lt;/tt&amp;gt;) tells the dynamic loader &amp;lt;tt&amp;gt;ldd&amp;lt;/tt&amp;gt; where to find the FFTW library when &amp;lt;tt&amp;gt;fftwbasic.o1&amp;lt;/tt&amp;gt; is loaded into gsc.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Aside&amp;lt;/b&amp;gt;: Note that if the headers and libraries are in a standard place known to gcc, and the location of the shared library is already in the path of the dynamic loader, then these options may not be necessary.  In many GNU/Linux systems, for examples, nearly all packages are installed in &amp;lt;tt&amp;gt;/usr/{bin,include,lib}&amp;lt;/tt&amp;gt;, and you may not need to pass these special options to gsc.&lt;br /&gt;
&lt;br /&gt;
Then we can do&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-316% gsc&lt;br /&gt;
Gambit v4.2.8&lt;br /&gt;
&lt;br /&gt;
&amp;gt; (load &amp;quot;fftbasic&amp;quot;)&lt;br /&gt;
&amp;quot;/export/users/lucier/programs/gambc-v4_2_8/test-load-options/fftbasic.o1&amp;quot;&lt;br /&gt;
&amp;gt; fftwc&lt;br /&gt;
#&amp;lt;procedure #2 fftwc&amp;gt;&lt;br /&gt;
&amp;gt;&lt;br /&gt;
*** EOF again to exit&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
We can check that &amp;lt;tt&amp;gt;fftbasic.o1&amp;lt;/tt&amp;gt; links to the right libraries:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-317% ldd fftbasic.o1&lt;br /&gt;
        libfftw.so.2 =&amp;gt; /export/users/lucier/local/fftw-2.1.5/lib/libfftw.so.2 (0x0000002a9565a000)&lt;br /&gt;
        libc.so.6 =&amp;gt; /lib64/tls/libc.so.6 (0x0000002a957aa000)&lt;br /&gt;
        libm.so.6 =&amp;gt; /lib64/tls/libm.so.6 (0x0000002a959df000)&lt;br /&gt;
        /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Finally, recall from the the [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#SEC21 Gambit manual] that anything you can do with gsc on the command line you can do with one of the gsc-specific scheme procedures &amp;lt;tt&amp;gt;compile-file&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;compile-file-to-c&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;link-incremental&amp;lt;/tt&amp;gt;, or &amp;lt;tt&amp;gt;link-flat&amp;lt;/tt&amp;gt;.  Thus, one could build &amp;lt;tt&amp;gt;fftbasic.o1&amp;lt;/tt&amp;gt; by&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-352% gsc&lt;br /&gt;
Gambit v4.2.8&lt;br /&gt;
&lt;br /&gt;
&amp;gt; (compile-file &amp;quot;fftbasic.scm&amp;quot; cc-options: &amp;quot;-I/export/users/lucier/local/fftw-2.1.5/include&amp;quot;&lt;br /&gt;
 ld-options: &amp;quot;-L/export/users/lucier/local/fftw-2.1.5/lib/ -Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/ -lfftw&amp;quot;)&lt;br /&gt;
#t&lt;br /&gt;
&amp;gt; (load &amp;quot;fftbasic&amp;quot;)&lt;br /&gt;
&amp;quot;/export/users/lucier/programs/gambc-v4_2_8/test-load-options/fftbasic.o1&amp;quot;&lt;br /&gt;
&amp;gt; fftwc&lt;br /&gt;
#&amp;lt;procedure #2 fftwc&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Accessing Scheme vectors within a C function ==&lt;br /&gt;
&lt;br /&gt;
Example. Get the pointer to the beginning of a u8vector Scheme object:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(define ffi-with-scheme-vectors&lt;br /&gt;
  (c-lambda (scheme-object int) ; scheme-object : the vector , int : the vector size&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,&amp;amp;___FETCH_U8(___BODY(___arg1),___INT(0)));&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,&amp;amp;___FETCH_U8(___arg1,0));&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,___BODY(___arg1));&lt;br /&gt;
//void *u8vectorptr = ___CAST(___U8*,___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
&lt;br /&gt;
// Of course, you can cast directly to uchar* if you plan to work with that&lt;br /&gt;
unsigned char *u8vectorptr = ___CAST(___U8*,___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
&lt;br /&gt;
/* Then here do your work with *u8vectorptr, you have its size as the ___arg2 argument */&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Look for examples in &amp;quot;gambit.h&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Caveat: the C compiler does not know that the GC might move objects, so the C code must be written to avoid calling the GC either directly or indirectly. Remember that the pointer is only to be kept until the next return to Scheme.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Practices in FFI development ==&lt;br /&gt;
(There are a couple of posts from September 2008 in the mailing list archive on this subject. Someone please cut and paste them over here.)&lt;br /&gt;
   https://mercure.iro.umontreal.ca/pipermail/gambit-list/2008-September/002572.html&lt;br /&gt;
&lt;br /&gt;
[[Category: FFI]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Using_Gambit_with_External_Libraries</id>
		<title>Using Gambit with External Libraries</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Using_Gambit_with_External_Libraries"/>
				<updated>2011-03-28T14:04:03Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== The return strategy required by Gambit apps on Scheme-&amp;gt;C-&amp;gt;Scheme calls ==&lt;br /&gt;
How Gambit integrates the Scheme stack with the C stack is described in the section &amp;quot;19.7 Continuations and the C-interface&amp;quot; in the manual, and also in the paper [http://www.iro.umontreal.ca/~feeley/papers/FeeleySW00.pdf|A Portable Implementation of First-Class Continuations for Unrestricted Interoperaibility with C in a Multithreaded Scheme]. Here is a clarification though, which was detailed 28 march 2011 on the mailing list:&lt;br /&gt;
&lt;br /&gt;
If you have several C stack frames (produced by a Scheme-&amp;gt;C call which made a C-&amp;gt;Scheme call that made a Scheme-&amp;gt;C call in turn) at the same time, you must return them in the same sequence as you'd have needed to do ordinarily in C, i.e. from the last to the first in sequence.&lt;br /&gt;
&lt;br /&gt;
I.e., if you have the Scheme procedures A, C, E and G, and the C procedures b, d and f, and they invoke each other A -&amp;gt; b -&amp;gt; C -&amp;gt; d -&amp;gt; E -&amp;gt; f -&amp;gt; G, then you must ensure that G will return to f, f to E, E to d, d to C, C to b and b to A.&lt;br /&gt;
&lt;br /&gt;
If you return them in another order - i.e. for example G to d etc. - there will be a runtime error, which terminates the application silently.&lt;br /&gt;
&lt;br /&gt;
Note that anytime during a program's execution in the Scheme world, Gambit's thread multitasker may switch the running thread. If several threads do Scheme-&amp;gt;C-&amp;gt;Scheme calls at the same time, then in the ordinary case, thread switching may happen such that the C stack is rewinded invalidly (i.e. in another order than as described above), which at some point (not necessarily on the first invalid return) will cause the abovementioned runtime error. You can fix this by keeping all Scheme-&amp;gt;C-&amp;gt;Scheme calls in your app to one thread in total, by rewriting your code to do what you wanted to achieve through making a C-&amp;gt;Scheme call some other way instead, or by going with the &amp;quot;Ensuring singlethreaded behavior&amp;quot; described below.&lt;br /&gt;
&lt;br /&gt;
== Ensuring singlethreaded behaviour ==&lt;br /&gt;
In certain situations, it's vital to ensure a single thread of execution.&lt;br /&gt;
&lt;br /&gt;
One way may be to create one thread to which you send closures containing code to be executed, and which returns the responses through a mailbox mechanism, there's an example implementation in the Gambit manual.&lt;br /&gt;
&lt;br /&gt;
Ways to get Gambit execute completely single-threaded is:&lt;br /&gt;
&lt;br /&gt;
* Use (thread-quantum-set! (current-thread) +inf.0)&lt;br /&gt;
&lt;br /&gt;
* Use (##disable-interrupts) and (##enable-interrupts) in Scheme or ___EXT(___disable_interrupts)() and ___EXT(___enable_interrupts)() from C.&lt;br /&gt;
&lt;br /&gt;
Please note that Gambit's I/O system makes use of the scheduler, and threading routines do this also, so don't do read, write, thread-sleep!, thread-yield! etc. in code you intended to execute single-threaded.&lt;br /&gt;
&lt;br /&gt;
== Export and import C symbols ==&lt;br /&gt;
Gambit's gambit.h provides helper macros for exporting functions and variables. They are  ___EXPORT_FUNC(type,name) and ___EXPORT_DATA(type,name), and are used like ___EXPORT_FUNC(int,five) () { return 5; } . Grep lib/*.c of the Gambit sources for EXP_FUNC and EXP_DATA to see examples.&lt;br /&gt;
&lt;br /&gt;
On Windows, exporting and importing functions and variables from C code may be particularly tricky. Check out the Microsoft-provided __declspec(dllexport) and __declspec(dllimport).&lt;br /&gt;
&lt;br /&gt;
== Using gsc to compile and link a dynamically loadable object file that uses external libraries ==&lt;br /&gt;
&lt;br /&gt;
Here is an example of building a dynamically loadable Gambit object file that uses [http://www.fftw.org FFTW].  This example is on Red Hat Enterprise Linux 4.2 on x86-64.&lt;br /&gt;
&lt;br /&gt;
The program uses the FFTW version 2 API, so we downloaded fftw-2.1.5.tar.gz, untarred it and configured it with&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
./configure --enable-shared --prefix=/export/users/lucier/local/fftw-2.1.5&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
You need the &amp;lt;tt&amp;gt;--enable-shared&amp;lt;/tt&amp;gt; option because shared Gambit modules must be linked to shared external libraries.  I set the &amp;lt;tt&amp;gt;--prefix&amp;lt;/tt&amp;gt; to install the final FFTW libraries and header files in my home directory.&lt;br /&gt;
&lt;br /&gt;
The file &amp;lt;tt&amp;gt;fftbasics.scm&amp;lt;/tt&amp;gt; provides the basic interface between the Scheme code and FFTW; it is as follows:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(c-declare&lt;br /&gt;
&amp;quot;&lt;br /&gt;
#include \&amp;quot;fftw.h\&amp;quot;&lt;br /&gt;
&lt;br /&gt;
fftwnd_plan p;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;)&lt;br /&gt;
&lt;br /&gt;
(define fftw2d_create_plan_backward&lt;br /&gt;
  (c-lambda ()&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;p = fftw2d_create_plan(64,&lt;br /&gt;
                                    64,&lt;br /&gt;
                                    FFTW_BACKWARD,&lt;br /&gt;
                                    FFTW_ESTIMATE | FFTW_IN_PLACE);&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&lt;br /&gt;
(define fftw2d_create_plan_forward&lt;br /&gt;
  (c-lambda ()&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;p = fftw2d_create_plan(64,&lt;br /&gt;
                                    64,&lt;br /&gt;
                                    FFTW_FORWARD,&lt;br /&gt;
                                    FFTW_ESTIMATE | FFTW_IN_PLACE);&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&lt;br /&gt;
;;; Both forward and backward ffts, depends on which way the plan was created.&lt;br /&gt;
&lt;br /&gt;
(define fftwc&lt;br /&gt;
  (c-lambda (scheme-object)&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;&lt;br /&gt;
int j; double *fp = (double *)((___WORD)___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
  fftwnd_one(p,&lt;br /&gt;
             (fftw_complex *)(fp),&lt;br /&gt;
             NULL);&lt;br /&gt;
  for (j = 0; j &amp;lt; 64 * 64 * 2; j++)&lt;br /&gt;
    fp[j] *= .015625;&lt;br /&gt;
&amp;quot;))&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
We need to pass special options to gsc to compile this file, namely&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
gsc -cc-options &amp;quot;-I/export/users/lucier/local/fftw-2.1.5/include&amp;quot; \&lt;br /&gt;
    -ld-options &amp;quot;-L/export/users/lucier/local/fftw-2.1.5/lib/ -Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/ -lfftw&amp;quot; fftbasic.scm&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
The first option (&amp;lt;tt&amp;gt;-I/export/users/lucier/local/fftw-2.1.5/include&amp;lt;/tt&amp;gt;) tells gcc where to find the header file &amp;lt;tt&amp;gt;fftw.h&amp;lt;/tt&amp;gt; at compile time.  The second option (&amp;lt;tt&amp;gt;-L/export/users/lucier/local/fftw-2.1.5/lib/&amp;lt;/tt&amp;gt;) tells the linker where to find the FFTW library (&amp;lt;tt&amp;gt;-lfftw&amp;lt;/tt&amp;gt;) at link time (i.e., when building the file &amp;lt;tt&amp;gt;fftwbasic.o1&amp;lt;/tt&amp;gt; from &amp;lt;tt&amp;gt;fftwbasic.o&amp;lt;/tt&amp;gt;), and the third option (&amp;lt;tt&amp;gt;-Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/&amp;lt;/tt&amp;gt;) tells the dynamic loader &amp;lt;tt&amp;gt;ldd&amp;lt;/tt&amp;gt; where to find the FFTW library when &amp;lt;tt&amp;gt;fftwbasic.o1&amp;lt;/tt&amp;gt; is loaded into gsc.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Aside&amp;lt;/b&amp;gt;: Note that if the headers and libraries are in a standard place known to gcc, and the location of the shared library is already in the path of the dynamic loader, then these options may not be necessary.  In many GNU/Linux systems, for examples, nearly all packages are installed in &amp;lt;tt&amp;gt;/usr/{bin,include,lib}&amp;lt;/tt&amp;gt;, and you may not need to pass these special options to gsc.&lt;br /&gt;
&lt;br /&gt;
Then we can do&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-316% gsc&lt;br /&gt;
Gambit v4.2.8&lt;br /&gt;
&lt;br /&gt;
&amp;gt; (load &amp;quot;fftbasic&amp;quot;)&lt;br /&gt;
&amp;quot;/export/users/lucier/programs/gambc-v4_2_8/test-load-options/fftbasic.o1&amp;quot;&lt;br /&gt;
&amp;gt; fftwc&lt;br /&gt;
#&amp;lt;procedure #2 fftwc&amp;gt;&lt;br /&gt;
&amp;gt;&lt;br /&gt;
*** EOF again to exit&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
We can check that &amp;lt;tt&amp;gt;fftbasic.o1&amp;lt;/tt&amp;gt; links to the right libraries:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-317% ldd fftbasic.o1&lt;br /&gt;
        libfftw.so.2 =&amp;gt; /export/users/lucier/local/fftw-2.1.5/lib/libfftw.so.2 (0x0000002a9565a000)&lt;br /&gt;
        libc.so.6 =&amp;gt; /lib64/tls/libc.so.6 (0x0000002a957aa000)&lt;br /&gt;
        libm.so.6 =&amp;gt; /lib64/tls/libm.so.6 (0x0000002a959df000)&lt;br /&gt;
        /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Finally, recall from the the [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#SEC21 Gambit manual] that anything you can do with gsc on the command line you can do with one of the gsc-specific scheme procedures &amp;lt;tt&amp;gt;compile-file&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;compile-file-to-c&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;link-incremental&amp;lt;/tt&amp;gt;, or &amp;lt;tt&amp;gt;link-flat&amp;lt;/tt&amp;gt;.  Thus, one could build &amp;lt;tt&amp;gt;fftbasic.o1&amp;lt;/tt&amp;gt; by&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-352% gsc&lt;br /&gt;
Gambit v4.2.8&lt;br /&gt;
&lt;br /&gt;
&amp;gt; (compile-file &amp;quot;fftbasic.scm&amp;quot; cc-options: &amp;quot;-I/export/users/lucier/local/fftw-2.1.5/include&amp;quot;&lt;br /&gt;
 ld-options: &amp;quot;-L/export/users/lucier/local/fftw-2.1.5/lib/ -Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/ -lfftw&amp;quot;)&lt;br /&gt;
#t&lt;br /&gt;
&amp;gt; (load &amp;quot;fftbasic&amp;quot;)&lt;br /&gt;
&amp;quot;/export/users/lucier/programs/gambc-v4_2_8/test-load-options/fftbasic.o1&amp;quot;&lt;br /&gt;
&amp;gt; fftwc&lt;br /&gt;
#&amp;lt;procedure #2 fftwc&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Accessing Scheme vectors within a C function ==&lt;br /&gt;
&lt;br /&gt;
Example. Get the pointer to the beginning of a u8vector Scheme object:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(define ffi-with-scheme-vectors&lt;br /&gt;
  (c-lambda (scheme-object int) ; scheme-object : the vector , int : the vector size&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,&amp;amp;___FETCH_U8(___BODY(___arg1),___INT(0)));&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,&amp;amp;___FETCH_U8(___arg1,0));&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,___BODY(___arg1));&lt;br /&gt;
//void *u8vectorptr = ___CAST(___U8*,___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
&lt;br /&gt;
// Of course, you can cast directly to uchar* if you plan to work with that&lt;br /&gt;
unsigned char *u8vectorptr = ___CAST(___U8*,___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
&lt;br /&gt;
/* Then here do your work with *u8vectorptr, you have its size as the ___arg2 argument */&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Look for examples in &amp;quot;gambit.h&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Caveat: the C compiler does not know that the GC might move objects, so the C code must be written to avoid calling the GC either directly or indirectly. Remember that the pointer is only to be kept until the next return to Scheme.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Practices in FFI development ==&lt;br /&gt;
(There are a couple of posts from September 2008 in the mailing list archive on this subject. Someone please cut and paste them over here.)&lt;br /&gt;
   https://mercure.iro.umontreal.ca/pipermail/gambit-list/2008-September/002572.html&lt;br /&gt;
&lt;br /&gt;
[[Category: FFI]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Using_Gambit_with_External_Libraries</id>
		<title>Using Gambit with External Libraries</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Using_Gambit_with_External_Libraries"/>
				<updated>2011-03-28T14:01:56Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== The return strategy required by Gambit apps on Scheme-&amp;gt;C-&amp;gt;Scheme calls ==&lt;br /&gt;
How Gambit integrates the Scheme stack with the C stack is described in the section &amp;quot;19.7 Continuations and the C-interface&amp;quot; in the manual, and also in the paper [http://www.iro.umontreal.ca/~feeley/papers/FeeleySW00.pdf|A Portable Implementation of First-Class Continuations for Unrestricted Interoperaibility with C in a Multithreaded Scheme]. Here is a clarification though, which was detailed 28 march 2011 on the mailing list:&lt;br /&gt;
&lt;br /&gt;
If you have several C stack frames (produced by a Scheme-&amp;gt;C call which made a C-&amp;gt;Scheme call that made a Scheme-&amp;gt;C call in turn) at the same time, you must return them in the same sequence as you'd have needed to do ordinarily in C, i.e. from the last to the first in sequence.&lt;br /&gt;
&lt;br /&gt;
I.e., if you have the Scheme procedures A, C, E and G, and the C procedures b, d and f, and they invoke each other A -&amp;gt; b -&amp;gt; C -&amp;gt; d -&amp;gt; E -&amp;gt; f -&amp;gt; G, then you must ensure that G will return to f, f to E, E to d, d to C, C to b and b to A.&lt;br /&gt;
&lt;br /&gt;
If you return them in another order - i.e. for example G to d etc. - there will be a runtime error, which terminates the application silently.&lt;br /&gt;
&lt;br /&gt;
Note that anytime during a program's execution in the Scheme world, Gambit's thread multitasker may switch the running thread. If several threads do Scheme-&amp;gt;C-&amp;gt;Scheme calls at the same time, then in the ordinary case, thread switching may happen such that the C stack is rewinded invalidly (i.e. in another order than as described above), which at some point (not necessarily on the first invalid return) will cause the abovementioned runtime error. You can fix this by keeping all Scheme-&amp;gt;C-&amp;gt;Scheme calls in your app to one thread in total, by rewriting your code to do what you wanted to achieve through making a C-&amp;gt;Scheme some other way instead, or by going with the &amp;quot;Ensuring singlethreaded behavior&amp;quot; described below.&lt;br /&gt;
&lt;br /&gt;
== Ensuring singlethreaded behaviour ==&lt;br /&gt;
In certain situations, it's vital to ensure a single thread of execution.&lt;br /&gt;
&lt;br /&gt;
One way may be to create one thread to which you send closures containing code to be executed, and which returns the responses through a mailbox mechanism, there's an example implementation in the Gambit manual.&lt;br /&gt;
&lt;br /&gt;
Ways to get Gambit execute completely single-threaded is:&lt;br /&gt;
&lt;br /&gt;
* Use (thread-quantum-set! (current-thread) +inf.0)&lt;br /&gt;
&lt;br /&gt;
* Use (##disable-interrupts) and (##enable-interrupts) in Scheme or ___EXT(___disable_interrupts)() and ___EXT(___enable_interrupts)() from C.&lt;br /&gt;
&lt;br /&gt;
Please note that Gambit's I/O system makes use of the scheduler, and threading routines do this also, so don't do read, write, thread-sleep!, thread-yield! etc. in code you intended to execute single-threaded.&lt;br /&gt;
&lt;br /&gt;
== Export and import C symbols ==&lt;br /&gt;
Gambit's gambit.h provides helper macros for exporting functions and variables. They are  ___EXPORT_FUNC(type,name) and ___EXPORT_DATA(type,name), and are used like ___EXPORT_FUNC(int,five) () { return 5; } . Grep lib/*.c of the Gambit sources for EXP_FUNC and EXP_DATA to see examples.&lt;br /&gt;
&lt;br /&gt;
On Windows, exporting and importing functions and variables from C code may be particularly tricky. Check out the Microsoft-provided __declspec(dllexport) and __declspec(dllimport).&lt;br /&gt;
&lt;br /&gt;
== Using gsc to compile and link a dynamically loadable object file that uses external libraries ==&lt;br /&gt;
&lt;br /&gt;
Here is an example of building a dynamically loadable Gambit object file that uses [http://www.fftw.org FFTW].  This example is on Red Hat Enterprise Linux 4.2 on x86-64.&lt;br /&gt;
&lt;br /&gt;
The program uses the FFTW version 2 API, so we downloaded fftw-2.1.5.tar.gz, untarred it and configured it with&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
./configure --enable-shared --prefix=/export/users/lucier/local/fftw-2.1.5&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
You need the &amp;lt;tt&amp;gt;--enable-shared&amp;lt;/tt&amp;gt; option because shared Gambit modules must be linked to shared external libraries.  I set the &amp;lt;tt&amp;gt;--prefix&amp;lt;/tt&amp;gt; to install the final FFTW libraries and header files in my home directory.&lt;br /&gt;
&lt;br /&gt;
The file &amp;lt;tt&amp;gt;fftbasics.scm&amp;lt;/tt&amp;gt; provides the basic interface between the Scheme code and FFTW; it is as follows:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(c-declare&lt;br /&gt;
&amp;quot;&lt;br /&gt;
#include \&amp;quot;fftw.h\&amp;quot;&lt;br /&gt;
&lt;br /&gt;
fftwnd_plan p;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;)&lt;br /&gt;
&lt;br /&gt;
(define fftw2d_create_plan_backward&lt;br /&gt;
  (c-lambda ()&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;p = fftw2d_create_plan(64,&lt;br /&gt;
                                    64,&lt;br /&gt;
                                    FFTW_BACKWARD,&lt;br /&gt;
                                    FFTW_ESTIMATE | FFTW_IN_PLACE);&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&lt;br /&gt;
(define fftw2d_create_plan_forward&lt;br /&gt;
  (c-lambda ()&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;p = fftw2d_create_plan(64,&lt;br /&gt;
                                    64,&lt;br /&gt;
                                    FFTW_FORWARD,&lt;br /&gt;
                                    FFTW_ESTIMATE | FFTW_IN_PLACE);&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&lt;br /&gt;
;;; Both forward and backward ffts, depends on which way the plan was created.&lt;br /&gt;
&lt;br /&gt;
(define fftwc&lt;br /&gt;
  (c-lambda (scheme-object)&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;&lt;br /&gt;
int j; double *fp = (double *)((___WORD)___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
  fftwnd_one(p,&lt;br /&gt;
             (fftw_complex *)(fp),&lt;br /&gt;
             NULL);&lt;br /&gt;
  for (j = 0; j &amp;lt; 64 * 64 * 2; j++)&lt;br /&gt;
    fp[j] *= .015625;&lt;br /&gt;
&amp;quot;))&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
We need to pass special options to gsc to compile this file, namely&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
gsc -cc-options &amp;quot;-I/export/users/lucier/local/fftw-2.1.5/include&amp;quot; \&lt;br /&gt;
    -ld-options &amp;quot;-L/export/users/lucier/local/fftw-2.1.5/lib/ -Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/ -lfftw&amp;quot; fftbasic.scm&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
The first option (&amp;lt;tt&amp;gt;-I/export/users/lucier/local/fftw-2.1.5/include&amp;lt;/tt&amp;gt;) tells gcc where to find the header file &amp;lt;tt&amp;gt;fftw.h&amp;lt;/tt&amp;gt; at compile time.  The second option (&amp;lt;tt&amp;gt;-L/export/users/lucier/local/fftw-2.1.5/lib/&amp;lt;/tt&amp;gt;) tells the linker where to find the FFTW library (&amp;lt;tt&amp;gt;-lfftw&amp;lt;/tt&amp;gt;) at link time (i.e., when building the file &amp;lt;tt&amp;gt;fftwbasic.o1&amp;lt;/tt&amp;gt; from &amp;lt;tt&amp;gt;fftwbasic.o&amp;lt;/tt&amp;gt;), and the third option (&amp;lt;tt&amp;gt;-Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/&amp;lt;/tt&amp;gt;) tells the dynamic loader &amp;lt;tt&amp;gt;ldd&amp;lt;/tt&amp;gt; where to find the FFTW library when &amp;lt;tt&amp;gt;fftwbasic.o1&amp;lt;/tt&amp;gt; is loaded into gsc.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Aside&amp;lt;/b&amp;gt;: Note that if the headers and libraries are in a standard place known to gcc, and the location of the shared library is already in the path of the dynamic loader, then these options may not be necessary.  In many GNU/Linux systems, for examples, nearly all packages are installed in &amp;lt;tt&amp;gt;/usr/{bin,include,lib}&amp;lt;/tt&amp;gt;, and you may not need to pass these special options to gsc.&lt;br /&gt;
&lt;br /&gt;
Then we can do&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-316% gsc&lt;br /&gt;
Gambit v4.2.8&lt;br /&gt;
&lt;br /&gt;
&amp;gt; (load &amp;quot;fftbasic&amp;quot;)&lt;br /&gt;
&amp;quot;/export/users/lucier/programs/gambc-v4_2_8/test-load-options/fftbasic.o1&amp;quot;&lt;br /&gt;
&amp;gt; fftwc&lt;br /&gt;
#&amp;lt;procedure #2 fftwc&amp;gt;&lt;br /&gt;
&amp;gt;&lt;br /&gt;
*** EOF again to exit&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
We can check that &amp;lt;tt&amp;gt;fftbasic.o1&amp;lt;/tt&amp;gt; links to the right libraries:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-317% ldd fftbasic.o1&lt;br /&gt;
        libfftw.so.2 =&amp;gt; /export/users/lucier/local/fftw-2.1.5/lib/libfftw.so.2 (0x0000002a9565a000)&lt;br /&gt;
        libc.so.6 =&amp;gt; /lib64/tls/libc.so.6 (0x0000002a957aa000)&lt;br /&gt;
        libm.so.6 =&amp;gt; /lib64/tls/libm.so.6 (0x0000002a959df000)&lt;br /&gt;
        /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Finally, recall from the the [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#SEC21 Gambit manual] that anything you can do with gsc on the command line you can do with one of the gsc-specific scheme procedures &amp;lt;tt&amp;gt;compile-file&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;compile-file-to-c&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;link-incremental&amp;lt;/tt&amp;gt;, or &amp;lt;tt&amp;gt;link-flat&amp;lt;/tt&amp;gt;.  Thus, one could build &amp;lt;tt&amp;gt;fftbasic.o1&amp;lt;/tt&amp;gt; by&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-352% gsc&lt;br /&gt;
Gambit v4.2.8&lt;br /&gt;
&lt;br /&gt;
&amp;gt; (compile-file &amp;quot;fftbasic.scm&amp;quot; cc-options: &amp;quot;-I/export/users/lucier/local/fftw-2.1.5/include&amp;quot;&lt;br /&gt;
 ld-options: &amp;quot;-L/export/users/lucier/local/fftw-2.1.5/lib/ -Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/ -lfftw&amp;quot;)&lt;br /&gt;
#t&lt;br /&gt;
&amp;gt; (load &amp;quot;fftbasic&amp;quot;)&lt;br /&gt;
&amp;quot;/export/users/lucier/programs/gambc-v4_2_8/test-load-options/fftbasic.o1&amp;quot;&lt;br /&gt;
&amp;gt; fftwc&lt;br /&gt;
#&amp;lt;procedure #2 fftwc&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Accessing Scheme vectors within a C function ==&lt;br /&gt;
&lt;br /&gt;
Example. Get the pointer to the beginning of a u8vector Scheme object:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(define ffi-with-scheme-vectors&lt;br /&gt;
  (c-lambda (scheme-object int) ; scheme-object : the vector , int : the vector size&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,&amp;amp;___FETCH_U8(___BODY(___arg1),___INT(0)));&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,&amp;amp;___FETCH_U8(___arg1,0));&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,___BODY(___arg1));&lt;br /&gt;
//void *u8vectorptr = ___CAST(___U8*,___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
&lt;br /&gt;
// Of course, you can cast directly to uchar* if you plan to work with that&lt;br /&gt;
unsigned char *u8vectorptr = ___CAST(___U8*,___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
&lt;br /&gt;
/* Then here do your work with *u8vectorptr, you have its size as the ___arg2 argument */&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Look for examples in &amp;quot;gambit.h&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Caveat: the C compiler does not know that the GC might move objects, so the C code must be written to avoid calling the GC either directly or indirectly. Remember that the pointer is only to be kept until the next return to Scheme.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Practices in FFI development ==&lt;br /&gt;
(There are a couple of posts from September 2008 in the mailing list archive on this subject. Someone please cut and paste them over here.)&lt;br /&gt;
   https://mercure.iro.umontreal.ca/pipermail/gambit-list/2008-September/002572.html&lt;br /&gt;
&lt;br /&gt;
[[Category: FFI]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Using_Gambit_with_External_Libraries</id>
		<title>Using Gambit with External Libraries</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Using_Gambit_with_External_Libraries"/>
				<updated>2011-03-28T14:00:42Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: Added section: The return strategy required by Gambit apps on Scheme-&amp;gt;C-&amp;gt;Scheme calls&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== The return strategy required by Gambit apps on Scheme-&amp;gt;C-&amp;gt;Scheme calls ==&lt;br /&gt;
How Gambit integrates the Scheme stack with the C stack is described in the section &amp;quot;19.7 Continuations and the C-interface&amp;quot; in the manual, and also in the paper [http://www.iro.umontreal.ca/~feeley/papers/FeeleySW00.pdf|A Portable Implementation of First-Class Continuations for Unrestricted Interoperaibility with C in a Multithreaded Scheme]. Here is a clarification though, which was detailed 28 march 2011 on the mailing list:&lt;br /&gt;
&lt;br /&gt;
If you have several C stack frames (produced by a Scheme-&amp;gt;C call which made a C-&amp;gt;Scheme call that made a Scheme-&amp;gt;C call in turn) at the same time, you must return them in the same sequence as you'd have needed to do ordinarily in C, i.e. from the last to the first in sequence.&lt;br /&gt;
&lt;br /&gt;
I.e., if you have the Scheme procedures A, C, E and G, and the C procedures b, d and f, and they invoke each other A -&amp;gt; b -&amp;gt; C -&amp;gt; d -&amp;gt; E -&amp;gt; f -&amp;gt; G, then you must ensure that G will return to f, f to E, E to d, d to C, C to b and b to A.&lt;br /&gt;
&lt;br /&gt;
If you return them in another order - i.e. for example G to d etc. - there will be a runtime error, which terminates the application silently.&lt;br /&gt;
&lt;br /&gt;
Note that anytime during a program's execution in the Scheme world, Gambit's thread multitasker may switch the running thread. If several threads do Scheme-&amp;gt;C-&amp;gt;Scheme calls at the same time, then in the ordinary case, thread switching may happen such that the C stack is rewinded invalidly (i.e. in another order than as described above), which at some point (not on the first invalid return) will cause the abovementioned runtime error. You can fix this by keeping all Scheme-&amp;gt;C-&amp;gt;Scheme calls in your app to one thread in total, by rewriting your code to do what you wanted to achieve through making a C-&amp;gt;Scheme some other way instead, or by going with the &amp;quot;Ensuring singlethreaded behavior&amp;quot; described below.&lt;br /&gt;
&lt;br /&gt;
== Ensuring singlethreaded behaviour ==&lt;br /&gt;
In certain situations, it's vital to ensure a single thread of execution.&lt;br /&gt;
&lt;br /&gt;
One way may be to create one thread to which you send closures containing code to be executed, and which returns the responses through a mailbox mechanism, there's an example implementation in the Gambit manual.&lt;br /&gt;
&lt;br /&gt;
Ways to get Gambit execute completely single-threaded is:&lt;br /&gt;
&lt;br /&gt;
* Use (thread-quantum-set! (current-thread) +inf.0)&lt;br /&gt;
&lt;br /&gt;
* Use (##disable-interrupts) and (##enable-interrupts) in Scheme or ___EXT(___disable_interrupts)() and ___EXT(___enable_interrupts)() from C.&lt;br /&gt;
&lt;br /&gt;
Please note that Gambit's I/O system makes use of the scheduler, and threading routines do this also, so don't do read, write, thread-sleep!, thread-yield! etc. in code you intended to execute single-threaded.&lt;br /&gt;
&lt;br /&gt;
== Export and import C symbols ==&lt;br /&gt;
Gambit's gambit.h provides helper macros for exporting functions and variables. They are  ___EXPORT_FUNC(type,name) and ___EXPORT_DATA(type,name), and are used like ___EXPORT_FUNC(int,five) () { return 5; } . Grep lib/*.c of the Gambit sources for EXP_FUNC and EXP_DATA to see examples.&lt;br /&gt;
&lt;br /&gt;
On Windows, exporting and importing functions and variables from C code may be particularly tricky. Check out the Microsoft-provided __declspec(dllexport) and __declspec(dllimport).&lt;br /&gt;
&lt;br /&gt;
== Using gsc to compile and link a dynamically loadable object file that uses external libraries ==&lt;br /&gt;
&lt;br /&gt;
Here is an example of building a dynamically loadable Gambit object file that uses [http://www.fftw.org FFTW].  This example is on Red Hat Enterprise Linux 4.2 on x86-64.&lt;br /&gt;
&lt;br /&gt;
The program uses the FFTW version 2 API, so we downloaded fftw-2.1.5.tar.gz, untarred it and configured it with&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
./configure --enable-shared --prefix=/export/users/lucier/local/fftw-2.1.5&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
You need the &amp;lt;tt&amp;gt;--enable-shared&amp;lt;/tt&amp;gt; option because shared Gambit modules must be linked to shared external libraries.  I set the &amp;lt;tt&amp;gt;--prefix&amp;lt;/tt&amp;gt; to install the final FFTW libraries and header files in my home directory.&lt;br /&gt;
&lt;br /&gt;
The file &amp;lt;tt&amp;gt;fftbasics.scm&amp;lt;/tt&amp;gt; provides the basic interface between the Scheme code and FFTW; it is as follows:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(c-declare&lt;br /&gt;
&amp;quot;&lt;br /&gt;
#include \&amp;quot;fftw.h\&amp;quot;&lt;br /&gt;
&lt;br /&gt;
fftwnd_plan p;&lt;br /&gt;
&lt;br /&gt;
&amp;quot;)&lt;br /&gt;
&lt;br /&gt;
(define fftw2d_create_plan_backward&lt;br /&gt;
  (c-lambda ()&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;p = fftw2d_create_plan(64,&lt;br /&gt;
                                    64,&lt;br /&gt;
                                    FFTW_BACKWARD,&lt;br /&gt;
                                    FFTW_ESTIMATE | FFTW_IN_PLACE);&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&lt;br /&gt;
(define fftw2d_create_plan_forward&lt;br /&gt;
  (c-lambda ()&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;p = fftw2d_create_plan(64,&lt;br /&gt;
                                    64,&lt;br /&gt;
                                    FFTW_FORWARD,&lt;br /&gt;
                                    FFTW_ESTIMATE | FFTW_IN_PLACE);&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&lt;br /&gt;
;;; Both forward and backward ffts, depends on which way the plan was created.&lt;br /&gt;
&lt;br /&gt;
(define fftwc&lt;br /&gt;
  (c-lambda (scheme-object)&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;&lt;br /&gt;
int j; double *fp = (double *)((___WORD)___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
  fftwnd_one(p,&lt;br /&gt;
             (fftw_complex *)(fp),&lt;br /&gt;
             NULL);&lt;br /&gt;
  for (j = 0; j &amp;lt; 64 * 64 * 2; j++)&lt;br /&gt;
    fp[j] *= .015625;&lt;br /&gt;
&amp;quot;))&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
We need to pass special options to gsc to compile this file, namely&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
gsc -cc-options &amp;quot;-I/export/users/lucier/local/fftw-2.1.5/include&amp;quot; \&lt;br /&gt;
    -ld-options &amp;quot;-L/export/users/lucier/local/fftw-2.1.5/lib/ -Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/ -lfftw&amp;quot; fftbasic.scm&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
The first option (&amp;lt;tt&amp;gt;-I/export/users/lucier/local/fftw-2.1.5/include&amp;lt;/tt&amp;gt;) tells gcc where to find the header file &amp;lt;tt&amp;gt;fftw.h&amp;lt;/tt&amp;gt; at compile time.  The second option (&amp;lt;tt&amp;gt;-L/export/users/lucier/local/fftw-2.1.5/lib/&amp;lt;/tt&amp;gt;) tells the linker where to find the FFTW library (&amp;lt;tt&amp;gt;-lfftw&amp;lt;/tt&amp;gt;) at link time (i.e., when building the file &amp;lt;tt&amp;gt;fftwbasic.o1&amp;lt;/tt&amp;gt; from &amp;lt;tt&amp;gt;fftwbasic.o&amp;lt;/tt&amp;gt;), and the third option (&amp;lt;tt&amp;gt;-Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/&amp;lt;/tt&amp;gt;) tells the dynamic loader &amp;lt;tt&amp;gt;ldd&amp;lt;/tt&amp;gt; where to find the FFTW library when &amp;lt;tt&amp;gt;fftwbasic.o1&amp;lt;/tt&amp;gt; is loaded into gsc.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Aside&amp;lt;/b&amp;gt;: Note that if the headers and libraries are in a standard place known to gcc, and the location of the shared library is already in the path of the dynamic loader, then these options may not be necessary.  In many GNU/Linux systems, for examples, nearly all packages are installed in &amp;lt;tt&amp;gt;/usr/{bin,include,lib}&amp;lt;/tt&amp;gt;, and you may not need to pass these special options to gsc.&lt;br /&gt;
&lt;br /&gt;
Then we can do&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-316% gsc&lt;br /&gt;
Gambit v4.2.8&lt;br /&gt;
&lt;br /&gt;
&amp;gt; (load &amp;quot;fftbasic&amp;quot;)&lt;br /&gt;
&amp;quot;/export/users/lucier/programs/gambc-v4_2_8/test-load-options/fftbasic.o1&amp;quot;&lt;br /&gt;
&amp;gt; fftwc&lt;br /&gt;
#&amp;lt;procedure #2 fftwc&amp;gt;&lt;br /&gt;
&amp;gt;&lt;br /&gt;
*** EOF again to exit&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
We can check that &amp;lt;tt&amp;gt;fftbasic.o1&amp;lt;/tt&amp;gt; links to the right libraries:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-317% ldd fftbasic.o1&lt;br /&gt;
        libfftw.so.2 =&amp;gt; /export/users/lucier/local/fftw-2.1.5/lib/libfftw.so.2 (0x0000002a9565a000)&lt;br /&gt;
        libc.so.6 =&amp;gt; /lib64/tls/libc.so.6 (0x0000002a957aa000)&lt;br /&gt;
        libm.so.6 =&amp;gt; /lib64/tls/libm.so.6 (0x0000002a959df000)&lt;br /&gt;
        /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Finally, recall from the the [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#SEC21 Gambit manual] that anything you can do with gsc on the command line you can do with one of the gsc-specific scheme procedures &amp;lt;tt&amp;gt;compile-file&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;compile-file-to-c&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;link-incremental&amp;lt;/tt&amp;gt;, or &amp;lt;tt&amp;gt;link-flat&amp;lt;/tt&amp;gt;.  Thus, one could build &amp;lt;tt&amp;gt;fftbasic.o1&amp;lt;/tt&amp;gt; by&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
euler-352% gsc&lt;br /&gt;
Gambit v4.2.8&lt;br /&gt;
&lt;br /&gt;
&amp;gt; (compile-file &amp;quot;fftbasic.scm&amp;quot; cc-options: &amp;quot;-I/export/users/lucier/local/fftw-2.1.5/include&amp;quot;&lt;br /&gt;
 ld-options: &amp;quot;-L/export/users/lucier/local/fftw-2.1.5/lib/ -Wl,-rpath,/export/users/lucier/local/fftw-2.1.5/lib/ -lfftw&amp;quot;)&lt;br /&gt;
#t&lt;br /&gt;
&amp;gt; (load &amp;quot;fftbasic&amp;quot;)&lt;br /&gt;
&amp;quot;/export/users/lucier/programs/gambc-v4_2_8/test-load-options/fftbasic.o1&amp;quot;&lt;br /&gt;
&amp;gt; fftwc&lt;br /&gt;
#&amp;lt;procedure #2 fftwc&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Accessing Scheme vectors within a C function ==&lt;br /&gt;
&lt;br /&gt;
Example. Get the pointer to the beginning of a u8vector Scheme object:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(define ffi-with-scheme-vectors&lt;br /&gt;
  (c-lambda (scheme-object int) ; scheme-object : the vector , int : the vector size&lt;br /&gt;
            void&lt;br /&gt;
            &amp;quot;&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,&amp;amp;___FETCH_U8(___BODY(___arg1),___INT(0)));&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,&amp;amp;___FETCH_U8(___arg1,0));&lt;br /&gt;
//void *u8vectorptr = ___CAST(void*,___BODY(___arg1));&lt;br /&gt;
//void *u8vectorptr = ___CAST(___U8*,___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
&lt;br /&gt;
// Of course, you can cast directly to uchar* if you plan to work with that&lt;br /&gt;
unsigned char *u8vectorptr = ___CAST(___U8*,___BODY_AS(___arg1,___tSUBTYPED));&lt;br /&gt;
&lt;br /&gt;
/* Then here do your work with *u8vectorptr, you have its size as the ___arg2 argument */&lt;br /&gt;
            &amp;quot;))&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Look for examples in &amp;quot;gambit.h&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Caveat: the C compiler does not know that the GC might move objects, so the C code must be written to avoid calling the GC either directly or indirectly. Remember that the pointer is only to be kept until the next return to Scheme.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Practices in FFI development ==&lt;br /&gt;
(There are a couple of posts from September 2008 in the mailing list archive on this subject. Someone please cut and paste them over here.)&lt;br /&gt;
   https://mercure.iro.umontreal.ca/pipermail/gambit-list/2008-September/002572.html&lt;br /&gt;
&lt;br /&gt;
[[Category: FFI]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/File:Black_Hole.zip</id>
		<title>File:Black Hole.zip</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/File:Black_Hole.zip"/>
				<updated>2009-08-14T12:19:08Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: Black Hole dump file&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Black Hole dump file&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Black_Hole</id>
		<title>Black Hole</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Black_Hole"/>
				<updated>2009-08-14T12:17:41Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Black Hole''' (“BH”) is a module system abstraction for [[Documentation|Gambit]] providing recurring module file dependency compilation and loading, including export of macros, for regular R5RS Scheme.&lt;br /&gt;
&lt;br /&gt;
Read further in the Introduction section of the documentation, found below.&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
Its latest version is avilable via GIT, and can be downloaded using [http://www.git-scm.org GIT] by&lt;br /&gt;
&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;git clone http://mwaza.dyndns.org/apps/files/modules.git&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
or via repo.or.cz mirror&lt;br /&gt;
&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;git clone git://repo.or.cz/blackhole.git&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
or non-automatically, probably very old copy [[media:Black_Hole.zip|here]].&lt;br /&gt;
&lt;br /&gt;
== Documentation == &lt;br /&gt;
Core documentation: [[media:Black_Hole_Core.pdf|PDF]], [[media:Black_Hole_Core.odf|OpenOffice]] and [[media:Black_Hole_Core.doc|Microsoft Word]]&lt;br /&gt;
&lt;br /&gt;
Bundled libraries documentation: [[media:Black_Hole_Bundled_libraries.pdf|PDF]], [[media:Black_Hole_Bundled_libraries.odf|OpenOffice]] and [[media:Black_Hole_Bundled_libraries.doc|Microsoft Word]]&lt;br /&gt;
&lt;br /&gt;
(The tutorial for the alpha release can still be found on http://mwaza.dyndns.org/apps/files/bh-tutorial.html .)&lt;br /&gt;
&lt;br /&gt;
== Bundled libraries ==&lt;br /&gt;
BH is bundled with a set of general purpose libraries, including:&lt;br /&gt;
&lt;br /&gt;
*SRFI 1 (list processing), 13 (string), 14 (character sets), 16 (case-lambda support), 19 (time data types and procedures), 95 (sorting)&lt;br /&gt;
*pregexp, hash digestion, base64 handling, UUID generator&lt;br /&gt;
*HTTP client, server, URI and session variable handling&lt;br /&gt;
*XML&amp;amp;lt;-&amp;amp;gt;SXML routines&lt;br /&gt;
*FIFO queue, mailbox, weight balanced tree, erlang-style list matcher&lt;br /&gt;
*String, u8vector, list, exception handling helper libraries&lt;br /&gt;
*let-optionals support&lt;br /&gt;
&lt;br /&gt;
BH's core is completely independent of the bundled libraries, and can be separated from them without any modifications.&lt;br /&gt;
&lt;br /&gt;
See the documentation for more information.&lt;br /&gt;
&lt;br /&gt;
== Additional libraries ==&lt;br /&gt;
Termite: A version suited for usage in Black Hole is found at GitHub, http://github.com/pereckerdal/termite/tree/master.&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/File:Black_Hole_Bundled_libraries.doc</id>
		<title>File:Black Hole Bundled libraries.doc</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/File:Black_Hole_Bundled_libraries.doc"/>
				<updated>2009-07-15T08:57:57Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: Bundled libraries documentation for the Black Hole module system. Revision 1. ** DRAFT **&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Bundled libraries documentation for the Black Hole module system. Revision 1. ** DRAFT **&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/File:Black_Hole_Bundled_libraries.odf</id>
		<title>File:Black Hole Bundled libraries.odf</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/File:Black_Hole_Bundled_libraries.odf"/>
				<updated>2009-07-15T08:56:01Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: Bundled libraries documentation for the Black Hole module system. Revision 1. ** DRAFT **&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Bundled libraries documentation for the Black Hole module system. Revision 1. ** DRAFT **&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/File:Black_Hole_Bundled_libraries.pdf</id>
		<title>File:Black Hole Bundled libraries.pdf</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/File:Black_Hole_Bundled_libraries.pdf"/>
				<updated>2009-07-15T08:55:14Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Black_Hole</id>
		<title>Black Hole</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Black_Hole"/>
				<updated>2009-07-15T08:54:37Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Black Hole''' (“BH”) is a module system abstraction for [[Documentation|Gambit]] providing recurring module file dependency compilation and loading, including export of macros, for regular R5RS Scheme.&lt;br /&gt;
&lt;br /&gt;
Read further in the Introduction section of the documentation, found below.&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
Its latest version is avilable via GIT, and can be downloaded using [http://www.git-scm.org GIT] by&lt;br /&gt;
&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;git clone http://mwaza.dyndns.org/apps/files/modules.git&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
or via repo.or.cz mirror&lt;br /&gt;
&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;git clone git://repo.or.cz/blackhole.git&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Documentation == &lt;br /&gt;
Core documentation: [[media:Black_Hole_Core.pdf|PDF]], [[media:Black_Hole_Core.odf|OpenOffice]] and [[media:Black_Hole_Core.doc|Microsoft Word]]&lt;br /&gt;
&lt;br /&gt;
Bundled libraries documentation: [[media:Black_Hole_Bundled_libraries.pdf|PDF]], [[media:Black_Hole_Bundled_libraries.odf|OpenOffice]] and [[media:Black_Hole_Bundled_libraries.doc|Microsoft Word]]&lt;br /&gt;
&lt;br /&gt;
(The tutorial for the alpha release can still be found on http://mwaza.dyndns.org/apps/files/bh-tutorial.html .)&lt;br /&gt;
&lt;br /&gt;
== Bundled libraries ==&lt;br /&gt;
BH is bundled with a set of general purpose libraries, including:&lt;br /&gt;
&lt;br /&gt;
*SRFI 1 (list processing), 13 (string), 14 (character sets), 16 (case-lambda support), 19 (time data types and procedures), 95 (sorting)&lt;br /&gt;
*pregexp, hash digestion, base64 handling, UUID generator&lt;br /&gt;
*HTTP client, server, URI and session variable handling&lt;br /&gt;
*XML&amp;amp;lt;-&amp;amp;gt;SXML routines&lt;br /&gt;
*FIFO queue, mailbox, weight balanced tree, erlang-style list matcher&lt;br /&gt;
*String, u8vector, list, exception handling helper libraries&lt;br /&gt;
*let-optionals support&lt;br /&gt;
&lt;br /&gt;
BH's core is completely independent of the bundled libraries, and can be separated from them without any modifications.&lt;br /&gt;
&lt;br /&gt;
See the documentation for more information.&lt;br /&gt;
&lt;br /&gt;
== Additional libraries ==&lt;br /&gt;
Termite: A version suited for usage in Black Hole is found at GitHub, http://github.com/pereckerdal/termite/tree/master.&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/File:Black_Hole_Core.doc</id>
		<title>File:Black Hole Core.doc</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/File:Black_Hole_Core.doc"/>
				<updated>2009-07-15T08:40:04Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: Core documentation for the Black Hole module system. Revision 1.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Core documentation for the Black Hole module system. Revision 1.&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/File:Black_Hole_Core.pdf</id>
		<title>File:Black Hole Core.pdf</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/File:Black_Hole_Core.pdf"/>
				<updated>2009-07-15T08:38:00Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: Core documentation for the Black Hole module system. Revision 1.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Core documentation for the Black Hole module system. Revision 1.&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/File:Black_Hole_Core.odf</id>
		<title>File:Black Hole Core.odf</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/File:Black_Hole_Core.odf"/>
				<updated>2009-07-15T07:54:49Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: Core documentation for the Black Hole module system. Revision 1.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Core documentation for the Black Hole module system. Revision 1.&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Black_Hole</id>
		<title>Black Hole</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Black_Hole"/>
				<updated>2009-07-15T07:52:13Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Documentation == &lt;br /&gt;
Core documentation: [[media:Black_Hole_Core.pdf|PDF]], [[media:Black_Hole_Core.odf|OpenOffice]] and [[media:Black_Hole_Core.doc|Microsoft Word]]&lt;br /&gt;
&lt;br /&gt;
Bundled libraries documentation: [[media:Black_Hole_Bundled_libraries.pdf|PDF]], [[media:Black_Hole_Bundled_libraries.odf|OpenOffice]] and [[media:Black_Hole_Bundled_libraries.doc|Microsoft Word]]&lt;br /&gt;
&lt;br /&gt;
(The tutorial for the alpha release can still be found on http://mwaza.dyndns.org/apps/files/bh-tutorial.html .)&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Documentation</id>
		<title>Documentation</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Documentation"/>
				<updated>2009-07-14T08:45:32Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: /* Black Hole module system */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== User Documentation ==&lt;br /&gt;
&lt;br /&gt;
There is a user manual for Gambit in [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html HTML]&lt;br /&gt;
and [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.pdf PDF] formats.&lt;br /&gt;
&lt;br /&gt;
See the [[Scheme]] page for documentation on Scheme in general.&lt;br /&gt;
&lt;br /&gt;
== Prebuilt Distributions ==&lt;br /&gt;
&lt;br /&gt;
Some prebuilt distributions are [[Distributions | available]].&lt;br /&gt;
&lt;br /&gt;
== Building Gambit from Source ==&lt;br /&gt;
&lt;br /&gt;
To build Gambit from source, one must first run the configure script, which has a number&lt;br /&gt;
of important [[Configure script options | options]].&lt;br /&gt;
&lt;br /&gt;
There are various [[Make targets | make targets]] of which you should be aware.&lt;br /&gt;
&lt;br /&gt;
== Packages, modules, libraries and driving systems ==&lt;br /&gt;
&lt;br /&gt;
=== The Snow package system ===&lt;br /&gt;
[http://snow.iro.umontreal.ca/ Snow] is a package system for R4RS and R5RS Scheme.  Nearly&lt;br /&gt;
all Snow packages run on Gambit.  Users can simply download and install&lt;br /&gt;
[http://snow.iro.umontreal.ca/?tab=Packages existing packages]. For those who want&lt;br /&gt;
to develop new packages, Snow has its own&lt;br /&gt;
[http://snow.iro.umontreal.ca/?tab=Documentation documentation].&lt;br /&gt;
&lt;br /&gt;
=== Black Hole module system ===&lt;br /&gt;
[[Black Hole]] is a module system for incremental development and easily sharing code. It is bundled with a set of general purpose libraries.&lt;br /&gt;
&lt;br /&gt;
=== SRFI:s ===&lt;br /&gt;
The Scheme community has accumulated a set of common libraries and conventions called Scheme Requests for Implementation, publicly collected on [http://srfi.schemers.org/ srfi.schemers.org].&lt;br /&gt;
&lt;br /&gt;
Gambit has SRFIs [http://srfi.schemers.org/srfi-0/ 0],  [http://srfi.schemers.org/srfi-4/ 4], [http://srfi.schemers.org/srfi-6/ 6], [http://srfi.schemers.org/srfi-8/ 8], [http://srfi.schemers.org/srfi-9/ 9], [http://srfi.schemers.org/srfi-18/ 18], [http://srfi.schemers.org/srfi-21/ 21], [http://srfi.schemers.org/srfi-22/ 22], [http://srfi.schemers.org/srfi-23/ 23], [http://srfi.schemers.org/srfi-27/ 27], and  [http://srfi.schemers.org/srfi-39/ 39] built-in.&lt;br /&gt;
&lt;br /&gt;
Snow as well as Black Hole feature certain SRFI:s. Also, there are SRFI:s that remain to be ported to Gambit.&lt;br /&gt;
&lt;br /&gt;
=== Dumping grounds ===&lt;br /&gt;
There is an informal listing of sourcecode on the [[Dumping Grounds]].&lt;br /&gt;
&lt;br /&gt;
== Editor/IDE Support ==&lt;br /&gt;
&lt;br /&gt;
Gambit provides a powerful development environment through [http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#SEC28 Emacs]. &lt;br /&gt;
&lt;br /&gt;
For those running Windows you can [http://ftp.gnu.org/pub/gnu/emacs/windows/ download Emacs here]. You may want to read the [http://www.gnu.org/software/emacs/windows/ntemacs.html Emacs FAQ for Windows] before customizing Emacs for use with Gambit.&lt;br /&gt;
&lt;br /&gt;
Editors such as [http://www.eclipse.org/ Eclipse] with the [http://schemeway.sourceforge.net/ SchemeWay] extension, or just about any text editor with Scheme syntax highlighting, such as [http://www.vim.org VIM or GVIM], may prove valuable as well.&lt;br /&gt;
&lt;br /&gt;
== Termite ==&lt;br /&gt;
&lt;br /&gt;
[http://code.google.com/p/termite/ Termite] is an Erlang-like distributed programming system written in Scheme.&lt;br /&gt;
&lt;br /&gt;
Distributed computing hot right now, and Termite has been noticed in blogs and elsewhere.&lt;br /&gt;
&lt;br /&gt;
Termite depends on specific features of Gambit, and at one time or another&lt;br /&gt;
the Termite source code has been distributed with Gambit, so we point to the Termite web site&lt;br /&gt;
from here.&lt;br /&gt;
&lt;br /&gt;
== Tutorials ==&lt;br /&gt;
[[A Tour of Scheme in Gambit]] gives a general introduction to Scheme and Gambit to people with experiences of general programming languages. Available in [[media:A_Tour_of_Scheme_in_Gambit.pdf|PDF]], [[media:A_Tour_of_Scheme_in_Gambit.odf|Open Office]] and [[media:A_Tour_of_Scheme_in_Gambit.doc|Microsoft Word]] formats.&lt;br /&gt;
&lt;br /&gt;
== Internals Documentation ==&lt;br /&gt;
&lt;br /&gt;
People who want to [[How to Contribute | contribute]] to Gambit development will need to learn something about how the Gambit-C&lt;br /&gt;
runtime and compiler are organized.  While we intend that source code documentation be included in the source&lt;br /&gt;
itself (currently there is very little documentation), we intend that descriptions of program design&lt;br /&gt;
or algorithms used in the runtime and compiler could be included on the [[Internal Documentation]] page.&lt;br /&gt;
&lt;br /&gt;
== Working with External Libraries ==&lt;br /&gt;
&lt;br /&gt;
With Gambit's C FFI (Foreign Function Interface), one can easily use standard C and C++ libraries with your code; this wiki has some examples of and practices on using Gambit with external libraries. See [[Using Gambit with External Libraries]].&lt;br /&gt;
&lt;br /&gt;
== Debugging ==&lt;br /&gt;
&lt;br /&gt;
See the [[Debugging]] page.&lt;br /&gt;
&lt;br /&gt;
== More ==&lt;br /&gt;
The [http://mailman.iro.umontreal.ca/pipermail/gambit-list mailing list archive] covers many topics at depth. You can make Google search queries limited to the mailing list by clicking &amp;quot;advanced settings&amp;quot; on www.google.com.&lt;br /&gt;
&lt;br /&gt;
[[Compiling Gambit software for different target environments]]&lt;br /&gt;
&lt;br /&gt;
[[Wish list]]&lt;br /&gt;
&lt;br /&gt;
[[External links]]&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Black_Hole</id>
		<title>Black Hole</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Black_Hole"/>
				<updated>2009-07-14T06:48:41Z</updated>
		
		<summary type="html">&lt;p&gt;Mikaelm: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Black Hole''' (“BH”) is a module system abstraction for [[Documentation|Gambit]] providing recurring module file dependency compilation and loading, including export of macros, for regular R5RS Scheme.&lt;br /&gt;
&lt;br /&gt;
Read further in the Introduction section of the documentation, found below.&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
Its latest version is avilable via GIT, and can be downloaded using [http://www.git-scm.org GIT] by&lt;br /&gt;
&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;git clone http://mwaza.dyndns.org/apps/files/modules.git&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
or via repo.or.cz mirror&lt;br /&gt;
&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;git clone git://repo.or.cz/blackhole.git&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Documentation == &lt;br /&gt;
Core documentation: [[media:Black_Hole_Core.pdf|PDF]], [[media:Black_Hole_Core.pdf|HTML]], [[media:Black_Hole_Core.odf|OpenOffice]] and [[media:Black_Hole_Core.doc|Microsoft Word]]&lt;br /&gt;
&lt;br /&gt;
Bundled libraries documentation: [[media:Black_Hole_Bundled_libraries.pdf|PDF]], [[media:Black_Hole_Bundled_libraries.pdf|HTML]], [[media:Black_Hole_Bundled_libraries.odf|OpenOffice]] and [[media:Black_Hole_Bundled_libraries.doc|Microsoft Word]]&lt;br /&gt;
&lt;br /&gt;
[Note: These links are broken. At the moment, the best documentation available can be found at http://mwaza.dyndns.org/apps/files/bh-tutorial.html]&lt;br /&gt;
&lt;br /&gt;
== Bundled libraries ==&lt;br /&gt;
BH is bundled with a set of general purpose libraries, including:&lt;br /&gt;
&lt;br /&gt;
*SRFI 1 (list processing), 13 (string), 14 (character sets), 16 (case-lambda support), 19 (time data types and procedures), 95 (sorting)&lt;br /&gt;
*pregexp, hash digestion, base64 handling, UUID generator&lt;br /&gt;
*HTTP client, server, URI and session variable handling&lt;br /&gt;
*XML&amp;amp;lt;-&amp;amp;gt;SXML routines&lt;br /&gt;
*FIFO queue, mailbox, weight balanced tree, erlang-style list matcher&lt;br /&gt;
*String, u8vector, list, exception handling helper libraries&lt;br /&gt;
*let-optionals support&lt;br /&gt;
&lt;br /&gt;
BH's core is completely independent of the bundled libraries, and can be separated from them without any modifications.&lt;br /&gt;
&lt;br /&gt;
See the documentation for more information.&lt;br /&gt;
&lt;br /&gt;
== Additional libraries ==&lt;br /&gt;
Termite: A version suited for usage in Black Hole is found at GitHub, http://github.com/pereckerdal/termite/tree/master.&lt;/div&gt;</summary>
		<author><name>Mikaelm</name></author>	</entry>

	</feed>