SPARK Documentation

Running SPARK is fairly simple. Run spark/bin/spark to start the SPARK interpreter. To load a particular module, type:

>>> module modulename

If you want SPARK to automatically load your module on start, use:

spark modulename

You can also pass in command-line arguments to your main: action by using:

spark modulename args

For more detailed information about interacting with the SPARK interpreter, see the SPARK tutorial.

There are also some advanced options you can pass to spark once you are more familiar with the system:

Usage:
        spark [-options] [module] [args...]
   or   spark [-options] -exec script [args...]        
Options:
        -s <file>,     run the interpreter script file
          --script=<file>
        -h, --help      print this help message
        -nomain         ignore "main:" declarations
        -r, --run       use run mode (no command-line interpreter)
        -v, --version   print the current version

The "spark [-options] [module] [args...]" usage allows you to optionally specify a module to load and also pass in command-line arguments to that module. This likely will be the most common way for you to load SPARK. The -exec script usage is an alternate method that is discussed below.

[module]

The name of the SPARK module to load on startup. If this parameter is omitted, SPARK will load using a default module.

[args...]

Any parameters specified after the [module] will be passed to the main: action of that module (if applicable).

-s, --script=<file>

An script file is a list of commands to run in the interpreter when SPARK loads. SPARK will load the [module] (if specified), then run the commands in the script. These commands can be any command the interpreter recognizes (e.g. trace, test, get intentions).

-nomain

SPARK-L files can contain a main: definition that indicates an action/procedure for SPARK to execute on startup. Using this option will tell SPARK to ignore this.

-r, --run

By default, after SPARK loads, it presents the user with a command-line interpreter. If you wish to disable this by using the -r run-mode option.

---

-exec script option:

The -exec script option allows you to pass arguments into an interpreter script without having to specify a module to load. (NOTE: THE ABILITY TO PASS IN ARGUMENTS TO THE INTEPRETER SCRIPT IS NOT IMPLEMENTED YET, SO USE OF THIS OPTION IS NOT RECOMMENDED.) This option is useful if you are writing SPARK interpreter scripts on Unix/Linux/OS X and want to use:

#!/path/to/bin/spark -exec

at the top of your interpreter script to make it executable.

The difference between this option and the -s <script> option is small: in order to pass in arguments using the -s <script> option, you have to specify a module name first. The -exec script usage removes this restriction in order to make it easier to write executable interpreter scripts.

SPARK loads its process models from a directory called spark_modules. NOTE: your distribution may not contain this directory (for CALO developers this directory is calo-lsi/apps/desktop/external/spark_modules). In order to properly locate .spark files within this directory, there is a convention that is followed for the directory layout within spark_modules. For example, if you have a module named my_module, the directory layout would be:

spark_modules/
 |- my_module/
    |- doc/  (documentation directory)
    |- src/ 
       |- spark/
          |- my_module/
	     |- __init__.py
	     |- file.spark
	     |- file.py	     

Python files

Both SPARK-L and Python files are placed in the same directory. In the my_module example, file.py would have the Python module name 'my_module.file'.

Be sure to include an __init__.py file so that Python can locate your .py files.

Java files

• .java files: There currently is no standard for how to include .java source files within the spark_modules tree, though we recommend placing them in spark_modules/my_modules/src/java.
• .jar files: See the Including Java libraries section.

If you are developing your own SPARK modules, you can set the SPARK_MODULES environment variable to tell SPARK where your .spark files are located. IMPORTANT: you can only set the SPARK_MODULES environment variable to one location, do not try to append multiple paths to this variable. All of the spark modules you wish to include must be within the same spark_modules directory.

If your module is named 'foo.bar' and is stored in

c:\path\to\spark_modules\foo\src\spark\foo\bar.spark

c:\path\to\spark_modules

You can include jar files on the SPARK classpath by placing them in spark/lib/thirdparty_include. Any and all jar files in this directory will become part of the classpath, so please be careful to avoid conflicts.

ModuleError: For SPARK module foo - Cannot find module file 'foo{_spark.py,_spark.pyc,.spark}'

Cause: First, make sure that you typed the correct filename. If your .spark file is foo/bar.spark, then the module name for it is foo.bar. If this does not appear to be the problem, then the problem might be that either the PROCESS_HOME environment variable is not set correctly, or SSPROCESS_HOME in spark/bin/spark.bat is not set correctly. See the above section ('Setting PROCESS_HOME') for directions on how to configure it correctly.

'java' is not recognized as an internal or external command, operable program or batch file.

Cause: Java is not installed or the 'java' command is not on your system path.

ImportError: no module named threading

Cause: this error occurs if the value for JYTHON_HOME has not been set. It should point to the directory where jython is installed (Jython 2.2a0 or 2.2a1).

Exception in thread "main" java.lang.NoClassDefFoundError: org/python/util/jython

Cause: the JYTHON_HOME environment variable is not set, or is not set correctly. It should be pointing to the directory where jython is installed.

Usage: java [-options] class [args...] etc...

Cause: this error occurs on Windows if the value for JYTHON_HOME variable in your spark/bin/spark.bat ends with a '\'. Please remove the trailing '\'.