Moved PiedPiper to its own repo

.bundle/config

@@ -0,0 +1,3 @@
+---
+BUNDLE_PATH: /usr/local/bin
+BUNDLE_DISABLE_SHARED_GEMS: true

CHANGELOG.md

@@ -0,0 +1,55 @@
+# Changelog
+
+## 0.8
+
+**Breaking changes**
+- The codebase has been migrated to Swift 2.2
+- `Promise` now has only an empty `init`. If you used one of the convenience `init` (with `value:`, with `error:` or with `value:error:`), they now moved to `Future`.
+
+**New features**
+- Adds `value` and `error` properties to `Result`
+- Added a way to initialize `Future`s through closures
+- It's now possible to `map` `Future`s through:
+  - a simple transformation closure
+  - a closure that `throws`
+- It's now possible to `flatMap` `Future`s through:
+  - a closure that returns an `Optional`
+  - a closure that returns another `Future`
+  - a closure that returns a `Result`  
+- It's now possible to `filter` `Future`s through:
+  - a simple condition closure
+  - a closure that returns a `Future<Bool>`
+- It's now possible to `reduce` a `SequenceType` of `Future`s into a new `Future` through a `combine` closure 
+- It's now possible to `zip` a `Future` with either another `Future` or with a `Result`
+- Added `merge` to a `SequenceType` of `Future`s to collapse a list of `Future`s into a single one
+- Added `traverse` to `SequenceType` to generate a list of `Future`s through a given closure and `merge` them together
+- Added `recover` to `Future` so that it's possible to provide a default value the `Future` can use instead of failing
+- It's now possible to `map` `Result`s through:
+  - a simple transformation closure
+  - a closure that `throws`
+- It's now possible to `flatMap` `Result`s through:
+  - a closure that returns an `Optional`
+  - a closure that returns a `Future`
+  - a closure that returns another `Result`
+- It's now possible to `filter` `Result`s through a simple condition closure  
+- Added `mimic` to `Result`
+
+
+## 0.7
+
+First release of `Pied Piper` as a separate framework.
+
+**Breaking changes**
+- As documented in the `MIGRATING.md` file, you will have to add a `import PiedPiper` line everywhere you make use of Carlos' `Future`s or `Promise`s.
+
+**New features**
+- It's now possible to compose async functions and `Future`s through the `>>>` operator.
+- The implementation of `ReadWriteLock` taken from [Deferred](https://github.com/bignerdranch/Deferred) is now exposed as `public`.
+- It's now possible to take advantage of the `GCD` struct to execute asynchronous computation through the functions `main` and `background` for GCD built-in queues and `async` for GCD serial or custom queues.
+
+**Improvements**
+- `Promise`s are now safer to use with GCD and in multi-thread scenarios.
+
+**Fixes**
+- Fixes a bug where calling `succeed`, `fail` or `cancel` on a `Promise` or a `Future` didn't correctly release all the attached listeners.
+- Fixes a retain cycle between `Promise` and `Future` objects.

Cartfile.private

@@ -0,0 +1,2 @@
+github "Quick/Quick"
+github "Quick/Nimble"

Cartfile.resolved

@@ -0,0 +1,2 @@
+github "Quick/Nimble" "v4.0.1"
+github "Quick/Quick" "v0.9.2"

Carthage/Checkouts/Nimble/.gitignore

@@ -0,0 +1,19 @@
+.DS_Store
+xcuserdata/
+build/
+.idea
+DerivedData/
+Nimble.framework.zip
+
+# Carthage
+#
+# Add this line if you want to avoid checking in source code from Carthage dependencies.
+# Carthage/Checkouts
+
+Carthage/Build
+
+# Swift Package Manager
+#
+# Add this line if you want to avoid checking in source code from Swift Package Manager dependencies.
+# Packages/
+.build/

Carthage/Checkouts/Nimble/.swift-version

@@ -0,0 +1 @@
+DEVELOPMENT-SNAPSHOT-2016-02-25-a

Carthage/Checkouts/Nimble/.travis.yml

@@ -0,0 +1,18 @@
+osx_image: xcode7.3
+language: generic
+matrix:
+  include:
+    - os: osx
+      env: NIMBLE_RUNTIME_IOS_SDK_VERSION=9.0 TYPE=ios
+    - os: osx
+      env: NIMBLE_RUNTIME_OSX_SDK_VERSION=10.10 TYPE=osx
+    - os: osx
+      env: TYPE=swiftpm
+    - os: linux
+      dist: trusty
+      sudo: required
+      env: TYPE=swiftpm
+install:
+  - if [[ "$TYPE" == "swiftpm" ]]; then eval "$(curl -sL https://gist.githubusercontent.com/kylef/5c0475ff02b7c7671d2a/raw/02090c7ede5a637b76e6df1710e83cd0bbe7dcdf/swiftenv-install.sh)"; fi
+script:
+  - ./test $TYPE

Carthage/Checkouts/Nimble/CONTRIBUTING.md

@@ -0,0 +1,113 @@
+<!-- START doctoc generated TOC please keep comment here to allow auto update -->
+<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
+
+- [Welcome to Nimble!](#welcome-to-nimble!)
+  - [Reporting Bugs](#reporting-bugs)
+  - [Building the Project](#building-the-project)
+  - [Pull Requests](#pull-requests)
+    - [Style Conventions](#style-conventions)
+  - [Core Members](#core-members)
+    - [Code of Conduct](#code-of-conduct)
+
+<!-- END doctoc generated TOC please keep comment here to allow auto update -->
+
+# Welcome to Nimble!
+
+We're building a testing framework for a new generation of Swift and
+Objective-C developers.
+
+Nimble should be easy to use and easy to maintain. Let's keep things
+simple and well-tested.
+
+**tl;dr:** If you've added a file to the project, make sure it's
+included in both the OS X and iOS targets.
+
+## Reporting Bugs
+
+Nothing is off-limits. If you're having a problem, we want to hear about
+it.
+
+- See a crash? File an issue.
+- Code isn't compiling, but you don't know why? Sounds like you should
+  submit a new issue, bud.
+- Went to the kitchen, only to forget why you went in the first place?
+  Better submit an issue.
+
+Be sure to include in your issue:
+
+- Your Xcode version (eg - Xcode 7.0.1 7A1001)
+- Your version of Nimble (eg - v2.0.0 or git sha `20a3f3b4e63cc8d97c92c4164bf36f2a2c9a6e1b`)
+- What are the steps to reproduce this issue?
+- What platform are you using? (eg - OS X, iOS, watchOS, tvOS)
+- If the problem is on a UI Testing Bundle, Unit Testing Bundle, or some other target configuration
+- Are you using carthage or cocoapods?
+
+## Building the Project
+
+- Use `Nimble.xcodeproj` to work on Nimble.
+
+## Pull Requests
+
+- Nothing is trivial. Submit pull requests for anything: typos,
+  whitespace, you name it.
+- Not all pull requests will be merged, but all will be acknowledged. If
+  no one has provided feedback on your request, ping one of the owners
+  by name.
+- Make sure your pull request includes any necessary updates to the
+  README or other documentation.
+- Be sure the unit tests for both the OS X and iOS targets of Nimble
+  before submitting your pull request. You can run all the OS X & iOS unit
+  tests using `./test`.
+- If you've added a file to the project, make sure it's included in both
+  the OS X and iOS targets.
+- The `master` branch will always support the stable Xcode version. Other
+  branches will point to their corresponding versions they support.
+- If you're making a configuration change, make sure to edit both the xcode
+  project and the podspec file.
+
+### Style Conventions
+
+- Indent using 4 spaces.
+- Keep lines 100 characters or shorter. Break long statements into
+  shorter ones over multiple lines.
+- In Objective-C, use `#pragma mark -` to mark public, internal,
+  protocol, and superclass methods.
+
+## Core Members
+
+If a few of your pull requests have been merged, and you'd like a
+controlling stake in the project, file an issue asking for write access
+to the repository.
+
+### Code of Conduct
+
+Your conduct as a core member is your own responsibility, but here are
+some "ground rules":
+
+- Feel free to push whatever you want to master, and (if you have
+  ownership permissions) to create any repositories you'd like.
+
+  Ideally, however, all changes should be submitted as GitHub pull
+  requests. No one should merge their own pull request, unless no
+  other core members respond for at least a few days.
+
+  If you'd like to create a new repository, it'd be nice if you created
+  a GitHub issue and gathered some feedback first.
+
+- It'd be awesome if you could review, provide feedback on, and close
+  issues or pull requests submitted to the project. Please provide kind,
+  constructive feedback. Please don't be sarcastic or snarky.
+
+### Creating a Release
+
+The process is relatively straight forward, but here's is a useful checklist for tagging:
+
+- Look at changes from the previously tagged release and write release notes: `git log v0.4.0...HEAD`
+- Run the release script: `./script/release A.B.C release-notes-file`
+- Go to [github releases](https://github.com/Quick/Nimble/releases) and mark the tagged commit as a release.
+  - Use the same release notes you created for the tag, but tweak up formatting for github.
+  - Attach the carthage release `Nimble.framework.zip` to the release.
+- Update [Quick](https://github.com/Quick/Quick)
+  - Update Quick's submodule reference to the newly released Nimble version
+  - Update Nimble version in `README.md` and Documentation in [Quick](https://github.com/Quick/Quick) if it's not a patch version update.
+- Announce!