Equipment

If you’ve made the slightly rash but equally rewarding decision to dive into developing the Swift language then make sure you have access to a fast computer with good, fast storage. What you don’t want to do is be running an old Mac mini using an old external hard drive because Apple hasn’t updated the mini line in a few forevers.

If your “About this Mac” panel looks like this, seriously question why you’re trying to do this in the first place. For the sake of uncomplicated narrative, I’m going to assume that just about everyone out there in the real world has a better Mac with better memory and primary disk than I do:

For those interested in the naming from these screen shots: Esopus Spitzenburg., Kiku, and Broxwood Firewhelp. I have others but I think those are the names you might see in screen shots and text examples. Hopefully this will be the first of several posts about the topic, in honor of Paul Cantrell.

Embrace the Wait

Before you can change the compiler, you must get the compiler downloaded, compiled, and working in its most recent form. For me, this is multi-day event. You probably will have slightly fewer roadblocks. Still, keep your day open and focus on other work as your Mac may or may not wind tunnel its way through the process.

Even after you’ve got your toolchain under control and build, you’ll continue to have many many waits in your development process as you’ll want to keep updating your repo to match the current state of Apple’s master and its supporting tools. Each time you do this, you can expect a morning of recompiling before you can start working on anything significant.

During this time, you cannot reasonably explore, test, and build unless you do so on a separate machine or for distinct installs. It’s a big pain in the ass but it’s part and parcel of developing the language.

If you plan to do this casually, and a week  has passed between the last pull from upstream/master and now, don’t expect to be productive until the afternoon at the earliest.

Although Swift’s toolset provides a quick iteration tool (called “Ninja”), that adds fast incremental builds, getting up to date and staying up to date means a large time commitment.

Further, don’t be shocked when your compiler or tools simply fail to build. They do that sometimes. It’s utterly frustrating to be stuck with a broken build for whatever reason. Incorporating workarounds into your toolset is a big part of swifting.

If you can’t embrace the wait, you don’t want to be developing swiftlang.

Selecting Xcode

Ensure that your default Xcode is set correctly. Use xcode-select -p to check which version is selected. If it isn’t your main app, use the utility to establish the right one. I use the production (not beta) version of Xcode:

sudo xcode-select -s /Applications/Xcode.app/Contents/Developer

Package Managers

Make sure you have a good package manager installed. I use Homebrew. I know there was some kind of controversy about that a while ago but I can’t remember why and it does the job for me.

Update your package manager to the most recent version:

brew update

If you run into any issues, you can do a full remove and re-install. These calls require bash and will misfire in csh/tcsh:

Uninstall Brew (removes all existing packages):

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/uninstall)"

Install:

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Get cmake and ninja

Grab a copy of cmake and ninja if you do not already have them installed on your system. CMake provides a cross-platform build/test/package solution that generates appropriate Make files, specialized to your environment. Ninja offers a speedy solution for incremental builds. It’s really fast, so once you’ve built out your libraries, you can go in and ninja swift for a really fast update when you’re doing edit/build/test cycles.

brew install cmake ninja

Go ahead and install sphinx now too. Sphinx “makes it easy to create intelligent and beautiful documentation” :

brew install sphinx

Notifications

Because of the long, long nature of setup and update process, consider some tools to help keep you on top of tasks, so you know when they finish and can move on to your next steps.

I use a command-line utility called noti to announce when each stage of downloading and compilation completes. Noti is an open source tools that triggers feedback as a command line process finishes.

You can have the utility speak, create a macOS system notification, and more. It’s helpful for when you’re running long tasks in background windows. Thanks goes to Scott Robbins for his recommendation.

To install noti, follow the directions in the repo’s Readme file. If you elect to curl a copy to your system, use bash, not csh (or in my case tcsh), for copy/pasting to your command line. The utility runs fine in tcsh but its escaping assumes bash is running.

Once installed, just prefix any command line command with noti followed by flags. I prefer using noti -b -s, which gives me both a banner alert and spoken text.

% noti --help
Usage:
  noti [flags] [utility [args...]]

Examples:
noti tar -cjf music.tar.bz2 Music/

Flags:
  -t, --title string     Set notification title. Default is utility name.
  -m, --message string   Set notification message. Default is "Done!".
  -b, --banner           Trigger a banner notification. This is enabled by default.
  -s, --speech           Trigger a speech notification.
  -c, --bearychat        Trigger a BearyChat notification.
  -i, --hipchat          Trigger a HipChat notification.
  -p, --pushbullet       Trigger a Pushbullet notification.
  -o, --pushover         Trigger a Pushover notification.
  -u, --pushsafer        Trigger a Pushsafer notification.
  -l, --simplepush       Trigger a Simplepush notification.
  -k, --slack            Trigger a Slack notification.
  -w, --pwatch int       Monitor a process by PID and trigger a notification when the pid disappears. (default -1)
  -f, --file string      Path to noti.yaml configuration file.
      --verbose          Enable verbose mode.
  -v, --version          Print noti version and exit.
  -h, --help             Print noti help and exit.

Fork Swift and Clone

Starting on Github, log into your account and then fork Apple’s Swift repo. Navigate to github.com/apple/swift, and click fork:

My fork uses my erica github account. Adjust the following directions accordingly so they correspond to your fork.

Hop over to a nice fast drive, and create a development directory. Enter the directory (cd swiftdev, for example) and clone the Swift repo:

git clone https://github.com/erica/swift.git

If you want to get a notification and time how long this took, your command may look like this:

noti -b -s time git clone https://github.com/erica/swift.git

I’ll skip the noti and time references from here on so they don’t clutter up these instructions. I like how time-ing gives you a sense of how long each task takes.

Install Supporting Utilities

Grab copies of the supporting utilities using the built-in update-checkout utility. There’s quite a few supporting folders that need to be built, including llvm, clang, and more. If you’re following these instructions, make sure you’re in the same top level directory as your swift install and not in the swift repo. Otherwise, adjust the path for the update-checkout to drop the initial swift:

% pwd
/Volumes/Kiku/Development
% ls
swift
% ./swift/utils/update-checkout --clone
Skipping clone of 'swift', directory already exists
Running ``obtain_additional_swift_sources`` with up to 8 processes.
Cloning 'compiler-rt'
Cloning 'llvm'
Cloning 'swift-xcode-playground-support'
Cloning 'swift-corelibs-foundation'
Cloning 'clang'
Cloning 'llbuild'
Cloning 'cmark'
Cloning 'lldb'

Now wait for everything to clone. There’s another way to clone using ssh, but I’ve never done it. I just know that it exists and is documented on Apple’s Swift repo Readme file.

Build

You should now be ready to perform a release build. I’m differing here from what’s recommended on Apple’s page because I got help early on from people who didn’t use that method. I’m sticking with my notes because they’re tried and trusted, not because I know what I’m doing.

% cd swift
% noti -s time utils/build-script -R

Building Swift (and, this first time, all its supporting utilities) is not…swift. So go do something else for a significantly long time. Unlike your initial Swift build and when you perform updates by pulling from Apple’s upstream master, incremental changes can be relatively quick. Getting things done the first time and after each update is long and tedious.

Test

If you’ve built things properly, you’ll find a newly build swift compiler waiting for you in the build folder. This directory is located at the top level of your development folder:

% ls

./                       lldb/
../                      llvm/
.DS_Store                ninja/
Hold/                    swift/ [1]
Notes.txt                swift-corelibs-foundation/
build/ [2]               swift-corelibs-libdispatch/
clang/                   swift-corelibs-xctest/
cmark/                   swift-integration-tests/
compiler-rt/             swift-xcode-playground-support/
llbuild/                 swiftpm/

Your cloned swift repo [1] sits along the build folder [2]. Navigate to build > Ninja-ReleaseAssert > swift-macosx-x86_64 > bin to find the swift executable. Check the modification date and run it with the -version flag to confirm it is the right build:

% ls -l build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swift 
-rwxr-xr-x  1 ericasadun  staff  96294356 Apr 30 09:23 build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swift*

% build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swift -version
Swift version 4.2-dev (LLVM bb2a4e8df7, Clang 56384a48b9, Swift 5f9bf115b3)
Target: x86_64-apple-darwin17.5.0

Go ahead and use it to compile a file. Use the path to this build to ensure you don’t accidentally use the default compiler:

% cd ~/Desktop/
% lns ~/github/apple/swift/build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swift swift
Created symbolic link at /Users/ericasadun/Desktop/swift
% echo 'print("Hello World")' > test.swift
% ./swift test.swift
Hello World

Conclusion

Getting your initial toolset built and running is the first step on the path to Swift evolution. Next up: ninja builds, creating branches, stashing differences, and managing test builds.

Some stride-related discussions took place on the forums today. I was inspired to play with strides as I took a break between my kids’ appointments. If any of this resonates with you as a potential user for it, let me know.

Index Strides

The following extension allows you to stride over a collection’s indices.

extension BidirectionalCollection where Index: Strideable {
    /// Returns the sequence of collection elements (`self[start]`,
    /// `self[start + stride]`, `self[start + 2 * stride]` ... *last*
    /// where *last* is the last element in the collection whose index
    /// is less than or equal to `end`.
    ///
    /// - Note: There is no guarantee that the element at index `end`
    ///   is part of the sequence
    ///
    /// - Parameter start: The starting index
    /// - Parameter end: The upper index bound
    /// - Parameter distance: The stride for each successive index
    /// - Returns: A lazy sequence of collection members
    public func stride(from start: Index, through end: Index, by distance: Index.Stride) -> LazyMapSequence<StrideThrough<Index>, Element> {
        return Swift.stride(from: start, through: end, by: distance)
            .lazy.map({ self[$0] })
    }
    
    /// Returns the sequence of collection elements (`self[start]`,
    /// `self[start + stride]`, `self[start + 2 * stride]` ... *last*
    /// where *last* is the last element in the collection whose index
    /// is strictly less than `end`.
    ///
    /// - Parameter start: The starting index
    /// - Parameter end: The upper index bound
    /// - Parameter distance: The stride for each successive index
    /// - Returns: A lazy sequence of collection members
    public func stride(from start: Index, to end: Index, by distance: Index.Stride) -> LazyMapSequence<StrideTo<Index>, Element> {
        return Swift.stride(from: start, to: end, by: distance)
            .lazy.map({ self[$0] })
    }
}

Here’s an example that uses this approach to form a sequence that strides through the collection:

let myArray = ["a", "b", "c", "d", "e", "f", "g", "h", "i", "j"]
for value in myArray.stride(from: 0, through: myArray.count, by: 3) {
    print(value) // a, d, g, j
}

Range Operators

The next snippet uses the division operator to create its stride. This was pitched by “Tony Y” in a forum thread.

extension CountableClosedRange {
    static func / (range: CountableClosedRange, divisor: Bound.Stride) -> StrideThrough<Bound> {
        let distance = range.distance(from: range.startIndex, to: range.endIndex) / divisor // deprecated
        return Swift.stride(from: range.lowerBound, through: range.upperBound, by: distance)
    }
}

In this example, you just “divide” the range:

for idx in (0 ... 100) / 5 {
    print(idx) // 0, 20, 40, 60, 80, 100
    // yes that's 6 not 5, but isn't that what 
    // you want? 5 subranges between each index?
}

Because I wrote this fairly quickly, I used the deprecated range.distance function as straight index arithmetic seemed to error:

error: binary operator '-' cannot be applied to two 'ClosedRangeIndex' operands
        let distance = (range.endIndex - range.startIndex) / divisor

As usual, I probably messed up somewhere (or several somewheres) or you might see ways I could improve the code. Let me know!

Update: After some thought, I decided I preferred a sequence of subranges (which should probably be a type and not like I do it here):

extension CountableClosedRange {
    static func / (range: CountableClosedRange, divisor: Bound.Stride) -> UnfoldSequence<CountableClosedRange<Bound>, (CountableClosedRange<Bound>?, Bool)> {
        let distance = range.distance(from: range.startIndex, to: range.endIndex) / divisor
        let rangeStride = Swift.stride(from: range.lowerBound, through: range.upperBound, by: distance)
        var indices = Array(rangeStride)
        indices.append(range.upperBound)
        indices.reverse()
        guard var current = indices.popLast(), var next = indices.popLast() else {
            fatalError("Guaranteed count failed in index population")
        }
        var done = false
        return sequence(first: current ... next.advanced(by: -1), next: { _ in
            guard !done else { return nil }
            (current, next) = (next, indices.popLast()!)
            if current == next {
                done = true
                return next ... next
            } else if next == range.upperBound && indices.isEmpty  {
                done = true
                return current ... next
            } else {
                return current ... next.advanced(by: -1)
            }
        })
    }
}

for idx in (0 ... 99) / 5 {
    print(idx) // 0...19, 20...39, 40...59, 60...79, 80...99
}

for idx in (0 ... 100) / 5 {
    print(idx) // 0...19, 20...39, 40...59, 60...79, 80...99, 100...100
}

This isn’t a debugged solution. For example, trying to divide 1 … 1 by 1 or 1 … 2 by 1 will both fail.

No.

// So I have a [String: [String]]
// Is there a way to do this without the force unwrapping?
if let _ = result[key] {
    result[key]!.append(decodedValue!)
} else {
    result[key] = [decodedValue!]
}

Yes.

if let decodedValue = decodedValue {
    result[key, default: []].append(decodedValue)
}

Commentary

Dictionaries now support default values (SE-0165 and SE-0154), but even if they didn’t, you could still use nil-coalescing without introducing the check on result’s lookup:

// a [String] type for the rhs is inferred by context
result[key] ?? []

The decodedValue should be handled through with either guard-let for early exit or if-let to unwrap then use. Since this kind of code often appears in loops, if may be the better choice, allowing each optional value to be tested and added.

If you are looping, consider applying a flatMap compactMap to your source array or using for case let, enabling you to unwrap and select your input:

for value in decodedValues.compactMap({ $0 }) { 
    result[key, default: []].append(value) 
}

for case let value? in decodedValues { 
    result[key, default: []].append(value) 
}

The two approaches are not significantly different, although I tend to lean towards the latter. It involves a single pass and I think it’s more elegant.