initial upload of open-source release

BUILDING

@@ -0,0 +1,248 @@
+Building Chez Scheme Version 9.4
+Copyright 1984-2016 Cisco Systems, Inc.
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+
+----------------------------------------------------------------------------
+
+This directory contains the sources for Chez Scheme, plus boot and header
+files for various supported machine types.
+
+BASICS
+
+Building and installing Chez Scheme on a recent version of Linux or OS X
+is typically as simple as installing the prerequisites listed below and
+running (Windows build instructions appear under the heading WINDOWS
+later in this file):
+
+./configure
+sudo make install
+
+This should not take more than a minute or so, after which the commands
+'scheme' and 'petite' can be used to run Chez Scheme and Petite Chez
+Scheme, while 'man scheme' and 'man petite' can be used to view the
+manual pages.  Chez Scheme and Petite Chez Scheme are terminal-based
+programs, not GUIs.  They both incorporate sophisticated command-line
+editing reminiscent of tcsh but with support for expressions that span
+multiple lines.
+
+Prerequisites:
+
+* GNU Make
+* gcc
+* Header files and libraries for ncurses
+* Header files and libraries for X windows
+
+DETAILS
+
+The sources for Chez Scheme come in two parts:
+
+* A set of Scheme source files found in the subdirectory s.  Compiling
+  these produces the boot files petite.boot and scheme.boot, along with
+  two header files, equates.h and scheme.h.
+
+* A set of C source files found in the subdirectory c.  Compiling and
+  linking these files produces the executable scheme (scheme.exe under
+  Windows).  Compiling the C sources requires the two header files
+  produced by compiling the Scheme sources.
+
+Since the Scheme sources can be compiled only by a working version of
+Chez Scheme, it's not actually possible to build Chez Scheme from source.
+That's why the boot and header files are packaged with the sources.
+
+'./configure' attempts to determine what type of machine it's on and,
+if successful, creates several files and directories:
+
+* The directory nanopass containing the Nanopass Infrastructure,
+  retrieved from github.
+
+* A make file, Makefile, in the root (top level) directory.
+
+* A "workarea", or subdirectory named for the machine type (e.g.,
+  a6le for nonthreaded 64-bit linux).  The workarea is a mirror of
+  the root directory, with subdirectories named c, s, and so on.
+  Compilation takes place in the workarea.
+
+* Within the workarea, the files Makefile, Mf-install, and Mf-boot.
+
+'./configure' supports various options, among which is --help, which
+can be used to list the supported options.
+
+The make file supports several targets:
+
+'make' or 'make build'
+  compiles and links the C sources to produce the executable, then
+  bootstraps the Scheme sources.  Bootstrapping involves using the
+  freshly built scheme executable along with the distributed boot files
+  to compile the Scheme sources.  If the new boot files are equivalent
+  to the old boot files, the system is bootstrapped.  Otherwise, the new
+  boot files are used to create a newer set, and those are compared.
+  If this succeeds, the system is bootstrapped.  Otherwise, the make
+  fails.  This should not fail unless the distributed boot files are
+  out of sync with the sources.
+
+  To run Chez Scheme without installing, you need to tell the executable
+  where to find the boot files.  This can be done via command-line
+  arguments, e.g.:
+
+    $W/bin/$M/scheme -b $W/boot/$M/petite.boot -b $W/boot/$M/scheme.boot
+
+  or by setting the SCHEMEHEAPDIRS variable to point to the directory
+  containing the boot files.  For example, in bash:
+
+    SCHEMEHEAPDIRS=$W/boot/$M $W/bin/$M/scheme
+
+  and in tcsh:
+
+    setenv SCHEMEHEAPDIRS "$W/boot/$M"
+    $W/bin/$M/scheme
+
+  In all cases, $W should be replaced with the name of the workarea,
+  and $M should be replaced with the machine type.  (Unless the default
+  is overridden via an argument to ./configure, $W is the same as $M.)
+
+'sudo make install'
+  runs the build plus installs the resulting executable, boot files,
+  example files, and manual pages.
+
+'make test'
+  runs the build plus runs a set of test programs in various different
+  ways, e.g., with different compiler options.  It can take 30 minutes
+  or more, depending on the speed of the machine.  It produces voluminous
+  output, so it's best to redirect its stdout and stderr to a file.
+
+  NB: A complete run does not imply no errors occurred.  To check for
+  errors, look at the file $W/mats/summary, where $W is the name of the
+  workarea created by ./configure.  $W/mats/summary should contain one
+  line per test run, something like this:
+
+  -------- o=0 --------
+  -------- o=3 --------
+  -------- o=0 cp0=t --------
+  -------- o=3 cp0=t --------
+  -------- o=0 spi=t p=t --------
+  -------- o=3 spi=t p=t --------
+  -------- o=0 eval=interpret --------
+  -------- o=3 eval=interpret --------
+  -------- o=0 cp0=t eval=interpret --------
+  -------- o=3 cp0=t eval=interpret --------
+  -------- o=0 ehc=t eoc=f --------
+  -------- o=3 ehc=t eval=interpret --------
+
+  If there is anything else in $W/mats/summary, something unexpected
+  occurred.
+
+'make bootfiles'
+  runs the build plus uses the locally built system to recreate the
+  distributed boot and header files for each supported machine type.
+  It should be run whenever modifications made to the Scheme sources
+  are to be committed to the source-code repository so that up-to-date
+  boot and header files can be committed as well.  'make bootfiles'
+  can take 5 minutes or more.
+
+'make clean'
+  removes binaries from the workarea.
+
+'make distclean'
+  removes nanopass, Makefile, and all workareas.
+
+WINDOWS
+
+Building Chez Scheme under Windows is currently more complicated than it
+should be.  It requires the configure script (and through it, the workarea
+script) to be run on a host system that supports a compatible shell,
+e.g., bash, and the various command-line tools employed by configure
+and workarea, e.g., sed and ln.  For example, the host system could be a
+Linux or MacOS X machine.  The release directory must be made available
+on a shared filesystem, e.g., samba, to a build machine running Windows.
+It is not presently possible to copy the release directory to a Windows
+filesystem due to the use of symbolic links.
+
+Prerequisite:
+
+The Microsoft Visual C compiler (express or full) and associated
+tools must be available on the Windows build machine, and the PATH,
+INCLUDE, and LIB variables must be set up properly for those tools.
+
+Between the configure and build steps (below), the 32-bit or 64-bit
+(as appropriate) C runtime library vcruntime$V.dll must be placed into
+$W/bin/$M with a symbolic link to or copy of the file in $W/bin, where
+$V is the expected C runtime version for the installed Visual C compiler
+(e.g., 140 for Visual Studio 2015), $W is the workarea name, and $M is
+the machine type.
+
+Configure step (host machine):
+
+To configure the build, run:
+
+./configure -m=$M
+
+where $M is replaced with one of the Windows machine types, i.e.,
+i3nt for 32-bit, a6nt for 64-bit, ti3nt for threaded 32-bit, and
+ta6nt for 64-bit threaded.
+
+Build step (Windows build machine):
+
+To build the executable $W\bin\$M\scheme.exe, run:
+
+nmake -f Makefile.i3nt 
+
+in the directory $W\c, then recompile the Scheme sources via:
+
+bldnt $M
+
+in the directory $W/c, where $W is replaced by the name of the
+workarea created by ./configure, and $M is the machine type.
+
+To run Chez Scheme or Petite Chez Scheme from a terminal window,
+set PATH and SCHEMEHEAPDIRS:
+
+set PATH=$W\bin\$M;%PATH%
+set SCHEMEHEAPDIRS=$W/boot/$M
+
+again with $W and $M replaced with the workarea name and machine
+type, and start Chez Scheme with the command "scheme" or Petite
+Chez with the command "petite".
+
+Chez Scheme and Petite Chez Scheme are terminal-based programs,
+not GUIs.  They both incorporate sophisticated command-line editing
+reminiscent of tcsh but with support for expressions that span
+multiple lines.
+
+Testing under Windows
+
+The iconv tests in mats/io.ms require that a 32-bit or 64-bit (as
+appropriate) libiconv-2.dll implementing GNU libiconv be located in
+$W/bin/$M with a symbolic link to or copy of the file in $W/bin, where
+$W and $M are the workarea name and machine type.  Windows sources for
+libiconv can be found at:
+
+http://gnuwin32.sourceforge.net/packages/libiconv.htm
+
+If the dlls are not present, the iconv tests will fail.  No other
+tests should be affected.
+
+The tests can be run with a default set of options at a single
+optimize level by running the command:
+
+bldnt $M $O
+
+in $W/mats, with $W and $M replaced with the workarea name and
+machine type and $O replaced by an optimize level, e.g., 0 or 3.
+This produces a set of output (.mo) files in the directory
+$W/mats/output-compile-$O-f-f-f.  "make fastreport o=$O" can be
+then used to generate a report; this step must be run on a host
+system supporting GNU make and the various tools required by the
+fastreport target, e.g., grep.  The resulting report file
+$W/mats/report-compile-$O-f-f-f should be empty if all tests
+succeeded.

CHARTER.md

@@ -0,0 +1,55 @@
+# Chez Scheme Project Charter (the “Charter”)
+
+This Charter sets forth the responsibilities and procedures for
+technical contribution to, and oversight of, the Chez Scheme Project
+(the “Project”).  Participation in the Project is open to all in a
+fair, reasonable, and non-discriminatory manner.  Contributors to
+the Project must comply with the terms of this Charter.
+
+1. Governance
+   * The Project will involve Contributors and Committers.
+     Contributors include anyone in the technical community who
+     contributes code, documentation, or other technical artifacts
+     to the Project.  Committers are Contributors who have the
+     ability to commit code directly to the Project’s main branch
+     or repository.
+   * The Committers shall be responsible for technical oversight
+     and other decision making of the Project.  The Committers will
+     seek to make decisions by consensus.  Except where otherwise
+     specified below, if a consensus cannot be reached, Project
+     decisions shall be made by a two-thirds vote of the Committers.
+   * A unanimous vote of the Committers shall be required for any
+     change or amendment to this Charter.
+
+2. Technical Policy
+   * Any Committer may review a pull request and accept, reject,
+     or solicit modifications to the request, at the Committer’s
+     sole discretion.  For changes that might be highly impactful
+     or controversial, Committers are encouraged, but not required,
+     to seek consensus from the other Committers before proceeding.
+     Committers are not required to respond to every pull request,
+     but shall make reasonable efforts to do so.
+   * Any existing Committer may nominate a Contributor with the
+     demonstrated experience, knowledge, and commitment to the
+     Project to become a new Committer.  A nominee can become a
+     Committer only by a unanimous vote of the existing Committers.
+   * Any Committer may resign at any time by giving notice to the
+     other Committers.  Any Committer may also be removed at any
+     time by a unanimous vote of the other Committers.
+
+3. Intellectual Property Policy
+   * All new inbound code contributions to the Project shall be
+     made under the [Apache 2.0 license]
+     (http://www.apache.org/licenses/LICENSE-2.0).
+   * By submitting a contribution, a Contributor certifies that
+     the Contributor is the sole creator of the contribution and/or
+     has the right under all applicable intellectual property laws
+     to provide the contribution to the Project under the terms of
+     the Apache 2.0 license.
+   * If a Contributor wishes to contribute existing source code
+     covered by an open-source license other than Apache 2.0, the
+     Contributor must seek an exception from the Committers.
+     Exceptions shall be approved only by a unanimous vote of the
+     Committers and duly recorded in the file NOTICE.
+   * All outbound code will be made available under the Apache 2.0
+     license.