## 1. Introduction

This is an introductory tutorial describing the use of Swift and its programming language SwiftScript. It is intended to introduce new users to the basics of Swift. It is structured as a series of simple exercises/examples which you can try for yourself as you read along.

For information on getting an installation of Swift running, consult the Swift Quickstart Guide. We advise you to install the latest stable release of Swift. Return to this document when you have successfully run the test SwiftScript program mentioned there.

There is also a Swift User Guide which contains a more detailed reference material on topics covered in this manual. All of the programs included in this tutorial can be found in your Swift distribution in the examples/tutorial directory.

## 2. Hello World

The first example program, hello.swift, outputs a hello world message into a file called hello.txt.

hello.swift

To run hello.swift, change directories to the location of the script and run the swift command as follows.

 Make sure the bin directory of your swift installation is in your PATH.
$cd examples/tutorial$ swift hello.swift
Swift svn swift-r3334 (swift modified locally) cog-r2752

RunID: 20100526-1925-8zjupq1b
Progress:
Final status:  Finished successfully:1
$cat hello.txt Hello, world! The basic structure of this program is a type definition, an application procedure definition, a variable definition and then a call to the procedure. First we define a new type, called messagefile. In this example, we will use this messagefile type for our output message. All data in SwiftScript must be typed, whether it is stored in memory or on disk. This example defines a very simple type. Later on we will see more complex type examples. Next we define a procedure called greeting. This procedure will write out the "hello world" message to a file. To achieve this, it executes the unix utility echo with a parameter "Hello, world!" and directs the standard output into the output file. The actual file to use is specified by the return parameter, t. Here we define a variable called outfile. The type of this variable is messagefile, and we specify that the contents of this variable will be stored on disk in a file called hello.txt Now we call the greeting procedure, with its output going to the outfile variable and therefore to hello.txt on disk. Over the following exercises, we’ll extend this simple hello world program to demonstrate various features of Swift. ## 3. Language features ### 3.1. Parameters Procedures can have parameters. Input parameters specify inputs to the procedure and output parameters specify outputs. Our hello world greeting procedure already uses an output parameter, t, which indicates where the greeting output will go. In this section, we will modify the previous script to add an input parameter to the greeting function. parameter.swift We have modified the signature of the greeting procedure to indicate that it takes a single parameter, s, of type string. We have modified the invocation of the echo utility so that it takes the value of s as a parameter, instead of the string literal "Hello, world!". We have modified the output file definition to point to a different file on disk. We have modified the invocation of greeting so that a greeting string is supplied. The code for this section can be found in parameter.swift. It can be invoked using the swift command, with output appearing in parameter.hello.txt: $ swift parameter.swift

Now that we can choose our greeting text, we can call the same procedure with different parameters to generate several output files with different greetings. The code is in manyparam.swift and can be run as before using the swift command.

manyparam.swift

Note that we can intermingle definitions of variables with invocations of procedures.

When this program runs, there should be three new files in the working directory (manyparam.english.txt, manyparam.francais.txt and manyparam.nihongo.txt) each containing a greeting in a different language.

In addition to specifying parameters positionally, parameters can be named, and if desired a default value can be specified.

Now we’ll define a new application procedure. The procedure we define will capitalise all the words in the input file.

To do this, we’ll use the unix tr (translate) utility. Here is an example of using tr on the unix command line, not using Swift:

$echo hello | tr '[a-z]' '[A-Z]' HELLO There are two main steps - updating the transformation catalog, and updating the application block. The transformation catalog lists where application executables are located on remote sites. We need to modify the transformation catalog to define a logical transformation for the tr utility. The transformation catalog can be found in etc/tc.data. There are already several entries specifying where executables can be found. Add a new line to the file, specifying where tr can be found (usually in /usr/bin/tr but it may differ on your system), like this: localhost tr /usr/bin/tr INSTALLED INTEL32::LINUX null For now, ignore all of the fields except the second and the third. The second field tr specifies a logical application name and the third specifies the location of the application executable. Now that we have defined where to find tr, we can use it in SwiftScript. We can define a new procedure, capitalise, which calls tr. We can call capitalise like this: Here is the full program based on this exercise: capitalise.swift Next, run swift and verify the output is correct. $ swift capitalise.swift
...
$dot -ograph.png -Tpng graph.dot graph.png can then be viewed using your favourite image viewer. The dot application is part of the graphViz project. More information can be found at http://www.graphviz.org. ### 4.2. Running on a remote site As configured by default, all jobs are run locally. In the previous examples, we’ve invoked echo and tr executables from our SwiftScript program. These have been run on the local system (the same computer on which you ran swift). We can also make our computations run on a remote resource. For more information on running Swift on a remote site please see the Site Configuration Guide. ### 4.3. Starting and restarting Now we’re going to try out the restart capabilities of Swift. We will make a workflow that will deliberately fail, and then we will fix the problem so that Swift can continue with the workflow. First we have the program in working form, restart.swift. restart.swift We must define some transformation catalog entries: localhost touch /usr/bin/touch INSTALLED INTEL32::LINUX null localhost broken /bin/true INSTALLED INTEL32::LINUX null Now we can run the program: $ swift restart.swift
Swift 0.9 swift-r2860 cog-r2388

RunID: 20100526-1119-3kgzzi15
Progress:
Final status:  Finished successfully:4

Four jobs run - touch, echo, broken and a final echo. (note that broken isn’t actually broken yet).

Now we will break the broken job and see what happens. Replace the definition in tc.data for broken with this:

localhost    broken     /bin/false   INSTALLED       INTEL32::LINUX  null

Now when we run the workflow, the broken task fails:

$swift restart.swift Swift 0.9 swift-r2860 cog-r2388 RunID: 20100526-1121-tssdcljg Progress: Progress: Stage in:1 Finished successfully:2 Execution failed: Exception in broken: Arguments: [process] Host: localhost Directory: restart-20100526-1121-tssdcljg/jobs/1/broken-1i6ufisj stderr.txt: stdout.txt: From the output we can see that touch and the first echo completed, but then broken failed and so swift did not attempt to execute the final echo. There will be a restart log with the same name as the RunID: $ ls *20100526-1121-tssdcljg*rlog
restart-20100526-1121-tssdcljg.0.rlog

This restart log contains enough information for swift to know which parts of the workflow were executed successfully.

We can try to rerun it immediately, like this:

$swift -resume restart-20100526-1121-tssdcljg.0.rlog restart.swift Swift 0.9 swift-r2860 cog-r2388 RunID: 20100526-1125-7yx0zi6d Progress: Execution failed: Exception in broken: Arguments: [process] Host: localhost Directory: restart-20100526-1125-7yx0zi6d/jobs/m/broken-msn1gisj stderr.txt: stdout.txt: Caused by: Exit code 1 Swift tried to resume the workflow by executing "broken" again. It did not try to run the touch or first echo jobs, because the restart log says that they do not need to be executed again. Broken failed again, leaving the original restart log in place. Now we will fix the problem with "broken" by restoring the original tc.data line that works. Remove the existing "broken" line and replace it with the successful tc.data entry above: localhost broken /bin/true INSTALLED INTEL32::LINUX null Now run again: $ swift -resume restart-20100526-1121-tssdcljg.0.rlog restart.swift

Swift 0.9 swift-r2860 cog-r2388

RunID: 20100526-1128-a2gfuxhg
Progress:
Final status:  Initializing:2  Finished successfully:2

Swift tries to run "broken" again. This time it works, and so Swift continues on to execute the final piece of the workflow as if nothing had ever gone wrong.

## 5. Bits

### 5.1. Named and optional parameters

In addition to specifying parameters positionally, parameters can be named, and if desired a default value can be specified:

default.swift