mxcl

#!/usr/bin/swift sh
import Foundation
import PromiseKit  // @mxcl ~> 6.5
import Swifter     // @mattdonnelly == b27a89

let swifter = Swifter(
    consumerKey: "FILL",
    consumerSecret: "ME",
    oauthToken: "IN",
    oauthTokenSecret: "https://developer.twitter.com/en/docs/basics/apps/overview.html"

DougGregor

import Darwin

@dynamicMemberLookup
struct Environment {
  subscript(dynamicMember name: String) -> String? {
    get {
      guard let value = getenv(name) else { return nil }

      return String(validatingUTF8: value)
    }

pnc

#!/bin/bash

set -e

CONTENTS=$(tesseract -c language_model_penalty_non_dict_word=0.8 --tessdata-dir /usr/local/share/tessdata/ "$1" stdout -l eng | xml esc)

hex=$((cat <<EOF
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">

zats

javascript:document.getElementsByTagName('video')%5B0%5D.webkitEnterFullscreen()

lattner

Async/Await for Swift

• Proposal: SE-XXXX
• Authors: Chris Lattner, Joe Groff

Introduction

Modern Cocoa development involves a lot of asynchronous programming using closures and completion handlers, but these APIs are hard to use. This gets particularly problematic when many asynchronous operations are used, error handling is required, or control flow between asynchronous calls gets complicated. This proposal describes a language extension to make this a lot more natural and less error prone.

This paper introduces a first class Coroutine model to Swift. Functions can opt into to being async, allowing the programmer to compose complex logic involving asynchronous operations, leaving the compiler in charge of producing the necessary closures and state machines to implement that logic.

rentzsch

(*
OmniFocus Selected Mail Messages.applescript
	Copyright (c) 2015 Jonathan 'Wolf' Rentzsch: http://rentzsch.com
	Some rights reserved: http://opensource.org/licenses/mit
  
Pure AppleScript reimplementation of OmniGroup's Clip-o-Tron for OmniFocus.

Hopefully this implementation will be more resilient against OS X, Mail, and OmniFocus updates.
Successfully tested against OS X 10.10.1, OmniFocus 1.10.6, and OmniFocus 2.0.4.

alloy

The easiest way to start using the LLVM C++ API by example is to have LLVM generate the API usage for a given code sample. In this example it will emit the code required to rebuild the test.c sample by using LLVM:

$ clang -c -emit-llvm test.c -o test.ll
$ llc -march=cpp test.ll -o test.cpp

nicklockwood

Suppose we want to add support for a new iOS 8 API in our framework that replaces an older iOS 7 API. There are a few problems we might face:

1. The new API will crash if we call it on iOS 7
2. The new API won't compile if we build it using the iOS 7 SDK
3. The old API will raise a deprecation warning if built with a deployment target of iOS 8 and up

These three problems require three different technical solutions:

1. We can avoid calling the new API on an old OS version by using runtime detection (e.g. respondsToSelector:)
2. We can avoid compiling new APIs on old SDKs using the __IPHONE_OS_VERSION_MAX_ALLOWED macro

drewmccormack

// Dispatch
//
// Usage:
// Async dispatch to main queue
//     -->block
// Async dispatch to queue
//     queue --> block
// Sync dispatch to main queue
//     -->|block
// Sync dispatch to queue

steipete

#ifndef NS_DESIGNATED_INITIALIZER
#if __has_attribute(objc_designated_initializer)
#define NS_DESIGNATED_INITIALIZER __attribute((objc_designated_initializer))
#else
#define NS_DESIGNATED_INITIALIZER
#endif
#endif