Author: Chris Lattner
#!/bin/bash | |
# Global build settings | |
export SDKPATH=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk | |
export SIMSDKPATH=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk | |
export MIN_IOS_VERSION=8.0 | |
export HOST=arm-apple-darwin | |
export LDFLAGS_NATIVE="-isysroot $SDKPATH" | |
export LDFLAGS_SIMULATOR="-isysroot $SIMSDKPATH" | |
export TASN1_CFLAGS="-Ilibtasn1/include" |
- Proposal: SE-XXXX
- Authors: Chris Lattner, Joe Groff
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.
[ Update 2025-03-24: Commenting is disabled permanently. Previous comments are archived at web.archive.org. ]
Most of the terminal emulators auto-detect when a URL appears onscreen and allow to conveniently open them (e.g. via Ctrl+click or Cmd+click, or the right click menu).
It was, however, not possible until now for arbitrary text to point to URLs, just as on webpages.
#!/bin/bash | |
# run_ios_sim builds and runs an iOS app on the simulator | |
# | |
# It is designed to replicate the behavior of "Run" in Xcode and assumes basic | |
# xcodebuild usage. | |
# | |
# USAGE: | |
# export IOS_SIM_UDID=342F9A20-DF48-41A9-BE60-C6B35F47E97F; \ | |
# export BUNDLE_IDENTIFIER=a.Some; \ | |
# export APP_PATH=$PWD/Build/Debug-iphonesimulator/$APP_NAME.app \ |
package main | |
import ( | |
"compress/gzip" | |
"fmt" | |
"io/ioutil" | |
"net/http" | |
"time" | |
"encoding/json" |
// check version | |
node -v || node --version | |
// list locally installed versions of node | |
nvm ls | |
// list remove available versions of node | |
nvm ls-remote | |
// install specific version of node |
- View: Also called a "template", a file that contains markup (like HTML) and optionally additional instructions on how to generate snippets of HTML, such as text interpolation, loops, conditionals, includes, and so on.
- View engine: Also called a "template library" or "templater", ie. a library that implements view functionality, and potentially also a custom language for specifying it (like Pug does).
- HTML templater: A template library that's designed specifically for generating HTML. It understands document structure and thus can provide useful advanced tools like mixins, as well as more secure output escaping (since it can determine the right escaping approach from the context in which a value is used), but it also means that the templater is not useful for anything other than HTML.
- String-based templater: A template library that implements templating logic, but that has no understanding of the content it is generating - it simply concatenates together strings, potenti
Based on Abdelrahman Omran PWA presentation, and Google PWA Codelab