ZipPy is a work in progress Python 3 implementation as one of the Truffle languages. It currently borrows the same project setup as FastR, in which the guest language code is managed in its own repository splitting ZipPy and Graal in two different repositories. This arrangement is made possible by
Because of the commonalities on project setup, this introduction borrows materials from the FastR.
ZipPy is developed and tested on Mac OS X (10.11/10.10). Building on Windows is currently not supported.
To build and run ZipPy, you need a Latest JDK 8 and a C/C++ compiler tool chain. You also need to use the
mx) build tool, which is used in all projects built around Graal.
mx requires Python 2.7 (not exactly ZipPy at this point...).
git clone https://github.com/graalvm/mx.git
- Append the
mxdirectory to your
ZipPy requires Graal.
Both projects are hosted in different repositories.
To obtain both, use the multiple-repository support in
mx, create a directory, e.g.,
r, that serves as the project root. We will refer to this as
$ZIPPY_HOME in what follows.
$ cd $ZIPPY_HOME $ mx -v sclone https://bitbucket.org/ssllab/zippy
After this, you should find two directories called
graal in the project root. Note that the
-v is optional, and shows the actual
hg commands being invoked by
mx. Note that mx first downloaded
zippy and then, using the information in the
mx.zippy/imports file, downloaded a specific revision of Graal.
If you are using Java 8 to build, you should create a file
$ZIPPY_HOME/zippy/mx.zippy/env and add the following line of text:
JAVA_HOME=<path to Java 8 home> DEFAULT_VM=jvmci
With an existing ZipPy checkout
If your starting point is an existing checkout of ZipPy, please refer to the following steps.
First make sure that you have
mx installed (refer to the section above to installed it).
Pick or create a project directory referred as
$ZIPPY_HOME (not the actual name, name it as you want) and move your ZipPy checkout to
This is necessary because
mx's default suite model is sibling model, which means that imported suites are placed with the primary suite under the same directory (
$ZIPPY_HOME). It is better to keep the entire project in its own directory (
Download imported suites:
$ cd $ZIPPY_HOME/zippy $ mx spull
Now you should have
jvmci under the project root.
Alternatively you can also use the
--primary-suite-path option to specify the path of
$ cd $ZIPPY_HOME $ mx -v --primary-suite-path zippy spull
If everything looks good at this point, you should be able to move on to the building step.
More about mx
mx manages software in suites, which are normally one-to-one with a Mercurial repository.
One suite is always designated as the primary suite, which in this case is
mx to your
PATH is to make it more accessible in the command line. If you prefer not to do so, you can of course specify its full path when firing a
For more information about
mx please refer to the mx.
To build a suite and the suites it depends on, the
mx build command is used:
$ cd zippy $ mx build
When building for the first time, the build script will prompt you for a VM configuration to build.
In general, choosing the
jvmci configuration is advised.
For details, see Graal Instructions.
The first build will also download various required libraries, so there must be a network connection.
After building, running ZipPy can be done with
$ mx python <file.py>
Sadly, interactive shell and many of the CPython command line options are not yet implemented...
edu.uci.python.test includes a set of tests that we currently use. The
mx unittest command runs all JUnit test it can find in the current suite. The following command runs all the unit tests with their class paths matching the pattern,
$ mx unittest python.test
Benchmarks are located in the subproject
zippy/benchmark. One can use the
mx python command to run each benchmark separately.
Yes we need help to push the completeness of ZipPy!
No lawyer BS. Simply raise an issue or submit a pull request when you feel like to.
Wei Zhang, Twitter, Inc.
Mohaned Qunaibit, University of California Irvine