<?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/Pipping&amp;feed=atom&amp;limit=50&amp;target=Pipping&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/Pipping&amp;feed=atom&amp;limit=50&amp;target=Pipping&amp;year=&amp;month="/>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Special:Contributions/Pipping"/>
		<updated>2013-05-25T04:19:40Z</updated>
		<subtitle>From Gambit wiki</subtitle>
		<generator>MediaWiki 1.16.4</generator>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Contributing_Patches_to_Gambit_Source_Code</id>
		<title>Contributing Patches to Gambit Source Code</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Contributing_Patches_to_Gambit_Source_Code"/>
				<updated>2010-07-11T19:36:55Z</updated>
		
		<summary type="html">&lt;p&gt;Pipping: use `git format-patch` (one might want to also use `git send-email`)&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__ __NOEDITSECTION__&lt;br /&gt;
The Gambit [[Source code repository | source code repository]] is&lt;br /&gt;
managed with the [http://git.or.cz/ git]&lt;br /&gt;
distributed version control system.&lt;br /&gt;
&lt;br /&gt;
Each developer uses a local copy of the central repository.  The&lt;br /&gt;
copies can be edited independently using any tool (editors, utility&lt;br /&gt;
programs, etc).  When a developer completes making a set of related&lt;br /&gt;
changes they are recorded as a ''commit''.  The developer can submit&lt;br /&gt;
these changes to the Gambit maintainers as a ''patch''.  If the patch is accepted&lt;br /&gt;
then it will be applied to the repository by the Gambit maintainers&lt;br /&gt;
and will become part of the central repository.&lt;br /&gt;
&lt;br /&gt;
This page only gives the main procedures and git commands that are needed&lt;br /&gt;
to manage the local copy of the central repository.&lt;br /&gt;
Please read the [http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html git tutorial] for&lt;br /&gt;
typical usage instructions.&lt;br /&gt;
&lt;br /&gt;
==== Installing git ====&lt;br /&gt;
&lt;br /&gt;
Git was created for the development of the Linux kernel, and&lt;br /&gt;
is sometimes preinstalled on Linux distributions.&lt;br /&gt;
Prebuilt distributions of git and a source code distribution are&lt;br /&gt;
available [http://git.or.cz/#download here].&lt;br /&gt;
Please follow the installation instructions on the&lt;br /&gt;
[http://git.or.cz/ git web site].&lt;br /&gt;
&lt;br /&gt;
To simplify usage of git the git configuration file '''$HOME/.gitconfig'''&lt;br /&gt;
should be created and contain at least your username.  There are&lt;br /&gt;
many settings that can be specified&lt;br /&gt;
such as the editor to use for entering the comment attached&lt;br /&gt;
to a commit.  For example, to use emacs:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[user]&lt;br /&gt;
        name = Marc Feeley&lt;br /&gt;
        email = feeley@iro.umontreal.ca&lt;br /&gt;
[core]&lt;br /&gt;
        editor = emacs -nw&lt;br /&gt;
[color]&lt;br /&gt;
        ui = auto&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Obtaining a local copy of the Gambit source code ====&lt;br /&gt;
&lt;br /&gt;
The best way to obtain a local copy of the Gambit source code is to&lt;br /&gt;
download and unpack a recent source code release.  You need&lt;br /&gt;
the '''developer''' version, which has a '''-devel''' in the tarball name.&lt;br /&gt;
Normally the most recent source code release should be downloaded&lt;br /&gt;
and you need at least v4.3.2 (the first version to support git).&lt;br /&gt;
After that you can use the '''make update''' command to&lt;br /&gt;
update your local copy with all the changes committed to&lt;br /&gt;
the central source code repository.&lt;br /&gt;
&lt;br /&gt;
Get the most recent tarball from the &lt;br /&gt;
[http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Main_Page main Gambit page].&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
wget http://www.iro.umontreal.ca/~gambit/download/gambit/v4.3/source/gambc-v4_3_2-devel.tgz&lt;br /&gt;
tar zxf gambc-v4_3_2-devel.tgz&lt;br /&gt;
mv gambc-v4_3_2-devel gambit&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Note that in anticipation of making changes to the source code the&lt;br /&gt;
directory has been renamed to '''gambit''' to avoid thinking it is a&lt;br /&gt;
pristine copy of a particular release.&lt;br /&gt;
&lt;br /&gt;
The system should then be prepared for modifications of the Scheme&lt;br /&gt;
source code by creating a compiler for bootstrapping:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
cd gambit&lt;br /&gt;
./configure --enable-single-host&lt;br /&gt;
make bootstrap&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will create the '''gsc-comp''' compiler, which is executed when a&lt;br /&gt;
Scheme source code file in the Gambit system must be compiled&lt;br /&gt;
following a change.&lt;br /&gt;
&lt;br /&gt;
==== Synchronizing with the central source code repository ====&lt;br /&gt;
&lt;br /&gt;
The local source code files can then be updated to contain the latest commits&lt;br /&gt;
on the central source code repository with the command:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
make update&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will call the '''git fetch''' and '''git checkout''' commands in a loop, so that the Gambit compiler&lt;br /&gt;
for each release between the local copy's release and the most recent release are&lt;br /&gt;
built in succession.  This is necessary because the Gambit system is bootstrapped&lt;br /&gt;
with itself, and to compile the runtime system for a specific version the Gambit&lt;br /&gt;
compiler for that version must be used.  If for some reason you need to do this&lt;br /&gt;
manually the following procedure should be used.  Assuming the local copy is currently&lt;br /&gt;
at release v1.2.3 and that v1.2.5 is the most recent release, do this:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
git checkout v1.2.4-bootstrap&lt;br /&gt;
make bootstrap&lt;br /&gt;
git checkout v1.2.4&lt;br /&gt;
make bootclean bootstrap&lt;br /&gt;
git checkout v1.2.5-bootstrap&lt;br /&gt;
make bootstrap&lt;br /&gt;
git checkout v1.2.5&lt;br /&gt;
make bootclean bootstrap&lt;br /&gt;
git checkout master&lt;br /&gt;
make bootstrap&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Note that the latest source code may be unstable.  It is wise to check&lt;br /&gt;
that it passes basic consistency checks by running the command '''make check'''.&lt;br /&gt;
&lt;br /&gt;
The local source code files can be updated to a specific version&lt;br /&gt;
with the '''git checkout'''  command.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
git checkout v4.2.1&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
After this command it is not possible to build Gambit with&lt;br /&gt;
a '''make''' because the local '''gsc-comp''' is not the appropriate&lt;br /&gt;
version to compile the runtime system.  One way around this problem&lt;br /&gt;
is to download the release for that version in a different directory, do a&lt;br /&gt;
'''make bootstrap''' in that directory, and then copy '''gsc-comp'''&lt;br /&gt;
back here.&lt;br /&gt;
&lt;br /&gt;
==== Creating a commit ====&lt;br /&gt;
&lt;br /&gt;
A source code change may simply be modifications of existing&lt;br /&gt;
files, deletions, and addition of new files.&lt;br /&gt;
If a new file has been created git should be informed by entering:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
git add newfile&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
After making a set of related changes it is customary to review which files have changed&lt;br /&gt;
by executing the command:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
make status&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If all checks out, a commit is created with the command:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
make commit&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This command will pop up an editor to compose a comment describing the nature of the patch.&lt;br /&gt;
Please use a short but descriptive comment on the first line of text entered.&lt;br /&gt;
&lt;br /&gt;
To get a list of the commits (starting with the latest, i.e. the '''HEAD''') use:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
make log&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Contributing a patch ====&lt;br /&gt;
&lt;br /&gt;
A patch file can be created using the '''git diff''' command.  To include only the&lt;br /&gt;
most recent commit use:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
git format-patch -1&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
A range of patches can be specified like this:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
git format-patch -4 HEAD~3&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The patch file(s) can then be submitted to the Gambit maintainers&lt;br /&gt;
by sending the file by email to '''gambit@iro.umontreal.ca'''.  For example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
mail -s &amp;quot;[PATCH] ,b command fix&amp;quot; gambit@iro.umontreal.ca &amp;lt; my-patch&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Releasing a new version of Gambit ====&lt;br /&gt;
&lt;br /&gt;
This section contains some notes for the Gambit maintainers.  It explains the steps to follow to release a new version of Gambit.  '''The steps must be followed carefully or you may end up with a wedged system!'''&lt;br /&gt;
&lt;br /&gt;
===== Manual procedure =====&lt;br /&gt;
&lt;br /&gt;
Assume the latest release of Gambit is v1.2.3 and the new release will be v4.5.6.&lt;br /&gt;
Because Gambit is bootstrapped with itself, releasing a new version of Gambit is a two step process.&lt;br /&gt;
The Gambit compiler must first be modified so that it generates C code which references the '''gambit.h''' file version v4.5.6.&lt;br /&gt;
Then the '''gambit.h''' file, '''configure.ac''' file, and other files with an embedded version number must be updated so they refer to version v4.5.6.&lt;br /&gt;
&lt;br /&gt;
'''1. Creating a Gambit compiler for version v4.5.6'''&lt;br /&gt;
&lt;br /&gt;
Make sure you have a working bootstrap compiler ('''gsc-comp''') and save a copy just in case:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
make check&lt;br /&gt;
make bootstrap&lt;br /&gt;
cp gsc-comp gsc-comp.old&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Now modify the definition of '''compiler-version''' in the file '''gsc/_parms.scm''' so that it refers to v4.5.6 (using a single integer encoding of the version number):&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(define (compiler-version) 405006) ;; 100000*major + 1000*minor + revision&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Now create the new bootstrap compiler and commit the change with an easily identifiable comment:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
make bootstrap&lt;br /&gt;
git commit -a -m &amp;quot;[COMPILER CHANGES NEEDED FOR v4.5.6] Changed version in compiler&amp;quot;&lt;br /&gt;
git tag v4.5.6-bootstrap&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Note that at this very point the new compiler will not pass the tests because the runtime still expects the old version number.&lt;br /&gt;
&lt;br /&gt;
'''2. Upgrading the runtime files from version v1.2.3 to v4.5.6'''&lt;br /&gt;
&lt;br /&gt;
For the C files generated from Scheme files the version numbers can easily be upgraded by compiling them from scratch using the new Gambit compiler.&lt;br /&gt;
This will be done automatically by a '''make''' after a '''make bootclean'''.  The other changes to the files are made by running the script '''misc/changev''' (this must be done first because it changes the file '''configure.ac''' which produces the '''configure''' script which must be run again).&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
misc/changev 102003 405006&lt;br /&gt;
make bootclean&lt;br /&gt;
./configure&lt;br /&gt;
make&lt;br /&gt;
make check   # will fail test5 because version numbers have changed&lt;br /&gt;
mv tests/mix.c tests/test5.ok&lt;br /&gt;
make check   # this time all tests should pass&lt;br /&gt;
git commit -a -m &amp;quot;[RUNTIME CHANGES NEEDED FOR v4.5.6] Changed version of runtime using misc/changev&amp;quot;&lt;br /&gt;
git tag v4.5.6&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''3. Creating prebuilt installers for version v4.5.6'''&lt;br /&gt;
&lt;br /&gt;
To create prebuilt installers for Mac OS and Windows you need a Mac with Xcode and Parallels workstation with Windows and the MinGW and Microsoft Visual C Express environments.  The following command will build all variants of the installers (it takes about 2 hours in total):&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
make release&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If no errors were reported then you can upload the new release to the Gambit repository using:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
make publish-release&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will automatically send an announcement on the Gambit mailing list.  You must manually update the main page of the Gambit Wiki so that it refers to the latest version.&lt;br /&gt;
&lt;br /&gt;
===== Automated procedure =====&lt;br /&gt;
&lt;br /&gt;
Step 1 and 2 in the above instructions are executed with the '''change-version''' make target:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
make NEW_VERSION=v4.5.6 change-version&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Alternatively, the '''new-revision''', '''new-minor''', or '''new-major''' make targets can be used&lt;br /&gt;
to compute the new version number from the current version by incrementing one&lt;br /&gt;
of the version number fields:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
make new-revision&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Troubleshooting ====&lt;br /&gt;
&lt;br /&gt;
A user was having trouble using trouble building an up-to-date version of Gambit starting from v4.3.2.  '''make update''' was failing.  Marc Feeley responded with an explanation and a solution.&lt;br /&gt;
&lt;br /&gt;
The solution is to download the latest version of Gambit and use that to run the '''make update''' in the git repository.&lt;br /&gt;
&lt;br /&gt;
Here's the [http://article.gmane.org/gmane.lisp.scheme.gambit/4399 reply]:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;blockquote&amp;gt;&lt;br /&gt;
Let me explain the problem.  If you're only interested in a solution: get v4.6.0 and a make update from that.&lt;br /&gt;
&amp;lt;/blockquote&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;blockquote&amp;gt;&lt;br /&gt;
Gambit is a self-hosting compiler.  That means that it is bootstrapped using itself.  Most of the system is&lt;br /&gt;
implemented in Scheme (not just the libraries, but the compiler itself).  So when a change is made in the&lt;br /&gt;
compiler's source code, it must be compiled with the current version of the compiler.  Roughly speaking,&lt;br /&gt;
version 2 must be compiled with version 1.  Then when changes are made (to get the source code of version 3),&lt;br /&gt;
then version 3 must be compiled with version 2.  And so on.  When you &amp;quot;make update&amp;quot; the build process executes&lt;br /&gt;
the chain of self compilations that led to the most recent version of Gambit.  In other words, if the most&lt;br /&gt;
recent Gambit is v4 and you currently have v1 installed, then the &amp;quot;make update&amp;quot; will: compile the v2 source&lt;br /&gt;
with the v1 executable to get the v2 executable, then it will compile the v3 source with the v2 executable to&lt;br /&gt;
get the v3 executable, and finally compile the v4 source with the v3 executable to get the v4 executable. &lt;br /&gt;
This chain must be followed because features that are used in the source code of the most recent version of&lt;br /&gt;
the compiler may have appeared (i.e. were implemented) in an intermediate version of the compiler.&lt;br /&gt;
&amp;lt;/blockquote&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;blockquote&amp;gt;&lt;br /&gt;
This self dependency is not easy to handle in the build process and makefiles, and currently there is a bug. &lt;br /&gt;
In your particular case, Gambit v4.3.2 does not support the same command line options as more recent&lt;br /&gt;
version of Gambit.  So somewhere in this chain of commits, the makefiles were not consistent with the then&lt;br /&gt;
current compiler.  But because the commits can't be &amp;quot;taken back&amp;quot; the self compilation sequence that &amp;quot;make&lt;br /&gt;
update&amp;quot; executes has some version transitions that will forever be broken.  I haven't looked into ways&lt;br /&gt;
(automatic tool, or better version changing habits) to avoid this problem in the future.&lt;br /&gt;
&amp;lt;/blockquote&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Category: Development]]&lt;/div&gt;</summary>
		<author><name>Pipping</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Talk:Programming_language_shootout:_mandelbrot</id>
		<title>Talk:Programming language shootout: mandelbrot</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Talk:Programming_language_shootout:_mandelbrot"/>
				<updated>2008-09-03T03:38:57Z</updated>
		
		<summary type="html">&lt;p&gt;Pipping: New page: The invocation should probably be    gsi -:m10000 mandelbrot 3000 &amp;gt; output.pbm  instead of    gsi mandelbrot -:m10000 3000 &amp;gt; output.pbm  since the latter passes -:m10000 to main() instead ...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The invocation should probably be&lt;br /&gt;
&lt;br /&gt;
  gsi -:m10000 mandelbrot 3000 &amp;gt; output.pbm&lt;br /&gt;
&lt;br /&gt;
instead of&lt;br /&gt;
&lt;br /&gt;
  gsi mandelbrot -:m10000 3000 &amp;gt; output.pbm&lt;br /&gt;
&lt;br /&gt;
since the latter passes -:m10000 to main() instead of gsi, yielding&lt;br /&gt;
&lt;br /&gt;
  *** ERROR -- Wrong number of arguments passed to procedure&lt;br /&gt;
  (main &amp;quot;-:m10000&amp;quot; &amp;quot;3000&amp;quot;)&lt;br /&gt;
&lt;br /&gt;
[[User:Pipping|Pipping]] 23:38, 2 September 2008 (EDT)&lt;/div&gt;</summary>
		<author><name>Pipping</name></author>	</entry>

	<entry>
		<id>http://dynamo.iro.umontreal.ca/wiki/index.php/Wish_list</id>
		<title>Wish list</title>
		<link rel="alternate" type="text/html" href="http://dynamo.iro.umontreal.ca/wiki/index.php/Wish_list"/>
				<updated>2008-08-20T00:42:22Z</updated>
		
		<summary type="html">&lt;p&gt;Pipping: /* Support for R6RS */ note regarding licenses&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This page lists suggestions for new features.  We hope it will be useful for brainstorming by the user&lt;br /&gt;
community to help direct the further development of Gambit.  Suggestions should include a&lt;br /&gt;
description of the feature and a motivation.&lt;br /&gt;
&lt;br /&gt;
====Support for long (&amp;gt; 8192) lists in apply====&lt;br /&gt;
&lt;br /&gt;
Even if it has to be slow for large lists, it would be preferable to having to change the way you code for certain applications.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Delimited continuations====&lt;br /&gt;
&lt;br /&gt;
Would allow creating continuations that&lt;br /&gt;
don't capture the current-input/output-ports and are serializable (useful for Termite,&lt;br /&gt;
web-continuations, etc).&lt;br /&gt;
&lt;br /&gt;
====Integration of Termite with Snow====&lt;br /&gt;
&lt;br /&gt;
Handle namespaces, provide null (single threaded) implementations of more general operations (pmap, mapreduce etc) for other hosts.&lt;br /&gt;
&lt;br /&gt;
====Multiple Processes on Multiple Cores====&lt;br /&gt;
&lt;br /&gt;
Automate the creation of nodes on the same machine to allow simpler use of multiple cores from within Termite (ie more like Erlang).  This should also load the correct environment.&lt;br /&gt;
&lt;br /&gt;
====Real Time and Generational Garbage Collection====&lt;br /&gt;
&lt;br /&gt;
Support multiple garbage collection strategies. Ideally garbage collection strategy could be decided at runtime but implementation details may force that decision to be specified at build time.&lt;br /&gt;
&lt;br /&gt;
====Support for R6RS====&lt;br /&gt;
&lt;br /&gt;
Support for running [[R6RS]] programs would be really useful and make it much easier to share code with other implementations (which promised to be R6RS compliant soon).&lt;br /&gt;
&lt;br /&gt;
While there are many things I don't like about R6RS, I would like to see the macro and module system integrated into Gambit, specifically so that Meroon can be rewritten to use these features.  I think Meroon is in a design space sweet spot, and with Meroon's close integration into the Gambit runtime, a better macro/module implementation would make it quite appealing.  Perhaps Gambit could use Andre van Tonder's implementation, but I haven't yet looked at the license.  (Brad Lucier)&lt;br /&gt;
&lt;br /&gt;
Regarding the [http://www.het.brown.edu/people/andre/macros/index.html implementation] mentioned above, there are two relevant licenses: [http://www.het.brown.edu/people/andre/macros/implementation/version%202.2%20(libraries)/simple-macros.scm this] file carries the [http://www.opensource.org/licenses/mit-license.php MIT license], whereas [http://www.het.brown.edu/people/andre/macros/implementation/version%202.2%20(libraries)/simple-syntax-case.scm this] file carries the [http://www.opensource.org/licenses/bsd-license.php BSD license]. (Elias Pipping)&lt;br /&gt;
&lt;br /&gt;
====FFI Improvement====&lt;br /&gt;
&lt;br /&gt;
Better and higher level support for the foreign function interface for C/C++. This could include some easy ways to create struct/class objects, easy way to access their inner elements, simple foreign struct/class declaration, etc...&lt;br /&gt;
&lt;br /&gt;
Also, a simplification of the Gambit-&amp;gt;C and C-&amp;gt;Gambit type translation process. Instead of having to define some very low level C macros, it would be interesting to have a simplified form which could cover most usage of such type translations and speed up the developpement process.&lt;br /&gt;
&lt;br /&gt;
It would be nice to be able to pass SRFI-4 style vectors as float*, int*, etc.&lt;br /&gt;
&lt;br /&gt;
====Better debugger support for locally bound procedures====&lt;br /&gt;
&lt;br /&gt;
When displaying a procedure, Gambit's debugger already scans all the global variables to try and find one that is bound to that procedure so it can display the variable's name instead of just a generic #&amp;lt;procedure&amp;gt;. This is very usefull but it would be nice to have a similar mecanism for locally bound procedures (internal define, named let, ...).&lt;br /&gt;
&lt;br /&gt;
====Native / pre-emptive threads====&lt;br /&gt;
&lt;br /&gt;
Given the fact that the world is moving from faster processors to parallel processing, I believe that support for true native threads is increasingly critical.  Eventually, no programming environment will survive that doesn't support native threads.  Support for multiple processes is good but pales in comparison to light weight, native, pre-emptive thread support.  PThreads would be a good, portable way to go here.&lt;br /&gt;
&lt;br /&gt;
====Continued support for the Windows environment====&lt;br /&gt;
&lt;br /&gt;
Few programmers like Windows less than I do.  However, Windows is in fact an environment we have to deal with.  Continued and native (Microsoft C) support enables programmers to use Linux at home and Windows at work.  If Windows is not supported then none of the cool stuff developed at home can be used at work thus reducing the excitement and usefulness of developing cool stuff at home.&lt;br /&gt;
&lt;br /&gt;
====Better Documentation of Compiler and Runtime Internals====&lt;br /&gt;
&lt;br /&gt;
The source code needs to be documented more thoroughly if Gambit is to thrive as an open-source project.  This is something a lot of people could work on, but Marc would probably need to do most of the work for the compiler.&lt;br /&gt;
&lt;br /&gt;
====Code-anlaysis tools====&lt;br /&gt;
&lt;br /&gt;
A call-graph printer, for example, would make the system sources much easier to understand and change.  It might also speed up the work of writing documentation (as mentioned above).  Ideally the compiler is already doing this kind of analysis and the data just needs to be printed out.&lt;br /&gt;
&lt;br /&gt;
====Identify and Implement Important Optimizations====&lt;br /&gt;
&lt;br /&gt;
=====More inline expansions=====&lt;br /&gt;
Inline expansion and run-time bindings have proved very effective compilation strategies for standard functions.  Perhaps the majority of the work has been done, but there are still opportunities to be identified and implemented (e.g., eqv?, read-char, and write-char for starters).  Two-list map is common enough that it should be inlined, as one-list map already is.&lt;br /&gt;
&lt;br /&gt;
=====Efficient compilation of quasiquote=====&lt;br /&gt;
Right now, any use of quasiquotation results in calls to the built-in routines ##quasi-cons, ##quasi-list, ##quasi-list-&amp;gt;vector, etc.  When I changed&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(define (make-node left val right) `#(node ,left ,val ,right))&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
to&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
(define (make-node left val right) (vector 'node left val right))&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
in the Ikarus version of the alioth binary trees benchmark, for example, and compiled the code with Gambit, the run time went from 40 seconds to 8 seconds.  Runtimes shouldn't depend so much on different ways of doing the same thing.&lt;br /&gt;
&lt;br /&gt;
(48 hours later.)  This should be fixed by checkin 95.  That was fast!&lt;br /&gt;
&lt;br /&gt;
=====Faster unsafe numerical inline expansions=====&lt;br /&gt;
The last operation in the unfolded code for (op x1 x2 x3 ...) when (declare (not safe)) should be a call to ##op, not op.&lt;br /&gt;
&lt;br /&gt;
=====Deforestation=====&lt;br /&gt;
A pass to eliminate code generation for unused intermediate structures (cons cells, small vector, ...).&lt;br /&gt;
&lt;br /&gt;
====Implement SRFI-63====&lt;br /&gt;
[http://srfi.schemers.org/srfi-63/srfi-63.html SRFI 63, &amp;quot;Homogeneous and Heterogeneous Arrays&amp;quot;], is the latest in the evolution of strongly-typed multidimensional array/matrix types in scheme, superseding SRFI-47  and including all SRFI-4 data types. Gambit already provides SRFI-4 support for homogeneous arrays; this would add on a few new types and allow for multidimensional operations. Coupled with the FFI, it might make it easy to link with BLAS/LAPACK and other optimized numeric libraries to allow gambit to be a first-class numerical processing and data analysis environment.&lt;br /&gt;
&lt;br /&gt;
====Graphical Extensions====&lt;br /&gt;
* Support for any kind of graphical library, low level like X, or high level like SDL, in order to generate pictures or animations.&lt;br /&gt;
* Graphical external representation of data structures, with boxes and arrows, à la UML, or like some graphical debuggers. Useful to represent trees, cyclic data structure, and for debugging too.&lt;br /&gt;
&lt;br /&gt;
====Error-free loading====&lt;br /&gt;
The possibility to load or include a file, without having any error when the file can't be read or does not exist.&lt;br /&gt;
 (unsafe-include &amp;quot;/path/to/inexistant.file&amp;quot;) &lt;br /&gt;
would just return #f, or not be expanded, or even better&lt;br /&gt;
 (include-with-exception-handler&lt;br /&gt;
   (lambda (err)&lt;br /&gt;
     (cond ...))&lt;br /&gt;
   &amp;quot;/path/to/file&amp;quot;)&lt;br /&gt;
&lt;br /&gt;
====Tying Data and files====&lt;br /&gt;
The ability to tie some data structure to a file would be greatly appreciated. For example,&lt;br /&gt;
 (define h (make-tied-hash &amp;quot;/tmp/myhash.scm&amp;quot;))&lt;br /&gt;
 (tied-hash-set! h 'foo 42)&lt;br /&gt;
 ^D&lt;br /&gt;
&lt;br /&gt;
 cat /tmp/myhash.scm&lt;br /&gt;
 foo =&amp;gt; 42&lt;br /&gt;
or a binary format or it could even dump its own code...&lt;br /&gt;
&lt;br /&gt;
And since we have procedures serialisation thanks to termite, functions too could be tied....&lt;br /&gt;
&lt;br /&gt;
The aim is to simplify file managing, when reading/writing data stored in S-exprs, such as a config file or else...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====TCP/IP interpreter====&lt;br /&gt;
Couldn't we run a session of the interpreter on a socket/pipe ?&lt;br /&gt;
It would enable calling gambit easily from other programs, from scripts, etc.&lt;br /&gt;
It could use several connexions for default input/ouput ports and result port, or reply with answers like &lt;br /&gt;
 (STDOUT 42) (STDERR &amp;quot;hello&amp;quot;) (VALUE 3.141592)&lt;br /&gt;
meaning that it wrote 42 on the standard output (with DISPLAY), the string hello on the standard error (with PP) and that the value returned by the call was π.&lt;br /&gt;
&lt;br /&gt;
====Better communication with the IDE====&lt;br /&gt;
Most of the Emacs &amp;quot;shell&amp;quot; packages for LISP and Scheme, and the Eclipse plugins, and specialized self-contained programs like GUIDE, work by creating ordinary UNIX streams between the IDE and the interpreter.&lt;br /&gt;
As a result neither side is very aware of what the other side is doing, and the IDE has to guess many things about the state of the interpreter like the locations of prompts and the syntax of the language.&lt;br /&gt;
It would be great to see a Gambit IDE moving beyond the UNIX stream idea.  That can be done in many ways.  SLIME uses streams of events or messages.  CLIM uses even fancier streams which may contain complex objects, which may update any part of a display of output instead of just adding to it, and which allow input to be edited and reread without much work by the REPL.&lt;br /&gt;
&lt;br /&gt;
Emacs LISP, MIT Scheme, Portable Hemlock, and Climacs make editor buffers as easily available as streams are on UNIX.  PLT Scheme has editor buffers, and controls the window organization (some buffers and a REPL are grouped together in a window) and limits the actions of the REPL to prevent side effects.  None of these systems deal with the problem of separate REPL and interpreter processes, however.&lt;br /&gt;
&lt;br /&gt;
A Gambit IDE might use TCP ports as described in the section above.  It might use a SLIME backend, as described on [[GSoC ideas list]].  Perhaps with enough work, &amp;lt;code&amp;gt;gambit.el&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;_repl.scm&amp;lt;/code&amp;gt; could be extended together to accomplish something similar to SLIME.  In any case the reader also could use some redesign.  It works only with input streams, not groups of streams like stdin/stdout/stderr, so for example the reader can't tell the REPL anything about its state or the characters it has read.  Making new port types and operations, and changing the reader in a few places to use the new operations, might be best since old code would work unchanged.&lt;br /&gt;
&lt;br /&gt;
A new IDE design could lead to useful new features:&lt;br /&gt;
* Completion of symbol names could be done even with the REPL and interpreter in different processes.&lt;br /&gt;
* Syntax-based editing, enforcing correct use of comma commands (which must come outside of code), and similar things would always be correct.&lt;br /&gt;
* The input history could be divided into forms and commands (which is what the interpreter really cares about) rather than lines.&lt;br /&gt;
* The REPL transcripts, backtraces, etc. shown in the editor would keep their structure (given by the interpreter).  You could navigate around them, and copy or re-evaluate pieces of code from them.  You could separate the display style from the contents.&lt;br /&gt;
* Then, for example, you could have the current state of your session (with multiple REPL levels, backtraces, environments, etc.) nicely organized in a series of windows.  The stepper and tracer would be available from menus and not just keyboard commands.  Ideally you could see many more details about the session than you can now, quickly and without being overwhelmed.&lt;br /&gt;
* Parse errors could put the cursor back in the input, making re-editing quicker.&lt;br /&gt;
* If the design was implemented well, it would include library functions that new tools could use.&lt;br /&gt;
Perhaps each feature doesn't sound essential, but I believe they would be very useful together.  They are also difficult or impossible to implement with the current design.&lt;br /&gt;
&lt;br /&gt;
====UDP Ports====&lt;br /&gt;
It would be nice to also be able to use UDP ports in gambit.&lt;/div&gt;</summary>
		<author><name>Pipping</name></author>	</entry>

	</feed>