harlanhaskins

import Foundation

/// `StringScanner` is a fast scanner for Strings and String-like objects.
/// It's used to extract structured bits from unstructured strings, while
/// avoiding making extra copies of string bits until absolutely necessary.
/// You can build Scanners over Substrings, allowing you to scan
/// parts of strings and use smaller, more specialized scanners to extract bits
/// of that String without needing to reuse another scanner.
public struct StringScanner<Input: StringProtocol> {
  let input: Input

ahoppen

Swift incremental syntax parsing

This proposal aims to add an incremental syntax parsing mode to the Swift compiler that takes a syntax tree of a pre-edit file, a post-edit file, and a diff between the pre-edit and the post-edit file as its input. It then generates the libSyntax tree of the modified file based on this information.

Motivation

In order to be able to use libSyntax for syntax colouring in IDEs, libSyntax needs to be able to rapidly regenerate the syntax tree based on minor edits. A complete reparse of the file is not acceptable. This proposal adds an incremental syntax parsing mode to the compiler that is able to rearrange on old syntax tree based on minor edits that have been performed on the source file.

The goal is that this incremental compilation is (nearly) in O(1) in terms of the size of the original source file so that the delay for regenerating syntax colouring after a single edit is independent of the file's size.

JALsnipe

//
//  crc32.swift
//  SuperSFV
//
//  Created by C.W. Betts on 8/23/15.
//
//
/* crc32.swift -- compute the CRC-32 of a data stream
 Copyright (C) 1995-1998 Mark Adler
 Copyright (C) 2015 C.W. "Madd the Sane" Betts

modocache

 $ lldb -- ../build/Ninja-DebugAssert/swift-macosx-x86_64/bin/swiftc -dump-parse ~/GitHub/tmp/hello.swift
(lldb) target create "../build/Ninja-DebugAssert/swift-macosx-x86_64/bin/swiftc"
Current executable set to '../build/Ninja-DebugAssert/swift-macosx-x86_64/bin/swiftc' (x86_64).
(lldb) settings set -- target.run-args  "-dump-parse" "/Users/bgesiak/GitHub/tmp/hello.swift"
(lldb) process launch --stop-at-entry
Process 91478 stopped
* thread #1: tid = 0x1bd329, 0x00007fff5fc01000 dyld`_dyld_start, stop reason = signal SIGSTOP
    frame #0: 0x00007fff5fc01000 dyld`_dyld_start
dyld`_dyld_start:
->  0x7fff5fc01000 <+0>: popq   %rdi

johannrichard

# Defaults / Configuration options for homebridge
# The following settings tells homebridge where to find the config.json file and where to persist the data (i.e. pairing and others)
HOMEBRIDGE_OPTS=-U /var/lib/homebridge

# If you uncomment the following line, homebridge will log more 
# You can display this via systemd's journalctl: journalctl -f -u homebridge
# DEBUG=*

rnapier

import Foundation

// Why bytesView rather than just extending NSData directly?
// Because this way we can keep our extension internal and not conflict
// with someone who imports us and has also extended NSData.
// If you're top-level code, you can just hoist everyting up to NSData directly.
internal extension NSData {
    var bytesView: BytesView { return BytesView(self) }
}

chrislavender

Note: This is an older post that I did back when I thought I might have time to be a blogger. Oh I was oh so wrong. However, it has proven useful for some folks on stackoverflow. Thus I'm keeping it alive here on Gist.

One of my past projects dealt heavily with an open source Apple technology called HTTP Live Streaming. It’s an HTTP based streaming protocol that at its most fundamental level provides a way to stream video and audio from just about any server with nothing but a few free software tools provided by Apple**. However, it has a few additional features that I think make it a really exciting tool. Yet, I haven’t seen HTTP Live Streaming used very much. This is probably mainly due to the combination of a lack of good/clear documentation, and Apple’s Live Streaming Developer Tools being command line based also make the barrier to entry higher than many developers want to deal with.

The hope is to share my understanding of how to use this technology to:

jhermann

Useful emoji for git commit messages

If you add emoji to your commit messages for a GitHub repo, they become less boring, and you can convey the kind of change you're adding. See the full set of GitHub supported emoji here (also useful for easy copy&paste via a simple click).

The following is a possible scheme to use:

dedy-purwanto

# There was a day where I have too many color schemes in iTerm2 and I want to remove them all.
# iTerm2 doesn't have "bulk remove" and it was literally painful to delete them one-by-one.

# iTerm2 save it's preference in ~/Library/Preferences/com.googlecode.iterm2.plist in a binary format
# What you need to do is basically copy that somewhere, convert to xml and remove color schemes in the xml files.

$ cd /tmp/
$ cp ~/Library/Preferences/com.googlecode.iterm2.plist .
$ plutil -convert xml1 com.googlecode.iterm2.plist
$ vi com.googlecode.iterm2.plist

Integralist

define(['require'], function(require) {
    var stubbed = [];
    return {
        stub: function(name, implementation) {
            stubbed.push(name);
            requirejs.undef(name);
            define(name, [], function() {
                return implementation;
            });
        },