jckarter

( scratchpad ) \ + see-methods
USING: math math.private ;
M: bignum + bignum+ ; inline

USING: math math.complex.private ;
M: complex + [ + ] complex-op ; inline

USING: math math.private ;
M: fixnum + fixnum+ ; inline

jckarter

fml

The function manipulation language

"I just implemented Conway's Game of Life in two lines of code. #fml"

pad = x flip[stitch] 0, stitch 0, flip[cat] 0, cat 0
life = pad, neighborhoods[3 3], [ravel, [sum in?: [x @ 4, + 3; 3]]]/2

jckarter

diff -Nur -x 'macos_*' tbb40_20120613oss.orig/build/macos.clang-libcxx.inc tbb40_20120613oss/build/macos.clang-libcxx.inc
--- tbb40_20120613oss.orig/build/macos.clang-libcxx.inc	1969-12-31 16:00:00.000000000 -0800
+++ tbb40_20120613oss/build/macos.clang-libcxx.inc	2012-07-20 15:10:31.000000000 -0700
@@ -0,0 +1,11 @@
+include $(tbb_root)/build/macos.clang.inc
+
+LIBS += -stdlib=libc++
+CPLUS_FLAGS += -stdlib=libc++
+
+CPP11_FLAGS = -std=c++11 -D_TBB_CPP0X

jckarter

A package system for Factor

Factor's current module system and development model is heavily monolithic, reflecting Factor's history as a small-scale hobby project. The default settings encourage development within the Factor source tree and make it difficult to accommodate packaged read-only installations or projects developed outside of the source tree. Altering the module search path to accommodate these use cases is currently a manual and error-prone process. This proposal describes a new model for module lookup and installation with the following improvements:

• a standardized search path for modules, allowing for global, user-local, project-local, and

jckarter

#include <vector>

struct vec4 {
  float __attribute__((vector_size(16))) elts;
};

void putVec4(vec4 *out, const std::vector<float> &v) {
  *out = {{v[0], v[1], v[2], v[3]}};
}

jckarter

public class Property<T> {
  let getter: () -> T
  let setter: T -> ()
  
  public init(_ getter: () -> T, _ setter: T -> ()) {
    self.getter = getter
    self.setter = setter
  }
  
  public var value: T {

jckarter

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.