TL;DR
Install Postgres 9.5, and then:
sudo pg_dropcluster 9.5 main --stop
sudo pg_upgradecluster 9.3 main
sudo pg_dropcluster 9.3 main| #!/usr/bin/env swift | |
| // | |
| // PrintBootCampESDInfo.swift | |
| // | |
| // Created by nuomi1 on 8/5/18. | |
| // Copyright © 2018年 nuomi1. All rights reserved. | |
| // | |
| import Foundation |
TL;DR
Install Postgres 9.5, and then:
sudo pg_dropcluster 9.5 main --stop
sudo pg_upgradecluster 9.3 main
sudo pg_dropcluster 9.3 main04/26/2103. From a lecture by Professor John Ousterhout at Stanford, class CS142.
This is my most touchy-feely thought for the weekend. Here’s the basic idea: It’s really hard to build relationships that last for a long time. If you haven’t discovered this, you will discover this sooner or later. And it's hard both for personal relationships and for business relationships. And to me, it's pretty amazing that two people can stay married for 25 years without killing each other.
[Laughter]
> But honestly, most professional relationships don't last anywhere near that long. The best bands always seem to break up after 2 or 3 years. And business partnerships fall apart, and there's all these problems in these relationships that just don't last. So, why is that? Well, in my view, it’s relationships don't fail because there some single catastrophic event to destroy them, although often there is a single catastrophic event around the the end of the relation
| // | |
| // YPLayoutGuideHelper.m | |
| // | |
| // Created by Yuya Tanaka, 2015 | |
| // | |
| // This is free and unencumbered software released into the public domain. | |
| // Refer: http://unlicense.org/ | |
| // | |
| // automaticallyAdjustsScrollViewInsets doesn't work for child view controllers | |
| // hosted by something like Container View or UIPageViewController. |
| #include <stdio.h> | |
| #include <stdlib.h> | |
| #include <string.h> | |
| int addi(int a, int b) { | |
| return a + b; | |
| } | |
| char *adds(char *a, char *b) { | |
| char *res = malloc(strlen(a) + strlen(b) + 1); |
| #!/usr/bin/env bash | |
| # If your OS X WiFi connection stops working, but can be fixed by | |
| # toggling WiFi off and then on, this script can help prevent mouse arm. | |
| # Pings Apple's server repeatedly, toggling WiFi off/on when a connection times out. | |
| while true ; do | |
| curl --head --silent --connect-timeout 10 http://www.apple.com/my-wifi-keeps-dropping-out > /dev/null | |
| if [ $? -ne 0 ] ; then | |
| networksetup -setairportpower en1 off | |
| networksetup -setairportpower en1 on |
A running example of the code from:
This gist creates a working example from blog post, and a alternate example using simple worker pool.
TLDR: if you want simple and controlled concurrency use a worker pool.
When Swift was first announced, I was gratified to see that one of the (few) philosophies that it shared with Objective-C was that exceptions should not be used for control flow, only for highlighting fatal programming errors at development time.
So it came as a surprise to me when Swift 2 brought (What appeared to be) traditional exception handling to the language.
Similarly surprised were the functional Swift programmers, who had put their faith in the Haskell-style approach to error handling, where every function returns an enum (or monad, if you like) containing either a valid result or an error. This seemed like a natural fit for Swift, so why did Apple instead opt for a solution originally designed for clumsy imperative languages?
I'm going to cover three things in this post: