You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A result type (based on swiftz) that can represent either an error or success:
enum Result<X, T> {
case Err(() -> X)
case Ok(() -> T)
}
Now we need a way to chain multiple results together without lots of nesting of if statements -- or exceptions. To do so, we can define a new bind (result, next) operator (implementation borrowed from swiftz) that operates on Result types (a.k.a flatMap or >>=):
If the result is Err, the result is immediately returned.
Swift SIL as a compilation target? /Applications/Xcode6-Beta.app/Contents/Developer/usr/bin/xcrun swift -emit-silgen example.swift -module-name MyNameSpace
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A much nicer single-header XCTest-compatible testing DSL, all in a single header.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The follow-up I wrote for CocoaPods issue #1852 covers a lot of technical ground, but I also wanted to tackle the issue from a less crash reporting-focused perspective.
While I think the technical direction is interesting, and we're exploring some of these ideas in PLCrashReporter, it's easy to lose sight of the original goal -- ensuring that CocoaPod users can introduce library dependencies without concern that there are significant regressions in a given library or release.
In this area, I think that social and tool-driven hints are not only cheaper to implement, but would be just as powerful -- if not more so -- than a complex crash reporting system that can only find issues after they've already shipped.
If you look at automated build and dependency tooling on other platforms (in particular, I have Maven since that's what I'm familiar with, but these notions are hardly unique to the JVM language family),